From lemonade-bounces@ietf.org Tue Aug 01 02:45:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7nzv-00034v-3p; Tue, 01 Aug 2006 02:44:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7nzs-00034i-QN for lemonade@ietf.org; Tue, 01 Aug 2006 02:44:56 -0400 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7nzr-0006ML-AB for lemonade@ietf.org; Tue, 01 Aug 2006 02:44:56 -0400 Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.3]) by smarthost.yourcomms.net (8.11.7p1+Sun/8.11.6) with ESMTP id k716Wo623266 for ; Tue, 1 Aug 2006 07:32:54 +0100 (BST) 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, 1 Aug 2006 07:42:58 +0100 Message-ID: <22C8A0D5D5E095449AB509FE777B5F80029DE3AC@svr-exchange.avocado.emccsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Notifications for multiple devices per user Thread-Index: Aca0tusCVa8zkGelRPCkrZd/5eNX1QAfXXwQ From: "Ben Last" To: "Mark Crispin" X-Spam-Score: 0.0 (/) 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 On 31 July 2006 16:35, Mark Crispin wrote: >On Mon, 31 Jul 2006, Ben Last wrote: >> Thus we have no >> reliable way to identify the Trash (or Outbox, or Sent folders)=20 >> created by other IMAP clients. Has there been discussion on this? >One simple answer is "don't use a Trash mailbox, use the native IMAP delete/expunge model instead." Thanks, Mark: an excellent point, and we do indeed use that model. However, the server that's our primary development target provides a webmail interface that creates its own "Deleted Items", "Sent Items" and "Drafts" folders. Thus there are strong suggestions that our client should use these. But since our client, as one might expect, is a generic P-IMAP one, we don't want to hard-wire in folder names, especially since (as I mentioned) these folder names are subject to localization, customization and user-modification. >For me, the razor of the quality of an IMAP client implemention is whether or not it uses a Trash mailbox. If it does, it is poor-quality by [my] definition. I understand your argument, but there are clients out there that do this, and mobile LEMONADE-speaking clients such as ours must interoperate with them. >The need to identify a sent-message mailbox is a different matter, provided that we agree upon a firm, immutable definition of what constitutes a sent-message mailbox >with no wiggle-room for fools to create non-interoperable situations. ACAP was supposed to solve that problem... Is there not a more general requirement; to be able to identify certain "special-case" folders? Some clients use a "Drafts/Sent" model, others an "Drafts/Outbox/Sent" model. Being able, from the results of a variant of LIST, for example, to identify these folders by type, not name, would make client development and interoperability with existing clients much easier. And whether one deprecates a Trash folder or not, if a PC client creates it and other clients can identify it, then at least they have the option to use it! The same mechanism (some unambiguous way to identify folders without basing it on names) could go some way to avoiding the huge re-downloading cost of renaming or moving a folder. Best regards to all Ben _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Aug 01 05:37:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7qhI-0006Em-C2; Tue, 01 Aug 2006 05:37:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7qXa-0008QP-8m for lemonade@ietf.org; Tue, 01 Aug 2006 05:27:54 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7qXX-0001TH-Ob for lemonade@ietf.org; Tue, 01 Aug 2006 05:27:54 -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 k719RlTt009072; Tue, 1 Aug 2006 12:27:47 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Aug 2006 12:27:47 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Aug 2006 12:27: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: Tue, 1 Aug 2006 12:27:17 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657A1B430@esebe199.NOE.Nokia.com> In-Reply-To: <44CE5D7F.10303@att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Notifications for multiple devices per user Thread-Index: Aca02cxueTRYBQUMRVCb5gUwP+E4HwAcXvQw From: To: , X-OriginalArrivalTime: 01 Aug 2006 09:27:47.0193 (UTC) FILETIME=[C01D5E90:01C6B54C] X-Spam-Score: 0.2 (/) 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 Hi all, I would like to express my support on "define an standardized list of = Annotations for this and other such "special" mailboxes". Identifying the special folders does not mean that they are going to be = used in every implementation, while it gives the benefit of knowing = what/where are those "special" mailboxes as well as helps a lot with = localization issues. I think the following "special" mailboxes should be identified: Trash: to store emails that have been deleted by the user - but not = marked as deleted yet e.g. expunge won't purge them. Calendar: to store emails that contain vCalendar or other content that = includes calendar information. Contacts: to store emails that contain vCard or other content that = includes contact information. Drafts: to store emails that the user composed but did not send yet. Junk: to store emails that the server decided to isolate. Sent: to store emails that the use has sent. I understand Draft, Trash, Junk and Sent would be the most often used = ones, while Contacts and Calendar would be used less often. What do You think? Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 -----Original Message----- From: ext Tony Hansen [mailto:tony@att.com]=20 Sent: 31 July, 2006 22:44 To: lemonade@ietf.org Subject: Re: [lemonade] Notifications for multiple devices per user Mark Crispin wrote: > The above is my opinion, and may not be shared by others. But I have=20 > a right to my opinion. >=20 > The need to identify a sent-message mailbox is a different matter,=20 > provided that we agree upon a firm, immutable definition of what=20 > constitutes a sent-message mailbox with no wiggle-room for fools to=20 > create non-interoperable situations. ACAP was supposed to solve that=20 > problem... Can we define an standardized list of Annotations for this and other = such "special" mailboxes? Tony Hansen tony@att.com _______________________________________________ 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 Aug 01 05:37:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7qhL-0006Ki-Tq; Tue, 01 Aug 2006 05:37:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7qZH-0002x6-W0 for lemonade@ietf.org; Tue, 01 Aug 2006 05:29:40 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7qZG-0001oi-FL for lemonade@ietf.org; Tue, 01 Aug 2006 05:29:39 -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 k719TVUR014432; Tue, 1 Aug 2006 12:29:32 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Aug 2006 12:29:30 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Aug 2006 12:29: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] Notifications for multiple devices per user Date: Tue, 1 Aug 2006 12:29:01 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657A1B435@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: Aca01hnYJe1xc0RLQFeYghB+xMJ9BAAdqvNg From: To: X-OriginalArrivalTime: 01 Aug 2006 09:29:30.0550 (UTC) FILETIME=[FDB86560:01C6B54C] X-Spam-Score: 0.2 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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 Mark, Yes, this is certainly a good opinion, however it does not solve the = problem of identifying the special mailboxes.=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 Mark Crispin [mailto:mrc@CAC.Washington.EDU]=20 Sent: 31 July, 2006 18:35 To: Ben Last Cc: lemonade@ietf.org Subject: RE: [lemonade] Notifications for multiple devices per user On Mon, 31 Jul 2006, Ben Last wrote: > Thus we have no > reliable way to identify the Trash (or Outbox, or Sent folders)=20 > created by other IMAP clients. Has there been discussion on this? One simple answer is "don't use a Trash mailbox, use the native IMAP = delete/expunge model instead." For me, the razor of the quality of an IMAP client implemention is = whether or not it uses a Trash mailbox. If it does, it is poor-quality = by [my] definition. It indicates an unimaginative client author who = expects data in a store to implement and mirror GUI artifacts. Such = individuals tend to do things like "hmm, it says here that the * = wildcard is harmful and should be avoided. OK, I will a %/% wildcard, = and walk the tree manually with multiple LIST commands." I find it amusing that the same working group that is so obsessed with = minimizing downloads would even consider a Trash mailbox, given the = enormous costs that it imposes. Specifically, unlike the native IMAP = delete/expunge model, there is no way in Trash to undelete a message = without creating a completely new instance of the message in the = mailbox. The above is my opinion, and may not be shared by others. But I have a = right to my opinion. The need to identify a sent-message mailbox is a different matter, = provided that we agree upon a firm, immutable definition of what = constitutes a sent-message mailbox with no wiggle-room for fools to = create non-interoperable situations. ACAP was supposed to solve that = problem... -- 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 Tue Aug 01 06:20:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7rMA-0008A7-KH; Tue, 01 Aug 2006 06:20:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7rM9-00089g-FL for lemonade@ietf.org; Tue, 01 Aug 2006 06:20:09 -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 1G7qk9-0003JN-Jd for lemonade@ietf.org; Tue, 01 Aug 2006 05:40:53 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G7qdc-0006m8-9Z for lemonade@ietf.org; Tue, 01 Aug 2006 05:34:09 -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 k719Y3AE012996; Tue, 1 Aug 2006 12:34:04 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Aug 2006 12:34:03 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Aug 2006 12:34: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: Tue, 1 Aug 2006 12:33:33 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657A1B440@esebe199.NOE.Nokia.com> In-Reply-To: <6137.1154383678.599309@invsysm1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Notifications for multiple devices per user Thread-Index: Aca07e5kupBQoGkzRtuS9IQnQycGTQAXy9og From: To: X-OriginalArrivalTime: 01 Aug 2006 09:34:03.0384 (UTC) FILETIME=[A0578F80:01C6B54D] X-Spam-Score: -1.6 (-) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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, There are some disadvantages listed in this draft. Earlier I suggested to standardize a MOVE command, but it has been = turned down for some reason - however moving emails from one mailbox to = another (like inbox to trash) would be just the perfect candidate to = support it. So, if the LEMONADE profile were to add a MOVE command, You could strike = though a few disadvantages in the IMAP TRASH draft.=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: 01 August, 2006 01:07 To: Mark Crispin Cc: Enhancements to Internet email to support diverse service = enivronments Subject: RE: [lemonade] Notifications for multiple devices per user On Mon Jul 31 16:34:44 2006, Mark Crispin wrote: > On Mon, 31 Jul 2006, Ben Last wrote: >> Thus we have no >> reliable way to identify the Trash (or Outbox, or Sent folders)=20 >> created by other IMAP clients. Has there been discussion on this? >=20 > One simple answer is "don't use a Trash mailbox, use the native IMAP=20 > delete/expunge model instead." >=20 >=20 http://dave.cridland.net/draft-cridland-imap-trash.txt (Which was sufficiently contentious that I've not submitted, but will do = if there's demand). > The need to identify a sent-message mailbox is a different matter,=20 > provided that we agree upon a firm, immutable definition of what=20 > constitutes a sent-message mailbox with no wiggle-room for fools to=20 > create non-interoperable situations. ACAP was supposed to solve that=20 > problem... I think you're oversimplifying the problem in any case - there's two problems: The first relates to the difficulty in identifying the difference = between a message you intend to send (perhaps assembling it on the = server with CATENATE) and one that actually has been successfully sent. = Whether all the messages in the same category happen to be in a specific = mailbox or not is another matter. The second relates to interoperable configuration between clients, such = that different clients automatically reflect the user's stated = preferences. This is the problem that was solved by ACAP very well = nearly a decade ago, a solution which I happily use every time I send a = message. 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 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Aug 01 07:12:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7sAW-0003O1-5s; Tue, 01 Aug 2006 07:12:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7sAU-0003Nm-G7 for lemonade@ietf.org; Tue, 01 Aug 2006 07:12:10 -0400 Received: from smtp-out.sendmail.com ([209.246.26.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7sAS-0002Ee-3a for lemonade@ietf.org; Tue, 01 Aug 2006 07:12:10 -0400 Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.2.3/Switch-3.2.0) with ESMTP id k71B73Qs005621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Aug 2006 04:07:04 -0700 X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com k71B73Qs005621 DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1154430430; bh=5Tz/3RDVQiFkTvuJ8X8JMrm8pEg=; h=X-DomainKeys: DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:In-Reply-To: Message-ID:References:MIME-Version:Content-Type; b=YWqVoGWDPL/eA6GZ SL0z0G4/Iq5KEKrodTmdQGw2AGuCD74ABcnyd64IKWoCc97IJ+4sSgfI4WTeUioPY9S W4j9qEwSLASPHTSSzH1VPN/aQaITadwURlMe/CSlwujNlUBaKc+q3YZXwtmmGcZ00o0 nHMVFRj/rm4Svx7iO1D14= X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com k71B73Qs005621 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type; b=QQCtwY26IwHaT+SfUHB9MkuhJMBCn4oA5DKTlXD3vQq4i1Y125Fr7L75oU3yG8Xar JhQ0Oqu/sw3jRBN8vew9WNN48IRtFJ9I4//1OcEG50GbGAssM4VHMcWaMIq6vyIdbF/ 0vZ1pnUUhEhg2kkaYzuYteNX4K9D35kKij5K564= Date: Tue, 1 Aug 2006 04:07:03 -0700 From: Philip Guenther X-X-Sender: guenther@lab.smi.sendmail.com To: Zoltan.Ordogh@nokia.com Subject: RE: [lemonade] Notifications for multiple devices per user In-Reply-To: <0FA975F2D8295A448BE3ADC161244657A1B440@esebe199.NOE.Nokia.com> Message-ID: <20060801033941.T26250@lab.smi.sendmail.com> References: <0FA975F2D8295A448BE3ADC161244657A1B440@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 1.3 (+) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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, 1 Aug 2006, Zoltan.Ordogh@nokia.com wrote: > There are some disadvantages listed in this draft. Earlier I suggested > to standardize a MOVE command, but it has been turned down for some > reason "Some reason"? I seem to recall a number of responses describing implementation problems and questioning the benefits. > - however moving emails from one mailbox to another (like inbox to > trash) would be just the perfect candidate to support it. So, if the > LEMONADE profile were to add a MOVE command, You could strike though a > few disadvantages in the IMAP TRASH draft. But which disadvantages does it remove, the easy ones or the hard ones? As far as I can tell, it doesn't solve any of the hard ones on Dave's list. Yes, it solves the quota problem, but only for servers where quotas strictly follow the QUOTA extension and not those based on actual filesystem quotas. Dave, here's another item for your I-D: in the native method, both steps are atomic and idempotent; in the Trash mailbox method, the mark+copy+ expunge process is neither atomic nor idempotent. This means that concurrent clients may result in multiple copies of a message in the Trash mailbox. (I've seen a client where each time you hit the delete button, it would open a new session to the mailbox and use that to do the mark+copy+ expunge. That's not a bad idea, except that if you hit the delete button more than once then it would open multiple sessions, each session 'moving' the *same* messages to the Trash mailbox.) Hmm, weren't you going to add a bit about quotas and how Trash mailboxes interact poorly with them? Philip Guenther _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Aug 01 07:37:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7sZ8-0007NA-T7; Tue, 01 Aug 2006 07:37:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7sZ7-0007Mx-C4 for lemonade@ietf.org; Tue, 01 Aug 2006 07:37:37 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7sZ5-00042g-Rz for lemonade@ietf.org; Tue, 01 Aug 2006 07:37:37 -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 k71BbYRD006145; Tue, 1 Aug 2006 14:37:34 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Aug 2006 14:37:33 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Aug 2006 14:37:33 +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, 1 Aug 2006 14:37:04 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657A1B556@esebe199.NOE.Nokia.com> In-Reply-To: <20060801033941.T26250@lab.smi.sendmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Notifications for multiple devices per user Thread-Index: Aca1WsP84IkQXIYKTV2a1te60yBokgAAeVjA From: To: X-OriginalArrivalTime: 01 Aug 2006 11:37:33.0569 (UTC) FILETIME=[E1280F10:01C6B55E] X-Spam-Score: 1.4 (+) 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 Hi Philip, Please find my responses inline, tagged with [Z=D6r]. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 -----Original Message----- From: ext Philip Guenther [mailto:guenther+lemonade@sendmail.com]=20 Sent: 01 August, 2006 14:07 To: Ordogh Zoltan (Nokia-TP-MSW/Tampere) Cc: dave@cridland.net; lemonade@ietf.org Subject: RE: [lemonade] Notifications for multiple devices per user On Tue, 1 Aug 2006, Zoltan.Ordogh@nokia.com wrote: > There are some disadvantages listed in this draft. Earlier I suggested = > to standardize a MOVE command, but it has been turned down for some=20 > reason "Some reason"? I seem to recall a number of responses describing = implementation problems and questioning the benefits. [Z=D6r] Yes, I did not want to quote the entire discussion here - I call = it some reason because I disagree: I believe that it does add value and = implementation problems are a good thing - they force a better = architecture in the long run - so we should address this. Also, the = command was suggested to be optional so it should not cause any problems = for those unwilling to implement it. So that implementation problem You = mention I only see as a minor problem in exchange for a much bigger = benefit (think about mobile phones having to copy mails: download, = upload, extra roundtrips) . But that's about it, I do not wish to open = this discussion again (yet). > - however moving emails from one mailbox to another (like inbox to=20 > trash) would be just the perfect candidate to support it. So, if the=20 > LEMONADE profile were to add a MOVE command, You could strike though a = > few disadvantages in the IMAP TRASH draft. But which disadvantages does it remove, the easy ones or the hard ones?=20 As far as I can tell, it doesn't solve any of the hard ones on Dave's=20 list. Yes, it solves the quota problem, but only for servers where = quotas=20 strictly follow the QUOTA extension and not those based on actual=20 filesystem quotas. [Z=D6r] This is in the draft: 4.1. Advantages This is more familiar to users of desktop operating systems. 4.2. Disadvantages It is less efficient, using multiple round-trips. It is impossible to accurately reverse the first stage of the metaphor - doing so requires the client to copy the message back, which issues it with a new UID, and can alter the message's position in the display. For shared mailboxes, deleted messages are generally moved to a personal trash folder. It relies for safety on the UIDPLUS extension defined in [RFC4315] - servers not implementing this extension, or not supporting it for the mailboxes involved, will cause additional downloads and potentially inadvertant irrevocable deletions. It is not interoperable - aside from the issues noted above, there is no mechanism for denoting a trash mailbox, and many clients vary the name used. The disadvantage the MOVE command would remove is the first one shown = above: no need for multiple roundtrips to copy an email and remove the = original (plus, the UID would be kept so it would not be downloaded = again to the client). Also, I suspect it would address the third one = about UIDPLUS and the last one as well. So, only the second one would remain - which I believe is not a real = problem because You indicate where to move the emails, so You can move = it to any mailbox You wish. While at it, I believe that there is an additional advantage of using = Trash mailbox: to have the emails organized better - the deleted mails = do not mix with the ones that one wants to keep there, making it easier = to find emails (besides then searched would not be performed on deleted = emails either which means performance boost). _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Aug 01 11:08:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7vqx-0006io-6W; Tue, 01 Aug 2006 11:08:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7vqv-0006id-HR for lemonade@ietf.org; Tue, 01 Aug 2006 11:08:13 -0400 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7vqu-0000bB-27 for lemonade@ietf.org; Tue, 01 Aug 2006 11:08:13 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.50) id 1G7vqt-0001JJ-94; Tue, 01 Aug 2006 15:08:11 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id DC7B5498003; Tue, 1 Aug 2006 16:12: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 00642-09; Tue, 1 Aug 2006 16:12:36 +0100 (BST) Received: from invsysm1 (shiny.isode.com [62.3.217.250]) by turner.dave.cridland.net (Postfix) with ESMTP id 8A8E2498002; Tue, 1 Aug 2006 16:12:36 +0100 (BST) Date: Tue, 01 Aug 2006 16:07:45 +0100 References: <0FA975F2D8295A448BE3ADC161244657A1B556@esebe199.NOE.Nokia.com> In-Reply-To: <0FA975F2D8295A448BE3ADC161244657A1B556@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Message-Id: <5827.1154444868.252985@invsysm1> From: Dave Cridland To: "Zoltan.Ordogh@nokia.com" Content-Type: text/plain; charset="iso-8859-1"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net Content-Transfer-Encoding: quoted-printable X-Originating-Heisenberg-IP: [217.155.137.60] X-Spam-Score: 0.5 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Enhancements to Internet email to support diverse service enivronments Subject: [lemonade] Trash and MOVE X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 Aug 1 12:37:04 2006, Zoltan.Ordogh@nokia.com wrote: > [Z=D6r] This is in the draft: I should clarify this is not a draft, strictly. It's a draft of a=20 draft. > > 4.1. Advantages >=20 > This is more familiar to users of desktop operating systems. >=20 > 4.2. Disadvantages >=20 > It is less efficient, using multiple round-trips. MOVE helps this. > It is impossible to accurately reverse the first stage of the > metaphor - doing so requires the client to copy the message=20 > back, > which issues it with a new UID, and can alter the message's > position in the display. MOVE doesn't help this. > For shared mailboxes, deleted messages are generally moved to=20 > a > personal trash folder. Nor this. > It relies for safety on the UIDPLUS extension defined in=20 > [RFC4315] > - servers not implementing this extension, or not supporting=20 > it > for the mailboxes involved, will cause additional downloads=20 > and > potentially inadvertant irrevocable deletions. MOVE exchanges this required extension for another, so whilst it=20 removes reliance on UIDPLUS, it's replacing it with reliance on an=20 extension that's yet to be defined, let alone implemented. > It is not interoperable - aside from the issues noted above,=20 > there > is no mechanism for denoting a trash mailbox, and many clients > vary the name used. MOVE does not help this. > While at it, I believe that there is an additional advantage of=20 > using Trash mailbox: to have the emails organized better - the=20 > deleted mails do not mix with the ones that one wants to keep there, That's related to the view of the mailbox, though. Some form of view=20 filter eliminates the deleted messages from the view. > making it easier to find emails (besides then searched would not=20 > be performed on deleted emails either which means performance=20 > boost). Prepending UNDELETED to the search key ought to be virtually as fast=20 as physically removing the messages, though, since it's a search on=20 flags. I'm really not against Trash mailboxes, as such, it's just that IMAP=20 doesn't have the concept, and retrofitting it onto existing IMAP=20 servers can cause far more problems than it solves. 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 From lemonade-bounces@ietf.org Tue Aug 01 11:40:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7wLu-0000m1-Pp; Tue, 01 Aug 2006 11:40:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7wLt-0000lw-Lz for lemonade@ietf.org; Tue, 01 Aug 2006 11:40:13 -0400 Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7wLs-0003OE-BV for lemonade@ietf.org; Tue, 01 Aug 2006 11:40:13 -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 k71Fe93E029296; Tue, 1 Aug 2006 08:40:09 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k71Fe8G0013706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Aug 2006 08:40:09 -0700 Date: Tue, 1 Aug 2006 08:40:07 -0700 (PDT) From: Mark Crispin To: Dave Cridland Subject: Re: [lemonade] Trash and MOVE In-Reply-To: <5827.1154444868.252985@invsysm1> Message-ID: References: <0FA975F2D8295A448BE3ADC161244657A1B556@esebe199.NOE.Nokia.com> <5827.1154444868.252985@invsysm1> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.1.81933 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: 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, 1 Aug 2006, Dave Cridland wrote: > I'm really not against Trash mailboxes, as such, it's just that IMAP doesn't > have the concept, and retrofitting it onto existing IMAP servers can cause > far more problems than it solves. I, on the other hand, am completely opposed to adding a Trash mailbox to IMAP. I am also completely opposed to a MOVE command. These decisions were correct when they were made in 1986, and remain correct today. I strongly suggest to people who want a protocol that has a Trash mailbox that they design their own competing protocol to IMAP (there is Exchange after all) and use that protocol instead of IMAP. -- 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 Aug 01 11:45:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7wQj-0001Um-Ib; Tue, 01 Aug 2006 11:45:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7wQi-0001UZ-BF for lemonade@ietf.org; Tue, 01 Aug 2006 11:45:12 -0400 Received: from mxout5.cac.washington.edu ([140.142.32.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7wQg-00048G-Uj for lemonade@ietf.org; Tue, 01 Aug 2006 11:45:12 -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 k71FjATZ016316 for ; Tue, 1 Aug 2006 08:45:10 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k71Fj8ha015392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 1 Aug 2006 08:45:09 -0700 Date: Tue, 1 Aug 2006 08:45:08 -0700 (PDT) From: Mark Crispin To: Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] Trash and MOVE In-Reply-To: Message-ID: References: <0FA975F2D8295A448BE3ADC161244657A1B556@esebe199.NOE.Nokia.com> <5827.1154444868.252985@invsysm1> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.1.82433 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 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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, 1 Aug 2006, Mark Crispin wrote: > I strongly suggest to people who want a protocol that has a Trash mailbox > that they design their own competing protocol to IMAP (there is Exchange > after all) and use that protocol instead of IMAP. There is also a protocol called SMAP that is touted by its creator as being superior to IMAP. The point of this rant is that there is no need to bloat IMAP with extraneous functionality; alternatives exist. As it is, IMAP needs to go on a diet. -- 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 Aug 01 12:03:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7wiI-0007tH-3G; Tue, 01 Aug 2006 12:03:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7wiG-0007rH-LH for lemonade@ietf.org; Tue, 01 Aug 2006 12:03: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 1G7tb0-0001Aw-SL for lemonade@ietf.org; Tue, 01 Aug 2006 08:43:38 -0400 Received: from smtp-out.sendmail.com ([209.246.26.45]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G7tWe-00035z-CN for lemonade@ietf.org; Tue, 01 Aug 2006 08:39:11 -0400 Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.2.3/Switch-3.2.0) with ESMTP id k71CZTjk014078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Aug 2006 05:35:30 -0700 X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com k71CZTjk014078 DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1154435733; bh=A0l9FF1FHTwabG5T9TIsgUgx0oA=; h=X-DomainKeys: DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:In-Reply-To: Message-ID:References:MIME-Version:Content-Type: Content-Transfer-Encoding; b=cfaGHGJhhxp18LYNYurfnVGMORzMrjOCTtPh68 z3R4PLKpC6R8k+t/RfRzLKP7WaiVfSDkN3ocRCMM0248ALHW3oKx0PQevH4mmNM9t85 B87/G/i/i2tdDWFrGXqF0OBSY3gHDo+V6J/JboDMXZB5Rxb8hpssrcIf5n74BFEcJ8= X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com k71CZTjk014078 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type:content-transfer-encoding; b=phMdF/PkhzsX9xAf07T8Ki+Ha11Di+wCLPM7i1/2T5DfgpVM4xIxAR5PAlmKGS9fO djlFGj7gb/y7K1EXRILjQqkbzL/WXs4Es3H9nZn3WgfbyPC1B4fV5d7DEWKfSWo6KsI obDaxyxQYLa0jq25OtLW3za4sssrA8DuGO0qecw= Date: Tue, 1 Aug 2006 05:35:29 -0700 From: Philip Guenther X-X-Sender: guenther@lab.smi.sendmail.com To: Zoltan.Ordogh@nokia.com Subject: RE: [lemonade] Notifications for multiple devices per user In-Reply-To: <0FA975F2D8295A448BE3ADC161244657A1B556@esebe199.NOE.Nokia.com> Message-ID: <20060801045815.B26250@lab.smi.sendmail.com> References: <0FA975F2D8295A448BE3ADC161244657A1B556@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by foon.sendmail.com id k71CZTjk014078 X-Spam-Score: -1.1 (-) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c 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, 1 Aug 2006, Zoltan.Ordogh@nokia.com wrote: > From: ext Philip Guenther [mailto:guenther+lemonade@sendmail.com] ... > On Tue, 1 Aug 2006, Zoltan.Ordogh@nokia.com wrote: >> There are some disadvantages listed in this draft. Earlier I suggested >> to standardize a MOVE command, but it has been turned down for some >> reason > > "Some reason"? I seem to recall a number of responses describing=20 > implementation problems and questioning the benefits. [Z=D6r] Yes, I di= d=20 > not want to quote the entire discussion here - I call it some reason=20 > because I disagree: I believe that it does add value and implementation= =20 > problems are a good thing - they force a better architecture in the lon= g=20 > run - so we should address this. No, implementation problems mean you're less likely to have a tight spec=20 and more likely to have subtle differences in behavior between=20 implementations. If an implementor has to choose between: a) a 100% accurate implementation that requires a major architectural change, b) a 95% accurate implementation that doesn't require that major re-arch, and c) not implementing it then (a) is going to lose out unless that last 5% has a value that the=20 implementors can show to their management. > Also, the command was suggested to be > optional so it should not cause any problems for those unwilling to=20 > implement it. ...until it becomes part of some profile, at which point that 95% solutio= n=20 looks _real_ good. Too bad some clients get confused by the results. ... > But which disadvantages does it remove, the easy ones or the hard ones? > As far as I can tell, it doesn't solve any of the hard ones on Dave's > list. Yes, it solves the quota problem, but only for servers where quo= tas > strictly follow the QUOTA extension and not those based on actual > filesystem quotas. > > [Z=D6r] This is in the draft: > > 4.1. Advantages > > This is more familiar to users of desktop operating systems. > > 4.2. Disadvantages > > It is less efficient, using multiple round-trips. > It is impossible to accurately reverse the first stage of the > metaphor - doing so requires the client to copy the message back, > which issues it with a new UID, and can alter the message's > position in the display. > For shared mailboxes, deleted messages are generally moved to a > personal trash folder. > It relies for safety on the UIDPLUS extension defined in [RFC4315] > - servers not implementing this extension, or not supporting it > for the mailboxes involved, will cause additional downloads and > potentially inadvertant irrevocable deletions. > It is not interoperable - aside from the issues noted above, there > is no mechanism for denoting a trash mailbox, and many clients > vary the name used. > > The disadvantage the MOVE command would remove is the first one shown=20 > above: no need for multiple roundtrips to copy an email and remove the=20 > original I think MOVE would *only* save the RTT waiting for the COPY to return OK=20 before expunging the messages. At least as how I understand the methods,= =20 that still would leave you an RTT slower than the native method. > (plus, the UID would be kept so it would not be downloaded=20 > again to the client). If you're referring to the second item, ("It is impossible...") then no,=20 it can't. Moving a message from mailbox A to mailbox B and back MUST=20 place the message at the end of the mailbox. The IMAP base spec=20 guarantees that messages CANNOT be reinserted into the middle of mailbox=20 without changing the UIDVALIDITY and no extension can change that. > Also, I suspect it would address the third one=20 > about UIDPLUS If you're implying that support for MOVE would require support for=20 UIDPLUS, well, you're just _confirming_ the need for UIDPLUS. > and the last one as well. I have no idea what you mean by this, as the presence of the MOVE command= =20 doesn't standardize the name of the Trash mailbox and requiring an=20 extension makes the process *less* interoperable. > So, only the second one would=20 > remain - which I believe is not a real problem because You indicate=20 > where to move the emails, so You can move it to any mailbox You wish. The client you use lets you designate _different_ Trash mailboxes to be=20 used when deleting messages from different folders? So you designate a=20 separate Trash mailbox for each shared mailbox you use? How many clients do you know support that? How many people actually go t= o=20 the bother of using that capability? > While at it, I believe that there is an additional advantage of using=20 > Trash mailbox: to have the emails organized better - the deleted mails=20 > do not mix with the ones that one wants to keep there, making it easier= =20 > to find emails (besides then searched would not be performed on deleted= =20 > emails either which means performance boost). tag SEARCH UNDELETED Philip Guenther _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Aug 01 12:40:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7xHu-0004yr-HV; Tue, 01 Aug 2006 12:40:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7xHs-0004wT-UZ for lemonade@ietf.org; Tue, 01 Aug 2006 12:40:09 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7xHr-0000wH-Fu for lemonade@ietf.org; Tue, 01 Aug 2006 12:40:08 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 82A9E4AD56; Tue, 1 Aug 2006 18:40:05 +0200 (CEST) Received: by libertango.oryx.com (Postfix, from userid 1000) id 87D0CA30A1; Tue, 1 Aug 2006 18:40:05 +0200 (CEST) Date: Tue, 1 Aug 2006 18:40:05 +0200 From: Arnt Gulbrandsen To: Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] Re: WGLC compress-02 IANA registry Message-ID: <20060801164005.GD7059@oryx.com> References: <330A23D8336C0346B5C1A5BB19666647034EECEB@ATLANTIS.Brooktrout.com> <44C01838.4030303@isode.com> <6483.1153478826.555212@invsysm1> <44C0B335.5030102@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44C0B335.5030102@isode.com> X-Message-Flag: WARNING! Message was not sent using Microsoft software! X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 > Dave Cridland wrote: > > I actually think that a better way forward would be to define a > > distinct document which created the IANA registry and populated it > > with DEFLATE as the MTI, and then subsequently this document would > > then reference it. > > After writing draft on comparators Arnt should be an expert on IANA > registrations ;-). That's why Arnt doesn't want to bother the IANA except when it's important ;) (The -03 revision creates a registry, even though I personally think it's not justified.) Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Aug 01 12:52:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7xTZ-0006VB-Nf; Tue, 01 Aug 2006 12:52:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7xTZ-0006V6-2b for lemonade@ietf.org; Tue, 01 Aug 2006 12:52:13 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7xTX-0001bq-M2 for lemonade@ietf.org; Tue, 01 Aug 2006 12:52:13 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id A20904AD86; Tue, 1 Aug 2006 18:52:10 +0200 (CEST) Message-Id: <4+G+FeQA+M1YhKJNi3qGZg.md5@libertango.oryx.com> Date: Tue, 1 Aug 2006 18:52:10 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [lemonade] IANA entry naming issue X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org WG consensus is to establish a new registry for compression algorithms. Fine. Then the IANA entry for the IMAP4 capability has to change. It was for COMPRESS=DEFLATE, now it has to be for COMPRESS=*. There are three older examples. RFC 4314 directs the IANA to add 'RIGHT=' to the IMAP4 Capabilities Registry. The SORT and THREAD extensions add SORT and THREAD. In all three cases, the actual capability is A=B. What should I add, COMPRESS or COMPRESS=? Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Aug 01 13:09:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7xkY-0004tT-SH; Tue, 01 Aug 2006 13:09:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7xkX-0004tO-9F for lemonade@ietf.org; Tue, 01 Aug 2006 13:09:45 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7xkV-0003xD-Qz for lemonade@ietf.org; Tue, 01 Aug 2006 13:09:45 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 663D34AD8A for ; Tue, 1 Aug 2006 19:09:42 +0200 (CEST) Message-Id: Date: Tue, 1 Aug 2006 19:09:42 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [lemonade] Compress, future algorithm and their arguments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 couple of people have proposed including general arguments for future compression algorithms. At least that's how I read their mail. My basic position on such issues is that until we know at least a little about what these arguments might be, it's best to not specify them in any way. The best way to cater for the completely unknown is to not specify it at all. I could attempt to specify it in the way Mark did in the RFC 3501 body-extension or Barry and Alexey in listext's return-option, but I'm wary that a) it's practically untestable at present and b) that if/when these unknown arguments become known, they just might not fit into a list-of-lists. Because of this, I would prefer to leave it open. I would prefer to state the syntax as "COMPRESS" SP algorithm and if some day an RFC comes along and needs arguments, it can extend the syntax somewhat generally, and it can do at least as good a job then as we can now. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Aug 01 13:12:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7xnL-0005mc-4o; Tue, 01 Aug 2006 13:12:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7xnJ-0005mV-UR for lemonade@ietf.org; Tue, 01 Aug 2006 13:12:37 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7xnI-00047r-H6 for lemonade@ietf.org; Tue, 01 Aug 2006 13:12:37 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Tue, 1 Aug 2006 18:12:32 +0100 Message-ID: <44CF8B4A.1080302@isode.com> Date: Tue, 01 Aug 2006 18:11:38 +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: Arnt Gulbrandsen Subject: Re: [lemonade] Compress, future algorithm and their arguments 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: 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 Arnt Gulbrandsen wrote: > A couple of people have proposed including general arguments for > future compression algorithms. At least that's how I read their mail. > > My basic position on such issues is that until we know at least a > little about what these arguments might be, it's best to not specify > them in any way. The best way to cater for the completely unknown is > to not specify it at all. > > I could attempt to specify it in the way Mark did in the RFC 3501 > body-extension or Barry and Alexey in listext's return-option, but I'm > wary that a) it's practically untestable at present and b) that > if/when these unknown arguments become known, they just might not fit > into a list-of-lists. > > Because of this, I would prefer to leave it open. I would prefer to > state the syntax as > "COMPRESS" SP algorithm > and if some day an RFC comes along and needs arguments, it can extend > the syntax somewhat generally, and it can do at least as good a job > then as we can now. I agree. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Aug 01 13:24:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7xyM-0004Ke-WA; Tue, 01 Aug 2006 13:24:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7xyL-0004KW-JR for lemonade@ietf.org; Tue, 01 Aug 2006 13:24:01 -0400 Received: from mxout1.cac.washington.edu ([140.142.32.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7xyK-0004ny-9I for lemonade@ietf.org; Tue, 01 Aug 2006 13:24:01 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout1.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k71HNhha011905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Aug 2006 10:23:43 -0700 X-Auth-Received: from Shimo-Tomobiki.panda.com ([65.122.177.186]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k71HNduK021219 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 1 Aug 2006 10:23:42 -0700 Date: Tue, 1 Aug 2006 10:23:36 -0700 From: Mark Crispin To: Alexey Melnikov Subject: Re: [lemonade] Compress, future algorithm and their arguments In-Reply-To: <44CF8B4A.1080302@isode.com> Message-ID: References: <44CF8B4A.1080302@isode.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.1.95933 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 +1 On Tue, 1 Aug 2006, Alexey Melnikov wrote: > Arnt Gulbrandsen wrote: >> Because of this, I would prefer to leave it open. I would prefer to state >> the syntax as >> "COMPRESS" SP algorithm >> and if some day an RFC comes along and needs arguments, it can extend the >> syntax somewhat generally, and it can do at least as good a job then as we >> can now. > I agree. -- 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 Aug 01 14:44:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7zER-0002Z3-UM; Tue, 01 Aug 2006 14:44:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7zER-0002YU-8b for lemonade@ietf.org; Tue, 01 Aug 2006 14:44: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 1G7wSv-0004Np-0K for lemonade@ietf.org; Tue, 01 Aug 2006 11:47:29 -0400 Received: from mxout5.cac.washington.edu ([140.142.32.135]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G7wIK-00075w-Il for lemonade@ietf.org; Tue, 01 Aug 2006 11:36:42 -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 k71FaTgN013310; Tue, 1 Aug 2006 08:36:29 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k71FaMNd012537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Aug 2006 08:36:28 -0700 Date: Tue, 1 Aug 2006 08:36:22 -0700 (PDT) From: Mark Crispin To: Zoltan.Ordogh@nokia.com Subject: RE: [lemonade] Notifications for multiple devices per user In-Reply-To: <0FA975F2D8295A448BE3ADC161244657A1B435@esebe199.NOE.Nokia.com> Message-ID: References: <0FA975F2D8295A448BE3ADC161244657A1B435@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.1.81933 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: -2.6 (--) 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 Tue, 1 Aug 2006, Zoltan.Ordogh@nokia.com wrote: > Yes, this is certainly a good opinion, however it does not solve the problem of identifying the special mailboxes. You inadvertantly referred to a major problem by using the plural "mailboxes". This is a slippery slope, and it opens up the way to define a Trash mailbox in IMAP. I agree that we need a means to identify the location of sent messages. I am less certain about drafts or a pending queue for outgoing messages (to be pulled by URLFETCH). I would like to see a more convincing use case for multiple clients using the same name. I tend to suspect that clients are less likely to be able to do useful things with a different client's draft than at first appearance. I am completely opposed to any definition of a Trash mailbox in IMAP. -- 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 Aug 01 14:45:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7zF2-0003k5-Ne; Tue, 01 Aug 2006 14:45:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7zEw-0003TK-7R; Tue, 01 Aug 2006 14:45:14 -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 1G7wkY-00062e-FR; Tue, 01 Aug 2006 12:05:42 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G7wbc-00008c-CO; Tue, 01 Aug 2006 11:56:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 8483E2AC34; Tue, 1 Aug 2006 15:34:08 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G7dm5-0007Z2-UP; Mon, 31 Jul 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, 31 Jul 2006 15:50:01 -0400 X-Spam-Score: -5.5 (-----) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-client-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 : IMAP4 Extensions for Quick Mailbox Resynchronization Author(s) : A. Melnikov, et al. Filename : draft-ietf-lemonade-reconnect-client-01.txt Pages : 10 Date : 2006-7-31 This document defines an IMAP4 extension, which gives an IMAP client the ability to quickly resynchronize any previously opened mailbox as part of the SELECT command, without the need for server-side state or additional client round-trips. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-reconnect-client-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-reconnect-client-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-reconnect-client-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-7-31141443.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-reconnect-client-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-reconnect-client-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-7-31141443.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 Aug 01 18:50:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G834d-0001A5-34; Tue, 01 Aug 2006 18:50:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G834P-0000ZC-Aa; Tue, 01 Aug 2006 18:50: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 1G834P-0004A7-85; Tue, 01 Aug 2006 18:50:37 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G834K-0000gD-4w; Tue, 01 Aug 2006 18:50:36 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id DCB5617609; Tue, 1 Aug 2006 22:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G833p-0004MT-G6; Tue, 01 Aug 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: Tue, 01 Aug 2006 18:50:01 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-compress-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 : The IMAP COMPRESS Extension Author(s) : A. Gulbrandsen Filename : draft-ietf-lemonade-compress-03.txt Pages : 9 Date : 2006-8-1 The COMPRESS extension allows an IMAP connection to be effectively and efficiently compressed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-compress-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-compress-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-compress-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-8-1151141.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-compress-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-compress-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-1151141.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 Aug 01 20:47:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G84tC-0001EN-7V; Tue, 01 Aug 2006 20:47:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G84tB-0001AJ-CL for lemonade@ietf.org; Tue, 01 Aug 2006 20:47:09 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G84tA-0004rJ-1Y for lemonade@ietf.org; Tue, 01 Aug 2006 20:47:09 -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 k720l4Sa015294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 1 Aug 2006 17:47:05 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k720l2s7011173; Tue, 1 Aug 2006 17:47:03 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <330A23D8336C0346B5C1A5BB19666647034EECEB@ATLANTIS.Brooktrout.com> <44C01838.4030303@isode.com> <20060728155520.R26250@lab.smi.sendmail.com> <20060728195619.J26250@lab.smi.sendmail.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Tue, 1 Aug 2006 17:46:59 -0700 To: Mark Crispin , Philip Guenther From: Randall Gellens Subject: Re: [lemonade] WGLC draft-ietf-lemonade-compress-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: 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 8:15 PM -0700 7/28/06, Mark Crispin wrote: > On Fri, 28 Jul 2006, Philip Guenther wrote: >> I don't think we expect to see future THREAD mechanisms either, >> but it's apparently simpler and less contentious to create a >> registry than it is to _not_ do so. As author/editor/review time >> is the most precious commodity in the IETF, creating the registry >> and copying text to do so that people have already nodded their >> heads at seem like the most efficient choice. I get a bit queasy at the thought of IANA registry pollution (creating useless registries) just because it is easier for us to do that than to include a sentence in the document as to why one isn't needed. IANA is trying to speed up its response times. Adding useless work hurts that. > Excellent point. > > It's also important to note that creating a registry is a great way > to prevent bad ideas from getting into a protocol. If you don't > have a registry, then everybody who thinks that he has a Very > Important Idea will fillibuster the specification until the bad > idea is added to the specification. With a registry, the people > with VIIs have an outlet, but then have to make the VII stand on > its own (which few VIIs will actually accomplish). Perhaps I'm naive, but I think we can block bad ideas from being added to our document just as easily (in fact, more easily) as we can block them as stand-alone additions to an IANA registry. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- If I like it I say it's mine. If I don't I say it's a fake. --Pablo Picasso _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Aug 01 20:58:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G853w-0004kR-Fo; Tue, 01 Aug 2006 20:58:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G853u-0004kM-Sp for lemonade@ietf.org; Tue, 01 Aug 2006 20:58:14 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G853t-0005d6-Ge for lemonade@ietf.org; Tue, 01 Aug 2006 20:58:14 -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 k720wBuR016641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 1 Aug 2006 17:58:12 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k720w64F013939; Tue, 1 Aug 2006 17:58:11 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <0FA975F2D8295A448BE3ADC161244657A1AD57@esebe199.NOE.Nokia.com> References: <0FA975F2D8295A448BE3ADC161244657A1AD57@esebe199.NOE.Nokia.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Tue, 1 Aug 2006 17:58:03 -0700 To: , From: Randall Gellens Subject: RE: [lemonade] WGLC compress-02 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: b7b9551d71acde901886cc48bfc088a6 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 11:14 AM +0300 7/31/06, <Zoltan.Ordogh@nokia.com> wrote: > > Section 3: > > "The client MUST NOT send any=20 > commands until it has seen the result > > of COMPRESS." This is fine, but can=20 > the server send anything else in > > the meantime? I mean I can turn it on at any time during the session= =2E > > The server can't send anything else (such as an=20 > unsolicited response) in the meantime . This=20 > seems obvious but could be explicitly stated. > [Z=D6r] This is true only if You issue the=20 > command during login I guess - if You issue it=20 > during some other time during the session, You=20 > might get other responses as well. The server can't send anything between the time=20 it sees the COMPRESS command and when it sends=20 the response to it. So the only ambiguity comes=20 if the client has an outstanding command (one=20 that it hasn't seen the tagged response to).=20 Clients would see responses related to the=20 outstanding command before seeing responses to=20 the COMPRESS, but presumably the client knows if=20 it has outstanding responses and won't get=20 confused. This will need to be clarified when we do the=20 SMTP COMPRESS draft, by the way (pipeling and=20 COMPRESS). > >From Your response below to my question=20 > below it seems that this command can be used=20 > only once - but the draft does not say that it=20 > is the login phase during which it has to be=20 > used when compression is desired. If the command succeeds, it can't be reissued.=20 See Section 3, where it says a BAD response is=20 issued if COMPRESS is already active. It can be issued at any time during the session, however. > Thank you. > > > > > Section 3 and section 5: > > How can it be turned off? > > By logging out and back in. The added=20 > complexity of allowing it to be turned off=20 > doesn't seem to be justified by the low utility. > [Z=D6r] Question: if I do a quick reconnect, will=20 > the compression state be restored? (in which=20 > case disconnect will not help me much). I wouldn't expect this to be the case. It would=20 need to be added to the reconnect document in=20 order to do so, and I can't see any benefit.=20 Plus, the reconnect document is morphing into a=20 re-select. > Another thing is that when I store an email=20 > that contains an uncompressable (JPG, ZIP)=20 > file, I might want to switch compression off=20 > before uploading it, and turn it back on=20 > afterwards. I am sure that this has been=20 > discussed, but I do not seem to be able to find=20 > the related emails - so I ask it again to get=20 > the right answers. This is discussed in the document in Section 4.=20 The compressing side uses the zlib API to set the=20 level to 0 before sending such data, and resets=20 it to a non-zero value afterwards. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Demagogue: One who preaches doctrines he knows to be untrue to men he knows to be idiots. --H.L. Mencken _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Aug 01 21:56:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G85xu-0004nx-Se; Tue, 01 Aug 2006 21:56:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G85xt-0004ns-Hf for lemonade@ietf.org; Tue, 01 Aug 2006 21:56:05 -0400 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G85xq-0007y4-5e for lemonade@ietf.org; Tue, 01 Aug 2006 21:56:05 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M5HL4NZNC000HZY0@mauve.mrochek.com> for lemonade@ietf.org; Tue, 1 Aug 2006 18:55:56 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1154483755; h=Date: From:Subject:MIME-version:Content-type; b=cYkANaX8Li10MtLK48Bu7LhM6 Ld9PG1a5kT+Iv2ls4FDr++jyVRsP3uFgSeuYto/tvlxKrOvjvAf15uIwobh2A== Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M5GWWBS6PS0008CX@mauve.mrochek.com>; Tue, 01 Aug 2006 18:55:52 -0700 (PDT) To: Arnt Gulbrandsen Message-id: <01M5HL4MFZY20008CX@mauve.mrochek.com> Date: Tue, 01 Aug 2006 18:50:54 -0700 (PDT) From: Ned Freed Subject: Re: [lemonade] Re: WGLC compress-02 IANA registry In-reply-to: "Your message dated Tue, 01 Aug 2006 18:40:05 +0200" <20060801164005.GD7059@oryx.com> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <330A23D8336C0346B5C1A5BB19666647034EECEB@ATLANTIS.Brooktrout.com> <44C01838.4030303@isode.com> <6483.1153478826.555212@invsysm1> <44C0B335.5030102@isode.com> <20060801164005.GD7059@oryx.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Enhancements to Internet email to support diverse service enivronments , 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 > > Dave Cridland wrote: > > > I actually think that a better way forward would be to define a > > > distinct document which created the IANA registry and populated it > > > with DEFLATE as the MTI, and then subsequently this document would > > > then reference it. > > > > After writing draft on comparators Arnt should be an expert on IANA > > registrations ;-). > That's why Arnt doesn't want to bother the IANA except when it's > important ;) > (The -03 revision creates a registry, even though I personally think > it's not justified.) What I'm not getting is why a registry separate from the one we already have for TLS compression schemes is needed. The table already exists: http://www.iana.org/assignments/comp-meth-ids All we need to do is add a column for an identifier name (as opposed to identifier value) and we should be good to go. The advantage of doing it this way is that every time someone adds a compression scheme to TLS it's available for use as a compression layer, and vice versa. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Aug 02 02:39:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8ANg-0002bg-Hf; Wed, 02 Aug 2006 02:39:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8ANf-0002bb-El for lemonade@ietf.org; Wed, 02 Aug 2006 02:38:59 -0400 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8ANd-0003Bl-Ur for lemonade@ietf.org; Wed, 02 Aug 2006 02:38:59 -0400 Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.3]) by smarthost.yourcomms.net (8.11.7p1+Sun/8.11.6) with ESMTP id k726Qv612481 for ; Wed, 2 Aug 2006 07:26:57 +0100 (BST) 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: Wed, 2 Aug 2006 07:38:21 +0100 Message-ID: <22C8A0D5D5E095449AB509FE777B5F80029DE7AA@svr-exchange.avocado.emccsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Notifications for multiple devices per user Thread-Index: Aca1moR5FRxb+1znRpOUFyfWl6atHAAYpjOA From: "Ben Last" To: "Mark Crispin" X-Spam-Score: 0.6 (/) 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 >At 01 August 2006 16:36, Mark Crispin wrote: >>On Tue, 1 Aug 2006, Zoltan.Ordogh@nokia.com wrote: >>Yes, this is certainly a good opinion, however it does not solve the problem of identifying the special mailboxes. >You inadvertantly referred to a major problem by using the plural "mailboxes". >This is a slippery slope, and it opens up the way to define a Trash mailbox in IMAP. I'm not clear which part of Zoltan's message exactly is the slippery slope, but the rationale I have for a way to identify special mailboxes comes from a rather different perspective: the need for mobile clients to interoperate with systems that are already out there and in production use. At least one such system creates its own Sent/Outbox/Trash folders and whilst I agree with Mark on the general awkwardness and non-IMAP-nature of a Trash, the fact remains that our mobile client will see Trash folders in the response to a LIST and has, right now, no way to know that is anything other than a regular folder, potentially leading to interesting, inefficient and non-useful behaviour if it tries to synchronize it :) >I agree that we need a means to identify the location of sent messages. If such a mechanism is generalized to allow identification of "special" folders, then it allows a client to, at the very least, identify and ignore a Trash folder. It then imposes no obligation on any client to *use* a Trash folder. >I am less certain about drafts or a pending queue for outgoing messages (to be pulled by URLFETCH). I would like to see a more convincing use case for multiple >clients using the same name. I tend to suspect that clients are less likely to be able to do useful things with a different client's draft than at first appearance. Agreed (on the last point), but again, it allows clients to avoid synchronizing folders that should not be synchronized. It also allows clients to choose to store their own drafts in that same folder; it does not impose on them any requirement to process other client's drafts. Mark: I guess my point is that I respect (and in general agree with) the reasons that you have for opposing the implementation of a Trash folder in IMAP, but a way to identify a Trash folder does not count (in my humble view) as a way to *implement* it and in fact provides a way for clients to avoid needing to implement it (or, even worse, appear to provide it to the user by inadvertently showing some other client's Trash folder). Regards to all ben _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Aug 02 02:55:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Adw-0007Tw-GV; Wed, 02 Aug 2006 02:55:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Adv-0007Tr-7u for lemonade@ietf.org; Wed, 02 Aug 2006 02:55:47 -0400 Received: from mxout7.cac.washington.edu ([140.142.32.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8Adt-00044O-Rb for lemonade@ietf.org; Wed, 02 Aug 2006 02:55:47 -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 k726tZmS001560; Tue, 1 Aug 2006 23:55:35 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k726tXUg000811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Aug 2006 23:55:34 -0700 Date: Tue, 1 Aug 2006 23:55:33 -0700 (PDT) From: Mark Crispin To: Ben Last Subject: RE: [lemonade] Notifications for multiple devices per user In-Reply-To: <22C8A0D5D5E095449AB509FE777B5F80029DE7AA@svr-exchange.avocado.emccsoft.com> Message-ID: References: <22C8A0D5D5E095449AB509FE777B5F80029DE7AA@svr-exchange.avocado.emccsoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.1.233432 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: 2409bba43e9c8d580670fda8b695204a 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 Wed, 2 Aug 2006, Ben Last wrote: > Mark: I guess my point is that I respect (and in general agree with) the > reasons that you have for opposing the implementation of a Trash folder > in IMAP, but a way to identify a Trash folder does not count (in my > humble view) as a way to *implement* it and in fact provides a way for > clients to avoid needing to implement it (or, even worse, appear to > provide it to the user by inadvertently showing some other client's > Trash folder). I strongly disagree. I feel that it would be a terrible mistake for any portion of any IMAP related specification to identify a token called a Trash mailbox (not "folder"; there is no such thing as a "folder" in IMAP and the word "folder" is not suitable for use in IMAP due to its ambiguity). It would effectively bless a Trash mailbox, and opens the possibility of something adding it to its profile. As matters stand now, Trash is completely outside of IMAP. Any software that attempts to use Trash has no guarantee of interoperability or even that it will work at all. This is a feature, not a bug. -- 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 Aug 02 03:00:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8AiF-0004vm-NZ; Wed, 02 Aug 2006 03:00:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8AiE-0004s2-Bo for lemonade@ietf.org; Wed, 02 Aug 2006 03:00:14 -0400 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8AiC-0004G8-Vm for lemonade@ietf.org; Wed, 02 Aug 2006 03:00:14 -0400 Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.3]) by smarthost.yourcomms.net (8.11.7p1+Sun/8.11.6) with ESMTP id k726mC613104 for ; Wed, 2 Aug 2006 07:48:12 +0100 (BST) 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: Wed, 2 Aug 2006 07:59:37 +0100 Message-ID: <22C8A0D5D5E095449AB509FE777B5F80029DE7B4@svr-exchange.avocado.emccsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Notifications for multiple devices per user Thread-Index: Aca2AJtsX5kNZSgBSRuOfs3o1YroiAAABRXQ From: "Ben Last" To: "Mark Crispin" 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 At 02 August 2006 07:56, Mark Crispin wrote: >I strongly disagree. I feel that it would be a terrible mistake for any portion of any IMAP related specification to identify >a token called a Trash mailbox (not "folder"; there is no such thing as a "folder" in IMAP and the word "folder" is not >suitable for use in IMAP due to its ambiguity). Apologies for the inadvertent use of incorrect terminology :) >It would effectively bless a Trash mailbox, and opens the possibility of something adding it to its profile. I disagree here, and I guess we'll have to continue to differ: I don't see the way to identify the folder as any form of "blessing". What if there were a mechanism to identify folders that are "reserved for other clients, may do terrible things like implement a Trash and should not be synchronized to or attended to by other clients"? That would help address my concerns. >As matters stand now, Trash is completely outside of IMAP. Any software that attempts to use Trash has no guarantee of interoperability >or even that it will work at all. This is a feature, not a bug. And yet there is at least one major, industrial strength mail server, that uses LEMONADE IMAP to present itself to mobile clients that uses a Trash mailbox/view/whatever. This is a fact of the real world, and unfortunately we cannot make it go away. All I want to do is find a sensible, optimal way to work with what exists. Best regards Ben _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Aug 02 04:00:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Beq-0002bm-Se; Wed, 02 Aug 2006 04:00:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Bep-0002bg-UA for lemonade@ietf.org; Wed, 02 Aug 2006 04:00:47 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8Beo-0000VX-D4 for lemonade@ietf.org; Wed, 02 Aug 2006 04:00:47 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 0C6224ACBD; Wed, 2 Aug 2006 10:00:43 +0200 (CEST) Message-Id: Date: Wed, 2 Aug 2006 10:00:45 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Re: WGLC compress-02 IANA registry References: <330A23D8336C0346B5C1A5BB19666647034EECEB@ATLANTIS.Brooktrout.com> <44C01838.4030303@isode.com> <6483.1153478826.555212@invsysm1> <44C0B335.5030102@isode.com> <20060801164005.GD7059@oryx.com> <01M5HL4MFZY20008CX@mauve.mrochek.com> In-Reply-To: <01M5HL4MFZY20008CX@mauve.mrochek.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Alexey Melnikov , 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 Ned Freed writes: > What I'm not getting is why a registry separate from the one we > already have for TLS compression schemes is needed. The table already > exists: > > http://www.iana.org/assignments/comp-meth-ids > > All we need to do is add a column for an identifier name (as opposed > to identifier value) and we should be good to go. I looked at that table, and the change needed seemed to be a little too much butchery. I contemplated using the description column (which happens to contain suitable strings). Seemed a bit hackish. Opportunistic reuse. Adding a third column means there's two references for each line, which seemed wrong, and also I thought it might be impossible to alter the format of an existing IANA registry. So... I thought it would be cleanest to use a separate registry, and made a note to make it easy for the IANA (see yesterday's message) by sending the rfc-editor two files: The RFC in nroff format and additionally a text file containing the complete registry. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Aug 02 04:20:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Bxm-0007Nc-9q; Wed, 02 Aug 2006 04:20:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Bxm-0007NX-1L for lemonade@ietf.org; Wed, 02 Aug 2006 04:20:22 -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 1G8Bxl-0002Oc-Vo for lemonade@ietf.org; Wed, 02 Aug 2006 04:20:22 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G8Bvv-0002mK-1n for lemonade@ietf.org; Wed, 02 Aug 2006 04:18:28 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 9947C4ACBD; Wed, 2 Aug 2006 10:18:16 +0200 (CEST) Message-Id: Date: Wed, 2 Aug 2006 10:18:19 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Re: WGLC compress-02 IANA registry References: <330A23D8336C0346B5C1A5BB19666647034EECEB@ATLANTIS.Brooktrout.com> <44C01838.4030303@isode.com> <6483.1153478826.555212@invsysm1> <44C0B335.5030102@isode.com> <20060801164005.GD7059@oryx.com> <01M5HL4MFZY20008CX@mauve.mrochek.com> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: -2.4 (--) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Eric Burger , Glenn Parsons , Arnt Gulbrandsen List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Thinking about it again: If I create a registry, the IANA has to do that. If I modify comp-meth-tls, the IANA has to do that. Seems about the same, with modification perhaps a touch more work since it's less routine. If I don't create a registry, the IANA needs to do nothing now, but the result is different from several other IMAP extensions (SORT and THREAD notably), which is arguably inferior. (Yes, I know I'm a bit fascist about this consistency thing.) For each new algorithm, which I fervently hope never happens, the IANA has to add an antry to one registry. Either to imap4-capabilities, comp-meth-tls or comp-meth-imap. Seems the same. So I think it doesn't really make a difference for the IANA. I hear a couple of people wanting a registry and a couple not. I can't confidently say one side is stronger. I've set the reply-to field on this message to emulate a hum, so if everyone with an opinion can just check one, I can make a quick -04 revision if needed: [ ] hum for piggybacking on imap4-capabilities using "COMPRESS=" entries, like -02 revision [ ] hum for new registry, like -03 revision, and like SORT/THREAD [ ] hum for modifying and using comp-meth-tls registry, without precedent AFAIK Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Aug 02 04:47:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8CO4-0002lz-0r; Wed, 02 Aug 2006 04:47:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8CO2-0002lb-Pr for lemonade@ietf.org; Wed, 02 Aug 2006 04:47:30 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8CO0-0005M3-AJ for lemonade@ietf.org; Wed, 02 Aug 2006 04:47:30 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id E32EF4AD0A; Wed, 2 Aug 2006 10:47:26 +0200 (CEST) Message-Id: Date: Wed, 2 Aug 2006 10:47:29 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] WGLC compress-02 References: <0FA975F2D8295A448BE3ADC161244657A1AD57@esebe199.NOE.Nokia.com> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Randall Gellens , 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 writes: > The server can't send anything between the time it sees the COMPRESS > command and when it sends the response to it. It can, though... "* 8586513070 EXISTS" or "* ALERT Server shutdown in 600 seconds" for example. Of course it's very unlikely. > So the only ambiguity comes if the client has an outstanding command > (one that it hasn't seen the tagged response to). Clients would see > responses related to the outstanding command before seeing responses > to the COMPRESS, but presumably the client knows if it has > outstanding responses and won't get confused. Yes. Lots of clients do this sort of thing and handle it just fine. The other case (an outstanding command which is not completed before COMPRESS) is also well-defined, but at least some clients don't handle it. However, this is not a COMPRESS issue, it applies to any IMAP command pair where the second command is much faster than the first and the server can do concurrent execution. I've seen it with base IMAP (STORE 1:*+STORE 1 and a freezing mutt). Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Aug 02 11:11:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8IO6-0007RV-JQ; Wed, 02 Aug 2006 11:11:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8IO4-0007RP-Uq for lemonade@ietf.org; Wed, 02 Aug 2006 11:11:56 -0400 Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8IO3-0006Ep-Jk for lemonade@ietf.org; Wed, 02 Aug 2006 11:11:56 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k72FBkWt005210; Wed, 2 Aug 2006 08:11:46 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k72FBeWt027261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Aug 2006 08:11:45 -0700 Date: Wed, 2 Aug 2006 08:11:39 -0700 (PDT) From: Mark Crispin To: Ben Last Subject: RE: [lemonade] Notifications for multiple devices per user In-Reply-To: <22C8A0D5D5E095449AB509FE777B5F80029DE7B4@svr-exchange.avocado.emccsoft.com> Message-ID: References: <22C8A0D5D5E095449AB509FE777B5F80029DE7B4@svr-exchange.avocado.emccsoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.2.74933 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: 52e1467c2184c31006318542db5614d5 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 Wed, 2 Aug 2006, Ben Last wrote: > I disagree here, and I guess we'll have to continue to differ: I don't > see the way to identify the folder as any form of "blessing". What if > there were a mechanism to identify folders that are "reserved for other > clients, may do terrible things like implement a Trash and should not be > synchronized to or attended to by other clients"? That would help > address my concerns. What is there was a mechanism in IMAP to set the secret backdoor that allows complete root-level access to the entire system? Or to send unlimited anonymous email? Do you honestly believe that having such mechanisms defined wouldn't encourage some fool to implement them? > And yet there is at least one major, industrial strength mail server, > that uses LEMONADE IMAP to present itself to mobile clients that uses a > Trash mailbox/view/whatever. This is a fact of the real world, and > unfortunately we cannot make it go away. All I want to do is find a > sensible, optimal way to work with what exists. What you are really saying is: A mail server vendor made a terrible design mistake in its implementation of IMAP for LEMONADE, and now you expect the IMAP protocol to cover for this vendor's mistake. The only appropriate answer to such a request is "no". 1000 times "no". We should not break protocols to cover for vendor's broken products. -- 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 Aug 02 13:27:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8KV9-00005z-7E; Wed, 02 Aug 2006 13:27:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8KV7-0008Tu-Pi for lemonade@ietf.org; Wed, 02 Aug 2006 13:27:21 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8KV5-0005On-C7 for lemonade@ietf.org; Wed, 02 Aug 2006 13:27:21 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Wed, 2 Aug 2006 18:27:04 +0100 Message-ID: <44D0E056.8030001@isode.com> Date: Wed, 02 Aug 2006 18:26:46 +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] WGLC compress-02 References: <0FA975F2D8295A448BE3ADC161244657A1AD57@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: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Randall Gellens , 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: >> > Section 3 and section 5: >> > How can it be turned off? >> >> By logging out and back in. The added complexity of allowing it to = >> be turned off doesn't seem to be justified by the low utility. >> [Z=D6r] Question: if I do a quick reconnect, will the compression = >> state be restored? (in which case disconnect will not help me much). > > I wouldn't expect this to be the case. Resuming compression state on both sides of the connection would be a = nightmare. It sounds that reestablishing COMPRESS would be much simpler. There is a similar issue with reestablishing TLS. However STARTTLS is = already quite capable of doing that already. I would not want to = complicate [server side] reconnect by tying TLS state to it. > It would need to be added to the reconnect document in order to do so, = > and I can't see any benefit. Plus, the reconnect document is morphing = > into a re-select. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Aug 02 17:23:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8OBQ-00056J-EZ; Wed, 02 Aug 2006 17:23:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8OBO-00056E-PV for lemonade@ietf.org; Wed, 02 Aug 2006 17:23:14 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8OBN-0006Jz-Fo for lemonade@ietf.org; Wed, 02 Aug 2006 17:23:14 -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 k72LMmnw016803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 2 Aug 2006 14:22:49 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k72LMahe007723; Wed, 2 Aug 2006 14:22:47 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <0FA975F2D8295A448BE3ADC161244657A1AD57@esebe199.NOE.Nokia.com> X-Mailer: Eudora for Mac OS X (dev alpha) X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Wed, 2 Aug 2006 14:20:12 -0700 To: Arnt Gulbrandsen , lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] WGLC compress-02 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: de4f315c9369b71d7dd5909b42224370 Cc: R.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 At 10:47 AM +0200 8/2/06, Arnt Gulbrandsen wrote: >> The server can't send anything between the time it sees the >> COMPRESS command and when it sends the response to it. > > It can, though... "* 8586513070 EXISTS" or "* ALERT > Server shutdown in 600 seconds" for example. Of course it's > very unlikely. I thought the draft prohibited unsolicited responses after seeing COMPRESS. Likely I'm thinking of something else. But perhaps we should disallow this? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Do files get embarrassed when they are unzipped? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Aug 02 17:28:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8OG2-0001re-KD; Wed, 02 Aug 2006 17:28:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8OG1-0001rZ-Kd for lemonade@ietf.org; Wed, 02 Aug 2006 17:28:01 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G8OG0-0006qH-8m for lemonade@ietf.org; Wed, 02 Aug 2006 17:28:01 -0400 X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-5.tower-120.messagelabs.com!1154554078!10807603!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 6437 invoked from network); 2 Aug 2006 21:27:59 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-5.tower-120.messagelabs.com with SMTP; 2 Aug 2006 21:27:59 -0000 Received: from [135.91.110.64] (thansen-n.mt.att.com[135.91.110.64](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20060802212758gw1003jog4e> (Authid: tony); Wed, 2 Aug 2006 21:27:58 +0000 Message-ID: <44D118DB.1060601@att.com> Date: Wed, 02 Aug 2006 17:27:55 -0400 From: Tony Hansen User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 CC: lemonade@ietf.org Subject: Re: [lemonade] WGLC compress-02 References: <0FA975F2D8295A448BE3ADC161244657A1AD57@esebe199.NOE.Nokia.com> In-Reply-To: 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: 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 I don't see the problem with unsolicited responses arriving before the "x OK Compression starting now" response. They just can't be compressed and should be treated the same way as any other unsolicited responses to any other command. Tony Hansen tony@att.com Randall Gellens wrote: > At 10:47 AM +0200 8/2/06, Arnt Gulbrandsen wrote: > >>> The server can't send anything between the time it sees the COMPRESS >>> command and when it sends the response to it. >> >> It can, though... "* 8586513070 EXISTS" or "* ALERT >> Server shutdown in 600 seconds" for example. Of course it's very >> unlikely. > > I thought the draft prohibited unsolicited responses after seeing > COMPRESS. Likely I'm thinking of something else. But perhaps we should > disallow this? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Aug 02 17:30:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8OIP-0003Fm-Ta; Wed, 02 Aug 2006 17:30:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8OIP-0003Fb-2k for lemonade@ietf.org; Wed, 02 Aug 2006 17:30:29 -0400 Received: from smtp-out.sendmail.com ([209.246.26.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8OIN-000746-Fz for lemonade@ietf.org; Wed, 02 Aug 2006 17:30:29 -0400 Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.2.3/Switch-3.2.0) with ESMTP id k72LUICY021324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Aug 2006 14:30:18 -0700 X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com k72LUICY021324 DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1154554219; bh=vaGoqqA6RQOmqSxmXtnLMnZKeIM=; h=X-DomainKeys: DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:In-Reply-To: Message-ID:References:MIME-Version:Content-Type; b=jbFlWQ58+UJJ1oB2 jAaeIIMlSODBMDDVmEr73pdz0c4vAh3qvbciJCxJoK0IIBln7b7xcT9aJArUdtri1Qk q60KxSzCZEnTMnW4giySVRr3ssVmUtdmceDX/fs2gow2aMVAilT6wuFHnqhve+aE8OL 2qRJ3mlsK765IZN/7mLOY= X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com k72LUICY021324 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type; b=PRuu0xsUVIRQeSqpwyrefHLOe/v9NOpBgWOgHZusA4yr8Fo5glbxv0bdbAv5s0BrS byA7bFlfbirH3o50o1SDS96K87cN99LhkgUk4uVRGm6d4kZt60YszLczYCFO/gwPMYD 8Gb4AcSs8hsD6peuH8w9uPH8uNVT3aJOK+3gGig= Date: Wed, 2 Aug 2006 14:30:18 -0700 From: Philip Guenther X-X-Sender: guenther@lab.smi.sendmail.com To: Randall Gellens Subject: Re: [lemonade] WGLC compress-02 In-Reply-To: Message-ID: <20060802142807.O26250@lab.smi.sendmail.com> References: <0FA975F2D8295A448BE3ADC161244657A1AD57@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 Wed, 2 Aug 2006, Randall Gellens wrote: ... > I thought the draft prohibited unsolicited responses after seeing COMPRESS. > Likely I'm thinking of something else. But perhaps we should disallow this? How can the server know that the client is going to send COMPRESS next? The restriction you suggest would effectively ban sending of untagged responses when no commands are pending. Philip Guenther _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Aug 02 17:37:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8OPR-0001Ik-Qq; Wed, 02 Aug 2006 17:37:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8OPR-0001If-3H for lemonade@ietf.org; Wed, 02 Aug 2006 17:37:45 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8OPN-0007n5-K8 for lemonade@ietf.org; Wed, 02 Aug 2006 17:37:45 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 74A274AD0B; Wed, 2 Aug 2006 23:37:40 +0200 (CEST) Message-Id: Date: Wed, 2 Aug 2006 23:37:41 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] WGLC compress-02 References: <0FA975F2D8295A448BE3ADC161244657A1AD57@esebe199.NOE.Nokia.com> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Randall Gellens , R.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 writes: > At 10:47 AM +0200 8/2/06, Arnt Gulbrandsen wrote: > >>> The server can't send anything between the time it sees the >>> COMPRESS command and when it sends the response to it. >> >> It can, though... "* 8586513070 EXISTS" or "* ALERT >> Server shutdown in 600 seconds" for example. Of course it's >> very unlikely. > > I thought the draft prohibited unsolicited responses after seeing > COMPRESS. Likely I'm thinking of something else. But perhaps we > should disallow this? The draft does not prohibit unsolicited responses after the client sends compress (before the server receives it), and that cannot be prohibited. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Aug 02 17:42:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8OTY-0005kv-DZ; Wed, 02 Aug 2006 17:42:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8OTW-0005kq-W4 for lemonade@ietf.org; Wed, 02 Aug 2006 17:41:58 -0400 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8OTV-00089P-Lj for lemonade@ietf.org; Wed, 02 Aug 2006 17:41:58 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.50) id 1G8OTU-0006aH-Uc; Wed, 02 Aug 2006 21:41:57 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 10F1C498003; Wed, 2 Aug 2006 22:46: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 11650-05; Wed, 2 Aug 2006 22:46:32 +0100 (BST) Received: from invsysm1 (unknown [213.205.249.191]) by turner.dave.cridland.net (Postfix) with ESMTP id 05715498002; Wed, 2 Aug 2006 22:46:30 +0100 (BST) Date: Wed, 02 Aug 2006 22:39:58 +0100 Subject: Re: [lemonade] WGLC compress-02 References: <0FA975F2D8295A448BE3ADC161244657A1AD57@esebe199.NOE.Nokia.com> <44D118DB.1060601@att.com> In-Reply-To: <44D118DB.1060601@att.com> MIME-Version: 1.0 Message-Id: <7968.1154554890.115220@invsysm1> From: Dave Cridland To: Tony Hansen 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: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Aug 2 22:27:55 2006, Tony Hansen wrote: > I don't see the problem with unsolicited responses arriving before > the > "x OK Compression starting now" response. They just can't be > compressed > and should be treated the same way as any other unsolicited > responses to > any other command. Right. The ones arriving after the server's OK are actually harder to deal with, I find, but clients just have to be careful about that. 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 Aug 02 18:02:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Omz-0006MC-2D; Wed, 02 Aug 2006 18:02:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Omy-0006M7-Kl for lemonade@ietf.org; Wed, 02 Aug 2006 18:02:04 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8Omx-0001M9-8s for lemonade@ietf.org; Wed, 02 Aug 2006 18:02:04 -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 k72M1bwI025663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 2 Aug 2006 15:01:38 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k72M1POU025365; Wed, 2 Aug 2006 15:01:37 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <0FA975F2D8295A448BE3ADC161244657A1AD57@esebe199.NOE.Nokia.com> X-Mailer: Eudora for Mac OS X (dev alpha) X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Wed, 2 Aug 2006 15:00:50 -0700 To: Arnt Gulbrandsen , lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] WGLC compress-02 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: R.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 At 11:37 PM +0200 8/2/06, Arnt Gulbrandsen wrote: >> I thought the draft prohibited unsolicited responses after seeing >> COMPRESS. Likely I'm thinking of something else. But perhaps we >> should disallow this? > > The draft does not prohibit unsolicited responses after the client > sends compress (before the server receives it), and that cannot be > prohibited. Of course we can't prohibit sending unsolicited responses between when the client sent COMPRESS and when the server sees it. I was talking about after the server sees it. I was thinking perhaps we could prohibit unsolicited responses starting at the time that, after the server has seen COMPRESS, it has sent the tagged response to all outstanding commands, and ending at the time after it has sent the tagged response to COMPRESS. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- The two most common elements in the universe are hydrogen and stupidity. --Harlan Ellison _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Aug 02 18:19:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8P3i-0003jN-MV; Wed, 02 Aug 2006 18:19:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8P3h-0003fn-JL for lemonade@ietf.org; Wed, 02 Aug 2006 18:19:21 -0400 Received: from smtp-out.sendmail.com ([209.246.26.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8P3g-0002h9-80 for lemonade@ietf.org; Wed, 02 Aug 2006 18:19:21 -0400 Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.2.3/Switch-3.2.0) with ESMTP id k72MJB6p026421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Aug 2006 15:19:11 -0700 X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com k72MJB6p026421 DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1154557153; bh=VM32EtyIptUADBgBuOsb+DWU03E=; h=X-DomainKeys: DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:In-Reply-To: Message-ID:References:MIME-Version:Content-Type; b=rI+2Izf3J5KQ5ZoA BuqO10vy2BjOYhcngm/a9Zx/NQw44wb8ZTP2ySMdjz9aSv7Yk7zgxImSV7kcyJ4MKu3 mr7fKnD1rgGMGqIJlpT7o8sh8hhpXuX6omkvNKXrZUnpnsVwXuiN//ETUOzk6r7ZAzL FoQBFG3XKVmd4tx9paB4A= X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com k72MJB6p026421 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type; b=q9AjQrBD3hzrjm4TmJz0djnsH31dOtQqBOI/nExvFDeV2vpeMMLBSJdkRS2a5//Mt kzPWI2h038p2VV3i6cPLbPLChI0Bb837rqCPPQcybPbdzMzc/K0OU8KKcBW86WhTb1w 3xziBVdKk4+yJu3rI6FTvZ3Cr7Q4C9zZEVc3FT0= Date: Wed, 2 Aug 2006 15:19:11 -0700 From: Philip Guenther X-X-Sender: guenther@lab.smi.sendmail.com To: Randall Gellens Subject: Re: [lemonade] WGLC compress-02 In-Reply-To: Message-ID: <20060802151447.A26250@lab.smi.sendmail.com> References: <0FA975F2D8295A448BE3ADC161244657A1AD57@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 On Wed, 2 Aug 2006, Randall Gellens wrote: > At 11:37 PM +0200 8/2/06, Arnt Gulbrandsen wrote: ... >> The draft does not prohibit unsolicited responses after the client sends >> compress (before the server receives it), and that cannot be prohibited. > > Of course we can't prohibit sending unsolicited responses between when the > client sent COMPRESS and when the server sees it. I was talking about after > the server sees it. I was thinking perhaps we could prohibit unsolicited > responses starting at the time that, after the server has seen COMPRESS, it > has sent the tagged response to all outstanding commands, and ending at the > time after it has sent the tagged response to COMPRESS. The moment when the server reads the COMPRESS command is not an observable event, so it's impossible to tell from the TCP stream whether a server's sending of untagged responses between the final tagged response and the tagged response to COMPRESS was legal or not. Therefore the ban you describe would't help clients in any way as they would still have to handle such untagged responses. Philip Guenther _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Aug 02 18:21:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8P5X-0006LW-DO; Wed, 02 Aug 2006 18:21:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8P5W-0006LR-8D for lemonade@ietf.org; Wed, 02 Aug 2006 18:21:14 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G8P5U-0002rF-TO for lemonade@ietf.org; Wed, 02 Aug 2006 18:21:14 -0400 X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-12.tower-120.messagelabs.com!1154557271!14375846!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 15369 invoked from network); 2 Aug 2006 22:21:11 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-12.tower-120.messagelabs.com with SMTP; 2 Aug 2006 22:21:11 -0000 Received: from [135.91.110.64] (thansen-n.mt.att.com[135.91.110.64](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20060802222111gw1003joghe> (Authid: tony); Wed, 2 Aug 2006 22:21:11 +0000 Message-ID: <44D12554.9010801@att.com> Date: Wed, 02 Aug 2006 18:21:08 -0400 From: Tony Hansen User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: lemonade@ietf.org Subject: Re: [lemonade] WGLC compress-02 References: <0FA975F2D8295A448BE3ADC161244657A1AD57@esebe199.NOE.Nokia.com> In-Reply-To: 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: de4f315c9369b71d7dd5909b42224370 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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: > Of course we can't prohibit sending unsolicited responses between when > the client sent COMPRESS and when the server sees it. I was talking > about after the server sees it. I was thinking perhaps we could > prohibit unsolicited responses starting at the time that, after the > server has seen COMPRESS, it has sent the tagged response to all > outstanding commands, and ending at the time after it has sent the > tagged response to COMPRESS. Why? The client will have to handle any unsolicited responses that were in the pipeline anyway. So why have a prohibition on the server generating some more before it sends the OK response? It seems like a development choice for the server as to which way is easier, and has no affect on the client implementation. Tony Hansen tony@att.com _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Aug 02 18:43:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8PRK-00018M-BQ; Wed, 02 Aug 2006 18:43:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8PRI-000189-Vz for lemonade@ietf.org; Wed, 02 Aug 2006 18:43:44 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8PRG-0004cg-Bd for lemonade@ietf.org; Wed, 02 Aug 2006 18:43:44 -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 k72Mheea030173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 2 Aug 2006 15:43:41 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k72Mha5R013555; Wed, 2 Aug 2006 15:43:40 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <20060802142807.O26250@lab.smi.sendmail.com> References: <0FA975F2D8295A448BE3ADC161244657A1AD57@esebe199.NOE.Nokia.com> <20060802142807.O26250@lab.smi.sendmail.com> X-Mailer: Eudora for Mac OS X (dev alpha) X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Wed, 2 Aug 2006 15:40:00 -0700 To: Philip Guenther From: Randall Gellens Subject: Re: [lemonade] WGLC compress-02 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 At 2:30 PM -0700 8/2/06, Philip Guenther wrote: > On Wed, 2 Aug 2006, Randall Gellens wrote: > ... >> I thought the draft prohibited unsolicited responses after seeing >> COMPRESS. Likely I'm thinking of something else. But perhaps we >> should disallow this? > > How can the server know that the client is going to send COMPRESS > next? The restriction you suggest would effectively ban sending of > untagged responses when no commands are pending. No, I said "seeing" not "sending". Meaning after the server sees COMPRESS. Of course the server can't know what the client is about to do :-) But as Tony has pointed out none of this is needed. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Rank of Catwoman among the "superheroes" 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 Wed Aug 02 18:43:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8PRK-00018W-Gt; Wed, 02 Aug 2006 18:43:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8PRI-000187-VN for lemonade@ietf.org; Wed, 02 Aug 2006 18:43:44 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8PRG-0004cf-Ba for lemonade@ietf.org; Wed, 02 Aug 2006 18:43:44 -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 k72MhcaZ030161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 2 Aug 2006 15:43:39 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k72Mha5P013555; Wed, 2 Aug 2006 15:43:37 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <44D118DB.1060601@att.com> References: <0FA975F2D8295A448BE3ADC161244657A1AD57@esebe199.NOE.Nokia.com> <44D118DB.1060601@att.com> X-Mailer: Eudora for Mac OS X (dev alpha) X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Wed, 2 Aug 2006 15:38:17 -0700 To: Tony Hansen From: Randall Gellens Subject: Re: [lemonade] WGLC compress-02 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: 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 At 5:27 PM -0400 8/2/06, Tony Hansen wrote: > I don't see the problem with unsolicited responses arriving before the > "x OK Compression starting now" response. They just can't > be compressed > and should be treated the same way as any other unsolicited responses to > any other command. You're right -- there's no problem; data is compressed starting when the server sends the tagged OK to COMPRESS. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Violence is the last refuge of the incompetent. Salvador Hardin _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Aug 02 18:43:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8PRK-00018M-BQ; Wed, 02 Aug 2006 18:43:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8PRI-000189-Vz for lemonade@ietf.org; Wed, 02 Aug 2006 18:43:44 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8PRG-0004cg-Bd for lemonade@ietf.org; Wed, 02 Aug 2006 18:43:44 -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 k72Mheea030173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 2 Aug 2006 15:43:41 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k72Mha5R013555; Wed, 2 Aug 2006 15:43:40 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <20060802142807.O26250@lab.smi.sendmail.com> References: <0FA975F2D8295A448BE3ADC161244657A1AD57@esebe199.NOE.Nokia.com> <20060802142807.O26250@lab.smi.sendmail.com> X-Mailer: Eudora for Mac OS X (dev alpha) X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Wed, 2 Aug 2006 15:40:00 -0700 To: Philip Guenther From: Randall Gellens Subject: Re: [lemonade] WGLC compress-02 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 At 2:30 PM -0700 8/2/06, Philip Guenther wrote: > On Wed, 2 Aug 2006, Randall Gellens wrote: > ... >> I thought the draft prohibited unsolicited responses after seeing >> COMPRESS. Likely I'm thinking of something else. But perhaps we >> should disallow this? > > How can the server know that the client is going to send COMPRESS > next? The restriction you suggest would effectively ban sending of > untagged responses when no commands are pending. No, I said "seeing" not "sending". Meaning after the server sees COMPRESS. Of course the server can't know what the client is about to do :-) But as Tony has pointed out none of this is needed. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Rank of Catwoman among the "superheroes" 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 Wed Aug 02 18:43:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8PRK-00018W-Gt; Wed, 02 Aug 2006 18:43:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8PRI-000187-VN for lemonade@ietf.org; Wed, 02 Aug 2006 18:43:44 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8PRG-0004cf-Ba for lemonade@ietf.org; Wed, 02 Aug 2006 18:43:44 -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 k72MhcaZ030161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 2 Aug 2006 15:43:39 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k72Mha5P013555; Wed, 2 Aug 2006 15:43:37 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <44D118DB.1060601@att.com> References: <0FA975F2D8295A448BE3ADC161244657A1AD57@esebe199.NOE.Nokia.com> <44D118DB.1060601@att.com> X-Mailer: Eudora for Mac OS X (dev alpha) X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Wed, 2 Aug 2006 15:38:17 -0700 To: Tony Hansen From: Randall Gellens Subject: Re: [lemonade] WGLC compress-02 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: 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 At 5:27 PM -0400 8/2/06, Tony Hansen wrote: > I don't see the problem with unsolicited responses arriving before the > "x OK Compression starting now" response. They just can't > be compressed > and should be treated the same way as any other unsolicited responses to > any other command. You're right -- there's no problem; data is compressed starting when the server sends the tagged OK to COMPRESS. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Violence is the last refuge of the incompetent. Salvador Hardin _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Aug 02 18:49:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8PWX-0006Ze-Nr; Wed, 02 Aug 2006 18:49:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8PWX-0006ZZ-2U for lemonade@ietf.org; Wed, 02 Aug 2006 18:49:09 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8PWU-00054v-Lm for lemonade@ietf.org; Wed, 02 Aug 2006 18:49:09 -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 k72Mn37e000418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 2 Aug 2006 15:49:05 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k72MmxI1008658; Wed, 2 Aug 2006 15:49:02 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <20060802151447.A26250@lab.smi.sendmail.com> References: <0FA975F2D8295A448BE3ADC161244657A1AD57@esebe199.NOE.Nokia.com> <20060802151447.A26250@lab.smi.sendmail.com> X-Mailer: Eudora for Mac OS X (dev alpha) X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Wed, 2 Aug 2006 15:48:17 -0700 To: Philip Guenther From: Randall Gellens Subject: Re: [lemonade] WGLC compress-02 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: 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 At 3:19 PM -0700 8/2/06, Philip Guenther wrote: > The moment when the server reads the COMPRESS command is not an > observable event, so it's impossible to tell from the TCP stream > whether a server's sending of untagged responses between the final > tagged response and the tagged response to COMPRESS was legal or > not. Well, we often have prohibitions that are not strictly observable from the TCP stream, for example, SMTP requires servers to safeguard messages. How can such a thing be observed on the wire? Here is an excerpt from RFC 2821: 6.1 Reliable Delivery and Replies by Email When the receiver-SMTP accepts a piece of mail (by sending a "250 OK" message in response to DATA), it is accepting responsibility for delivering or relaying the message. It must take this responsibility seriously. It MUST NOT lose the message for frivolous reasons, such as because the host later crashes or because of a predictable resource shortage. -- 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 Wed Aug 02 20:42:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8RI9-0000qX-6U; Wed, 02 Aug 2006 20:42:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8RI7-0000pl-MA for lemonade@ietf.org; Wed, 02 Aug 2006 20:42:23 -0400 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8RI6-0000Kv-6i for lemonade@ietf.org; Wed, 02 Aug 2006 20:42:23 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M5IWUQ8NNK00K5OH@mauve.mrochek.com> for lemonade@ietf.org; Wed, 2 Aug 2006 17:42:18 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1154565738; h=Date: From:Subject:MIME-version:Content-type; b=fZVXS9F/o9PjBExLxwa63svqZ rfgBfmEHoS40bfD2tftPCNAbI00FGJT9Cf8HofXanGBZltB4RWDQdyNuF4YNg== Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M5IK8LHHC00008CX@mauve.mrochek.com>; Wed, 02 Aug 2006 17:42:15 -0700 (PDT) To: Arnt Gulbrandsen Message-id: <01M5IWUONZAS0008CX@mauve.mrochek.com> Date: Wed, 02 Aug 2006 17:13:35 -0700 (PDT) From: Ned Freed Subject: Re: [lemonade] Re: WGLC compress-02 IANA registry In-reply-to: "Your message dated Wed, 02 Aug 2006 10:18:19 +0200" MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <330A23D8336C0346B5C1A5BB19666647034EECEB@ATLANTIS.Brooktrout.com> <44C01838.4030303@isode.com> <6483.1153478826.555212@invsysm1> <44C0B335.5030102@isode.com> <20060801164005.GD7059@oryx.com> <01M5HL4MFZY20008CX@mauve.mrochek.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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 > Thinking about it again: > If I create a registry, the IANA has to do that. If I modify > comp-meth-tls, the IANA has to do that. Seems about the same, with > modification perhaps a touch more work since it's less routine. Generalizations here are difficult since the staff and abilities of IANA have changed considerably over time, but my experience has been more or less the exact opposite: Getting new registries created has proved to be harder than tweaking an existing registry. The key factor in how difficult registry creation and/or tweaking seems to be the complexity of the registration process itself. And this no longer seems to be the problem it used to be now that we have various canned models available. > If I > don't create a registry, the IANA needs to do nothing now, but the > result is different from several other IMAP extensions (SORT and THREAD > notably), which is arguably inferior. (Yes, I know I'm a bit fascist > about this consistency thing.) I like consistency too, but I'm more concerned about having a consistent set of registries for the things we do register than I am for having registries for all things that might ever get extended. > For each new algorithm, which I fervently hope never happens, the IANA > has to add an antry to one registry. Either to imap4-capabilities, > comp-meth-tls or comp-meth-imap. Seems the same. Assuming a new algorithm comes along, wouldn't it make sense to register it for use in both TLS and COMPRESS? It isn't much more work, but it is more work. > So I think it doesn't really make a difference for the IANA. I'm not sure the degree of difference of work is the main factor here in any case. I want things to work well even if that means more work for all concerned. > I hear a couple of people wanting a registry and a couple not. I can't > confidently say one side is stronger. I've set the reply-to field on > this message to emulate a hum, so if everyone with an opinion can just > check one, I can make a quick -04 revision if needed: > [ ] hum for piggybacking on imap4-capabilities using > "COMPRESS=" entries, like -02 revision > [ ] hum for new registry, like -03 revision, and like SORT/THREAD > [x] hum for modifying and using comp-meth-tls registry, without > precedent AFAIK I vote for the third of these and I also note that there are precedents. The most obvious one is the media types registry. This was originally specific to MIME, but was subsequently adopted for use with HTTP, then with SDP/RTSP/SIP and now they're all over the place. Defining a single registry that's heavily used and is defined appropriately for some very different protocols has not been easy, but the alternative of having multiple overlapping registries for media types is just too awful to contemplate. Another case I'm familiar with is the content disposition registry. This was originally set up for email but is now used by SIP and probably others. And this one points out the risks of having separate registries for the same general sorts of things: We weren't paying attention when SIP started using disposition values and we came within inches of approving what amounted to conflicting registrations. Now, in the present case it is likely that there will be no additional values registered, or a least very few will be. So this may well be a largely academic exercise, and I can't get excited if we decide on two registries. But I do think it is the wrong choice. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Aug 02 21:15:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Rnw-0002es-Gk; Wed, 02 Aug 2006 21:15:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Rnv-0002dm-3a for lemonade@ietf.org; Wed, 02 Aug 2006 21:15:15 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G8Rnt-0004Ur-LF for lemonade@ietf.org; Wed, 02 Aug 2006 21:15:15 -0400 X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-10.tower-120.messagelabs.com!1154567311!2643549!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 14500 invoked from network); 3 Aug 2006 01:08:31 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-10.tower-120.messagelabs.com with SMTP; 3 Aug 2006 01:08:31 -0000 Received: from [135.210.128.206] (unknown[135.210.128.206](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20060803010830gw1003jogue> (Authid: tony); Thu, 3 Aug 2006 01:08:31 +0000 Message-ID: <44D14C8A.4040700@att.com> Date: Wed, 02 Aug 2006 21:08:26 -0400 From: Tony Hansen User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 CC: lemonade@ietf.org Subject: Re: [lemonade] Re: WGLC compress-02 IANA registry References: <330A23D8336C0346B5C1A5BB19666647034EECEB@ATLANTIS.Brooktrout.com> <44C01838.4030303@isode.com> <6483.1153478826.555212@invsysm1> <44C0B335.5030102@isode.com> <20060801164005.GD7059@oryx.com> <01M5HL4MFZY20008CX@mauve.mrochek.com> <01M5IWUONZAS0008CX@mauve.mrochek.com> In-Reply-To: <01M5IWUONZAS0008CX@mauve.mrochek.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: a87a9cdae4ac5d3fbeee75cd0026d632 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Using a separate registry, I was trying to make it harder to add future algorithms. If we modify comp-meth-tls, is that going to suddenly swamp us with lots of potential algorithms and make interop testing harder? Tony Hansen tony@att.com Ned Freed wrote: >> Thinking about it again: > >> If I create a registry, the IANA has to do that. If I modify >> comp-meth-tls, the IANA has to do that. Seems about the same, with >> modification perhaps a touch more work since it's less routine. > > Generalizations here are difficult since the staff and abilities of IANA > have > changed considerably over time, but my experience has been more or less the > exact opposite: Getting new registries created has proved to be harder than > tweaking an existing registry. > > The key factor in how difficult registry creation and/or tweaking seems > to be > the complexity of the registration process itself. And this no longer > seems to > be the problem it used to be now that we have various canned models > available. > >> If I >> don't create a registry, the IANA needs to do nothing now, but the >> result is different from several other IMAP extensions (SORT and THREAD >> notably), which is arguably inferior. (Yes, I know I'm a bit fascist >> about this consistency thing.) > > I like consistency too, but I'm more concerned about having a consistent > set of > registries for the things we do register than I am for having registries > for > all things that might ever get extended. > >> For each new algorithm, which I fervently hope never happens, the IANA >> has to add an antry to one registry. Either to imap4-capabilities, >> comp-meth-tls or comp-meth-imap. Seems the same. > > Assuming a new algorithm comes along, wouldn't it make sense to register > it for > use in both TLS and COMPRESS? It isn't much more work, but it is more work. > >> So I think it doesn't really make a difference for the IANA. > > I'm not sure the degree of difference of work is the main factor here in > any > case. I want things to work well even if that means more work for all > concerned. > >> I hear a couple of people wanting a registry and a couple not. I can't >> confidently say one side is stronger. I've set the reply-to field on >> this message to emulate a hum, so if everyone with an opinion can just >> check one, I can make a quick -04 revision if needed: > >> [ ] hum for piggybacking on imap4-capabilities using >> "COMPRESS=" entries, like -02 revision > >> [ ] hum for new registry, like -03 revision, and like SORT/THREAD > >> [x] hum for modifying and using comp-meth-tls registry, without >> precedent AFAIK > > I vote for the third of these and I also note that there are precedents. > The > most obvious one is the media types registry. This was originally > specific to > MIME, but was subsequently adopted for use with HTTP, then with > SDP/RTSP/SIP > and now they're all over the place. > > Defining a single registry that's heavily used and is defined > appropriately for > some very different protocols has not been easy, but the alternative of > having > multiple overlapping registries for media types is just too awful to > contemplate. > > Another case I'm familiar with is the content disposition registry. This > was > originally set up for email but is now used by SIP and probably others. And > this one points out the risks of having separate registries for the same > general sorts of things: We weren't paying attention when SIP started using > disposition values and we came within inches of approving what amounted to > conflicting registrations. > > Now, in the present case it is likely that there will be no additional > values registered, or a least very few will be. So this may well be a > largely > academic exercise, and I can't get excited if we decide on two registries. > But I do think it is the wrong choice. > > Ned > > _______________________________________________ > 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 Aug 02 21:31:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8S41-0000U8-3P; Wed, 02 Aug 2006 21:31:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8S3z-0000U2-9w for lemonade@ietf.org; Wed, 02 Aug 2006 21:31:51 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8S3y-0006V0-0H for lemonade@ietf.org; Wed, 02 Aug 2006 21:31:51 -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 k731VmWG021646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 2 Aug 2006 18:31:49 -0700 Received: from [129.46.172.15] (vpn-10-50-0-116.qualcomm.com [10.50.0.116]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k731VlrL019465 for ; Wed, 2 Aug 2006 18:31:48 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <44D12554.9010801@att.com> References: <0FA975F2D8295A448BE3ADC161244657A1AD57@esebe199.NOE.Nokia.com> <44D12554.9010801@att.com> X-Mailer: Eudora for Mac OS X (dev alpha) X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Wed, 2 Aug 2006 18:31:31 -0700 To: lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] WGLC compress-02 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: d17f825e43c9aed4fd65b7edddddec89 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 thinking about this some more, the prohibition might be needed on the client side, not the server. The client should not send any commands to the server between the time it sends COMPRESS and when it gets the tagged response for it. Otherwise there is ambiguity on the server side as to if the data was compressed or not, since the server doesn't know when the client saw the response. -- 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 Wed Aug 02 22:52:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8TKE-0002rm-7e; Wed, 02 Aug 2006 22:52:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8TKC-0002rb-DI for lemonade@ietf.org; Wed, 02 Aug 2006 22:52:40 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G8TKB-0007im-4o for lemonade@ietf.org; Wed, 02 Aug 2006 22:52:40 -0400 X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-12.tower-121.messagelabs.com!1154573558!12022417!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 32549 invoked from network); 3 Aug 2006 02:52:38 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-12.tower-121.messagelabs.com with SMTP; 3 Aug 2006 02:52:38 -0000 Received: from [135.210.82.7] (unknown[135.210.82.7](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20060803025238gw1003joh3e> (Authid: tony); Thu, 3 Aug 2006 02:52:38 +0000 Message-ID: <44D164F3.8030800@att.com> Date: Wed, 02 Aug 2006 22:52:35 -0400 From: Tony Hansen User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: lemonade@ietf.org Subject: Re: [lemonade] WGLC compress-02 References: <0FA975F2D8295A448BE3ADC161244657A1AD57@esebe199.NOE.Nokia.com> <44D12554.9010801@att.com> In-Reply-To: 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: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 I agree with. Tony Hansen tony@att.com Randall Gellens wrote: > In thinking about this some more, the prohibition might be needed on the > client side, not the server. The client should not send any commands to > the server between the time it sends COMPRESS and when it gets the > tagged response for it. Otherwise there is ambiguity on the server > side as to if the data was compressed or not, since the server doesn't > know when the client saw the response. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Aug 02 22:59:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8TQT-0004Cu-25; Wed, 02 Aug 2006 22:59:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8TQR-0004Ck-Ue for lemonade@ietf.org; Wed, 02 Aug 2006 22:59:07 -0400 Received: from smtp-out.sendmail.com ([209.246.26.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8TQQ-0008N3-IH for lemonade@ietf.org; Wed, 02 Aug 2006 22:59:07 -0400 Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.2.3/Switch-3.2.0) with ESMTP id k732wwOR020096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Aug 2006 19:58:58 -0700 X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com k732wwOR020096 DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1154573939; bh=MN5EofiQ0oq51e3ozT7QXX6IyMk=; h=X-DomainKeys: DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:In-Reply-To: Message-ID:References:MIME-Version:Content-Type; b=hXVZB+dEc8u68zPT jNIjuNvi62XE7EW8CWYLqRiUlXdoMnz0EZNVRo7pO418k/1nHsg8hJwgAyiwEmR1+of fHrh+6AJrw3BCAnuA6v+hjM7oWMBZH25a/EYB3tIDeld55GkjVwHI2pGlaQCdn0smhh DSx7Wx/d5Zoy559sa9OSI= X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com k732wwOR020096 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type; b=dOvTAeQmmEUxi8WOsaKtmela+GtGw3sK1avyK1WPb/Yk2vbYwCkQgZ0+bXMQSy/+h drAvUjgb/bxcEgMp3geK761IV5ck89sAYe4Ul6ugVvMuinlwQqGHLWRHCo/nsd9MUfp MjZa23FYiyoDB8nkoKQirV5eQ1KUX7CDtCsYNgo= Date: Wed, 2 Aug 2006 19:58:58 -0700 From: Philip Guenther X-X-Sender: guenther@lab.smi.sendmail.com To: Randall Gellens Subject: Re: [lemonade] WGLC compress-02 In-Reply-To: Message-ID: <20060802195558.N26250@lab.smi.sendmail.com> References: <0FA975F2D8295A448BE3ADC161244657A1AD57@esebe199.NOE.Nokia.com> <44D12554.9010801@att.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 Wed, 2 Aug 2006, Randall Gellens wrote: > In thinking about this some more, the prohibition might be needed on the > client side, not the server. The client should not send any commands to the > server between the time it sends COMPRESS and when it gets the tagged > response for it. Otherwise there is ambiguity on the server side as to if > the data was compressed or not, since the server doesn't know when the client > saw the response. Yep. Arnt already put such a restriction in. To quote compress-03: The client MUST NOT send any commands until it has seen the result of COMPRESS. If the response was OK, the client MUST compress starting with the first command after COMPRESS, and the server MUST compress starting with the first response after the OK. Philip Guenther _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Aug 03 04:30:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8YbH-0005RA-Si; Thu, 03 Aug 2006 04:30:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8YbG-0005KS-Ke for lemonade@ietf.org; Thu, 03 Aug 2006 04:30:38 -0400 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8YbF-0004SB-Ad for lemonade@ietf.org; Thu, 03 Aug 2006 04:30:38 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.50) id 1G8YbE-0002GM-Fe; Thu, 03 Aug 2006 08:30:36 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 52164498003; Thu, 3 Aug 2006 09:35:41 +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 15855-06; Thu, 3 Aug 2006 09:35:31 +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 A1CAF498002; Thu, 3 Aug 2006 09:35:31 +0100 (BST) Date: Thu, 03 Aug 2006 09:30:25 +0100 Subject: Re: [lemonade] Re: WGLC compress-02 IANA registry References: <330A23D8336C0346B5C1A5BB19666647034EECEB@ATLANTIS.Brooktrout.com> <44C01838.4030303@isode.com> <6483.1153478826.555212@invsysm1> <44C0B335.5030102@isode.com> <20060801164005.GD7059@oryx.com> <01M5HL4MFZY20008CX@mauve.mrochek.com> <01M5IWUONZAS0008CX@mauve.mrochek.com> <44D14C8A.4040700@att.com> In-Reply-To: <44D14C8A.4040700@att.com> MIME-Version: 1.0 Message-Id: <10036.1154593826.325499@peirce.dave.cridland.net> From: Dave Cridland To: Tony Hansen 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 Thu Aug 3 02:08:26 2006, Tony Hansen wrote: > Using a separate registry, I was trying to make it harder to add > future > algorithms. > > If we modify comp-meth-tls, is that going to suddenly swamp us with > lots > of potential algorithms and make interop testing harder? I had assumed that if we allow for multiple algorithms by any mechanism, then DEFLATE would become a Mandatory To Implement algorithm. 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 Aug 03 05:05:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Z8n-0000Sf-Af; Thu, 03 Aug 2006 05:05:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Z8m-0000Rf-LK for lemonade@ietf.org; Thu, 03 Aug 2006 05:05:16 -0400 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8Z8i-0001A8-0w for lemonade@ietf.org; Thu, 03 Aug 2006 05:05:16 -0400 Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.3]) by smarthost.yourcomms.net (8.11.7p1+Sun/8.11.6) with ESMTP id k738rB629963 for ; Thu, 3 Aug 2006 09:53:11 +0100 (BST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: RE: [lemonade] WGLC compress-02 Date: Thu, 3 Aug 2006 10:04:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <22C8A0D5D5E095449AB509FE777B5F80029DF07E@svr-exchange.avocado.emccsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] WGLC compress-02 Thread-Index: Aca2nI+vZelDcd42Q62NmZwZr/kYJQAPvZNg From: "Ben Last" To: "Randall Gellens" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Randall Gellens [mailto:randy@qualcomm.com] wrote, at 03 August 2006 02:32: >In thinking about this some more, the prohibition might be needed on the client side, not the server. >The client should not send any commands to the server between the time it sends COMPRESS and when it >gets the tagged response for it. Otherwise there is ambiguity on the server side as to if the data >was compressed or not, since the server doesn't know when the client saw the response. Agreed, fervently. Also the client won't know whether the COMPRESS command was accepted (or provoked a NO or BAD response), so it can't begin compression anyway. Regards Ben EMCC Software Ltd _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Aug 03 05:14:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8ZHp-0001H4-AE; Thu, 03 Aug 2006 05:14:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8ZHn-0001E3-R0 for lemonade@ietf.org; Thu, 03 Aug 2006 05:14:35 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8ZHl-0006ud-Au for lemonade@ietf.org; Thu, 03 Aug 2006 05:14:35 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 4E7CE4AD56; Thu, 3 Aug 2006 11:14:32 +0200 (CEST) Message-Id: <3emM1prvqfgR5TPQiW+QPQ.md5@libertango.oryx.com> Date: Thu, 3 Aug 2006 11:14:36 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Re: WGLC compress-02 IANA registry References: <330A23D8336C0346B5C1A5BB19666647034EECEB@ATLANTIS.Brooktrout.com> <44C01838.4030303@isode.com> <6483.1153478826.555212@invsysm1> <44C0B335.5030102@isode.com> <20060801164005.GD7059@oryx.com> <01M5HL4MFZY20008CX@mauve.mrochek.com> <01M5IWUONZAS0008CX@mauve.mrochek.com> <44D14C8A.4040700@att.com> <10036.1154593826.325499@peirce.dave.cridland.net> In-Reply-To: <10036.1154593826.325499@peirce.dave.cridland.net> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Tony Hansen X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 Aug 3 02:08:26 2006, Tony Hansen wrote: >> Using a separate registry, I was trying to make it harder to add >> future algorithms. >> >> If we modify comp-meth-tls, is that going to suddenly swamp us with >> lots of potential algorithms and make interop testing harder? > > I had assumed that if we allow for multiple algorithms by any > mechanism, then DEFLATE would become a Mandatory To Implement > algorithm. I forgot to put that in. Sorry. There's also a wrong reference in -03, so a -04 is necessary. I'll do it once the chair have interpreted yesterday's hummish thingy. Possibly tomorrow, more likely Tuesday. But Tony is right. To test interoperation, we need to test the algorithm each client-server pair chooses to use. If a given client and server both support LZS and DEFLATE, and the client prefers LZS (see comp-meth-ids), then we need to to test that they correctly choose LZS when talking to each other, and that their LZS implementations interoperate. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Aug 03 05:57:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8ZxY-0001EY-2D; Thu, 03 Aug 2006 05:57:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Zx0-0000ef-GB for lemonade@ietf.org; Thu, 03 Aug 2006 05:57:10 -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 1G8ZDt-0005vD-5S for lemonade@ietf.org; Thu, 03 Aug 2006 05:10:33 -0400 Received: from smarthost.yourcomms.net ([195.8.160.124]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G8Z5c-0007y7-2F for lemonade@ietf.org; Thu, 03 Aug 2006 05:02:00 -0400 Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.3]) by smarthost.yourcomms.net (8.11.7p1+Sun/8.11.6) with ESMTP id k738nx629552 for ; Thu, 3 Aug 2006 09:49:59 +0100 (BST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: RE: [lemonade] WGLC compress-02 Date: Thu, 3 Aug 2006 10:01:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <22C8A0D5D5E095449AB509FE777B5F80029DF07A@svr-exchange.avocado.emccsoft.com> In-Reply-To: <44D118DB.1060601@att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] WGLC compress-02 Thread-Index: Aca2enxcRtSxEx8JSX6lFfUrbo9K0QAYJiQw From: "Ben Last" To: "Tony Hansen" X-Spam-Score: -1.6 (-) 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 Tony Hansen [mailto:tony@att.com] wrote, at 02 August 2006 22:28: >I don't see the problem with unsolicited responses arriving before the "x OK Compression starting now" >response. They just can't be compressed and should be treated the same way as any other unsolicited >responses to any other command. Speaking as a client developer here, I agree: as long as the client has some way in which it can detect the change from uncompressed to compressed server responses (ie, the x OK to the compress command), life is simple. No client should assume that, after sending the compression start command, compression will start: the server is always at liberty to say NO or BAD (and they so often do... :) Regards ben _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Aug 03 06:35:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8aY8-0007Jk-IZ; Thu, 03 Aug 2006 06:35:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8aXN-0006gN-Qg for lemonade@ietf.org; Thu, 03 Aug 2006 06:34:45 -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 1G8ZDv-0005vD-1V for lemonade@ietf.org; Thu, 03 Aug 2006 05:10:35 -0400 Received: from smarthost.yourcomms.net ([195.8.160.124]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G8Z1X-0007tB-WD for lemonade@ietf.org; Thu, 03 Aug 2006 04:57:49 -0400 Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.3]) by smarthost.yourcomms.net (8.11.7p1+Sun/8.11.6) with ESMTP id k738ji629106 for ; Thu, 3 Aug 2006 09:45:45 +0100 (BST) Content-class: urn:content-classes:message Subject: RE: [lemonade] Notifications for multiple devices per user Date: Thu, 3 Aug 2006 09:57:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <22C8A0D5D5E095449AB509FE777B5F80029DF075@svr-exchange.avocado.emccsoft.com> In-Reply-To: X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Notifications for multiple devices per user Thread-Index: Aca2Retmok74JNJEQ7yLyT1jdzYtEAAk9lyg From: "Ben Last" To: "Mark Crispin" X-Spam-Score: -0.7 (/) 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 Mark Crispin wrote at 02 August 2006 16:12: >What you are really saying is: >A mail server vendor made a terrible design mistake in its implementation of IMAP >for LEMONADE, and now you expect the IMAP protocol to cover for this vendor's mistake. Actually, no, that's not what I'm saying. Mark, with all due respect, taking my argument to extremes and making a straw-man response to that extreme does not help the debate. What I am really saying is that there are systems out there, installed and running in the real world, that operate in certain ways, and allowing clients to detect those ways and deal with them is beneficial to real companies building real products for real users. The problem of detecting folders that should not be synchronized is an important one to mobile clients (where the consequences of repeated download are bad and can involve serious data charges for end users). The LEMONADE working group has such mobile client concerns as one of its reasons for being. Thus I was interested in discussing ways in which the problem might be addressed. I apologise for inadvertently pushing your buttons on the issue of Trash folders being bad: as I have previously stated, I tend to agree with you on that. >We should not break protocols to cover for vendor's broken products. I completely agree. At no point did I suggest that we do so. To reframe part of the problem, then, in a manner less contentious: are there any proposals for mechanisms by which a client can be aware that a folder has been renamed, so that it may avoid redownloading the entire contents of that folder? Best regards Ben EMCC Software Ltd _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Aug 03 07:03:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8az2-0004uw-M3; Thu, 03 Aug 2006 07:03:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8az1-0004q5-FQ for lemonade@ietf.org; Thu, 03 Aug 2006 07:03:19 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8ayz-0008Rx-PT for lemonade@ietf.org; Thu, 03 Aug 2006 07:03:19 -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 k73B31EH002103; Thu, 3 Aug 2006 14:03:02 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Aug 2006 14:03: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, 3 Aug 2006 14:03:01 +0300 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 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 3 Aug 2006 14:01:48 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657A9E684@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: Aca2RpEOxCSWhnwIRJim5KDXyZObjgAo0pkQ From: To: , X-OriginalArrivalTime: 03 Aug 2006 11:03:01.0341 (UTC) FILETIME=[62D6A8D0:01C6B6EC] X-Spam-Score: 0.2 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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 Mark, I think "What if there was a mechanism in IMAP to set the secret backdoor that = allows complete root-level access to the entire system? Or to send = unlimited anonymous email?" is pretty far from what we are discussing here. Nobody asks for secret = backdoors - all that we want is the possibility to identify special = mailboxes. "Do you honestly believe that having such mechanisms defined wouldn't = encourage some fool to implement them?" Yes, exactly: implementation is the intent. Why would we propose such = thing otherwise? Call me a fool if You like, but we want to provide a = better email experience where the emails are organized in a better way. = The better way here means that specific emails are put to their = respective mailbox. Could You elaborate this ""terrible design mistake in its implementation = of IMAP" - I am confused. I thought that it is the IMAP standard that = lacks the possibility of identifying special mailboxes. "The only appropriate answer to such a request is "no". 1000 times = "no"." Just keeping saying no does not solve the problem. Providing a solution = does. Could You tell me how will different client implementations know which = mailbox they will use to store the "trash", "sent", "junk", etc emails = in an interoperable manner? (Consider now foreign language clients - not = English ones where the mailboxes are probably called "trash", "sent" and = "junk". "Probably" indicates that it is an issue with English clients as = well.) "We should not break protocols to cover for vendor's broken products."" Identifying the special mailboxes does not break the protocol in any = way. In fact, identifying the special mailboxes has nothing to do with = the protocol itself - it is merely a configuration setting so that each = client that connects knows how to behave. 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 Mark Crispin [mailto:mrc@CAC.Washington.EDU]=20 Sent: 02 August, 2006 18:12 To: Ben Last Cc: lemonade@ietf.org Subject: RE: [lemonade] Notifications for multiple devices per user On Wed, 2 Aug 2006, Ben Last wrote: > I disagree here, and I guess we'll have to continue to differ: I don't = > see the way to identify the folder as any form of "blessing". What if = > there were a mechanism to identify folders that are "reserved for=20 > other clients, may do terrible things like implement a Trash and=20 > should not be synchronized to or attended to by other clients"? That=20 > would help address my concerns. What is there was a mechanism in IMAP to set the secret backdoor that = allows complete root-level access to the entire system? Or to send = unlimited anonymous email? Do you honestly believe that having such mechanisms defined wouldn't = encourage some fool to implement them? > And yet there is at least one major, industrial strength mail server,=20 > that uses LEMONADE IMAP to present itself to mobile clients that uses=20 > a Trash mailbox/view/whatever. This is a fact of the real world, and=20 > unfortunately we cannot make it go away. All I want to do is find a=20 > sensible, optimal way to work with what exists. What you are really saying is: A mail server vendor made a terrible design mistake in its = implementation of IMAP for LEMONADE, and now you expect the IMAP = protocol to cover for this vendor's mistake. The only appropriate answer to such a request is "no". 1000 times "no". We should not break protocols to cover for vendor's broken products. -- 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 Thu Aug 03 07:05:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8b1W-0006pr-2W; Thu, 03 Aug 2006 07:05:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8b1U-0006pl-9R for lemonade@ietf.org; Thu, 03 Aug 2006 07:05:52 -0400 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8b1S-00007G-QL for lemonade@ietf.org; Thu, 03 Aug 2006 07:05:52 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.50) id 1G8b1O-0006QM-Ct; Thu, 03 Aug 2006 11:05:46 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id BE311498003; Thu, 3 Aug 2006 12:10: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 17094-06; Thu, 3 Aug 2006 12:10: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 07616498002; Thu, 3 Aug 2006 12:10:43 +0100 (BST) Date: Thu, 03 Aug 2006 12:05:35 +0100 Subject: RE: [lemonade] Notifications for multiple devices per user References: =?US-ASCII?Q?<22C8A0D5D5E095449AB509FE777B5F800?= =?US-ASCII?Q?9DF075@svr-exchange.avocado.emccsoft.com>?= In-Reply-To: =?US-ASCII?Q?<22C8A0D5D5E095449AB509FE777B5F80?= =?US-ASCII?Q?29DF075@svr-exchange.avocado.emccsoft.com>?= MIME-Version: 1.0 Message-Id: <12665.1154603136.581551@peirce.dave.cridland.net> From: Dave Cridland To: Ben Last 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: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Enhancements to Internet email to support diverse service enivronments , Mark Crispin X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 Aug 3 09:57:10 2006, Ben Last wrote: > The problem of > detecting folders that should not be synchronized is an important > one to > mobile clients (where the consequences of repeated download are bad > and > can involve serious data charges for end users). There's a limited amount of support for this particular item in the subscription handling. I think that in general, this area could use some more examination, in particular I think that allowing a more arbitrary subscription mechanism might be very beneficial. Something akin to user-settable flags, but on mailboxes. (Of course, purely with that, you then get the additional problem that the client needs to have configuration available to know which keywords indicated that the client ought to be fully synchronizing, or merely presenting for ad-hoc access). Incidentally, *not* synchronizing message content - using a model much closer to online access - does yield considerably lower bandwidth. > To reframe part of the problem, then, in a manner less contentious: > are > there any proposals for mechanisms by which a client can be aware > that a > folder has been renamed, so that it may avoid redownloading the > entire > contents of that folder? No. It could relatively easily be done, however, by (for example) overloading the UIDVALIDITY to act as a mailbox identifier. (You'd need to add a CAPABILITY string, force it to be unique system-wide, and that's really about it - I'm not claiming this is bullet-proof, but I can't see any obvious flaws). That said, although it's very simple to do, I've not really seen mailboxes renamed sufficiently often to warrant the effort of doing even that, but I'll write up the idea in more detail if there's demand. The far more prevelant problem is where messages are copied by a third-party (ie, another client), since there's no way for a client to know that it has the message in cache already. Most solutions for this problem tend to involve a sufficiently large overhead that the solution outweighs the problem, 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 Aug 03 07:16:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8bBn-0007xY-4n; Thu, 03 Aug 2006 07:16:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8bBl-0007vr-VH for lemonade@ietf.org; Thu, 03 Aug 2006 07:16:29 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8bBl-00017j-Dg for lemonade@ietf.org; Thu, 03 Aug 2006 07:16:29 -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 k73BGPLs012432; Thu, 3 Aug 2006 14:16:28 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Aug 2006 14:16:23 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Aug 2006 14:16:22 +0300 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] WGLC compress-02 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 3 Aug 2006 14:15:50 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657A9E6CF@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] WGLC compress-02 Thread-Index: Aca1ztHJ7elWlpc8Sr2aYQLsSeaFRQBHZMoA From: To: , X-OriginalArrivalTime: 03 Aug 2006 11:16:22.0640 (UTC) FILETIME=[40732F00:01C6B6EE] X-Spam-Score: 0.2 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f 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, just two questions and two comments (see [Z=D6r] tags = below). 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: 02 August, 2006 03:58 To: Ordogh Zoltan (Nokia-TP-MSW/Tampere); lemonade@ietf.org Subject: RE: [lemonade] WGLC compress-02 At 11:14 AM +0300 7/31/06, <Zoltan.Ordogh@nokia.com> wrote: > > Section 3: > > "The client MUST NOT send any commands until it has seen=20 > the result > of COMPRESS." This is fine, but can the server=20 > send anything else in > the meantime? I mean I can turn it on at=20 > any time during the session. > > The server can't send anything else (such as an unsolicited response) = > in the meantime . This seems obvious but could be explicitly stated. > [Z=D6r] This is true only if You issue the command during login I = guess=20 > - if You issue it during some other time during the session, You might = > get other responses as well. The server can't send anything between the time it sees the COMPRESS = command and when it sends the response to it. So the only ambiguity = comes if the client has an outstanding command (one that it hasn't seen = the tagged response to).=20 Clients would see responses related to the outstanding command before = seeing responses to the COMPRESS, but presumably the client knows if it = has outstanding responses and won't get confused. This will need to be clarified when we do the SMTP COMPRESS draft, by = the way (pipeling and COMPRESS). [Z=D6r] Certainly pipelining is an issue and we are going to have to = deal with it any way. However, there might be a latency (we need to = think about mobile devices here) between the client issuing the COMPRESS = command and the server "seeing" it. Hence my dilemma. Client sends it, = fine, but there might be other server responses coming from the server = in the meantime (even after the server has "seen" the command since = there might be latency on the way back as well). So, I suggest adding = something like "The client MAY receive other responses from the server = before before receiving the result of the COMPRESS command. The client = MUST treat these "intermediate" responses as if the COMPRESS command was = not issued." Or, something like this. What do You think? > >From Your response below to my question below it seems that this=20 > command can be used only once - but the draft does not say that it is=20 > the login phase during which it has to be used when compression is=20 > desired. If the command succeeds, it can't be reissued.=20 See Section 3, where it says a BAD response is issued if COMPRESS is = already active. [Z=D6r] I think it would be beneficial to capture this fact "If the = command succeeds, it can't be reissued.". Turning on compression is one = thing -.You can turn it on only once, fine. But how about when the = compression method is to be changed (EG. DEFLATE to something else)? <- = Just to think about being future-proof. It can be issued at any time during the session, however. > Thank you. > > > > > Section 3 and section 5: > > How can it be turned off? > > By logging out and back in. The added complexity of allowing it to=20 > be turned off doesn't seem to be justified by the low utility. > [Z=D6r] Question: if I do a quick reconnect, will the compression = state=20 > be restored? (in which case disconnect will not help me much). I wouldn't expect this to be the case. It would need to be added to the = reconnect document in order to do so, and I can't see any benefit.=20 Plus, the reconnect document is morphing into a re-select. [Z=D6r] I did not see that "morphing" - probably it something I missed = during the meeting. If RECONNECT will be changed, it will not be an = issue, but if not, we need to address it one way or another. > Another thing is that when I store an email that contains an=20 > uncompressable (JPG, ZIP) file, I might want to switch compression off = > before uploading it, and turn it back on afterwards. I am sure that=20 > this has been discussed, but I do not seem to be able to find the=20 > related emails - so I ask it again to get the right answers. This is discussed in the document in Section 4.=20 The compressing side uses the zlib API to set the level to 0 before = sending such data, and resets it to a non-zero value afterwards. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Demagogue: One who preaches doctrines he knows to be untrue to men he knows to be idiots. --H.L. Mencken _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Aug 03 08:32:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8cNZ-0003yU-5z; Thu, 03 Aug 2006 08:32:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8cNX-0003yP-Qq for lemonade@ietf.org; Thu, 03 Aug 2006 08:32:43 -0400 Received: from smtp-out.sendmail.com ([209.246.26.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8cNW-0000CO-DL for lemonade@ietf.org; Thu, 03 Aug 2006 08:32:43 -0400 Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.2.3/Switch-3.2.0) with ESMTP id k73CWM4j008268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Aug 2006 05:32:23 -0700 X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com k73CWM4j008268 DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1154608345; bh=xH4ojmVqLqCY8CH8sQ91aMLQv4k=; h=X-DomainKeys: DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:In-Reply-To: Message-ID:References:MIME-Version:Content-Type; b=KMofGr/0LajUcsXD MUix3yoPQ8d2phSocA0mOUXuh93OgbEjrW1Y4Y8KA2MfRyPF1/9mWPh0QazpS7Ggkmr aKCXCxD09cJTiUxZKqm4b+Xsi4MUzfBXx8BS4Mne6ULkvOCBrKVKMmQoZxJewcNvqoc 6s6MLDsQg5B19LJyIo/yk= X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com k73CWM4j008268 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type; b=TUVNnW3Si1RksUHJxViAZ2PkDoPe1FokhEz/a4v/eanwWrb7wyJhNzOl7AcDmGCm2 Xr//eF/uqXItPYvisx2+qdGVxIaV25mAfs9vf18Mt9nj76Pp77v/ATO7V4J74DCFpRS OMEVAPzF2GlG/BepL9gpmP00Q9aZuRNexh4k2Ow= Date: Thu, 3 Aug 2006 05:32:22 -0700 From: Philip Guenther X-X-Sender: guenther@lab.smi.sendmail.com To: Dave Cridland Subject: RE: [lemonade] Notifications for multiple devices per user In-Reply-To: <12665.1154603136.581551@peirce.dave.cridland.net> Message-ID: <20060803050720.A26250@lab.smi.sendmail.com> References: =?US-ASCII?Q?<22C8A0D5D5E095449AB509FE777B5F800?= =?US-ASCII?Q?9DF075@svr-exchange.avocado.emccsoft.com>?= <12665.1154603136.581551@peirce.dave.cridland.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) 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 On Thu, 3 Aug 2006, Dave Cridland wrote: > On Thu Aug 3 09:57:10 2006, Ben Last wrote: >> The problem of >> detecting folders that should not be synchronized is an important one to >> mobile clients (where the consequences of repeated download are bad and >> can involve serious data charges for end users). I always assumed that synchronization would be a "default off" kind of setting. That is, only those folder that you explicitly told the client to synchronize would be synced. If nothing else, a client that made the opposite choice will be buried by any server that contains even a few mailing-list archives or---even better---a USENET news gateway. ("$4000 in data charges!?!?" "Yeah, but I got all of comp.lang.c on my phone...") So, before we launch into proposals for recognizing various special purpose mailboxes, how about some explanations of why the existence of these mailboxes should provoke such angst in clients? > There's a limited amount of support for this particular item in the > subscription handling. I think that in general, this area could use some more > examination, in particular I think that allowing a more arbitrary > subscription mechanism might be very beneficial. > > Something akin to user-settable flags, but on mailboxes. (Of course, purely > with that, you then get the additional problem that the client needs to have > configuration available to know which keywords indicated that the client > ought to be fully synchronizing, or merely presenting for ad-hoc access). mumble METADATA mumble >> To reframe part of the problem, then, in a manner less contentious: are >> there any proposals for mechanisms by which a client can be aware that a >> folder has been renamed, so that it may avoid redownloading the entire >> contents of that folder? How often are mailboxes that clients synchronize going to be renamed? If the answer is "not too often", then the effort spent developing a mechanism may never pay off...because it'll never get tested well enough to be relied on. > No. It could relatively easily be done, however, by (for example) overloading > the UIDVALIDITY to act as a mailbox identifier. (You'd need to add a > CAPABILITY string, force it to be unique system-wide, and that's really about > it - I'm not claiming this is bullet-proof, but I can't see any obvious > flaws). The constraints on UIDVALIDITY cause problems: a CREATE foo b CREATE bar c DELETE bar d RENAME foo bar At this point, the UIDVALIDITY of bar must be greater than that of the original foo. Ergo, UIDVALIDITY can't always be a stable identifier. Some of us recall the NEWNAME response-code of RFC 2060. It was removed when that was revised into 3501 because it couldn't support all mailbox names, but a version using a imap URL instead of a simple name could be made to work...but then you have to tackle issues like "how does the server know who has the rights to see the new name?", "how can I remove such a 'tombstone'?", "what if the mailbox gets renamed again?", etc. Philip Guenther _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Aug 03 09:09:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8cxT-00038G-07; Thu, 03 Aug 2006 09:09:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8cxS-00037M-2s for lemonade@ietf.org; Thu, 03 Aug 2006 09:09:50 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8cxQ-00050a-H0 for lemonade@ietf.org; Thu, 03 Aug 2006 09:09:50 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 04C084AD59; Thu, 3 Aug 2006 15:09:47 +0200 (CEST) Message-Id: <7Fph5fKm07U0LeZmtagP+Q.md5@libertango.oryx.com> Date: Thu, 3 Aug 2006 15:09:51 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org References: <12665.1154603136.581551@peirce.dave.cridland.net> <20060803050720.A26250@lab.smi.sendmail.com> In-Reply-To: <20060803050720.A26250@lab.smi.sendmail.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Philip Guenther Subject: [lemonade] Detecting renamed mailboxes X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 do a strawman proposal. It's workable for some servers, and it's concrete enough that its cost can be judged against its value. 1. Supporting servers report the MAILBOXID capability and also support listext. 2. The MAILBOXID of a mailbox is an atom and SHOULD be at most 50 bytes. On a server which uses the unix file system, it could be generated using the device number and an inode number, concatenated and e.g. encoded using base36. 3. A server MUST NOT assign the same mailboxid to two mailboxes at the same time, and MUST NOT routinely change a mailbox' mailboxid. 4. A client can ask for the mailboxid using a return option of list. 5. A client MUST assume that if the name and uidvalidity of a mailbox hasn't changed, it is the same mailbox, even if its mailboxid changes. (The change could be the result of a restore from backup, for example.) A client MAY assume that if a mailbox has the same mailboxid and uidvalidity as a no longer existing mailbox, it is in fact the old mailbox, just renamed. A client MUST NOT assume that ACLs apply unchanged. (METADATA would work as well as listext, wouldn't it? Doesn't really matter. It's just a strawman.) Traffic cost for ignorant clients: 10 bytes per connection (skipping over the capability name). Traffic cost for a really smart client: About 50-200 bytes for each time the client starts caching information for a mailbox it hasn't formerly cached (send a LIST ... RETURN MAILBOXID, get the ID, see if it matches some other mailbox, and if it does, see if that other mailbox has gone away). Some savings in case of mailbox renames. Traffic cost for a stupid client: 20 bytes for each LIST command and say 50 bytes for each LIST response. Some savings as above. Implementation cost for servers: I could do it easily. I think quite a few others could, too. And some people couldn't do it at all. Implementation cost for clients: No idea. How often are mailboxes renamed? blah -> blah-july-2006 at the end of July 2006 seems about the only case which is common enough to even dream of bothering about. Is that common? Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Aug 03 11:44:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8fNF-00014S-Lx; Thu, 03 Aug 2006 11:44:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8fNE-00012u-Fn for lemonade@ietf.org; Thu, 03 Aug 2006 11:44:36 -0400 Received: from mxout3.cac.washington.edu ([140.142.32.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8fNC-0005OR-3V for lemonade@ietf.org; Thu, 03 Aug 2006 11:44:36 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k73Fi6WO028221; Thu, 3 Aug 2006 08:44:06 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k73Fi0Ki027270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 Aug 2006 08:44:06 -0700 Date: Thu, 3 Aug 2006 08:43:59 -0700 (PDT) From: Mark Crispin To: Ben Last Subject: RE: [lemonade] Notifications for multiple devices per user In-Reply-To: <22C8A0D5D5E095449AB509FE777B5F80029DF075@svr-exchange.avocado.emccsoft.com> Message-ID: References: <22C8A0D5D5E095449AB509FE777B5F80029DF075@svr-exchange.avocado.emccsoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.3.82433 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_NOT_1 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: 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 On Thu, 3 Aug 2006, Ben Last wrote: > Actually, no, that's not what I'm saying. Mark, with all due respect, > taking my argument to extremes and making a straw-man response to that > extreme does not help the debate. The problem is that it is neither a strawman nor an extreme: it leads exactly to the extremely undesirable outcome of an IMAP specification containing the concept of a Trash mailbox. It has been made clear that some individuals have that intent. > What I am really saying is that there are systems out there, installed > and running in the real world, that operate in certain ways, and > allowing clients to detect those ways and deal with them is beneficial > to real companies building real products for real users. If those systems do not comply with the specification, then those systems are defective and should be fixed. The specification should not bend to accomodate the defective systems. > The problem of > detecting folders that should not be synchronized is an important one to > mobile clients (where the consequences of repeated download are bad and > can involve serious data charges for end users). That problem is one that should be solved for sent messages mailbox and the like. However, the solution to that problem MUST NOT be used as a backdoor to install the concept of a Trash mailbox into IMAP. > To reframe part of the problem, then, in a manner less contentious: are > there any proposals for mechanisms by which a client can be aware that a > folder has been renamed, so that it may avoid redownloading the entire > contents of that folder? That is an entirely different problem. Sadly, I do not have much hope for a solution to that problem, as it imposes a mandate (effectively, a mailbox name history) that may not be feasible to implement in some servers. Personally, I feel that IMAP RENAME itself is fundamentally flawed, and should be removed from IMAP. The functionality is infrequently used, as as noted causes terrible 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 Thu Aug 03 12:14:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8fqR-0006So-S8; Thu, 03 Aug 2006 12:14:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8fqQ-0006Rc-E3 for lemonade@ietf.org; Thu, 03 Aug 2006 12:14:46 -0400 Received: from mxout4.cac.washington.edu ([140.142.33.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8fqO-000817-Vf for lemonade@ietf.org; Thu, 03 Aug 2006 12:14:46 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout4.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k73GEZiT021691; Thu, 3 Aug 2006 09:14:35 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k73GEXEA005500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 Aug 2006 09:14:34 -0700 Date: Thu, 3 Aug 2006 09:14:33 -0700 (PDT) From: Mark Crispin To: Zoltan.Ordogh@nokia.com Subject: RE: [lemonade] Notifications for multiple devices per user In-Reply-To: <0FA975F2D8295A448BE3ADC161244657A9E684@esebe199.NOE.Nokia.com> Message-ID: References: <0FA975F2D8295A448BE3ADC161244657A9E684@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.3.84932 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: 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 On Thu, 3 Aug 2006, Zoltan.Ordogh@nokia.com wrote: > Could You elaborate this ""terrible design mistake in its implementation > of IMAP" - I am confused. I thought that it is the IMAP standard that > lacks the possibility of identifying special mailboxes. It is a terrible design mistake for an IMAP client to implement message removal by moving messages to a mailbox named "Trash" or the like. The correct way to implement message removal is to use IMAP's name delete/expunge model. That model is in IMAP, and is specified in that fashion, for a reason. > "The only appropriate answer to such a request is "no". 1000 times "no"." > Just keeping saying no does not solve the problem. Providing a solution does. Excuse me. This matter has already been discussed and thoroughly explained. You yourself admitted that in a previous message in this thread. You also admitted that you disregarded the explanation. Just bringing up the same issue for discussion repeatedly does not solve the problem. What's more, it leads to unpleasant suspicions that your intent is to wear people down until they capitulate and grant you your desired outcome. > Could You tell me how will different client implementations know which > mailbox they will use to store the "trash", "sent", "junk", etc emails > in an interoperable manner? (Consider now foreign language clients - not > English ones where the mailboxes are probably called "trash", "sent" and > "junk". "Probably" indicates that it is an issue with English clients as > well.) There is no problem at all with sharing configuration with mailboxes for sent messages, nor, for that matter, a mailbox that identifies a repository of spam messages that are to be analyzed by spam filtering software to improve the filters. Supposedly, we have a protocol that does that: ACAP. The problem is solely with using that mechanism to define a "trash" mailbox; that is, a mailbox used to receive messages that the user wants removed and subjected to a later "empty trash" operation. This is an unnatural and non-interoperable use of IMAP that (as has been discussed to death) creates substantial problems -- all to make it easier for a lazy programmer to show a trash-type GUI to the user. The solution to this problem is exclusion of a "trash" mailbox in any form from any proposal which purports to identify sent messages and the like; and a stipulation that any attempt to include "trash" will be tantamount to a poison-pill that kills the entire proposal. The interoperable way to do message removal is with the native IMAP delete/expunge model and ***NOT*** with a "trash" mailbox. I will vigorously oppose any proposal that attempts to make matters otherwise. > Identifying the special mailboxes does not break the protocol in any > way. In fact, identifying the special mailboxes has nothing to do with > the protocol itself - it is merely a configuration setting so that each > client that connects knows how to behave. It all depends upon what the special mailbox is. A kludge that avoids the proper IMAP way of doing things is not something that belongs in any IMAP-sanctioned identification mechanism. Trash is such a kludge, and discussion should not be open for it. Now, it IS a reasonable discussion to investigate means by which a GUI with a trash-type user display can use the native IMAP delete/expunge model (without a "trash" mailbox) more effectively than is possible today. I understand, and sympathize with, the desire of a client to present a trash-type visual artifact that represents deleted messages in multiple mailboxes. I understand, and sympathize with, the technical difficulties that clients face in doing so. I agree that IMAP can, and should, do better. Nonetheless, a "trash" mailbox is not the solution. It is a kludge that creates new problems and breaks interoperability. It makes the kludge to insert it into a means of sharing configuration (which is supposed to be ACAP's job!) of such things as a sent messages mailbox. The only thing worse would be a mailbox called OUTBOX which, when appended to, gets its headers parsed and the message passed to SMTP for delivery. There are lots of people who want this, and say "it's easy to do, just pass it to sendmail." That doesn't make it right. The sooner that we drop discussion on a Trash mailbox and move on to the real tasks: . how to share configuration . how to make it easier for a GUI to present a Trash user metaphor while using the native IMAP delete/expunge model the better. -- 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 Aug 03 12:29:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8g4p-0001wE-Vp; Thu, 03 Aug 2006 12:29:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8g4o-0001ik-AQ for lemonade@ietf.org; Thu, 03 Aug 2006 12:29:38 -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 1G8aEP-00041x-3V for lemonade@ietf.org; Thu, 03 Aug 2006 06:15:09 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G8ZWO-000081-Ox for lemonade@ietf.org; Thu, 03 Aug 2006 05:29:42 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 3DFFD4AD11; Thu, 3 Aug 2006 11:29:30 +0200 (CEST) Message-Id: Date: Thu, 3 Aug 2006 11:29:32 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] WGLC compress-02 References: <0FA975F2D8295A448BE3ADC161244657A1AD57@esebe199.NOE.Nokia.com> <44D118DB.1060601@att.com> <7968.1154554890.115220@invsysm1> In-Reply-To: <7968.1154554890.115220@invsysm1> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: -2.4 (--) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: Tony Hansen X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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: > Right. The ones arriving after the server's OK are actually harder to > deal with, I find, but clients just have to be careful about that. Clients that support STARTTLS already know how to handle this. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Aug 03 12:49:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8gNf-0002Wz-AN; Thu, 03 Aug 2006 12:49:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8gNe-0002Wp-5A for lemonade@ietf.org; Thu, 03 Aug 2006 12:49:06 -0400 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8gNZ-0002a5-LS for lemonade@ietf.org; Thu, 03 Aug 2006 12:49:06 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.50) id 1G8gNX-0001iM-1Y; Thu, 03 Aug 2006 16:48:59 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 5762E498003; Thu, 3 Aug 2006 17:54:06 +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 20374-08; Thu, 3 Aug 2006 17:53:55 +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 DCC40498002; Thu, 3 Aug 2006 17:53:55 +0100 (BST) Date: Thu, 03 Aug 2006 17:48:46 +0100 Subject: RE: [lemonade] Notifications for multiple devices per user References: <0FA975F2D8295A448BE3ADC161244657A9E684@esebe199.NOE.Nokia.com> In-Reply-To: <0FA975F2D8295A448BE3ADC161244657A9E684@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Message-Id: <12665.1154623727.085121@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: 0fa76816851382eb71b0a882ccdc29ac Cc: Enhancements to Internet email to support diverse service enivronments , Mark Crispin X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 Aug 3 12:01:48 2006, Zoltan.Ordogh@nokia.com wrote: > "Do you honestly believe that having such mechanisms defined > wouldn't encourage some fool to implement them?" > Yes, exactly: implementation is the intent. Why would we propose > such thing otherwise? Call me a fool if You like, but we want to > provide a better email experience where the emails are organized in > a better way. The better way here means that specific emails are > put to their respective mailbox. > > Actually, recent practise seems to be moving away from the use of multiple mailboxes for organizational purposes, and toward an organizational method based on arbitrary "tagging" and metadata. The latter is passing through Last Call now as Experimental, in the form of ANNOTATE, and the former has existed for a decade as keywords. Of course, this change in practise isn't a technical change, it's just the swing of personal taste - 5 years ago I was dutifully ripping out-moded "keyword" systems out of software, because everyone wanted to organize data in heirarchical containers, whereas now the same facility is highly popular simply by renaming it to "tagging". > "The only appropriate answer to such a request is "no". 1000 times > "no"." > Just keeping saying no does not solve the problem. Providing a > solution does. > Could You tell me how will different client implementations know > which mailbox they will use to store the "trash", "sent", "junk", > etc emails in an interoperable manner? (Consider now foreign > language clients - not English ones where the mailboxes are > probably called "trash", "sent" and "junk". "Probably" indicates > that it is an issue with English clients as well.) > > Junk messages have a proposal for using standardized keywords for marking and processing. Deleted messages have the same. There is, I think, no clear consensus on what you might find in a "sent" or "sent items" mailbox - mainly due to a lack of specification - but in any case, I feel that for consistency if no other reason we should strive to mark such messages with keywords. It may well be that clients have a UI-based desire to present deleted messages, for example, within a single unified container, but on desktop operating systems, for example, this is not modelled as a simple directory - it's a much more complex area, as you'll see from specifications such as http://www.ramendik.ru/docs/trashspec.html - this mandates a considerable amount of metadata to be stored with the deleted file to allow the operation to be reversible. Note that in this case, the trash directory has contents very different from the directories the original content was trashed from, and this isn't unusual. Modelling a trash mailbox by using real IMAP mailboxes simply doesn't work, just as making a trash directory on a filesystem by using a simple directory also doesn't work. It is, however, possible to model them by using server-side support to provide a non-mailbox container (perhaps similar to a virtual mailbox), which listed all messages throughout the server marked as \Deleted for which the user could SELECT the containing mailbox. I'm not sure I'm aware of any server implementor who would be keen to implement that, though, because it involves server-wide searching, which is generally painful. I think the closest idea I've seen suggested so far was Randall Gellens's suggestion of a "trash heirarchy". 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 Aug 03 13:05:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8gdH-0007tO-9I; Thu, 03 Aug 2006 13:05:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8gdG-0007tJ-NY for lemonade@ietf.org; Thu, 03 Aug 2006 13:05:14 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8gdF-0004CP-C0 for lemonade@ietf.org; Thu, 03 Aug 2006 13:05:14 -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 k73H5BEx008410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 3 Aug 2006 10:05:12 -0700 Received: from [129.46.172.15] (vpn-10-50-0-141.qualcomm.com [10.50.0.141]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k73H58hx004020; Thu, 3 Aug 2006 10:05:10 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <0FA975F2D8295A448BE3ADC161244657A9E6CF@esebe199.NOE.Nokia.com> References: <0FA975F2D8295A448BE3ADC161244657A9E6CF@esebe199.NOE.Nokia.com> X-Mailer: Eudora for Mac OS X (dev alpha) X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Thu, 3 Aug 2006 09:57:12 -0700 To: , From: Randall Gellens Subject: RE: [lemonade] WGLC compress-02 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: 32b73d73e8047ed17386f9799119ce43 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 Zoltan, I've edited the quoted text down to make it=20 easier to follow (your email client's unfortunate=20 lack of support for RFC 3676 quoting makes it=20 very confusing). >> This will need to be clarified when we do the=20 >> SMTP COMPRESS draft, by the way (pipeling and=20 >> COMPRESS). > [Z=D6r] Certainly pipelining is an issue and we=20 > are going to have to deal with it any way.=20 > However, there might be a latency (we need to=20 > think about mobile devices here) between the=20 > client issuing the COMPRESS command and the=20 > server "seeing" it. Hence my dilemma.=20 > Client sends it, fine, but there might be other=20 > server responses coming from the server in the=20 > meantime (even after the server has=20 > "seen" the command since there might=20 > be latency on the way back as well). So, I=20 > suggest adding something like "The client=20 > MAY receive other responses from the server=20 > before before receiving the result of the=20 > COMPRESS command. The client MUST treat these=20 > "intermediate" responses as if the=20 > COMPRESS command was not issued." Or,=20 > something like this. > What do You think? I think it is sufficient to say that compression=20 starts on the server side when it sends the OK=20 response to COMPRESS, and on the client side when=20 it sees the OK response. >> If the command succeeds, it can't be reissued. >> See Section 3, where it says a BAD response is=20 >> issued if COMPRESS is already active. > [Z=D6r] I think it would be beneficial to capture=20 > this fact "If the command succeeds, it=20 > can't be reissued.". I think it is already captured since the draft=20 says a BAD response is issued if COMPRESS is=20 already active. > Turning on compression is one thing -.You can=20 > turn it on only once, fine. But how about when=20 > the compression method is to be changed (EG.=20 > DEFLATE to something else)? <- Just to think=20 > about being future-proof. I can't see any value in adding complexity just=20 to permit either side to decide to renegotiate=20 the compression algorithm. I find it very hard=20 to imagine a case where this would be useful. If=20 there is such a case, an additional TCP=20 connection can established. Existing IMAP=20 clients often have multiple TCP connections to=20 the IMAP server active. >> Plus, the reconnect document is morphing into a re-select. > [Z=D6r] I did not see that "morphing" -=20 > probably it something I missed during the=20 > meeting. The document itself has morphed. Especially with=20 client-side reconnect, it is mailbox selection=20 that is being made quicker. > If RECONNECT will be changed, it will not be an=20 > issue, but if not, we need to address it one=20 > way or another. Sorry for not being more clear in my earlier=20 reply: even if there is a session-resumption=20 draft, compression is extremely unlikely to be=20 part of that. It makes much more sense to=20 reestablish compression that to resume it. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- To define recursion, we must first define recursion. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Aug 04 05:07:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8veB-0005XD-Ug; Fri, 04 Aug 2006 05:07:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8veA-0005Ii-FG for lemonade@ietf.org; Fri, 04 Aug 2006 05:07:10 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8ve8-0006jc-Nv for lemonade@ietf.org; Fri, 04 Aug 2006 05:07:10 -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 k7496mPr015838; Fri, 4 Aug 2006 12:06:50 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Aug 2006 12:06:46 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Aug 2006 12:06: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: Fri, 4 Aug 2006 12:06:12 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657A9EA56@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: Aca3GBBGRacBjw1vQ2OvyivvDMLAIgAhhMGg From: To: X-OriginalArrivalTime: 04 Aug 2006 09:06:46.0190 (UTC) FILETIME=[4FBCD4E0:01C6B7A5] X-Spam-Score: 0.2 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f 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 Mark, Thank You for Your response. Please see my comments below with [Z=D6r] tags. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 -----Original Message----- From: mrc@pangtzu.panda.com [mailto:mrc@pangtzu.panda.com] On Behalf Of = ext Mark Crispin Sent: 03 August, 2006 19:15 To: Ordogh Zoltan (Nokia-TP-MSW/Tampere) Cc: Ben.Last@emccsoft.com; lemonade@ietf.org Subject: RE: [lemonade] Notifications for multiple devices per user On Thu, 3 Aug 2006, Zoltan.Ordogh@nokia.com wrote: > Could You elaborate this ""terrible design mistake in its=20 > implementation of IMAP" - I am confused. I thought that it is the IMAP = > standard that lacks the possibility of identifying special mailboxes. It is a terrible design mistake for an IMAP client to implement message = removal by moving messages to a mailbox named "Trash" or the like. The correct way to implement message removal is to use IMAP's name = delete/expunge model. That model is in IMAP, and is specified in that = fashion, for a reason. [Z=D6r] I do not see this as a terrible mistake - I see this as an = implementation choice to offer (in my opinion) better and interoperable = service. Interoperable meaning that two completely different clients = will both understand where to place "sent items"for example. If You do not want to allow identifying a "trash" mailbox on Your = server, You simply disallow updating the related setting - leaving it = empty - an reply to a client with a "bad" or whatever response so the = client understands that Your server does not allow this. I do not see = any problems in making implementation decisions - even the standard = itself could express a way to explicitly disable identifying "undesired" = special mailboxes. > "The only appropriate answer to such a request is "no". 1000 times = "no"." > Just keeping saying no does not solve the problem. Providing a = solution does. Excuse me. [Z=D6r] No biggie, just want to speed up things - so I need to make You = talk to figure out what's on Your mind and from a "no" I can't do that. This matter has already been discussed and thoroughly explained. You = yourself admitted that in a previous message in this thread. You also = admitted that you disregarded=20 the explanation. [Z=D6r] That was regarding the MOVE command - yes, I gave up because I = have been given an alternative solution (even though I do not like the = alternative solution because it is a workaround and it is the client = that needs to mess around instead of giving a simple command to the = server). And yes, I will bring it up over and over again whenever = someone mentions anything to which a MOVE command would be appropriate. = People get older, forget things - so eventually it will happen. Just bringing up the same issue for discussion repeatedly does not solve = the problem. What's more, it leads to unpleasant suspicions that your = intent is to wear people down until they capitulate and grant you your = desired outcome. [Z=D6r] I disagree. This is the basis for standardization - people come = up with ideas, and present them. Some people do not like it, fine. Later = on someone else comes with the same idea, so these two agree that "hey: = if they don't want to standardize it, fine: we will implement it = anyway". So these guys implement it, and make a better service than = anyone else and then You wish You have made it a standard. I believe = everything should be standardized - so if someone decides to implement = it then the solution will be available for the taking and it will be = interoperable with others. Your second sentence is valid - however, it does not conflict with any = rule to do such thing. Not nice, I agree, but it seems that there is no = interoperable solution that solve the problem in question - thus all I = can do is keep asking addressing the problem. > Could You tell me how will different client implementations know which = > mailbox they will use to store the "trash", "sent", "junk", etc emails = > in an interoperable manner? (Consider now foreign language clients -=20 > not English ones where the mailboxes are probably called "trash",=20 > "sent" and "junk". "Probably" indicates that it is an issue with=20 > English clients as > well.) There is no problem at all with sharing configuration with mailboxes for = sent messages, nor, for that matter, a mailbox that identifies a = repository of spam messages that are to be analyzed by spam filtering = software to improve the filters. Supposedly, we have a protocol that does that: ACAP. The problem is solely with using that mechanism to define a "trash"=20 mailbox; that is, a mailbox used to receive messages that the user wants = removed and subjected to a later "empty trash" operation. This is an = unnatural and non-interoperable use of IMAP that (as has been discussed = to death) creates substantial problems -- all to make it easier for a lazy = programmer to show a trash-type GUI to the user. The solution to this problem is exclusion of a "trash" mailbox in any = form from any proposal which purports to identify sent messages and the = like; and a stipulation that any attempt to include "trash" will be = tantamount to a poison-pill that kills the entire proposal. The interoperable way to do message removal is with the native IMAP = delete/expunge model and ***NOT*** with a "trash" mailbox. I will = vigorously oppose any proposal that attempts to make matters otherwise. [Z=D6r] Ok, so I try to recap this: Your problem is not the fact that we = would like to identify special mailboxes, your problem is that we = included "trash" in it, right?. Then it would be beneficial if we = separated these two arguments: one about identifying special mailboxes = and one about the list of special mailboxes to be identified. > Identifying the special mailboxes does not break the protocol in any=20 > way. In fact, identifying the special mailboxes has nothing to do with = > the protocol itself - it is merely a configuration setting so that=20 > each client that connects knows how to behave. It all depends upon what the special mailbox is. A kludge that avoids the proper IMAP way of doing things is not = something that belongs in any IMAP-sanctioned identification mechanism. = Trash is such a kludge, and discussion should not be open for it. Now, it IS a reasonable discussion to investigate means by which a GUI = with a trash-type user display can use the native IMAP delete/expunge = model (without a "trash" mailbox) more effectively than is possible = today. I understand, and sympathize with, the desire of a client to present a = trash-type visual artifact that represents deleted messages in multiple = mailboxes. I understand, and sympathize with, the technical = difficulties that clients face in doing so. I agree that IMAP can, and = should, do better. [Z=D6r] So, when should we expect the next IMAP revision? :-) Nonetheless, a "trash" mailbox is not the solution. It is a kludge that = creates new problems and breaks interoperability. It makes the kludge = to insert it into a means of sharing configuration (which is supposed to = be ACAP's job!) of such things as a sent messages mailbox. The only thing worse would be a mailbox called OUTBOX which, when = appended to, gets its headers parsed and the message passed to SMTP for = delivery.=20 There are lots of people who want this, and say "it's easy to do, just = pass it to sendmail." That doesn't make it right. The sooner that we drop discussion on a Trash mailbox and move on to the = real tasks: . how to share configuration . how to make it easier for a GUI to present a Trash user metaphor = while using the native IMAP delete/expunge model the better. [Z=D6r] The "trash" mailbox is not on my agenda, I used it as examples = along with the others. However, I do see benefit of identifying such = mailbox (otherwise those who need it will simply place everything in the = "junk" mailbox instead, or impement proprietary solutions that might = confuse the clients - which is even worse than what You are afraid of in = case of "trash"). -- 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 Fri Aug 04 05:23:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8vu3-0006y3-7z; Fri, 04 Aug 2006 05:23:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8vu2-0006xy-D2 for lemonade@ietf.org; Fri, 04 Aug 2006 05:23:34 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8vu0-00027F-Q6 for lemonade@ietf.org; Fri, 04 Aug 2006 05:23:34 -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 k749NT0f002126; Fri, 4 Aug 2006 12:23:31 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Aug 2006 12:23:03 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Aug 2006 12:23: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] WGLC compress-02 Date: Fri, 4 Aug 2006 12:22:30 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657A9EA74@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] WGLC compress-02 Thread-Index: Aca3HxyRkPGkPr/PRaqOMZQyM9ww2gAh3z9A From: To: , X-OriginalArrivalTime: 04 Aug 2006 09:23:03.0521 (UTC) FILETIME=[9645B510:01C6B7A7] X-Spam-Score: 0.2 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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've edited the quoted text down to make it easier to follow (your email = client's unfortunate lack of support for RFC 3676 quoting makes it very = confusing). [Z=D6r] Yes, I get this all the time. > [Z=D6r] Certainly pipelining is an issue and we are going to have to=20 > deal with it any way. > However, there might be a latency (we need to think about mobile=20 > devices here) between the client issuing the COMPRESS command and the=20 > server "seeing" it. Hence my dilemma. > Client sends it, fine, but there might be other server responses=20 > coming from the server in the meantime (even after the server has=20 > "seen" the command since there might be latency on the way=20 > back as well). So, I suggest adding something like "The client=20 > MAY receive other responses from the server before before receiving=20 > the result of the COMPRESS command. The client MUST treat these=20 > "intermediate" responses as if the COMPRESS command was not=20 > issued." Or, something like this. > What do You think? I think it is sufficient to say that compression starts on the server = side when it sends the OK response to COMPRESS, and on the client side = when it sees the OK response. [Z=D6r] So, You agree to what I wrote but You do not see value in adding = it to the draft? I can live with this as long as You confirm that text I = suggested above is valid. > [Z=D6r] I think it would be beneficial to capture this fact "If=20 > the command succeeds, it can't be reissued.". I think it is already captured since the draft says a BAD response is = issued if COMPRESS is already active. [Z=D6r] BAD response will come only when COMPRESS is already active, not = in any other case, right? (Just checking future-proofness where other = compression algorythms mgith be added.) > If RECONNECT will be changed, it will not be an issue, but if not, we = > need to address it one way or another. Sorry for not being more clear in my earlier reply: even if there is a session-resumption draft, compression is = extremely unlikely to be part of that. It makes much more sense to = reestablish compression that to resume it. [Z=D6r] I recognize this as a good thing - it is possible to quickly = turn compression off by using RECONNECT then. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Aug 04 05:43:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8wCz-00089G-5t; Fri, 04 Aug 2006 05:43:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8wCx-00088r-MA for lemonade@ietf.org; Fri, 04 Aug 2006 05:43:07 -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 1G8wCx-00044h-Jt for lemonade@ietf.org; Fri, 04 Aug 2006 05:43:07 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G8w5u-0002z4-Jv for lemonade@ietf.org; Fri, 04 Aug 2006 05:35:53 -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 k749ZNE5010932; Fri, 4 Aug 2006 12:35:34 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Aug 2006 12:35:28 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Aug 2006 12:35:28 +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: Fri, 4 Aug 2006 12:34:56 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657A9EA8E@esebe199.NOE.Nokia.com> In-Reply-To: <12665.1154623727.085121@peirce.dave.cridland.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Notifications for multiple devices per user Thread-Index: Aca3HNIGYSTpIWqZRjOZ0pwEQ5zODwAirSNQ From: To: , , X-OriginalArrivalTime: 04 Aug 2006 09:35:28.0225 (UTC) FILETIME=[52268510:01C6B7A9] X-Spam-Score: -2.5 (--) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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, I added some comments/questions below.=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: 03 August, 2006 19:49 To: Ordogh Zoltan (Nokia-TP-MSW/Tampere) Cc: Enhancements to Internet email to support diverse service = enivronments; Mark Crispin; Ben Last Subject: RE: [lemonade] Notifications for multiple devices per user Actually, recent practise seems to be moving away from the use of = multiple mailboxes for organizational purposes, and toward an = organizational method based on arbitrary "tagging" and metadata. The latter is passing through Last Call now as Experimental, in the form = of ANNOTATE, and the former has existed for a decade as keywords. Of course, this change in practise isn't a technical change, it's just = the swing of personal taste - 5 years ago I was dutifully ripping = out-moded "keyword" systems out of software, because everyone wanted to = organize data in heirarchical containers, whereas now the same facility = is highly popular simply by renaming it to "tagging". [Z=D6r] I agree with this, however when the clients are designed to = arrange emails in a hierarchical structure, it is important to identify = what goes where. Junk messages have a proposal for using standardized keywords for = marking and processing. Deleted messages have the same. [Z=D6r] It is a good thing - however I would like to see the junk = messages separated anyway - to prevent accidentally opening them up. = Tagging them is a good idea and does not conflict with storing them in a = different mailbox. There is, I think, no clear consensus on what you might find in a "sent" = or "sent items" mailbox - mainly due to a lack of specification - but in = any case, I feel that for consistency if no other reason we should = strive to mark such messages with keywords. [Z=D6r] My understanding on this is that the IMAP server will not know = which messages are sent - it is the client that created copies of emails = (so client could tag the messages). I have this understanding based on = the FCC problem description, please correct me if I am wrong. Modelling a trash mailbox by using real IMAP mailboxes simply doesn't = work, just as making a trash directory on a filesystem by using a simple = directory also doesn't work. [Z=D6r] I do not need a "trash" mailbox, but I do not see why it would = not work. User hits delete, and instead of tagging them deleted, client = moves them to some other mailbox. In that other mailbox user can hit = delete, where client marks them deleted. User hits empty, and then the = mails marked for deletion are expunged. If someone was to do something = like this - what would be the problem? (It even supports undelete until = expunge). _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Aug 04 09:03:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8zKe-0006kc-1Z; Fri, 04 Aug 2006 09:03:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8zKc-0006kX-VI for lemonade@ietf.org; Fri, 04 Aug 2006 09:03:14 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G8zKa-0004PI-Ia for lemonade@ietf.org; Fri, 04 Aug 2006 09:03:14 -0400 X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-6.tower-120.messagelabs.com!1154696591!9093990!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 2327 invoked from network); 4 Aug 2006 13:03:11 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-6.tower-120.messagelabs.com with SMTP; 4 Aug 2006 13:03:11 -0000 Received: from [135.210.40.17] (unknown[135.210.40.17](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20060804130310gw1003joqee> (Authid: tony); Fri, 4 Aug 2006 13:03:10 +0000 Message-ID: <44D3458C.1040507@att.com> Date: Fri, 04 Aug 2006 09:03:08 -0400 From: Tony Hansen User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: lemonade@ietf.org Subject: Re: [lemonade] WGLC compress-02 References: <0FA975F2D8295A448BE3ADC161244657A9EA74@esebe199.NOE.Nokia.com> In-Reply-To: <0FA975F2D8295A448BE3ADC161244657A9EA74@esebe199.NOE.Nokia.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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: >=20 > I think it is sufficient to say that compression starts on the server s= ide when it sends the OK response to COMPRESS, and on the client side whe= n it sees the OK response. > [Z=D6r] So, You agree to what I wrote but You do not see value in addin= g it to the draft? I can live with this as long as You confirm that text = I suggested above is valid. Your analysis is correct. The compression starts on the server side immediately >>after<< it has issued the OK response and its trailing CRLF. Unsolicited responses sent by the server >>before<< it issues the OK response must still be uncompressed. Here is some suggested replacement text for this text from section 3: < The client MUST NOT send any commands until it has seen the result < ... compress starting with the first response after the OK. The client MUST NOT send any further commands until it has seen the result of COMPRESS. If the response was OK, the client MUST compress starting with the first command after COMPRESS. If the server response was BAD or NO, the client MUST NOT turn on compression. If the server issues an OK response, the server MUST compress starting with the first response after the CRLF ending the OK response. (Unsolicited responses issued by the server before the OK response will, of course, still be uncompressed.) If the server issues a BAD or NO respnose, the server MUST NOT turn on compression. >> [Z=D6r] I think it would be beneficial to capture this fact "If = >> the command succeeds, it can't be reissued.". >=20 > I think it is already captured since the draft says a BAD response is i= ssued if COMPRESS is already active. > [Z=D6r] BAD response will come only when COMPRESS is already active, no= t in any other case, right? (Just checking future-proofness where other c= ompression algorythms mgith be added.) I think the text in -03 is adequate and complete. Result: OK The server will compress its responses and expects the client to compress its commands. NO The server doesn't support the requested mechanism. BAD Command unknown, invalid argument, or COMPRESS already active. So there are three cases that could lead to a BAD response; compression already being active is one of those cases. >> If RECONNECT will be changed, it will not be an issue, but if not, we= =20 >> need to address it one way or another. >=20 > Sorry for not being more clear in my earlier > reply: even if there is a session-resumption draft, compression is extr= emely unlikely to be part of that. It makes much more sense to reestabli= sh compression that to resume it. > [Z=D6r] I recognize this as a good thing - it is possible to quickly tu= rn compression off by using RECONNECT then. Instead of reconnecting to turn off compression, it is also possible, and even easier, to dynamically crank down the level of compression at any time during the conversation. This could set the amount of compression to 0 while leaving the compression layer in place. Once you're done with a section of the conversation that needs no compression, dynamically crank it back up again. Both the server and client have full control. Tony Hansen tony@att.com _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Aug 04 09:34:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8zoW-0001Kj-Nc; Fri, 04 Aug 2006 09:34:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8zoV-0001Kb-O6 for lemonade@ietf.org; Fri, 04 Aug 2006 09:34:07 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8zoT-0000F9-75 for lemonade@ietf.org; Fri, 04 Aug 2006 09:34:07 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 056344AD20 for ; Fri, 4 Aug 2006 15:34:04 +0200 (CEST) Message-Id: Date: Fri, 4 Aug 2006 15:34:07 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] WGLC compress-02 References: <0FA975F2D8295A448BE3ADC161244657A9EA74@esebe199.NOE.Nokia.com> <44D3458C.1040507@att.com> In-Reply-To: <44D3458C.1040507@att.com> Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Tony Hansen writes: > Zoltan.Ordogh@nokia.com wrote: > >> I think it is sufficient to say that compression starts on the >> server side when it sends the OK response to COMPRESS, and on the >> client side when it sees the OK response. >> [Z=D6r] So, You agree to what I wrote but You do not see value in >> adding it to the draft? I can live with this as long as You confirm >> that text I suggested above is valid. > > Your analysis is correct. > > The compression starts on the server side immediately >>after<< it has > issued the OK response and its trailing CRLF. Unsolicited responses > sent by the server >>before<< it issues the OK response must still be > uncompressed. > > Here is some suggested replacement text for this text from section 3: > > < The client MUST NOT send any commands until it has seen the result > < ... compress starting with the first response after the OK. > > The client MUST NOT send any further commands until it has seen > the result of COMPRESS. If the response was OK, the client MUST > compress starting with the first command after COMPRESS. If the > server response was BAD or NO, the client MUST NOT turn on > compression. > > If the server issues an OK response, the server MUST compress > starting with the first response after the CRLF ending the OK > response. (Unsolicited responses issued by the server before the > OK response will, of course, still be uncompressed.) If the > server issues a BAD or NO respnose, the server MUST NOT turn on > compression. Seems a little superfluous.... but since I tend to be a little on the brief side, I added the text. Except the word unsolicited, which IMO restricts the sentence unjustifiedly. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Aug 04 09:55:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9095-0001M9-9v; Fri, 04 Aug 2006 09:55:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9093-0001M3-K5 for lemonade@ietf.org; Fri, 04 Aug 2006 09:55:21 -0400 Received: from mail146.messagelabs.com ([216.82.245.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G9092-00033b-CZ for lemonade@ietf.org; Fri, 04 Aug 2006 09:55:21 -0400 X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-15.tower-146.messagelabs.com!1154699719!244298!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 30334 invoked from network); 4 Aug 2006 13:55:19 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-15.tower-146.messagelabs.com with SMTP; 4 Aug 2006 13:55:19 -0000 Received: from [135.210.40.17] (unknown[135.210.40.17](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20060804135518gw1003joqre> (Authid: tony); Fri, 4 Aug 2006 13:55:18 +0000 Message-ID: <44D351C5.3050804@att.com> Date: Fri, 04 Aug 2006 09:55:17 -0400 From: Tony Hansen User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: lemonade@ietf.org Subject: Re: [lemonade] WGLC compress-02 References: <0FA975F2D8295A448BE3ADC161244657A9EA74@esebe199.NOE.Nokia.com> <44D3458C.1040507@att.com> In-Reply-To: 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: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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: > > Seems a little superfluous.... but since I tend to be a little on the > brief side, I added the text. sounds good > Except the word unsolicited, which IMO > restricts the sentence unjustifiedly. sounds good Tony Hansen tony@att.com _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Aug 04 10:12:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G90PM-0003qW-MO; Fri, 04 Aug 2006 10:12:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G90PL-0003qR-AM for lemonade@ietf.org; Fri, 04 Aug 2006 10:12:11 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G90PJ-0006Xc-RF for lemonade@ietf.org; Fri, 04 Aug 2006 10:12:11 -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 k74EC5oT006491; Fri, 4 Aug 2006 17:12:05 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Aug 2006 17:12:01 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Aug 2006 17:12: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] WGLC compress-02 Date: Fri, 4 Aug 2006 17:11:28 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657A9ECC2@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] WGLC compress-02 Thread-Index: Aca3yx0Qyrv1fjRUQim6cmDFhi46QgABK4bw From: To: , X-OriginalArrivalTime: 04 Aug 2006 14:12:01.0872 (UTC) FILETIME=[F4BC1D00:01C6B7CF] X-Spam-Score: 0.2 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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 Tony and Arnt, thank You. I have no further questions/comments. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 -----Original Message----- From: ext Arnt Gulbrandsen [mailto:arnt@gulbrandsen.priv.no]=20 Sent: 04 August, 2006 16:34 To: lemonade@ietf.org Subject: Re: [lemonade] WGLC compress-02 Tony Hansen writes: > Zoltan.Ordogh@nokia.com wrote: > >> I think it is sufficient to say that compression starts on the =20 >> server side when it sends the OK response to COMPRESS, and on the =20 >> client side when it sees the OK response. >> [Z=D6r] So, You agree to what I wrote but You do not see value in =20 >> adding it to the draft? I can live with this as long as You confirm =20 >> that text I suggested above is valid. > > Your analysis is correct. > > The compression starts on the server side immediately >>after<< it has = > issued the OK response and its trailing CRLF. Unsolicited responses=20 > sent by the server >>before<< it issues the OK response must still be=20 > uncompressed. > > Here is some suggested replacement text for this text from section 3: > > < The client MUST NOT send any commands until it has seen the = result > < ... compress starting with the first response after the OK. > > The client MUST NOT send any further commands until it has seen=20 > the result of COMPRESS. If the response was OK, the client MUST=20 > compress starting with the first command after COMPRESS. If the=20 > server response was BAD or NO, the client MUST NOT turn on=20 > compression. > > If the server issues an OK response, the server MUST compress=20 > starting with the first response after the CRLF ending the OK=20 > response. (Unsolicited responses issued by the server before the=20 > OK response will, of course, still be uncompressed.) If the=20 > server issues a BAD or NO respnose, the server MUST NOT turn on=20 > compression. Seems a little superfluous.... but since I tend to be a little on the = brief side, I added the text. Except the word unsolicited, which IMO = restricts the sentence unjustifiedly. 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 Fri Aug 04 10:32:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G90jE-0002r0-1V; Fri, 04 Aug 2006 10:32:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G90jC-0002q1-60 for lemonade@ietf.org; Fri, 04 Aug 2006 10:32:42 -0400 Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G90XJ-0000In-1t for lemonade@ietf.org; Fri, 04 Aug 2006 10:20:27 -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-2.csi.cam.ac.uk ([131.111.8.54]:41109) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:fanf2) id 1G90X8-0004kY-05 (Exim 4.54) (return-path ); Fri, 04 Aug 2006 15:20:14 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1G90X7-0002E4-VU (Exim 4.54) (return-path ); Fri, 04 Aug 2006 15:20:13 +0100 Date: Fri, 4 Aug 2006 15:20:13 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Dave Cridland Subject: RE: [lemonade] Notifications for multiple devices per user In-Reply-To: <12665.1154623727.085121@peirce.dave.cridland.net> Message-ID: References: <0FA975F2D8295A448BE3ADC161244657A9E684@esebe199.NOE.Nokia.com> <12665.1154623727.085121@peirce.dave.cridland.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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, 3 Aug 2006, Dave Cridland wrote: > > I think the closest idea I've seen suggested so far was Randall Gellens's > suggestion of a "trash heirarchy". Our hacked Cyrus has a similar thing for recovering expunged messages which have not yet been removed from disk. Tony. -- f.a.n.finch http://dotat.at/ FISHER: WEST OR NORTHWEST 4 OR 5 BECOMING VARIABLE 3 OR 4. FAIR. MODERATE OR GOOD. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Aug 04 12:26:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G92Vk-0005kG-3l; Fri, 04 Aug 2006 12:26:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G92Vi-0005b3-Tm for lemonade@ietf.org; Fri, 04 Aug 2006 12:26:54 -0400 Received: from mxout4.cac.washington.edu ([140.142.33.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G92Nq-0000zm-Iw for lemonade@ietf.org; Fri, 04 Aug 2006 12:18:48 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout4.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k74GIaiF001763; Fri, 4 Aug 2006 09:18:36 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k74GIPwn013157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 4 Aug 2006 09:18:35 -0700 Date: Fri, 4 Aug 2006 09:18:24 -0700 (PDT) From: Mark Crispin To: Zoltan.Ordogh@nokia.com Subject: RE: [lemonade] Notifications for multiple devices per user In-Reply-To: <0FA975F2D8295A448BE3ADC161244657A9EA56@esebe199.NOE.Nokia.com> Message-ID: References: <0FA975F2D8295A448BE3ADC161244657A9EA56@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.4.85932 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: 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 Please fix your mail reader to use proper reply text conventions. On Fri, 4 Aug 2006, Zoltan.Ordogh@nokia.com wrote: > And yes, I will bring it up over and over again whenever > someone mentions anything to which a MOVE command would be appropriate. > People get older, forget things - so eventually it will happen. I recommend against doing so. That technique may work elsewhere. Within the context of the IETF and its personalities, it generally lead to negative effects on the perpetrator. > Ok, so I try to recap this: Your problem is not the fact that we > would like to identify special mailboxes, your problem is that we > included "trash" in it, right?. Then it would be beneficial if we > separated these two arguments: one about identifying special mailboxes > and one about the list of special mailboxes to be identified. No, it would be beneficial if you remove "trash" entirely from your proposal. A "trash" mailbox is not a role mailbox such as "sent messages" or "drafts". It is a functionality modification to IMAP. It is orthogonal to the problem of identifying role mailboxes, and its presence in the proposal is sabotaging the entire proposal. > > I understand, and sympathize with, the desire of a client to present a > > trash-type visual artifact that represents deleted messages in multiple > > mailboxes. I understand, and sympathize with, the technical > > difficulties that clients face in doing so. I agree that IMAP can, and > > should, do better. > So, when should we expect the next IMAP revision? :-) There is no need to wait for a new IMAP revision. This problem could conceivably be solved with an extension. Perhaps, if we weren't wasting time on this dead-end thread, some of us may be able to find time to work on such an extension. > The "trash" mailbox is not on my agenda, I used it as examples along > with the others. Then remove it from the proposal! > However, I do see benefit of identifying such mailbox > (otherwise those who need it will simply place everything in the "junk" > mailbox instead, or impement proprietary solutions that might confuse > the clients - which is even worse than what You are afraid of in case of > "trash"). That's the situation faced today by any client that uses "trash" instead of the proper delete/expunge model. It has served as a deterrant; I know client authors who gritted their teeth, and did the right thing even though a trash mailbox would have made their job easier. Rather than remove the deterrant, I prefer to help out the client authors who try to do the right thing. Certainly, a better job can be done; but undermining the client authors who did the right thing (which is what would happen if an IMAP specification defined a trash mailbox) is NOT "doing a better job"! -- 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 Fri Aug 04 21:05:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9Abv-0005Lg-TJ; Fri, 04 Aug 2006 21:05:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9Abv-0005Lb-2y for lemonade@ietf.org; Fri, 04 Aug 2006 21:05:51 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9Abs-0003yN-Mz for lemonade@ietf.org; Fri, 04 Aug 2006 21:05:51 -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 k7515iP9018499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 4 Aug 2006 18:05:45 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7515gGG017663; Fri, 4 Aug 2006 18:05:43 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <001501c6b140$55be8390$3078a40a@china.huawei.com> References: <01f901c6b065$caaf9d50$3478a40a@china.huawei.com> <001501c6b140$55be8390$3078a40a@china.huawei.com> X-Mailer: Eudora for Mac OS X (dev alpha) X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Fri, 4 Aug 2006 18:04:42 -0700 To: Gang Liang , lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] some questions in draft-ietf-lemonade-notifications-03 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 1.1 (+) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 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 haven't seen any replies to your questions. Here are my views. At 1:48 PM +0800 7/27/06, Gang Liang wrote: > Questions 1: > > In 10.2 (Provision Entries), "push.shared" is defined as > an attribute of in-band notifications (not the attribute of outband > notifications) while in the first example in 10.4 > "push.shared" is regarded as the attribute of outband > notifications. > > Why? Maybe "push.shared" should be defined as an > attribute of outband notifications too. I have concerns about the concept of using mailbox annotations for this purpose. For one thing, it seems to be have problems in the case where users have multiple devices. > Question 2: > > In 10.3 > > "limit.priv" = "size=" nz-number | > "total=" nz-number > > ;the maximum number of bytes to send in notification payloads or > the total number of messages to send. Both per-day > > What's the benefit of limiting the total number of messages > (notifications) per-day? If the number of notifications sent that > day has reached the limit (e.g. 10 notifications per-day ) but then > a very important email arrives, what should the server do? I agree. The issue of throttling is one that will need to be addressed, but a simplistic per-day limit doesn't seem to be the way to solve it. > Question 3: > > In 10.3: > > "push.priv" = "push" / "pull" > > ;specifies whether the client expects new messages to be pushed via > the unsolicited FETCH response defined above, or via client issued > FETCH in response to an EXISTS response. > > Is it possible to push new messages via outband notifications? E.g. > through MMS channel. If it's possible, maybe we could define such > an attribute for outband notification. Personally, I don't see much benefit in using MMS to push mail or notifications. More specifically on your question of including the message itself in the notification, I think that is feasible with small messages, but not large ones. Also, to the extent that notifications are unreliable, this would only be an ancillary service; that is, the client may get messages via notifications, but if this fails for any reason the client will get them normally. > Question 4: > > In 13.8 > > It MUST be possible to provide acknowledgment by the target to the > messaging system or to repeat notification until such an > acknowledgement is provided if supported by the notification > channel. > > Does it mean that the target (client) should provide acknowledgment > for per-notification and the messaging system should repeat the > same notification (not send the following notifications) until > receive the acknowledgment for the notification? This is what I think the document is saying, but personally I have concerns with this approach. > If so, maybe it's more appropriate to send a notification after > determining that the client is online (e.g. according to presence > status of the client provided by presence enabler). -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- I had a fortune cookie the other day and it said, "Outlook not so good." I said, "Sure, but Microsoft ships it anyway." --Tom Singer _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Aug 07 03:51:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9zty-00084K-MV; Mon, 07 Aug 2006 03:51:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9ztx-00084E-3g for lemonade@ietf.org; Mon, 07 Aug 2006 03:51:53 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9ztu-00080X-Ex for lemonade@ietf.org; Mon, 07 Aug 2006 03:51:53 -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 k777ouCd007659; Mon, 7 Aug 2006 10:50:57 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Aug 2006 10:50:55 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Aug 2006 10:50:54 +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] Notifications for multiple devices per user Date: Mon, 7 Aug 2006 10:50:23 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657A9EF9B@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: Aca34cQWeE1j0J8eSMOdSjNA03zVVQCCtZsg From: To: X-OriginalArrivalTime: 07 Aug 2006 07:50:54.0614 (UTC) FILETIME=[3606B360:01C6B9F6] X-Spam-Score: 0.2 (/) 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 Hi Mark, a couple of comments. >Please fix your mail reader to use proper reply text conventions. Is this better? I guess for this particular mailing list it is, but now my own colleagues will tell me the same thing (to revert back as it was before). :-) >I recommend against doing so. That technique may work=20 >elsewhere. Within the context of the IETF and its=20 >personalities, it generally lead to negative effects on the=20 >perpetrator. Oh, I do not mind such negative effects - I am here to improve the standards, not my relationship with people. >A "trash" mailbox is not a role mailbox such as "sent=20 >messages" or "drafts". It is a functionality modification to=20 >IMAP. It is orthogonal to the problem of identifying role=20 >mailboxes, and its presence in the proposal is sabotaging the=20 >entire proposal. There is something I here that I do not understand. One can do it already, today - without any extensions. The only thing missing is an interoperable way that makes sure that each and every client understands that if they want to use the trash, then this and that is the right place to store the trash - which has nothing to do with the protocol itself, it is merely a common setting for all clients stored on the server. As I said before I have no desire to implement such thing (yet) so You can consider it removed from my proposal. But: I would like to take Ben's side here for a second (the rest of the mail is as such). I am sorry to say that You did not present a valid technical argument against Ben's proposal - the arguments presented are based on history, what the intent of the author was and that it does not fit into the IMAP picture, etc. The answer to history is evolution. If the author's intent was not to allow "trashing mails", He would have made sure that it was not possible. Since it is allowed by the protocol I believe there is no problem with it at all. If the working group decides that "no, we don't want an interoperable way to identify trash folder between clients", You achieve nothing more than force clients to do proprietary implementations to achieve this - which is the exact opposite what standards are made for. And this is the particular point that bugs me the most. >That's the situation faced today by any client that uses=20 >"trash" instead of the proper delete/expunge model. It has=20 >served as a deterrant; I know client authors who gritted their=20 >teeth, and did the right thing even though a trash mailbox=20 >would have made their job easier. I feel sorry for those client implementors - they were forced doing something that some people think to be the right thing. I also find it sad that they were so weak-willed that they accepted this when the protocol allows "trashing" as well - perhaps they were doing a client for themselves only for a small group of people and not trying to satisfy a quickly evolving market that involves quite a lot of people. Then again, I do not think that "trashing" was proposed to "make the client's job easy". Consider this: At home I collect to the garbage to a bag, and take it out every now and then. What You saying here is that I should let the garbage laying on the floor, put a PostIt on them that says "garbage", and I can collect them any time I want. You are right - it achieves the exact same thing: the garbage will be gone eventually, however the second model has several drawbacks. The most disturbing ones are: - it takes a lot of time to colllect the garbage from every room (you need to look carefully) - garbage all over the house is just gross. I believe "trashing" was proposed to make the user's life easier: to implement a more efficient email disposal mechnism that the users are used to and feels more 'natural'. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Aug 08 04:03:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAMYv-0002Dc-Cd; Tue, 08 Aug 2006 04:03:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAMYu-00028N-4G for lemonade@ietf.org; Tue, 08 Aug 2006 04:03:40 -0400 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAMYp-0008V2-2j for lemonade@ietf.org; Tue, 08 Aug 2006 04:03:40 -0400 Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.12]) by smarthost.yourcomms.net (8.11.7p1+Sun/8.11.6) with ESMTP id k787pWw23701 for ; Tue, 8 Aug 2006 08:51:32 +0100 (BST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: RE: [lemonade] some questions in draft-ietf-lemonade-notifications-03 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Aug 2006 09:03:02 +0100 Message-ID: <22C8A0D5D5E095449AB509FE777B5F8002A8B68C@svr-exchange.avocado.emccsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] some questions in draft-ietf-lemonade-notifications-03 Thread-Index: Aca4K0ZLELAjAZKGReeMuOtPLs1Z9wCk+y4Q From: "Ben Last" To: "Randall Gellens" , "Gang Liang" , X-Spam-Score: 1.1 (+) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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 From: Randall Gellens [mailto:randy@qualcomm.com]=20 Sent: 05 August 2006 02:05 >At 1:48 PM +0800 7/27/06, Gang Liang wrote: >> What's the benefit of limiting the total number of messages >> (notifications) per-day? If the number of notifications sent that day >> has reached the limit (e.g. 10 notifications per-day ) but then a very=20 >> important email arrives, what should the server do? >I agree. The issue of throttling is one that will need to be addressed, but a simplistic per-day limit doesn't seem to be the way to solve it. I'd argue that throttling is a *client* issue, not a server issue, in that the user is in more direct control of the mobile client and can make decisions about incurring download costs. For example, our client allows a variety of options about when synchronizations take plae and how messages and attachment are downloaded (on demand, in anticipation, etc). I don't know for sure what the situation is in the US, but in Europe the data charges applicable can vary like crazy depending on where one is, and it's awkward to have to change server settings as you move from roaming zone to roaming zone. And I absolutely agree with Randall that a per-day limit is overly simplistic. >> Is it possible to push new messages via outband notifications? E.g.=20 >> through MMS channel. If it's possible, maybe we could define such an=20 >> attribute for outband notification. >Personally, I don't see much benefit in using MMS to push mail or notifications. I agree; I certainly don't see any benefit over using SMS to do notifications. Right now, it costs a minimum of 30p (UK prices) to originate an MMS via UK messaging providers (that price is a bulk one), but SMS messages can cost as little as 3.5p (again, in bulk). An SMS gives enough space to send the basic values needed for an OOB notification (EXISTS count, etc). More to the point, though, on a flat-rate data plan there is no extra cost to the user for receiving in-band notification of update events. Even when data's charged by the megabyte the cost per in-band notification is likely to be tiny. The cost of an SMS or MMS is likely to be several times more than the in-band cost, and it has to be borne by the server operator (who may then have to find a way to pass it on to the end-user). >> Does it mean that the target (client) should provide acknowledgment=20 >> for per-notification and the messaging system should repeat the same=20 >> notification (not send the following notifications) until receive the >> acknowledgment for the notification? >This is what I think the document is saying, but personally I have concerns with this approach. And I'd point to the notes above about SMS/MMS costs here. Personally I'd worry about any system that might start sending repeated notifications. However, the receipt reporting for SMS messages is usually extremely reliable, so it's possible to conclude with a high degree of assurance that an SMS has reached the target device (not, however, whether any software on the device has read the message). That would help reduce the need for an active client response. Regards, ben -- 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 Aug 08 23:08:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAeQn-0003eq-OB; Tue, 08 Aug 2006 23:08:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAeQm-0003ay-Eb for lemonade@ietf.org; Tue, 08 Aug 2006 23:08:28 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAeQj-0001er-Vd for lemonade@ietf.org; Tue, 08 Aug 2006 23:08:28 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J3P000FENO08U@szxga03-in.huawei.com> for lemonade@ietf.org; Wed, 09 Aug 2006 11:14:24 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J3P005C9NNYB2@szxga03-in.huawei.com> for lemonade@ietf.org; Wed, 09 Aug 2006 11:14:24 +0800 (CST) Received: from l48785 ([10.164.120.53]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J3P00CSSNQNG1@szxml04-in.huawei.com> for lemonade@ietf.org; Wed, 09 Aug 2006 11:16:01 +0800 (CST) Date: Wed, 09 Aug 2006 11:04:09 +0800 From: Gang Liang Subject: Re: [lemonade] some questions in draft-ietf-lemonade-notifications-03 To: lemonade@ietf.org Message-id: <000f01c6bb60$7c3dfe90$3578a40a@china.huawei.com> Organization: Huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 2.1 (++) X-Scan-Signature: fca741f5016e6ff607eaed2fd431d10d X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Gang Liang List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0787978556==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============0787978556== Content-type: multipart/alternative; boundary="Boundary_(ID_CxZkwHx2G8e6uBwHNKkgRw)" This is a multi-part message in MIME format. --Boundary_(ID_CxZkwHx2G8e6uBwHNKkgRw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi Randall Gellens and ben, Thank you for your reply. I combined the comments from both of you (comments from ben surrounded with double [ben]----) and gave some other comments inline. ----- Original Message ----- From: "Randall Gellens" To: "Gang Liang" ; Sent: Saturday, August 05, 2006 9:04 AM Subject: Re: [lemonade] some questions in draft-ietf-lemonade-notifications-03 >I haven't seen any replies to your questions. Here are my views. > > > At 1:48 PM +0800 7/27/06, Gang Liang wrote: > >> Questions 1: >> >> In 10.2 (Provision Entries), "push.shared" is defined as an >> attribute of in-band notifications (not the attribute of outband >> notifications) while in the first example in 10.4 "push.shared" >> is regarded as the attribute of outband notifications. >> >> Why? Maybe "push.shared" should be defined as an attribute of >> outband notifications too. > > I have concerns about the concept of using mailbox annotations for this > purpose. For one thing, it seems to be have problems in the case where > users have multiple devices. > In 10.2 "push.shared" is defined as an attribute of in-band notification while in the example in 10.4 it's regarded as the attribute of outband notification. Maybe it's because there is a typo in the example or some other mistakes. > >> Question 2: >> >> In 10.3 >> >> "limit.priv" = "size=" nz-number | >> "total=" nz-number >> >> ;the maximum number of bytes to send in notification payloads or the >> total number of messages to send. Both per-day >> >> What's the benefit of limiting the total number of messages >> (notifications) per-day? If the number of notifications sent that day has >> reached the limit (e.g. 10 notifications per-day ) but then a very >> important email arrives, what should the server do? > > I agree. The issue of throttling is one that will need to be addressed, > but a simplistic per-day limit doesn't seem to be the way to solve it. > [ben]----------------------------- I'd argue that throttling is a *client* issue, not a server issue, in that the user is in more direct control of the mobile client and can make decisions about incurring download costs. For example, our client allows a variety of options about when synchronizations take plae and how messages and attachment are downloaded (on demand, in anticipation, etc). I don't know for sure what the situation is in the US, but in Europe the data charges applicable can vary like crazy depending on where one is, and it's awkward to have to change server settings as you move from roaming zone to roaming zone. And I absolutely agree with Randall that a per-day limit is overly simplistic. [ben]-------------------------------- I agree. >> Question 3: >> >> In 10.3: >> >> "push.priv" = "push" / "pull" >> >> ;specifies whether the client expects new messages to be pushed via the >> unsolicited FETCH response defined above, or via client issued FETCH in >> response to an EXISTS response. >> >> Is it possible to push new messages via outband notifications? E.g. >> through MMS channel. If it's possible, maybe we could define such an >> attribute for outband notification. > > Personally, I don't see much benefit in using MMS to push mail or > notifications. [ben]----------------------------------------- I agree; I certainly don't see any benefit over using SMS to do notifications. Right now, it costs a minimum of 30p (UK prices) to originate an MMS via UK messaging providers (that price is a bulk one), but SMS messages can cost as little as 3.5p (again, in bulk). An SMS gives enough space to send the basic values needed for an OOB notification (EXISTS count, etc). More to the point, though, on a flat-rate data plan there is no extra cost to the user for receiving in-band notification of update events. Even when data's charged by the megabyte the cost per in-band notification is likely to be tiny. The cost of an SMS or MMS is likely to be several times more than the in-band cost, and it has to be borne by the server operator (who may then have to find a way to pass it on to the end-user). [ben]----------------------------------------- >More specifically on your question of including the > message itself in the notification, I think that is feasible with small > messages, but not large ones. Also, to the extent that notifications are > unreliable, this would only be an ancillary service; that is, the client > may get messages via notifications, but if this fails for any reason the > client will get them normally. Your views make sense. Using MMS to push email or notifications is just an example. What I want to talk about is the feasibility and rationality of pushing an email via outband notification. E.g. if the client is GPRS online and the email is very urgent, maybe it's more appropriate to push the email directly in the notification instead of pushing a wake-up notification that makes the client to create a connection with server to fetch the email. > >> Question 4: >> >> In 13.8 >> >> It MUST be possible to provide acknowledgment by the target to the >> messaging system or to repeat notification until such an acknowledgement >> is provided if supported by the notification channel. >> >> Does it mean that the target (client) should provide acknowledgment for >> per-notification and the messaging system should repeat the same >> notification (not send the following notifications) until receive the >> acknowledgment for the notification? > > This is what I think the document is saying, but personally I have > concerns with this approach. [ben]------------------------------------------- And I'd point to the notes above about SMS/MMS costs here. Personally I'd worry about any system that might start sending repeated notifications. However, the receipt reporting for SMS messages is usually extremely reliable, so it's possible to conclude with a high degree of assurance that an SMS has reached the target device (not, however, whether any software on the device has read the message). That would help reduce the need for an active client response. [ben]-------------------------------------------- If the messaging system can not receive the acknowledgment for a notification, maybe it's because the client is unavailable or the notification is lost or some other reasons. For the listed two reasons, the approach may be different. I think it's a waste to provide acknowledgments for all of the notifications or to send repeated notifications. > >> If so, maybe it's more appropriate to send a notification after >> determining that the client is online (e.g. according to presence status >> of the client provided by presence enabler). > How do you think this approach? Another question: In 13.8: A client can recover all missing events next time it connects to the server and the server MUST buffer the notifications and make them available to the MUA when it comes back to the server. Which notifications MUST the server buffer? All missing notifications or all of the notifications since the last connection? If the notifications that the server MUST buffer are all missing notifications, how the server determine what notifications are missing? According to acknowledgment? > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly-selected tag: --------------- > I had a fortune cookie the other day and it said, "Outlook not > so good." I said, "Sure, but Microsoft ships it anyway." > --Tom Singer > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade > Regards, Gang Liang ---------------------------------------------------- Lianggang Huawei Technologies Tel:+86 25 84676084 Mob:+86 13813998674 Fax:+86 25 84676060 Email:lianggang79@huawei.com ---------------------------------------------------- --Boundary_(ID_CxZkwHx2G8e6uBwHNKkgRw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi Randall Gellens and ben,

Thank you for your reply.
I combined the comments from both of you (comments from ben surrounded with
double [ben]----) and gave some other comments inline.

----- Original Message -----
From: "Randall Gellens" <randy@qualcomm.com>
To: "Gang Liang" <lianggang79@huawei.com>; <lemonade@ietf.org>
Sent: Saturday, August 05, 2006 9:04 AM
Subject: Re: [lemonade] some questions in
draft-ietf-lemonade-notifications-03


>I haven't seen any replies to your questions.  Here are my views.
>
>
> At 1:48 PM +0800 7/27/06, Gang Liang wrote:
>
>>  Questions 1:
>>
>>  In 10.2 (Provision Entries), &quot;push.shared&quot; is defined as an
>> attribute of in-band notifications (not the attribute of outband
>> notifications) while in the first example in 10.4 &quot;push.shared&quot;
>> is regarded as the attribute of outband notifications.
>>
>>  Why? Maybe &quot;push.shared&quot; should be defined as an attribute of
>> outband notifications too.
>
> I have concerns about the concept of using mailbox annotations for this
> purpose.  For one thing, it seems to be have problems in the case where
> users have multiple devices.
>
In 10.2 "push.shared" is defined as an attribute of in-band notification
while in the example in 10.4 it's regarded as the attribute of outband
notification.
Maybe it's because there is a typo in the example or some other mistakes.
>
>>  Question 2:
>>
>>  In 10.3
>>
>>  &quot;limit.priv&quot; = &quot;size=&quot; nz-number  |
>> &quot;total=&quot; nz-number
>>
>>  ;the maximum number of bytes to send in notification payloads or the
>> total number of messages to send. Both per-day
>>
>>  What's the benefit of limiting the total number of messages
>> (notifications) per-day? If the number of notifications sent that day has
>> reached the limit (e.g. 10 notifications per-day ) but then a very
>> important email arrives, what should the server do?
>
> I agree.  The issue of throttling is one that will need to be addressed,
> but a simplistic per-day limit doesn't seem to be the way to solve it.
>
[ben]-----------------------------
I'd argue that throttling is a *client* issue, not a server issue, in
that the user is in more direct control of the mobile client and can
make decisions about incurring download costs.  For example, our client
allows a variety of options about when synchronizations take plae and
how messages and attachment are downloaded (on demand, in anticipation,
etc).  I don't know for sure what the situation is in the US, but in
Europe the data charges applicable can vary like crazy depending on
where one is, and it's awkward to have to change server settings as you
move from roaming zone to roaming zone.  And I absolutely agree with
Randall that a per-day limit is overly simplistic.
[ben]--------------------------------
I agree.
>>  Question 3:
>>
>>  In 10.3:
>>
>>  &quot;push.priv&quot; = &quot;push&quot; / &quot;pull&quot;
>>
>>  ;specifies whether the client expects new messages to be pushed via the
>> unsolicited FETCH response defined above, or via client issued FETCH in
>> response to an EXISTS response.
>>
>>  Is it possible to push new messages via outband notifications? E.g.
>> through MMS channel. If it's possible, maybe we could define such an
>> attribute for outband notification.
>
> Personally, I don't see much benefit in using MMS to push mail or
> notifications.
[ben]-----------------------------------------
I agree; I certainly don't see any benefit over using SMS to do
notifications.  Right now, it costs a minimum of 30p (UK prices) to
originate an MMS via UK messaging providers (that price is a bulk one),
but SMS messages can cost as little as 3.5p (again, in bulk).  An SMS
gives enough space to send the basic values needed for an OOB
notification (EXISTS count, etc).
More to the point, though, on a flat-rate data plan there is no extra
cost to the user for receiving in-band notification of update events.
Even when data's charged by the megabyte the cost per in-band
notification is likely to be tiny.  The cost of an SMS or MMS is likely
to be several times more than the in-band cost, and it has to be borne
by the server operator (who may then have to find a way to pass it on to
the end-user).
[ben]-----------------------------------------
>More specifically on your question of including the
> message itself in the notification, I think that is feasible with small
> messages, but not large ones.  Also, to the extent that notifications are
> unreliable, this would only be an ancillary service; that is, the client
> may get messages via notifications, but if this fails for any reason the
> client will get them normally.

Your views make sense.
Using MMS to push email or notifications is just an example. What I want to
talk about is the feasibility and rationality of pushing an email via
outband notification. E.g. if the client is GPRS online and the email is
very urgent, maybe it's more appropriate to push the email directly in the
notification instead of pushing a wake-up notification that makes the client
to create a connection with server to fetch the email.
>
>>  Question 4:
>>
>>  In 13.8
>>
>>  It MUST be possible to provide acknowledgment by the target to the
>> messaging system or to repeat notification until such an acknowledgement
>> is provided if supported by the notification channel.
>>
>>  Does it mean that the target (client) should provide acknowledgment for
>> per-notification and the messaging system should repeat the same
>> notification (not send the following notifications) until receive the
>> acknowledgment for the notification?
>
> This is what I think the document is saying, but personally I have
> concerns with this approach.
[ben]-------------------------------------------
And I'd point to the notes above about SMS/MMS costs here.  Personally
I'd worry about any system that might start sending repeated
notifications.  However, the receipt reporting for SMS messages is
usually extremely reliable, so it's possible to conclude with a high
degree of assurance that an SMS has reached the target device (not,
however, whether any software on the device has read the message).  That
would help reduce the need for an active client response.
[ben]--------------------------------------------
If the messaging system can not receive the acknowledgment for a
notification, maybe it's because the client is unavailable or the
notification is lost or some other reasons. For the listed two reasons, the
approach may be different.
I think it's a waste to provide acknowledgments for all of the
notifications or to send repeated notifications.
>
>>  If so, maybe it's more appropriate to send a notification after
>> determining that the client is online (e.g. according to presence status
>> of the client provided by presence enabler).
>
How do you think this approach?

Another question:
In 13.8: A client can recover all missing events next time it connects to
the server and the server MUST buffer the notifications and make them
available to the MUA when it comes back to the server.

Which notifications MUST the server buffer? All missing notifications or all
of the notifications since the last connection? If the notifications that
the server MUST buffer are all missing notifications, how the server
determine what notifications are missing? According to acknowledgment?

> --
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for myself only
> -------------- Randomly-selected tag: ---------------
> I had a fortune cookie the other day and it said, "Outlook not
> so good."  I said, "Sure, but Microsoft ships it anyway."
>                                                  --Tom Singer
>
> _______________________________________________
> lemonade mailing list
> lemonade@ietf.org
> https://www1.ietf.org/mailman/listinfo/lemonade
>

Regards,
Gang Liang
----------------------------------------------------
Lianggang
Huawei Technologies
Tel:+86 25 84676084
Mob:+86 13813998674
Fax:+86 25 84676060
Email:lianggang79@huawei.com
----------------------------------------------------
--Boundary_(ID_CxZkwHx2G8e6uBwHNKkgRw)-- --===============0787978556== 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 --===============0787978556==-- From lemonade-bounces@ietf.org Wed Aug 09 04:36:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAjYf-0004ks-HB; Wed, 09 Aug 2006 04:36:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAjYe-0004kn-9K for lemonade@ietf.org; Wed, 09 Aug 2006 04:36:56 -0400 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAjYa-0003RM-8i for lemonade@ietf.org; Wed, 09 Aug 2006 04:36:56 -0400 Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.12]) by smarthost.yourcomms.net (8.11.7p1+Sun/8.11.6) with ESMTP id k798Olw15696 for ; Wed, 9 Aug 2006 09:24:47 +0100 (BST) 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] some questions in draft-ietf-lemonade-notifications-03 Date: Wed, 9 Aug 2006 09:36:18 +0100 Message-ID: <22C8A0D5D5E095449AB509FE777B5F8002A8BF74@svr-exchange.avocado.emccsoft.com> In-Reply-To: <000f01c6bb60$7c3dfe90$3578a40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] some questions in draft-ietf-lemonade-notifications-03 Thread-Index: Aca7YS+A8Pk1D5JjTaOrc5T3/NASQQAKTkHA From: "Ben Last" To: "Gang Liang" , X-Spam-Score: 1.1 (+) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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 Gang Liang [mailto:lianggang79@huawei.com] wrote on 09 August 2006 04:04: >Using MMS to push email or notifications is just an example. What I want to >talk about is the feasibility and rationality of pushing an email via >outband notification. E.g. if the client is GPRS online and the email is >very urgent, maybe it's more appropriate to push the email directly in the >notification instead of pushing a wake-up notification that makes the client >to create a connection with server to fetch the email. I think, then, that one of the key factors is the amount of data you can get into an outband notification. You can fit 140 bytes into an SMS, so there's not much room for more than a notification that events have occurred. You can fit far more into an MMS (with all the cost implications) and if the client is SIP-addressible from the server over something like IMS, you can push the whole email. So one definition of outband won't, of course, cover all. However, I think that the decisions on (a) when to retrieve mail and (b) how much to retrieve are better made by the client. For example, if the client can tell that the email is low-priority, or that it is in an area where network access is slow and expensive, it may choose to retrieve messages only once per hour, and to retrieve only the headers. Or, if it detects that it is in range of a usable wi-fi connection, and thus has high-speed and low-cost access, it might choose to retrieve the header and message text of new emails. In the mobile phone environment, I think there are many factors, which vary with time and location and that are detectable only by the client, which might affect the client's decisions about how to respond to the information that new messages (or changes to messages) are available. >I think it's a waste to provide acknowledgments for all of the >notifications or to send repeated notifications. OMA EMN, sends a timestamp, covers this, and Lemonade profile-bis-01 uses OMA EMN as the payload of a notification. Thus the cost of a missed message due to change A would be reduced, since the next message sent due to change B would implicitly include the fact that change A had occurred. This lets the client make all the decisions (as above) and avoids potential issues with duplication of notifications. >"Randall Gellens" wrote: >> If so, maybe it's more appropriate to send a notification after >> determining that the client is online (e.g. according to presence status >> of the client provided by presence enabler). >How do you think this approach? Many presence systems allow the user to set their status as "offline" (even though they're not really offline): the presence status is aimed at other humans and gives the user's interruptability. That may not be appropriate for a server to use when determining whether to send new mail notifications. >In 13.8: "A client can recover all missing events next time it connects to >the server and the server MUST buffer the notifications and make them >available to the MUA when it comes back to the server." >Which notifications MUST the server buffer? All missing notifications or all >of the notifications since the last connection? If the notifications that >the server MUST buffer are all missing notifications, how the server >determine what notifications are missing? According to acknowledgment? I wasn't going to respond to this since there are so many others far better able and qualified on the list, but as I understand it, the server may decide that the client has been away for too long and terminate the session. In this case, the client would not get a SESSION response when it next connected and would have to perform a state-comparison synchronization. Thus the server does have the option to avoid buffering if it becomes an excessive burden. Regards to all Ben EMCC Software Ltd _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Aug 09 04:58:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAjtP-0007j8-4f; Wed, 09 Aug 2006 04:58:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAjtO-0007j3-FF for lemonade@ietf.org; Wed, 09 Aug 2006 04:58:22 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAjtN-0006BM-1o for lemonade@ietf.org; Wed, 09 Aug 2006 04:58:22 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1GAjtL-0005Uu-NL; Wed, 09 Aug 2006 08:58:20 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 6975D498003; Wed, 9 Aug 2006 10:04:24 +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 31241-03; Wed, 9 Aug 2006 10:04:13 +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 14AE5498002; Wed, 9 Aug 2006 10:04:13 +0100 (BST) Date: Wed, 09 Aug 2006 09:58:07 +0100 Subject: RE: [lemonade] some questions in draft-ietf-lemonade-notifications-03 References: =?US-ASCII?Q?<22C8A0D5D5E095449AB509FE777B5F800?= =?US-ASCII?Q?A8BF74@svr-exchange.avocado.emccsoft.com>?= In-Reply-To: =?US-ASCII?Q?<22C8A0D5D5E095449AB509FE777B5F80?= =?US-ASCII?Q?2A8BF74@svr-exchange.avocado.emccsoft.com>?= MIME-Version: 1.0 Message-Id: <13887.1155113887.463913@peirce.dave.cridland.net> From: Dave Cridland To: Ben Last 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: 1.2 (+) 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 Wed Aug 9 09:36:18 2006, Ben Last wrote: > >"Randall Gellens" wrote: > >> If so, maybe it's more appropriate to send a notification after > >> determining that the client is online (e.g. according to presence > status > >> of the client provided by presence enabler). > >How do you think this approach? > > Many presence systems allow the user to set their status as > "offline" > (even though they're not really offline): the presence status is > aimed > at other humans and gives the user's interruptability. That may > not be > appropriate for a server to use when determining whether to send new > mail notifications. > > True, but equally, most presence mechanisms have the concept of appearing offline by default, but allowing a directed presence to indicate they're online to certain endpoints. In general, I think this would be good enough - you'd simply have the client appear offline, but send a directed presence for the notification server. 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 Aug 09 06:14:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAl5T-0006Qe-6j; Wed, 09 Aug 2006 06:14:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAl5S-0006OA-92 for lemonade@ietf.org; Wed, 09 Aug 2006 06:14:54 -0400 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAl5Q-00022o-TU for lemonade@ietf.org; Wed, 09 Aug 2006 06:14:54 -0400 Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.12]) by smarthost.yourcomms.net (8.11.7p1+Sun/8.11.6) with ESMTP id k79A2jn27342 for ; Wed, 9 Aug 2006 11:02:46 +0100 (BST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: RE: [lemonade] some questions in draft-ietf-lemonade-notifications-03 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Aug 2006 11:14:13 +0100 Message-ID: <22C8A0D5D5E095449AB509FE777B5F8002A8C0DB@svr-exchange.avocado.emccsoft.com> In-Reply-To: <13887.1155113887.463913@peirce.dave.cridland.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] some questions in draft-ietf-lemonade-notifications-03 Thread-Index: Aca7kei2lYYpimUHRFeIOD/NcUwVowACitDg From: "Ben Last" To: "Dave Cridland" X-Spam-Score: 1.1 (+) 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 Dave Cridland [mailto:dave@cridland.net] wrote on 09 August 2006 09:58: >On Wed Aug 9 09:36:18 2006, Ben Last wrote: >> Many presence systems allow the user to set their status as "offline" >> (even though they're not really offline): the presence status is aimed=20 >> at other humans and gives the user's interruptability. That may not=20 >> be appropriate for a server to use when determining whether to send=20 >> new mail notifications. >True, but equally, most presence mechanisms have the concept of appearing offline by default, but allowing a >directed presence to indicate they're online to certain endpoints. In general, I think this would be good >enough - you'd simply have the client appear offline, but send a directed presence for the notification server. A very good point, but then you have the problem that every presence client potentially needs to keep adding directed presence information for a new endpoint for each new server use case that crops up, and the relatively simple notion of presence as "user's interruptability" becomes overloaded by all sorts of other semantics. Plus the presence information on a given client may be handled by some IM application that doesn't have any programmatic way to add new sorts of directed presence. Regards Ben EMCC Software Ltd _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Aug 09 06:25:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAlFK-0002wn-TC; Wed, 09 Aug 2006 06:25:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAlFJ-0002wb-MU for lemonade@ietf.org; Wed, 09 Aug 2006 06:25: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 1GAkA9-0000C4-UP for lemonade@ietf.org; Wed, 09 Aug 2006 05:15:41 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GAjt4-0007pq-Gd for lemonade@ietf.org; Wed, 09 Aug 2006 04:58:04 -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 k798vo5B000947; Wed, 9 Aug 2006 11:57:50 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 11:57:49 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 11:57: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] some questions in draft-ietf-lemonade-notifications-03 Date: Wed, 9 Aug 2006 11:57:16 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657B2F6BC@esebe199.NOE.Nokia.com> In-Reply-To: <22C8A0D5D5E095449AB509FE777B5F8002A8BF74@svr-exchange.avocado.emccsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] some questions in draft-ietf-lemonade-notifications-03 Thread-Index: Aca7YS+A8Pk1D5JjTaOrc5T3/NASQQAKTkHAAAHLRvA= From: To: , , X-OriginalArrivalTime: 09 Aug 2006 08:57:49.0492 (UTC) FILETIME=[E3E7F740:01C6BB91] X-Spam-Score: -1.8 (-) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f 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 Ben, Why would anyone use MMS for notification? It it nothing more than a WAP = Push (well, there is a bit more but from email notification point of = view nothing useful). Why not use WAP Push right away (without all the = hassle that comes with MMS)? Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 =20 >-----Original Message----- >From: ext Ben Last [mailto:Ben.Last@emccsoft.com]=20 >Sent: 09 August, 2006 11:36 >To: Gang Liang; lemonade@ietf.org >Subject: RE: [lemonade] some questions in=20 >draft-ietf-lemonade-notifications-03 > >Gang Liang [mailto:lianggang79@huawei.com] wrote on 09 August 2006 >04:04: >>Using MMS to push email or notifications is just an example. What I >want to >>talk about is the feasibility and rationality of pushing an email via=20 >>outband notification. E.g. if the client is GPRS online and the email >is >>very urgent, maybe it's more appropriate to push the email directly in >the >>notification instead of pushing a wake-up notification that makes the >client >>to create a connection with server to fetch the email. > >I think, then, that one of the key factors is the amount of=20 >data you can get into an outband notification. You can fit=20 >140 bytes into an SMS, so there's not much room for more than=20 >a notification that events have occurred. You can fit far=20 >more into an MMS (with all the cost >implications) and if the client is SIP-addressible from the=20 >server over something like IMS, you can push the whole email. =20 >So one definition of outband won't, of course, cover all. > >However, I think that the decisions on (a) when to retrieve=20 >mail and (b) how much to retrieve are better made by the=20 >client. For example, if the client can tell that the email is=20 >low-priority, or that it is in an area where network access is=20 >slow and expensive, it may choose to retrieve messages only=20 >once per hour, and to retrieve only the headers. Or, if it=20 >detects that it is in range of a usable wi-fi connection, and=20 >thus has high-speed and low-cost access, it might choose to=20 >retrieve the header and message text of new emails. In the=20 >mobile phone environment, I think there are many factors,=20 >which vary with time and location and that are detectable only=20 >by the client, which might affect the client's decisions about=20 >how to respond to the information that new messages (or=20 >changes to messages) are available. > >>I think it's a waste to provide acknowledgments for all of the=20 >>notifications or to send repeated notifications. >OMA EMN, sends a timestamp, covers this, and Lemonade=20 >profile-bis-01 uses OMA EMN as the payload of a notification. =20 >Thus the cost of a missed message due to change A would be=20 >reduced, since the next message sent due to change B would=20 >implicitly include the fact that change A had occurred. This=20 >lets the client make all the decisions (as above) and avoids=20 >potential issues with duplication of notifications. > >>"Randall Gellens" wrote: >>> If so, maybe it's more appropriate to send a notification after=20 >>> determining that the client is online (e.g. according to presence >status >>> of the client provided by presence enabler). >>How do you think this approach? > >Many presence systems allow the user to set their status as "offline" >(even though they're not really offline): the presence status=20 >is aimed at other humans and gives the user's=20 >interruptability. That may not be appropriate for a server to=20 >use when determining whether to send new mail notifications. > >>In 13.8: "A client can recover all missing events next time=20 >it connects >to >>the server and the server MUST buffer the notifications and make them=20 >>available to the MUA when it comes back to the server." >>Which notifications MUST the server buffer? All missing notifications >or all >>of the notifications since the last connection? If the notifications >that >>the server MUST buffer are all missing notifications, how the server=20 >>determine what notifications are missing? According to acknowledgment? >I wasn't going to respond to this since there are so many=20 >others far better able and qualified on the list, but as I=20 >understand it, the server may decide that the client has been=20 >away for too long and terminate the session. In this case,=20 >the client would not get a SESSION response when it next=20 >connected and would have to perform a state-comparison=20 >synchronization. Thus the server does have the option to=20 >avoid buffering if it becomes an excessive burden. > >Regards to all >Ben >EMCC Software Ltd > >_______________________________________________ >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 Aug 09 07:22:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAm91-0007dc-0t; Wed, 09 Aug 2006 07:22:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAm90-0007aE-4u for lemonade@ietf.org; Wed, 09 Aug 2006 07:22:38 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAm8y-00021u-N9 for lemonade@ietf.org; Wed, 09 Aug 2006 07:22:38 -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 k79BMOoS030733; Wed, 9 Aug 2006 14:22:24 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 14:22:23 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 14:22: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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] some questions in draft-ietf-lemonade-notifications-03 Date: Wed, 9 Aug 2006 14:21:51 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657B2F8A5@esebe199.NOE.Nokia.com> In-Reply-To: <22C8A0D5D5E095449AB509FE777B5F8002A8C049@svr-exchange.avocado.emccsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] some questions in draft-ietf-lemonade-notifications-03 Thread-Index: Aca7YS+A8Pk1D5JjTaOrc5T3/NASQQAKTkHAAAHLRvAAAnn3oAAB19jg From: To: , , X-OriginalArrivalTime: 09 Aug 2006 11:22:23.0346 (UTC) FILETIME=[15ED0D20:01C6BBA6] X-Spam-Score: 1.3 (+) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 >>Ben, >>Why would anyone use MMS for notification? It it nothing more than a >WAP Push (well, there is a bit more but from email=20 >notification point of view >>nothing useful). Why not use WAP Push right away (without all the >hassle that comes with MMS)? > >I'd guess that it's because all the WAP-push-and-fetch=20 >functionality is handled by the platform. For example, on a=20 >Symbian-based device, it's easy to write a watcher process=20 >that will spot incoming MMS messages and process them, so from=20 >the point of view of the programmer you get a messaging system=20 >that will handle large messages as simply as SMS handles small=20 >ones, without any additional hassle. Sure, it's more complex=20 >from the OS's point of view, but that's hidden from the=20 >programmer. Similarly, most message-service providers provide=20 >APIs (over HTTP or RPC) that make sending MMS messages as easy=20 >as sending SMSs. Hmmm. You have a point about trying to make it as simple as sending SMSes. However, I feel that is is a waste of resources and bandwidth - I heard it expressed from operators already (they are even reluctant to use Wap Push and prefer SMS because it comsumes the least). When You get an MMS, this goes down: 1. You get a Wap Push message to tell You that You have an MMS. 2. You do HTTP/GET to fetch the MMS Message. 3. You get the HTTP respnse that contains that the actual notification. Now scale this up to a million user. This is the reason why I do not see any reason why would anyone do MMS - it adds with way too much signalling (and, consequently wait times) over the wireless network. But, my understanding is that the client can decide which notification medium to use (please correct if I am wrong), so one can choose to use SMS, Wap Push, MMS, right? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Aug 09 07:34:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAmKB-0004fY-33; Wed, 09 Aug 2006 07:34:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAmK9-0004e7-Dq for lemonade@ietf.org; Wed, 09 Aug 2006 07:34:09 -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 1GAlV9-0005Gp-QQ for lemonade@ietf.org; Wed, 09 Aug 2006 06:41:27 -0400 Received: from smarthost.yourcomms.net ([195.8.160.124]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GAl1v-0000x8-2Q for lemonade@ietf.org; Wed, 09 Aug 2006 06:11:15 -0400 Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.12]) by smarthost.yourcomms.net (8.11.7p1+Sun/8.11.6) with ESMTP id k799x2n26878 for ; Wed, 9 Aug 2006 10:59:02 +0100 (BST) 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] some questions in draft-ietf-lemonade-notifications-03 Date: Wed, 9 Aug 2006 11:10:30 +0100 Message-ID: <22C8A0D5D5E095449AB509FE777B5F8002A8C049@svr-exchange.avocado.emccsoft.com> In-Reply-To: <0FA975F2D8295A448BE3ADC161244657B2F6BC@esebe199.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] some questions in draft-ietf-lemonade-notifications-03 Thread-Index: Aca7YS+A8Pk1D5JjTaOrc5T3/NASQQAKTkHAAAHLRvAAAnn3oA== From: "Ben Last" To: , , X-Spam-Score: -1.3 (-) 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 Zoltan.Ordogh@nokia.com [mailto:Zoltan.Ordogh@nokia.com] wrote on 09 August 2006 09:57: >Ben, >Why would anyone use MMS for notification? It it nothing more than a WAP Push (well, there is a bit more but from email notification point of view >nothing useful). Why not use WAP Push right away (without all the hassle that comes with MMS)? I'd guess that it's because all the WAP-push-and-fetch functionality is handled by the platform. For example, on a Symbian-based device, it's easy to write a watcher process that will spot incoming MMS messages and process them, so from the point of view of the programmer you get a messaging system that will handle large messages as simply as SMS handles small ones, without any additional hassle. Sure, it's more complex from the OS's point of view, but that's hidden from the programmer. Similarly, most message-service providers provide APIs (over HTTP or RPC) that make sending MMS messages as easy as sending SMSs. Regards Ben EMCC Software Ltd _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Aug 09 07:53:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAmdC-0006Dp-09; Wed, 09 Aug 2006 07:53:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAmdA-0006Db-43 for lemonade@ietf.org; Wed, 09 Aug 2006 07:53:48 -0400 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAmd8-0004mu-LX for lemonade@ietf.org; Wed, 09 Aug 2006 07:53:48 -0400 Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.12]) by smarthost.yourcomms.net (8.11.7p1+Sun/8.11.6) with ESMTP id k79Bffn10416 for ; Wed, 9 Aug 2006 12:41:41 +0100 (BST) 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] some questions in draft-ietf-lemonade-notifications-03 Date: Wed, 9 Aug 2006 12:53:12 +0100 Message-ID: <22C8A0D5D5E095449AB509FE777B5F8002A8C2C7@svr-exchange.avocado.emccsoft.com> In-Reply-To: <0FA975F2D8295A448BE3ADC161244657B2F8A5@esebe199.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] some questions in draft-ietf-lemonade-notifications-03 Thread-Index: Aca7YS+A8Pk1D5JjTaOrc5T3/NASQQAKTkHAAAHLRvAAAnn3oAAB19jgAAHAsiA= From: "Ben Last" To: , , X-Spam-Score: 1.1 (+) 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 Zoltan.Ordogh@nokia.com [mailto:Zoltan.Ordogh@nokia.com] wrote on 09 August 2006 12:22: >My understanding is that the client can decide which notification medium to use (please correct if I am wrong), so one can choose to use SMS, Wap Push, MMS, right? I'm not sure that would work in the real world (as opposed to the standard). It surely depends on whether the server has some way to send SMS, MMS or WAP push messages. That is, has the organization who have installed and are running the server subscribed to a service that allows them to send messages. So the client can't arbitrarily choose a notification medium. Also: as far as I know there is no standard way to code up the sending of an SMS. Every messaging provider I've ever interfaced with has a different way of doing it, so any server vendor would have to either offer a set of different interfaces (and the number of these could be very large) or expect the installation process to include coding up some messaging-service-provider specific way to handle the messages. Regards Ben EMCC Software Ltd _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Aug 09 08:35:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAnHr-0003Z0-L8; Wed, 09 Aug 2006 08:35:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAnHr-0003Yv-0i for lemonade@ietf.org; Wed, 09 Aug 2006 08:35:51 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAnHp-0008E8-JR for lemonade@ietf.org; Wed, 09 Aug 2006 08:35:50 -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 k79CZZJU023694; Wed, 9 Aug 2006 15:35:35 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 15:35:35 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 15:35: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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] some questions in draft-ietf-lemonade-notifications-03 Date: Wed, 9 Aug 2006 15:35:03 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657B2F95B@esebe199.NOE.Nokia.com> In-Reply-To: <22C8A0D5D5E095449AB509FE777B5F8002A8C2C7@svr-exchange.avocado.emccsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] some questions in draft-ietf-lemonade-notifications-03 Thread-Index: Aca7YS+A8Pk1D5JjTaOrc5T3/NASQQAKTkHAAAHLRvAAAnn3oAAB19jgAAHAsiAAAY3BYA== From: To: , , X-OriginalArrivalTime: 09 Aug 2006 12:35:34.0933 (UTC) FILETIME=[4F840C50:01C6BBB0] X-Spam-Score: 1.3 (+) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 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 >Also: as far as I know there is no standard way to code up the=20 >sending of an SMS. Every messaging provider I've ever=20 >interfaced with has a different way of doing it, so any server=20 >vendor would have to either offer a set of different=20 >interfaces (and the number of these could be very large) or=20 >expect the installation process to include coding up some=20 >messaging-service-provider specific way to handle the messages. I think it only gets worse with MMS - especially that it has several versions. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Aug 10 09:34:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBAg2-00089q-Dz; Thu, 10 Aug 2006 09:34:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBAg0-00089f-Os for lemonade@ietf.org; Thu, 10 Aug 2006 09:34:20 -0400 Received: from capricorn.lunarpages.com ([216.227.217.128]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBAfy-00041u-O9 for lemonade@ietf.org; Thu, 10 Aug 2006 09:34:20 -0400 Received: from cpanel by capricorn.lunarpages.com with local (Exim 4.52) id 1GBAhZ-0007Fb-JR for lemonade@ietf.org; Thu, 10 Aug 2006 06:35:57 -0700 Received: from 194.144.10.228 ([194.144.10.228]) by www.skeyti.com (Horde MIME library) with HTTP; Thu, 10 Aug 2006 06:35:57 -0700 Message-ID: <20060810063557.2l6j6i0jaayin4k4@www.skeyti.com> Date: Thu, 10 Aug 2006 06:35:57 -0700 From: Jon Ingi To: lemonade@ietf.org Subject: RE: [lemonade] some questions in draft-ietf-lemonade-notifications-03 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.1) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - capricorn.lunarpages.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [502 503] / [47 12] X-AntiAbuse: Sender Address Domain - skeyti.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 1.1 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jii@skeyti.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 [Ben Last wrote] > Also: as far as I know there is no standard way to code up the sending > of an SMS. Every messaging provider I've ever interfaced with has a > different way of doing it, so any server vendor would have to either > offer a set of different interfaces (and the number of these could be > very large) or expect the installation process to include coding up some > messaging-service-provider specific way to handle the messages. Correct. No standardised interfaces have been specified for the connection to a SMSC. The main propriatery protocols are listed in 3GPP doc 23.039, SMPP being the most popular in areas where I've been involved in deployments. HTTP based protocols are also very popular with various SMS aggregators. Jon Ingi _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Aug 10 09:43:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBAoU-0005Ni-On; Thu, 10 Aug 2006 09:43:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBAoT-0005NR-Rs for lemonade@ietf.org; Thu, 10 Aug 2006 09:43:05 -0400 Received: from capricorn.lunarpages.com ([216.227.217.128]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBAoR-0004cA-IL for lemonade@ietf.org; Thu, 10 Aug 2006 09:43:05 -0400 Received: from cpanel by capricorn.lunarpages.com with local (Exim 4.52) id 1GBAq2-0000xT-TV for lemonade@ietf.org; Thu, 10 Aug 2006 06:44:42 -0700 Received: from 194.144.10.228 ([194.144.10.228]) by www.skeyti.com (Horde MIME library) with HTTP; Thu, 10 Aug 2006 06:44:42 -0700 Message-ID: <20060810064442.39ohqd7n9tcs08w4@www.skeyti.com> Date: Thu, 10 Aug 2006 06:44:42 -0700 From: Jon Ingi To: lemonade@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.1) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - capricorn.lunarpages.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [502 503] / [47 12] X-AntiAbuse: Sender Address Domain - skeyti.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 1.6 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [lemonade] (no subject) X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jii@skeyti.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 [Zoltan Ordogh wrote] >> Also: as far as I know there is no standard way to code up the >> sending of an SMS. Every messaging provider I've ever interfaced >> with has a different way of doing it, so any server vendor would >> have to either offer a set of different interfaces (and the number >> of these could be very large) or expect the installation process to >> include coding up some messaging-service-provider specific way to >> handle the messages. > I think it only gets worse with MMS - especially that it has several > versions. Contrary to SMS there is a standardized interface for MMS: the SOAP based MM7 interface defined by 3GPP in 23.140. Nokia propriatery EAIF is also popular with those operators deploying Nokia MMSC, but usually they also support MM7. Usually MMSCs hide the differences between different versions of MM7 and support all of the different xml schemas that have been defined by 3GPP. Jon Ingi _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Aug 10 19:00:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBJW8-0003oV-9v; Thu, 10 Aug 2006 19:00:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBJW7-0003oC-Bj for lemonade@ietf.org; Thu, 10 Aug 2006 19:00:43 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBJW6-0003Ko-19 for lemonade@ietf.org; Thu, 10 Aug 2006 19:00:43 -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 k7AN0eda020030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 10 Aug 2006 16:00:41 -0700 Received: from [[192.168.1.13]] (vpn-10-50-16-19.qualcomm.com [10.50.16.19]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7AN0bZO015872 for ; Thu, 10 Aug 2006 16:00:39 -0700 (PDT) Mime-Version: 1.0 Message-Id: X-Mailer: Eudora for Mac OS X (dev alpha) X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Thu, 10 Aug 2006 15:58:14 -0700 To: lemonade@ietf.org From: Randall Gellens 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: 08e48e05374109708c00c6208b534009 Subject: [lemonade] profile-bis and format=flowed (RFC 3676) X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Perhaps profile-bis should recommend the use of format=flowed (RFC 3676). After all, the ability to reflow text (regular and quoted) to fit small screens was the primary motivation behind format=flowed. -- 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 Thu Aug 10 19:06:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBJc9-0007P7-D8; Thu, 10 Aug 2006 19:06:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBJc8-0007P2-5K for lemonade@ietf.org; Thu, 10 Aug 2006 19:06:56 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBJc5-0005bc-Rb for lemonade@ietf.org; Thu, 10 Aug 2006 19:06:56 -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 k7AN6hrs021418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 10 Aug 2006 16:06:44 -0700 Received: from [[192.168.1.13]] (vpn-10-50-16-19.qualcomm.com [10.50.16.19]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7AN6a7b026453; Thu, 10 Aug 2006 16:06:40 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <22C8A0D5D5E095449AB509FE777B5F80029DE205@svr-exchange.avocado.emccsof t.com> References: <22C8A0D5D5E095449AB509FE777B5F80029DE205@svr-exchange.avocado.emccsof t.com> X-Mailer: Eudora for Mac OS X (dev alpha) X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Thu, 10 Aug 2006 16:05:59 -0700 To: "Ben Last" , From: Randall Gellens 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: Subject: [lemonade] F=F (was '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 At 1:23 PM +0100 7/31/06, Ben Last wrote: > we're > developing a mobile Symbian LEMONADE client I strongly urge you to support RFC 3676 (format=flowed) in your client. Your messages on this list are an example of why f=f support is needed, by showing how hard it is to read replies that don't properly handle quoting or folding. Not to pick on you or anything :-) -- 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 Aug 10 20:52:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBLGB-0004DN-FF; Thu, 10 Aug 2006 20:52:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBLGA-0004DI-EU for lemonade@ietf.org; Thu, 10 Aug 2006 20:52:22 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBLG9-0003vW-2Z for lemonade@ietf.org; Thu, 10 Aug 2006 20:52:22 -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 k7B0qJ1N003165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 10 Aug 2006 17:52:20 -0700 Received: from [[192.168.1.13]] (vpn-10-50-16-97.qualcomm.com [10.50.16.97]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7B0qF20003780; Thu, 10 Aug 2006 17:52:18 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <0FA975F2D8295A448BE3ADC161244657A1B556@esebe199.NOE.Nokia.com> References: <0FA975F2D8295A448BE3ADC161244657A1B556@esebe199.NOE.Nokia.com> X-Mailer: Eudora for Mac OS X (dev alpha) X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Thu, 10 Aug 2006 17:47:50 -0700 To: , From: Randall Gellens 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 Cc: lemonade@ietf.org Subject: [lemonade] 'MOVE' (was 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 At 2:37 PM +0300 8/1/06, wrote: > I believe that it does add value and implementation problems are a > good thing - they force a better architecture in the long run - so > we should address this. This is an unusual viewpoint: that proposals which are difficult to implement are good. I have to disagree with it. Such proposals lead to fewer implementations than those which are easy to do, and the implementations that are done tend to be non-compliant and hence have poor interoperability. > Also, the command was suggested to be optional so it should not > cause any problems for those unwilling to implement it. This is an attitude that I see often in other standards bodies: that the solution to a controversial or objectionable proposal is to make it optional. Optional features harm interoperability because implementations cannot rely on them being present. This has especially been a problem with IMAP, which suffers from too much variability in server behavior and hence is difficult for clients. One of the goals of lemonade is to create a specification which covers a number of desirable extensions and hence is easier for clients to support, and easier for organizations to specify in their RFPs. > So that implementation problem You mention I only see as a minor > problem in exchange for a much bigger benefit (think about mobile > phones having to copy mails: download, upload, extra roundtrips) . We can work on the underlying problem without necessarily agreeing on this specific proposal. > But that's about it, I do not wish to open this discussion again (yet). I'm not sure it is fair to slip in comments such as "objections for some reason" (which imply that there were no good reasons for the objection) and then say "but I do not wish to reopen the discussion". By slipping in the comments on the proposal you have reopened the discussion. I think it would be more productive to focus on the specific problems rather than keep re-proposing a specific approach which would not solve them. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- And still I persist in wondering if folly must always be man's nemesis. --Edgar Pangborn _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Aug 10 20:55:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBLJV-00067A-G4; Thu, 10 Aug 2006 20:55:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBLJU-00062r-Su for lemonade@ietf.org; Thu, 10 Aug 2006 20:55:48 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBLJS-00053q-Hn for lemonade@ietf.org; Thu, 10 Aug 2006 20:55: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 k7B0tfvV000665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 10 Aug 2006 17:55:42 -0700 Received: from [[192.168.1.13]] (vpn-10-50-16-97.qualcomm.com [10.50.16.97]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7B0td7B022609; Thu, 10 Aug 2006 17:55:40 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <0FA975F2D8295A448BE3ADC161244657A9EA56@esebe199.NOE.Nokia.com> References: <0FA975F2D8295A448BE3ADC161244657A9EA56@esebe199.NOE.Nokia.com> X-Mailer: Eudora for Mac OS X (dev alpha) X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Thu, 10 Aug 2006 17:53:46 -0700 To: , From: Randall Gellens 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: a7d6aff76b15f3f56fcb94490e1052e4 Cc: lemonade@ietf.org Subject: [lemonade] Standards Process (was '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 At 12:06 PM +0300 8/4/06, wrote: > [Z=D6r] I disagree. This is the basis for=20 > standardization - people come up with ideas,=20 > and present them. Some people do not like it,=20 > fine. Later on someone else comes with the same=20 > idea, so these two agree that "hey: if they=20 > don't want to standardize it, fine: we will=20 > implement it anyway". So these guys implement=20 > it, and make a better service than anyone else=20 > and then You wish You have made it a standard.=20 > I believe everything should be standardized -=20 > so if someone decides to implement it then the=20 > solution will be available for the taking and=20 > it will be interoperable with others. That behavior is problematic for standardized=20 protocols. Just because two people agree to=20 implement a bad idea does not make it a good=20 idea. It leads to poor interoperability as some=20 people do it one way and others do it another.=20 The two people who went off in a huff and=20 implemented what they want after their specific=20 proposal was not accepted are guilty of the same=20 attitude they accuse the other participants of=20 engaging in: ignoring what others are saying. If someone comes in with a problem he or she=20 wants to solve, the group should indeed listen=20 and see if it can be solved and if so what is the=20 best way. The group shouldn't dismiss the person=20 out of hand. But if the person proposes a very=20 specific approach to the problem and the group=20 points out fundamental difficulties with that=20 approach, the person should likewise listen to=20 the objections and work together to find better=20 solutions. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- It is the business of the future to be dangerous. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Aug 10 20:59:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBLNQ-0001sm-4b; Thu, 10 Aug 2006 20:59:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBLNO-0001sh-9Q for lemonade@ietf.org; Thu, 10 Aug 2006 20:59:51 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBLNM-0005VY-Tz for lemonade@ietf.org; Thu, 10 Aug 2006 20:59:50 -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 k7B0xkib003951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 10 Aug 2006 17:59:47 -0700 Received: from [[192.168.1.13]] (vpn-10-50-16-97.qualcomm.com [10.50.16.97]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7B0xjAO001904; Thu, 10 Aug 2006 17:59:46 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <0FA975F2D8295A448BE3ADC161244657A9EF9B@esebe199.NOE.Nokia.com> References: <0FA975F2D8295A448BE3ADC161244657A9EF9B@esebe199.NOE.Nokia.com> X-Mailer: Eudora for Mac OS X (dev alpha) X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Thu, 10 Aug 2006 17:58:50 -0700 To: , From: Randall Gellens 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 Subject: [lemonade] Trash (was '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 At 10:50 AM +0300 8/7/06, wrote: > At home I collect to the garbage to a bag, and take it out every now and > then. What You saying here is that I should let the garbage laying on > the floor, put a PostIt on them that says "garbage", and I can collect > them any time I want. You are right - it achieves the exact same thing: > the garbage will be gone eventually, however the second model has > several drawbacks. The most disturbing ones are: > - it takes a lot of time to colllect the garbage from every room (you > need to look carefully) > - garbage all over the house is just gross. > I believe "trashing" was proposed to make the user's life easier: to > implement a more efficient email disposal mechnism that the users are > used to and feels more 'natural'. This is a poor analogy, because there are fundamental differences between the physical world and the virtual one of protocols. First, garbage can only exist in one place: it cannot appear to you as if it is neatly in the rubbish bin when it is actually all over your floor. You'd stumble on it, you'd smell it, you'd kick it around. You'd know it was there, even if it was somehow invisible. You also would open your rubbish bin and not see it. So it is very different. With IMAP, messages can be in one place as far as the server is concerned, yet appear to be somewhere else as far as the user is concerned. Dave's Trash draft does a nice job of describing this. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Kids Make Nutritious Snacks --Newspaper headline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Aug 10 21:20:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBLhZ-0000W6-NT; Thu, 10 Aug 2006 21:20:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBLhY-0000W1-9j for lemonade@ietf.org; Thu, 10 Aug 2006 21:20:40 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBLhW-0007h0-UY for lemonade@ietf.org; Thu, 10 Aug 2006 21:20:40 -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 k7B1Kbj3007092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 10 Aug 2006 18:20:38 -0700 Received: from [[192.168.1.13]] (vpn-10-50-16-97.qualcomm.com [10.50.16.97]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7B1KZOs007333 for ; Thu, 10 Aug 2006 18:20:36 -0700 (PDT) Mime-Version: 1.0 Message-Id: X-Mailer: Eudora for Mac OS X (dev alpha) X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Thu, 10 Aug 2006 18:19:27 -0700 To: lemonade@ietf.org From: Randall Gellens 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: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [lemonade] Special-Purpose Mailboxes (was 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 At 12:27 PM +0300 8/1/06, wrote: > I would like to express my support on "define an standardized list > of Annotations for this and other such "special" mailboxes". > Identifying the special folders does not mean that they are going > to be used in every implementation, while it gives the benefit of > knowing what/where are those "special" mailboxes as well as helps a > lot with localization issues. > > I think the following "special" mailboxes should be identified: > Trash: to store emails that have been deleted by the user - but not > marked as deleted yet e.g. expunge won't purge them. > Calendar: to store emails that contain vCalendar or other content > that includes calendar information. > Contacts: to store emails that contain vCard or other content that > includes contact information. > Drafts: to store emails that the user composed but did not send yet. > Junk: to store emails that the server decided to isolate. > Sent: to store emails that the use has sent. > > I understand Draft, Trash, Junk and Sent would be the most often > used ones, while Contacts and Calendar would be used less often. I agree that clients need a way to cooperate on which mailboxes are used for special purposes. The metadata (a/k/a annotatemore) draft is one potential way to do this, but it has a problem: while clients can use it to discover that a specific mailbox has been tagged with a special purpose, I'm not sure they can use it to go the other way: connect to a server and learn which mailbox to use for a specific special purpose. We could hack around this by putting an annotation on Inbox, but that has the potential for inconsistent states, which would be a problem. ACAP does provide a way to do just that: it can tell a client the name of the mailbox to use for each special purpose. Because of the many problems with Trash mailboxes (as documented in Dave's Trash draft), I can see benefit in having a recommended alternative, such as the logical Trash mailbox concept, improved through extensions if needed. Given the widespread use of Trash mailboxes, I can also see benefit in having a way to identify to clients which mailboxes are so used by other clients. However, I can also see three reasons not to do this: (1) it seems unlikely that existing clients will be updated to specify the Trash mailbox they are using, so having a way for them to do so won't help; (2) since existing clients use different names for the Trash mailbox, anyone using multiple clients probably has multiple Trash mailboxes; (3) it is unclear that mobile clients will want to synchronize a Trash mailbox created by other clients: why waste bandwidth and memory caching messages that the user has already marked for deletion? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Television is simply automated day-dreaming. --Lee Lovinger, _Quote_, July 30, 1967 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Aug 11 02:36:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBQdF-0003EF-Ub; Fri, 11 Aug 2006 02:36:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBQdE-0003EA-NG for lemonade@ietf.org; Fri, 11 Aug 2006 02:36:32 -0400 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBQdA-00041j-11 for lemonade@ietf.org; Fri, 11 Aug 2006 02:36:32 -0400 Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.12]) by smarthost.yourcomms.net (8.11.7p1+Sun/8.11.6) with ESMTP id k7B6OM709160 for ; Fri, 11 Aug 2006 07:24:22 +0100 (BST) 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] profile-bis and format=flowed (RFC 3676) Date: Fri, 11 Aug 2006 07:35:49 +0100 Message-ID: <22C8A0D5D5E095449AB509FE777B5F8002ABEBF6@svr-exchange.avocado.emccsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] profile-bis and format=flowed (RFC 3676) Thread-Index: Aca80OXXVTaCKNIpS7SVD3504sluAgAPsn/g From: "Ben Last" To: "Randall Gellens" , 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 Randall Gellens [mailto:randy@qualcomm.com] wrote, at 10 August 2006 23:58: >Perhaps profile-bis should recommend the use of format=3Dflowed (RFC 3676). After all, the ability to reflow text >(regular and quoted) to fit small screens was the primary motivation behind format=3Dflowed. I'm not clear: do you mean that outgoing email messages from a (small-screen) client should use format=3Dflowed? Or that the server re-format text/plain messages to be text/plain;format=3Dflowed (which surely covers more server behaviour than in the scope of profile-bis)? Regards Ben -- 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 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Aug 11 02:59:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBQzK-00059T-F7; Fri, 11 Aug 2006 02:59:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBQzK-00059O-1C for lemonade@ietf.org; Fri, 11 Aug 2006 02:59:22 -0400 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBQzF-0000yf-AN for lemonade@ietf.org; Fri, 11 Aug 2006 02:59:22 -0400 Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.12]) by smarthost.yourcomms.net (8.11.7p1+Sun/8.11.6) with ESMTP id k7B6lB709991 for ; Fri, 11 Aug 2006 07:47:11 +0100 (BST) 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] Special-Purpose Mailboxes (was Notifications for multiple devices per user) Date: Fri, 11 Aug 2006 07:58:39 +0100 Message-ID: <22C8A0D5D5E095449AB509FE777B5F8002ABEBFF@svr-exchange.avocado.emccsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Special-Purpose Mailboxes (was Notifications for multiple devices per user) Thread-Index: Aca85FPIdyMntHulSvO0WhI/difB9gALLSZA From: "Ben Last" To: "Randall Gellens" , X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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 Randall Gellens [mailto:randy@qualcomm.com] wrote, at 11 August 2006 02:19: >Given the widespread use of Trash mailboxes, I can also see benefit in having a way to identify >to clients which mailboxes are so used by other clients. However, I can also see three reasons >not to do this: (1) it seems unlikely that existing clients will be updated to specify the Trash >mailbox they are using, so having a way for them to do so won't help; (2) since existing clients >use different names for the Trash mailbox, anyone using multiple clients probably has multiple >Trash mailboxes; (3) it is unclear that mobile clients will want to synchronize a Trash mailbox >created by other clients: why waste bandwidth and memory caching messages that the user has >already marked for deletion? Certainly my motivation for discussing this general area was issue (3) above: we have no interest in implementing a Trash mailbox (deleted/expunge works for us) but we do definitely want to avoid showing other clients special-purpose mailboxes to the user, or synchronzing them. Randall: I respectfully disagree that your arguments above are arguments against providing ways for clients to identify mailboxes. Specific responses: (1) But even if they don't use a Trash, they may use Sent Items/Drafts/Outbox mailboxes. (2) But if clients that currently do use a Trash mailbox could spot an existing one and re-use it, that would avoid the proliferation of Trash/Deleted Items/Wastebasket mailboxes that can occur. (3) If a client can identify other clients' Trash mailbox, it can avoid synchronizing it. If it can't, there's the risk that it will be synchronized inadvertently. That would also confuse the end user: seeing a Trash mailbox that doesn't hold newly deleted messages. At least one of our use cases involves three clients in use for any one account: * A desktop client such as Eudora or Thunderbird * A webmail client provided by the server vendor * A mobile client This is actually not an unusual setup for users in our target market, so anything that helps inter-client interoperability is key for us. ACAP would help with the Special-purpose Mailboxes problem, but as far as I can tell, there are very few servers that implement it (and none of the target server vendors for our client have any plans to implement it). For a client developer, especially in the mobile phone market, the assumption must always be that one must interoperate with what is out there now. We have no control over the servers with which a customer would expect our client to interoperate. But given that the Lemonade profiles and standards have a fair degree of momentum now, raising problems such as special-purpose mailboxes here is about the best chance we have of making our lives easier in the future! Regards to all Ben EMCC Software Ltd _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Aug 11 03:34:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBRWz-00058y-Sd; Fri, 11 Aug 2006 03:34:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBRWy-00058t-97 for lemonade@ietf.org; Fri, 11 Aug 2006 03:34:08 -0400 Received: from pathbreaker.com ([64.71.130.73]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GBRWw-0005lu-Sd for lemonade@ietf.org; Fri, 11 Aug 2006 03:34:08 -0400 Received: (qmail 16595 invoked by uid 89); 11 Aug 2006 07:32:31 -0000 Received: from localhost (HELO ?192.168.1.100?) (ray%logicaldepth.com@127.0.0.1) by 0 with SMTP; 11 Aug 2006 07:32:31 -0000 Message-ID: <44DC32CE.9020907@pathbreaker.com> Date: Fri, 11 Aug 2006 00:33:34 -0700 From: Ray Cromwell User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: lemonade@ietf.org Subject: Re: [lemonade] Special-Purpose Mailboxes (was Notifications for multiple devices per user) References: 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: 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 Randall Gellens wrote: > I agree that clients need a way to cooperate on which mailboxes are > used for special purposes. The metadata (a/k/a annotatemore) draft is > one potential way to do this, but it has a problem: while clients can > use it to discover that a specific mailbox has been tagged with a > special purpose, I'm not sure they can use it to go the other way: > connect to a server and learn which mailbox to use for a specific > special purpose. We could hack around this by putting an annotation > on Inbox, but that has the potential for inconsistent states, which > would be a problem. > > ACAP does provide a way to do just that: it can tell a client the name > of the mailbox to use for each special purpose. > I think METADATA can accomplish this with Server Entries too, e.g. "/specialmailboxes" -> trash.shared = name of trash mailbox, sent.shared=name of sent mailbox, draft.shared=name of draft mailbox, etc. I think there may be cases where you don't neccessarily want to indicate a real mailbox to be used, but merely want to indicate a mnemonic that the client should use for customer support purposes (e.g. there is no real "Trash" mailbox on the server, but the clients support best practices of using flags to group deleted messages into a special Trash virtual "mailbox" on the client. Cingular may want all clients to call this "Trash" in the US, but Orange may want all clients to call it "Rubbish", and Bell-Microsoft might want it called "Recycle Bin" :) ) All of this modulo i18n/l10n concerns. Granted, it's not a compelling usecase, just stream of consciousness. -Ray _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Aug 11 04:08:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBS4c-0005Hc-0X; Fri, 11 Aug 2006 04:08:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBS4a-0005HW-OF for lemonade@ietf.org; Fri, 11 Aug 2006 04:08:52 -0400 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBS4X-00086c-Ae for lemonade@ietf.org; Fri, 11 Aug 2006 04:08:52 -0400 Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.12]) by smarthost.yourcomms.net (8.11.7p1+Sun/8.11.6) with ESMTP id k7B7uh713625 for ; Fri, 11 Aug 2006 08:56:43 +0100 (BST) 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] Special-Purpose Mailboxes (was Notifications formultiple devices per user) Date: Fri, 11 Aug 2006 09:08:10 +0100 Message-ID: <22C8A0D5D5E095449AB509FE777B5F8002ABEC38@svr-exchange.avocado.emccsoft.com> In-Reply-To: <44DC32CE.9020907@pathbreaker.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Special-Purpose Mailboxes (was Notifications formultiple devices per user) Thread-Index: Aca9GIF3SFONdWr7Q6OybceShA+yqAABIrow From: "Ben Last" To: "Ray Cromwell" 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 Ray Cromwell [mailto:ray@pathbreaker.com] wrote, at 11 August 2006 08:34: >Cingular may want all clients to call this "Trash" in the US, but Orange may want >all clients to call it "Rubbish", and Bell-Microsoft might want it called "Recycle Bin" :) Actually, that'd be "Wastebasket" or "Deleted Items" in the UK :) "Rubbish" would be like Americans calling it "Garbage"... perhaps that'd be for spam messages. Regards ben EMCC Software Ltd _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Aug 11 05:09:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBT1c-00008U-NW; Fri, 11 Aug 2006 05:09:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBT1b-00008P-Iy for lemonade@ietf.org; Fri, 11 Aug 2006 05:09:51 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBT1a-0002BO-4b for lemonade@ietf.org; Fri, 11 Aug 2006 05:09:51 -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 k7B99kCZ008724; Fri, 11 Aug 2006 12:09:48 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Aug 2006 12:08:39 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Aug 2006 12:08:39 +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] 'MOVE' (was Notifications for multiple devices per user) Date: Fri, 11 Aug 2006 12:08:04 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657B90F4F@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] 'MOVE' (was Notifications for multiple devices per user) Thread-Index: Aca84NPiNyJUiox8RbWODS6I3k0ZzQAQInsQ From: To: , X-OriginalArrivalTime: 11 Aug 2006 09:08:39.0711 (UTC) FILETIME=[BC4B02F0:01C6BD25] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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, Some answers below. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 >We can work on the underlying problem without necessarily=20 >agreeing on this specific proposal. >I'm not sure it is fair to slip in comments such as=20 >"objections for some reason" (which imply that there were no=20 >good reasons for the >objection) and then say "but I do not wish to reopen the discussion".=20 >By slipping in the comments on the proposal you have reopened=20 >the discussion. I think it would be more productive to focus=20 >on the specific problems rather than keep re-proposing a=20 >specific approach which would not solve them. I would like to address this problem, but so far it seems that other = parties are happy with the solution available today, and see no benefit = of addressing it - this is the reason why I gave up. If everyone agrees = that this is the way to go, what can I do? Solve it in OMA where the = operator awareness is much stronger? I would like to do it here in = LEMONADE since this is the "natural home" of such extensions. I am more concerned about bandwidth usage and the number of roundtrips - = these are major concerns on mobile networks because: - the roundtrips and latencies are typically longer and - the amount of data transmitted should be minimal, hence my persistence regarding this issue. This is why I am saying that a simple MOVE command would solve it: Client says: MOVE mailbox/UID to this mailbox Servers says: OK done, here is the new UID. or: Client says: MOVE mailbox to this mailbox Server says: OK All done with one roundtrip. I do not think that there is a more = efficient way to do this. Then, there is this version - which might be imporant when the user = wants to move all messages: Client says: MOVE mailbox/* to this mailbox Servers says: OK done, here are the new UIDs. however, I am not sure how to solve this because there are several UIDs = involved (some kind of mapping of old UIDs to new UIDs is necessary = otherwise the client will re-download everything). I am not sure what You mean by working on the underlying problem - if it = makes it as efficient as this, I am more than wiling to drop my proposal = and take Yours right away. Could You elaborate please? Thank You. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Aug 11 05:24:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBTG1-0003ao-1B; Fri, 11 Aug 2006 05:24:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBTFy-0003S0-NY for lemonade@ietf.org; Fri, 11 Aug 2006 05:24:42 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBTFx-000312-8U for lemonade@ietf.org; Fri, 11 Aug 2006 05:24:42 -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 k7B9Oawn015527; Fri, 11 Aug 2006 12:24:37 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Aug 2006 12:24:29 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Aug 2006 12:24: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] Trash (was 'Notifications for multiple devices per user') Date: Fri, 11 Aug 2006 12:23:43 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657B90F70@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Trash (was 'Notifications for multiple devices per user') Thread-Index: Aca84dZ4jlrZ9EYdSZWMxK5kayiI0gARDUuA From: To: , X-OriginalArrivalTime: 11 Aug 2006 09:24:25.0712 (UTC) FILETIME=[F0274F00:01C6BD27] X-Spam-Score: 0.2 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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, Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 =20 >-----Original Message----- >From: ext Randall Gellens [mailto:randy@qualcomm.com]=20 >Sent: 11 August, 2006 03:59 >To: Ordogh Zoltan (Nokia-TP-MSW/Tampere); mrc@CAC.Washington.EDU >Cc: lemonade@ietf.org >Subject: Trash (was 'Notifications for multiple devices per user') > >At 10:50 AM +0300 8/7/06, wrote: > >> At home I collect to the garbage to a bag, and take it out=20 >every now=20 >> and then. What You saying here is that I should let the garbage=20 >> laying on the floor, put a PostIt on them that says=20 >"garbage", and I=20 >> can collect them any time I want. You are right - it=20 >achieves the exact same thing: >> the garbage will be gone eventually, however the second model has =20 >> several drawbacks. The most disturbing ones are: >> - it takes a lot of time to colllect the garbage from every room=20 >> (you need to look carefully) >> - garbage all over the house is just gross. >> I believe "trashing" was proposed to make the user's life=20 >easier: to =20 >> implement a more efficient email disposal mechnism that the=20 >users are =20 >> used to and feels more 'natural'. > >This is a poor analogy, because there are fundamental=20 >differences between the physical world and the virtual one of=20 >protocols. First, garbage can only exist in one place: it=20 >cannot appear to you as if it is neatly in the rubbish bin=20 >when it is actually all over your floor.=20 >You'd stumble on it, you'd smell it, you'd kick it around. =20 >You'd know it was there, even if it was somehow invisible. =20 >You also would open your rubbish bin and not see it. So it is=20 >very different. > >With IMAP, messages can be in one place as far as the server=20 >is concerned, yet appear to be somewhere else as far as the=20 >user is concerned. Dave's Trash draft does a nice job of=20 >describing this. It might be a poor analogy, but I think it's valid. I would not want to = smell and kick around the invisible garbage. Also, if garbage were = invisible, I would want it in my garbage bin. What if the user connected using a client that does not support Dave's = draft? All that invisible garbage becomes visible again and then the = user is confused. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Aug 11 06:30:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBUHy-0001mp-0I; Fri, 11 Aug 2006 06:30:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBUHw-0001mf-OX for lemonade@ietf.org; Fri, 11 Aug 2006 06:30:48 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBUHw-000631-4s for lemonade@ietf.org; Fri, 11 Aug 2006 06:30:48 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k7B9UdNe024417; Fri, 11 Aug 2006 12:30:44 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Aug 2006 13:30:43 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Aug 2006 13:30:42 +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] Standards Process (was 'Notifications for multiple devices per user') Date: Fri, 11 Aug 2006 13:30:09 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657B91000@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Standards Process (was 'Notifications for multiple devices per user') Thread-Index: Aca84PbOts6xo2cGS4CKvNia+ElDWAAR1k3A From: To: , X-OriginalArrivalTime: 11 Aug 2006 10:30:42.0647 (UTC) FILETIME=[32976E70:01C6BD31] X-Spam-Score: 0.2 (/) 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 Hi Randall, If we were living in a perfect world, I would agree with what You just = said here a 100%. But we live in a world where money talks. And it is the users who has = the money - including You and me(*). Client/server vendors, operators = all make a living from their money. If I can make a client/server/service that the users like more, users = will choose my product/service. There is no need to explain what this = means, right? Users do not care what is beneath the surface as long as they get what = they want: - they do not care how difficult it was to create something; - they do not care about poor interoperability (they will just stop = using the "old" products and buy the newest gadgets from the = provider/manufacturer who gives them what they want and it works with = their friend's gadgets); - and they do not care that their favourite product is based on a bad = idea. It is their money, they decide what they pay for. What is a standard worth that does not give us what we need? What if it = has potential? It will be ripped apart a thousand times and/or added a = lot of new things that make it more usable. Who rips it apart and/or = adds new thing is irrelevant. If a scientist (even if all scientists all = over the world) thinks it is a bad idea, it is irrelevant. The market = dictates and standards need to follow. If standards do not follow, = existing ones will be improved (first proprietary, then it becomes = de-facto) or new standards will be created. (*) Strictly personal opinion follows until the end of my message, feel free = to ignore this. I am paying for and using a couple of services myself, and I am very = disappointed sometimes. When I complain to the provider, they tell me = that there is no standard way to do it, so they cannot do it. What do I = do? Go to another provider. The other provider sells the exact same = thing, so I start looking up smaller providers who care about every = penny they can get. Tada, they have it. So, I go there and live my life = happily. I understand that picky like me are a minority, but there are good deal = of people who re-evaluate every now and then the value they get for = their money. Also, another factor is that large providers tend to care = less about their customers. So try scaling this up to see what happens = in the long run. When people start leaving the bigger providers in = favour of smaller providers (less costs, more favourable services), the = bigger providers wake up saying: "where did our income go"? They realize = that they decided to not to do something because it is not a standard. = "Oops. We are late. Let's make sure the things are standardized the next = time, so we can remain competitive." What happens is they try to = standardize a solution, but the standardization geeks turn them down = based on some scientific reasoning (which is valid but does not = recognize that users do not care much about scientific reasons), so in = the end they have two choices left: one is that they implement some = proprietary solution (or simply but it from someone who already has it), = or they create another standard (adding anything they need) based on the = geeks' standard in another standardization body (where they have more = influence) according to their needs without involving those scientific = geeks. Does this latter one sound familiar? I see it happening every = day. I am not saying scientific geeks are bad - they reason only based on = facts. I am not saying any providers are bad - they reason based on = revenues. It's just that things have changed. It's just that the way our = little planet is currently. Nowadays everyone is reasoning based on = money (or the value they get for their money). The scientific geeks = should step out from the universities and research laboratories for a = while to see how is the world nowadays. Of course it would not change = any scientific facts, but at least it might make them realize that = science is not being used in real life as they intended it to be used. = Remember Hiroshima? No scientist ever intended to use the power of the = atom like that. But it just happened anyway because there was demand for = it. Science gives us the tools, but in the end demand dictates how we = use them. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 =20 >-----Original Message----- >From: ext Randall Gellens [mailto:randy@qualcomm.com]=20 >Sent: 11 August, 2006 03:54 >To: Ordogh Zoltan (Nokia-TP-MSW/Tampere); mrc@CAC.Washington.EDU >Cc: lemonade@ietf.org >Subject: [lemonade] Standards Process (was 'Notifications for=20 >multiple devices per user') > >At 12:06 PM +0300 8/4/06, wrote: > >> [Z=D6r] I disagree. This is the basis for standardization -=20 >people come=20 >> up with ideas, and present them. Some people do not like it, fine.=20 >> Later on someone else comes with the same idea, so these two agree=20 >> that "hey: if they don't want to standardize it, fine: we will=20 >> implement it anyway". So these guys implement it, and make a better=20 >> service than anyone else and then You wish You have made it a=20 >> standard. >> I believe everything should be standardized - so if someone=20 >decides to=20 >> implement it then the solution will be available for the=20 >taking and it=20 >> will be interoperable with others. > >That behavior is problematic for standardized protocols. Just=20 >because two people agree to implement a bad idea does not make=20 >it a good idea. It leads to poor interoperability as some=20 >people do it one way and others do it another.=20 >The two people who went off in a huff and implemented what=20 >they want after their specific proposal was not accepted are=20 >guilty of the same attitude they accuse the other participants=20 >of engaging in: ignoring what others are saying. > >If someone comes in with a problem he or she wants to solve,=20 >the group should indeed listen and see if it can be solved and=20 >if so what is the best way. The group shouldn't dismiss the=20 >person out of hand. But if the person proposes a very=20 >specific approach to the problem and the group points out=20 >fundamental difficulties with that approach, the person should=20 >likewise listen to the objections and work together to find=20 >better solutions. >-- >Randall Gellens >Opinions are personal; facts are suspect; I speak for myself only >-------------- Randomly-selected tag: --------------- It is=20 >the business of the future to be dangerous. > >_______________________________________________ >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 Aug 11 06:43:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBUUL-0002VM-8h; Fri, 11 Aug 2006 06:43:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBUUJ-0002TR-HZ for lemonade@ietf.org; Fri, 11 Aug 2006 06:43:35 -0400 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBUUI-0006fe-2q for lemonade@ietf.org; Fri, 11 Aug 2006 06:43:35 -0400 Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.12]) by smarthost.yourcomms.net (8.11.7p1+Sun/8.11.6) with ESMTP id k7BAVR700651 for ; Fri, 11 Aug 2006 11:31:27 +0100 (BST) 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] 'MOVE' (was Notifications for multiple devices peruser) Date: Fri, 11 Aug 2006 11:42:53 +0100 Message-ID: <22C8A0D5D5E095449AB509FE777B5F8002ABED41@svr-exchange.avocado.emccsoft.com> In-Reply-To: <0FA975F2D8295A448BE3ADC161244657B90F4F@esebe199.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] 'MOVE' (was Notifications for multiple devices peruser) Thread-Index: Aca84NPiNyJUiox8RbWODS6I3k0ZzQAQInsQAAQgRzA= From: "Ben Last" To: 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 Zoltan.Ordogh@nokia.com [mailto:Zoltan.Ordogh@nokia.com] wrote at 11 August 2006 10:08: >This is why I am saying that a simple MOVE command would solve it: >Client says: MOVE mailbox/UID to this mailbox Servers says: OK done, here is the new UID. >or: >Client says: MOVE mailbox to this mailbox Server says: OK All done with one roundtrip. I >do not think that there is a more efficient way to do this. That solves the problem for the client doing the move, but doesn't address the needs of other clients who need to be informed of the move (in a more efficient manner than EXPUNGE / EXISTS)/. >...however, I am not sure how to solve this because there are several UIDs involved (some >kind of mapping of old UIDs to new UIDs is necessary otherwise the client will re-download >everything). But UIDs are very server-dependent: some servers use what looks like a timestamp, others use incrementing numbers... I'm not sure that such a mapping could ever be defined. Regards Ben _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Aug 11 07:56:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBVd7-0005ag-KK; Fri, 11 Aug 2006 07:56:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBVcO-00056w-EN for lemonade@ietf.org; Fri, 11 Aug 2006 07:56:00 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBVCc-0002lA-Hd for lemonade@ietf.org; Fri, 11 Aug 2006 07:29:23 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1GBVCZ-0003sb-Na; Fri, 11 Aug 2006 11:29:20 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id AC332498003; Fri, 11 Aug 2006 12:35: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 18859-09; Fri, 11 Aug 2006 12:35: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 0A9B5498002; Fri, 11 Aug 2006 12:35:42 +0100 (BST) Date: Fri, 11 Aug 2006 12:29:14 +0100 Subject: RE: [lemonade] Trash (was 'Notifications for multiple devices per user') References: <0FA975F2D8295A448BE3ADC161244657B90F70@esebe199.NOE.Nokia.com> In-Reply-To: <0FA975F2D8295A448BE3ADC161244657B90F70@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Message-Id: <13887.1155295755.274210@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: 52e1467c2184c31006318542db5614d5 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 Aug 11 10:23:43 2006, Zoltan.Ordogh@nokia.com wrote: > It might be a poor analogy, but I think it's valid. I would not > want to smell and kick around the invisible garbage. Also, if > garbage were invisible, I would want it in my garbage bin. Messages marked with the \Deleted flag do not decompose. If they do, then your server has some really interesting properties. :-) If you really want your analogy taken to task, I'll be happy to do it, but suffice to say that your analogy describes neither tha trash mailbox situation nor the existing standards-based message deletion handling very well. > What if the user connected using a client that does not support > Dave's draft? All that invisible garbage becomes visible again and > then the user is confused. The IMAP4rev1 base specification, like many, if not all IMAP specifications for over a decade before, define a methods for clients to delete messages, and search for undeleted (or deleted) ones. The Trash draft simply describes methods for making the above look like a trash mailbox, or something similar. Clients which simply follow the IMAP4rev1 base specification will interoperate with this method. So clients which don't know anything about the draft should be fine, and if not, then they aren't following IMAP4rev1. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarksFrom lemonade-bounces@ietf.org Fri Aug 11 07:56:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBVd7-0005ag-KK; Fri, 11 Aug 2006 07:56:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBVcO-00056w-EN for lemonade@ietf.org; Fri, 11 Aug 2006 07:56:00 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBVCc-0002lA-Hd for lemonade@ietf.org; Fri, 11 Aug 2006 07:29:23 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1GBVCZ-0003sb-Na; Fri, 11 Aug 2006 11:29:20 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id AC332498003; Fri, 11 Aug 2006 12:35: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 18859-09; Fri, 11 Aug 2006 12:35: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 0A9B5498002; Fri, 11 Aug 2006 12:35:42 +0100 (BST) Date: Fri, 11 Aug 2006 12:29:14 +0100 Subject: RE: [lemonade] Trash (was 'Notifications for multiple devices per user') References: <0FA975F2D8295A448BE3ADC161244657B90F70@esebe199.NOE.Nokia.com> In-Reply-To: <0FA975F2D8295A448BE3ADC161244657B90F70@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Message-Id: <13887.1155295755.274210@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: 52e1467c2184c31006318542db5614d5 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 Aug 11 10:23:43 2006, Zoltan.Ordogh@nokia.com wrote: > It might be a poor analogy, but I think it's valid. I would not > want to smell and kick around the invisible garbage. Also, if > garbage were invisible, I would want it in my garbage bin. Messages marked with the \Deleted flag do not decompose. If they do, then your server has some really interesting properties. :-) If you really want your analogy taken to task, I'll be happy to do it, but suffice to say that your analogy describes neither tha trash mailbox situation nor the existing standards-based message deletion handling very well. > What if the user connected using a client that does not support > Dave's draft? All that invisible garbage becomes visible again and > then the user is confused. The IMAP4rev1 base specification, like many, if not all IMAP specifications for over a decade before, define a methods for clients to delete messages, and search for undeleted (or deleted) ones. The Trash draft simply describes methods for making the above look like a trash mailbox, or something similar. Clients which simply follow the IMAP4rev1 base specification will interoperate with this method. So clients which don't know anything about the draft should be fine, and if not, then they aren't following IMAP4rev1. 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 Aug 11 07:56:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBVd7-0005bb-S7; Fri, 11 Aug 2006 07:56:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBVcO-00056w-Db for lemonade@ietf.org; Fri, 11 Aug 2006 07:56:00 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBVCd-0002lH-Ti for lemonade@ietf.org; Fri, 11 Aug 2006 07:29:25 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1GBVCd-0003vU-5W; Fri, 11 Aug 2006 11:29:23 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id B6514498003; Fri, 11 Aug 2006 12:35:49 +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 19017-04; Fri, 11 Aug 2006 12:35: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 C8CA5498002; Fri, 11 Aug 2006 12:35:45 +0100 (BST) Date: Fri, 11 Aug 2006 12:29:18 +0100 Subject: RE: [lemonade] 'MOVE' (was Notifications for multiple devices per user) References: <0FA975F2D8295A448BE3ADC161244657B90F4F@esebe199.NOE.Nokia.com> In-Reply-To: <0FA975F2D8295A448BE3ADC161244657B90F4F@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Message-Id: <13887.1155295759.055564@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: 4d87d2aa806f79fed918a62e834505ca 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 Aug 11 10:08:04 2006, Zoltan.Ordogh@nokia.com wrote: > I would like to address this problem, but so far it seems that > other parties are happy with the solution available today, and see > no benefit of addressing it - this is the reason why I gave up. If > everyone agrees that this is the way to go, what can I do? Solve it > in OMA where the operator awareness is much stronger? I would like > to do it here in LEMONADE since this is the "natural home" of such > extensions. > > There's no need to solve it. > This is why I am saying that a simple MOVE command would solve it: > Client says: MOVE mailbox/UID to this mailbox > Servers says: OK done, here is the new UID. > or: > Client says: MOVE mailbox to this mailbox > Server says: OK > All done with one roundtrip. I do not think that there is a more > efficient way to do this. > > There is an equally efficient method in the normal case: A01 UID COPY x A02 UID STORE x +FLAGS.SILENT (\Deleted) The client has to check the response to A01, and undo the UID STORE if it fails, but that's a rare case - it does involve a round-trip, but the client need not wait for it. > Then, there is this version - which might be imporant when the user > / - 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 Aug 11 07:56:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBVd7-0005bb-S7; Fri, 11 Aug 2006 07:56:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBVcO-00056w-Db for lemonade@ietf.org; Fri, 11 Aug 2006 07:56:00 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBVCd-0002lH-Ti for lemonade@ietf.org; Fri, 11 Aug 2006 07:29:25 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1GBVCd-0003vU-5W; Fri, 11 Aug 2006 11:29:23 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id B6514498003; Fri, 11 Aug 2006 12:35:49 +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 19017-04; Fri, 11 Aug 2006 12:35: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 C8CA5498002; Fri, 11 Aug 2006 12:35:45 +0100 (BST) Date: Fri, 11 Aug 2006 12:29:18 +0100 Subject: RE: [lemonade] 'MOVE' (was Notifications for multiple devices per user) References: <0FA975F2D8295A448BE3ADC161244657B90F4F@esebe199.NOE.Nokia.com> In-Reply-To: <0FA975F2D8295A448BE3ADC161244657B90F4F@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Message-Id: <13887.1155295759.055564@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: 4d87d2aa806f79fed918a62e834505ca 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 Aug 11 10:08:04 2006, Zoltan.Ordogh@nokia.com wrote: > I would like to address this problem, but so far it seems that > other parties are happy with the solution available today, and see > no benefit of addressing it - this is the reason why I gave up. If > everyone agrees that this is the way to go, what can I do? Solve it > in OMA where the operator awareness is much stronger? I would like > to do it here in LEMONADE since this is the "natural home" of such > extensions. > > There's no need to solve it. > This is why I am saying that a simple MOVE command would solve it: > Client says: MOVE mailbox/UID to this mailbox > Servers says: OK done, here is the new UID. > or: > Client says: MOVE mailbox to this mailbox > Server says: OK > All done with one roundtrip. I do not think that there is a more > efficient way to do this. > > There is an equally efficient method in the normal case: A01 UID COPY x A02 UID STORE x +FLAGS.SILENT (\Deleted) The client has to check the response to A01, and undo the UID STORE if it fails, but that's a rare case - it does involve a round-trip, but the client need not wait for it. > Then, there is this version - which might be imporant when the user > wants to move all messages: > Client says: MOVE mailbox/* to this mailbox > Servers says: OK done, here are the new UIDs. > however, I am not sure how to solve this because there are several > UIDs involved (some kind of mapping of old UIDs to new UIDs is > necessary otherwise the client will re-download everything). > > UIDPLUS does this for COPY already. So it would do it for MOVE, if MOVE were needed. I don't think that MOVE stands up to a balloon debate - it's not that it's a bad idea per se, it's more that it's not a sufficiently compelling idea that it would be worth having. 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 wants to move all messages: > Client says: MOVE mailbox/* to this mailbox > Servers says: OK done, here are the new UIDs. > however, I am not sure how to solve this because there are several > UIDs involved (some kind of mapping of old UIDs to new UIDs is > necessary otherwise the client will re-download everything). > > UIDPLUS does this for COPY already. So it would do it for MOVE, if MOVE were needed. I don't think that MOVE stands up to a balloon debate - it's not that it's a bad idea per se, it's more that it's not a sufficiently compelling idea that it would be worth having. 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 Aug 11 08:18:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBVy2-0005GW-DZ; Fri, 11 Aug 2006 08:18:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBVy1-0005GR-8y for lemonade@ietf.org; Fri, 11 Aug 2006 08:18:21 -0400 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBVxz-0000Er-Tr for lemonade@ietf.org; Fri, 11 Aug 2006 08:18:21 -0400 Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.12]) by smarthost.yourcomms.net (8.11.7p1+Sun/8.11.6) with ESMTP id k7BC6B709430 for ; Fri, 11 Aug 2006 13:06:14 +0100 (BST) 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] 'MOVE' (was Notifications for multiple devices peruser) Date: Fri, 11 Aug 2006 13:17:48 +0100 Message-ID: <22C8A0D5D5E095449AB509FE777B5F8002ABEDD6@svr-exchange.avocado.emccsoft.com> In-Reply-To: <0FA975F2D8295A448BE3ADC161244657B91057@esebe199.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] 'MOVE' (was Notifications for multiple devices peruser) Thread-Index: Aca84NPiNyJUiox8RbWODS6I3k0ZzQAQInsQAAQgRzAAAGcocAADCtZg From: "Ben Last" To: 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 [mailto:Zoltan.Ordogh@nokia.com] wrote at 11 August 2006 12:03: >Cpaable client could be notified about this with untagged responses (mailbox1/UID moved to mailbox2/UID, >mailbox1 moved to mailbox2, mailbox1/* moved to mailbox2/here is the UID mapping). Ok, that implies that your proposal needs to suggest formats for those untagged responses :) But as Dave Cridland pointed out, there's already an effective MOVE command using UID COPY/STORE. Maybe all that you need propose are untagged response formats, as part of new Lemonade profiles, to notify clients of UID COPY activities. Regards Ben EMCC Software Ltd _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Aug 11 08:46:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBWP2-0001gN-OE; Fri, 11 Aug 2006 08:46:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBWP1-0001gI-RW for lemonade@ietf.org; Fri, 11 Aug 2006 08:46:15 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBWP0-00025L-BM for lemonade@ietf.org; Fri, 11 Aug 2006 08:46:15 -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 k7BBkCvU030387; Fri, 11 Aug 2006 14:46:13 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Aug 2006 15:46:12 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Aug 2006 15:46:12 +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] 'MOVE' (was Notifications for multiple devices per user) Date: Fri, 11 Aug 2006 15:45:38 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657B9112C@esebe199.NOE.Nokia.com> In-Reply-To: <13887.1155295759.055564@peirce.dave.cridland.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] 'MOVE' (was Notifications for multiple devices per user) Thread-Index: Aca9OX+R/I4Ufu/fS2WH4Vyb6aupkAAB7i2Q From: To: X-OriginalArrivalTime: 11 Aug 2006 12:46:12.0175 (UTC) FILETIME=[202AF5F0:01C6BD44] X-Spam-Score: 0.2 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db 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 understand what You mean and how to do this for a single email. My = concern here is not moving a single email(*) - there are other use = cases. Most users organize emails to different mailboxes - we can all agree to = this, right? I do not worry here about weekend warriors who use email for fun - they = probably move emails one by one as the read them and they can live with = the current solution (although in the long run those extra commands = accumulate to a larger mobile phone bill). I worry here about those heavy-weight pros who use email as a tool in = their work every day (and do not know how to set up filters to do this = automatically). They move several emails (maybe all) at once. They even = whole mailboxes into another one. And this is where such MOVE command = would come really handy. One can argue that it is not an everyday task = and most likely will not be used from a mobile terminal, however I = believe that we are yet to see more advanced mobile terminals (bigger = screen, better UI) when the whole mobile email standards are ready and = the 'real' competition begins. (*) I see benefit of adding those two commands into a single command just = for the sake of moving single email also: this allows the client not to = worry too much about things - the server does all actions and finally = tells the client that it's done (or: not done). Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 =20 >-----Original Message----- >From: ext Dave Cridland [mailto:dave@cridland.net]=20 >Sent: 11 August, 2006 14:29 >To: Ordogh Zoltan (Nokia-TP-MSW/Tampere) >Cc: Enhancements to Internet email to support diverse service=20 >enivronments >Subject: RE: [lemonade] 'MOVE' (was Notifications for multiple=20 >devices per user) > >On Fri Aug 11 10:08:04 2006, Zoltan.Ordogh@nokia.com wrote: >> I would like to address this problem, but so far it seems that other=20 >> parties are happy with the solution available today, and see no=20 >> benefit of addressing it - this is the reason why I gave up. If=20 >> everyone agrees that this is the way to go, what can I do?=20 >Solve it in=20 >> OMA where the operator awareness is much stronger? I would=20 >like to do=20 >> it here in LEMONADE since this is the "natural home" of such=20 >> extensions. >>=20 >>=20 >There's no need to solve it. > >> This is why I am saying that a simple MOVE command would solve it: >> Client says: MOVE mailbox/UID to this mailbox Servers says: OK done,=20 >> here is the new UID. >> or: >> Client says: MOVE mailbox to this mailbox Server says: OK All done=20 >> with one roundtrip. I do not think that there is a more=20 >efficient way=20 >> to do this. >>=20 >>=20 >There is an equally efficient method in the normal case: > >A01 UID COPY x >A02 UID STORE x +FLAGS.SILENT (\Deleted) > >The client has to check the response to A01, and undo the UID=20 >STORE if it fails, but that's a rare case - it does involve a=20 >round-trip, but the client need not wait for it. > > >> Then, there is this version - which might be imporant when the user=20 >> wants to move all messages: >> Client says: MOVE mailbox/* to this mailbox Servers says: OK done,=20 >> here are the new UIDs. >> however, I am not sure how to solve this because there are several=20 >> UIDs involved (some kind of mapping of old UIDs to new UIDs is=20 >> necessary otherwise the client will re-download everything). >>=20 >>=20 >UIDPLUS does this for COPY already. So it would do it for=20 >MOVE, if MOVE were needed. I don't think that MOVE stands up=20 >to a balloon debate - it's not that it's a bad idea per se,=20 >it's more that it's not a sufficiently compelling idea that it=20 >would be worth having. > >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 Aug 11 10:21:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBXtN-0005qM-Il; Fri, 11 Aug 2006 10:21:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBXtN-0005qF-4d for lemonade@ietf.org; Fri, 11 Aug 2006 10:21: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 1GBV6B-0001gy-Fx for lemonade@ietf.org; Fri, 11 Aug 2006 07:22:43 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GBUoP-0004ax-4P for lemonade@ietf.org; Fri, 11 Aug 2006 07:04:21 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k7BA48gT010578; Fri, 11 Aug 2006 13:04:12 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Aug 2006 14:03:07 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Aug 2006 14:03:07 +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] 'MOVE' (was Notifications for multiple devices peruser) Date: Fri, 11 Aug 2006 14:02:34 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657B91057@esebe199.NOE.Nokia.com> In-Reply-To: <22C8A0D5D5E095449AB509FE777B5F8002ABED41@svr-exchange.avocado.emccsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] 'MOVE' (was Notifications for multiple devices peruser) Thread-Index: Aca84NPiNyJUiox8RbWODS6I3k0ZzQAQInsQAAQgRzAAAGcocA== From: To: X-OriginalArrivalTime: 11 Aug 2006 11:03:07.0403 (UTC) FILETIME=[B9C1A5B0:01C6BD35] X-Spam-Score: -2.4 (--) 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 >>This is why I am saying that a simple MOVE command would solve it: >>Client says: MOVE mailbox/UID to this mailbox Servers says: OK done, >here is the new UID. >>or: >>Client says: MOVE mailbox to this mailbox Server says: OK All=20 >done with >one roundtrip. I >>do not think that there is a more efficient way to do this. > >That solves the problem for the client doing the move, but=20 >doesn't address the needs of other clients who need to be=20 >informed of the move (in a more efficient manner than EXPUNGE=20 >/ EXISTS)/. Well, I supposed that the capability for the MOVE command would be announced the same way as any other extensions. Cpaable client could be notified about this with untagged responses (mailbox1/UID moved to mailbox2/UID, mailbox1 moved to mailbox2, mailbox1/* moved to mailbox2/here is the UID mapping). The only problem I can see here is with incapable clients: backwards compatility with older clients that would not support such untagged responses - I would rather find a workaround for these clients than having new clients do the workarounds (because the old ones are mostly fixed-network-based, while the new ones will be using mobile networks as well). But, I would not want to go into such details before I get a response from Randall - He mentioned "working on the underlying problem", I would like to know what Randall has in mind - it might be actually better than the current thinking. >>...however, I am not sure how to solve this because there are several >UIDs involved (some >>kind of mapping of old UIDs to new UIDs is necessary otherwise the >client will re-download >>everything). > >But UIDs are very server-dependent: some servers use what=20 >looks like a timestamp, others use incrementing numbers... I'm=20 >not sure that such a mapping could ever be defined. I do not think that we need to worry about this at all. It is the server that assigns the UID whatever it is, and the client would get a new one for every message after the move. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Aug 11 10:55:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBYPv-00062c-4v; Fri, 11 Aug 2006 10:55:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBYPt-00062X-W8 for lemonade@ietf.org; Fri, 11 Aug 2006 10:55:17 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBYPs-00028J-IO for lemonade@ietf.org; Fri, 11 Aug 2006 10:55:17 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1GBYPr-0004UM-Fk; Fri, 11 Aug 2006 14:55:15 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 2A34B498003; Fri, 11 Aug 2006 16:01: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 19855-03; Fri, 11 Aug 2006 16:01:32 +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 3662F498002; Fri, 11 Aug 2006 16:01:32 +0100 (BST) Date: Fri, 11 Aug 2006 15:55:02 +0100 Subject: RE: [lemonade] 'MOVE' (was Notifications for multiple devices per user) References: <0FA975F2D8295A448BE3ADC161244657B9112C@esebe199.NOE.Nokia.com> In-Reply-To: <0FA975F2D8295A448BE3ADC161244657B9112C@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Message-Id: <13887.1155308103.971162@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: 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 Fri Aug 11 13:45:38 2006, Zoltan.Ordogh@nokia.com wrote: > I understand what You mean and how to do this for a single email. > My concern here is not moving a single email(*) - there are other > use cases. x in my example can be either a single uid, or a uid set. So potentially that can move the entire contents of the mailbox. I think that renders the rest of your argument a little unsustainable. > I see benefit of adding those two commands into a single command > just for the sake of moving single email also: this allows the > client not to worry too much about things - the server does all > actions and finally tells the client that it's done (or: not done). This, of course, is actually the primary objection to MOVE. You're expecting that an IMAP server will be able to perform write activity on two mailboxes atomically, which is not required by any other part of the standard. At a simple glance at MOVE, it looks remarkably simple, but what you're saying is that servers have to potentially rewind the internal COPY if the internal STORE fails, all very carefully not allowing this to be observed by any session active on the target mailbox. It's really not quite as simple as you think. Basically, it's saving about 30 octets on the wire - probably much less after compression etc - for a comparitively rare operation that's difficult or impossible to implement atomically on most servers. It is also useful for weak client developers to avoid them having to handle proper pipeline processing, I suppose, but it's basically going to end up being an expensive and slow client to run anyway if the developers can't handle pipelines. 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 Aug 11 11:22:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBYqf-0003rD-Ev; Fri, 11 Aug 2006 11:22:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBYqe-0003lN-6R for lemonade@ietf.org; Fri, 11 Aug 2006 11:22:56 -0400 Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBYqb-0006Av-R8 for lemonade@ietf.org; Fri, 11 Aug 2006 11:22:56 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7BFMqHw021795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Aug 2006 08:22:52 -0700 X-Auth-Received: from Shimo-Tomobiki.panda.com (70-56-73-230.tukw.qwest.net [70.56.73.230]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7BFMoHq009105 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 11 Aug 2006 08:22:51 -0700 Date: Fri, 11 Aug 2006 08:22:43 -0700 From: Mark Crispin To: Zoltan.Ordogh@nokia.com Subject: RE: [lemonade] Standards Process (was 'Notifications for multiple devices per user') In-Reply-To: <0FA975F2D8295A448BE3ADC161244657B91000@esebe199.NOE.Nokia.com> Message-ID: References: <0FA975F2D8295A448BE3ADC161244657B91000@esebe199.NOE.Nokia.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.11.75932 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: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 On Fri, 11 Aug 2006, Zoltan.Ordogh@nokia.com wrote: > If we were living in a perfect world, I would agree with what You just > said here a 100%. But we live in a world where money talks. And it is > the users who has the money - including You and me(*). Client/server > vendors, operators all make a living from their money. You are also supposing a perfect world; that specifications are faithfully implemented, and thus if you sucessfully ram through a specification it will happen, no matter how vigorously someone objects to it. There have been many incidents in the past in which vendor A decided that vendor B's implementation is a threat. To respond to this threat, vendor A implemented technical means that targeted vendor B's product, and did so in a way that made the fault be in vendor B's implementation. This put market pressure on vendor B to "fix" the problem. Sadly, IMAP has not been immune. The IMAP community has been better than some (think HTML), but we've had our own vendor sabotage-wars. Such wars leads to no good for anybody. The ONLY way to avoid this is for EVERYBODY to cooperate in good faith. If objections are raised to a proposal, those objections should not be airily dismissed ("there was some reason"). For a proposal to succeed, there must be concensus among all parties that it is a good idea, or at least not an objectionable idea. The worst proposals are those which are "simple for me, so I don't care that it is not simple for you." Almost as bad are proposals which duplicate existing functionality, but better please someone's sense of esthetics. MOVE is an example of the former. Trash is an example of the latter. -- 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 Aug 11 14:11:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBbTP-0004y3-CN; Fri, 11 Aug 2006 14:11:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBbTO-0004xy-6q for lemonade@ietf.org; Fri, 11 Aug 2006 14:11:06 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBbTL-0002Ee-R7 for lemonade@ietf.org; Fri, 11 Aug 2006 14:11:06 -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 k7BIAcCq003283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Aug 2006 11:10:40 -0700 Received: from [[192.168.1.13]] (vpn-10-50-0-136.qualcomm.com [10.50.0.136]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7BIAZH1013797; Fri, 11 Aug 2006 11:10:38 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <22C8A0D5D5E095449AB509FE777B5F8002A8BF74@svr-exchange.avocado.emccsof t.com> References: <22C8A0D5D5E095449AB509FE777B5F8002A8BF74@svr-exchange.avocado.emccsof t.com> X-Mailer: Eudora for Mac OS X (dev alpha) X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Fri, 11 Aug 2006 11:09:22 -0700 To: "Ben Last" , "Gang Liang" , From: Randall Gellens Subject: RE: [lemonade] some questions in draft-ietf-lemonade-notifications-03 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 1.1 (+) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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:36 AM +0100 8/9/06, Ben Last wrote: > Gang Liang [mailto:lianggang79@huawei.com] wrote on 09 August 2006 > 04:04: >>Using MMS to push email or notifications is just an example. What I > want to >>talk about is the feasibility and rationality of pushing an email via >>outband notification. E.g. if the client is GPRS online and the email > is >>very urgent, maybe it's more appropriate to push the email directly in > the >>notification instead of pushing a wake-up notification that makes the > client >>to create a connection with server to fetch the email. > > I think, then, that one of the key factors is the amount of data you can > get into an outband notification. There's also the security implications: with a simple notification that an event has occurred, the payload generally needs to be signed but not encrypted. When actual data (such as subject, sender, or body of the mail) is included, it needs to be encrypted as well. > You can fit 140 bytes into an SMS, so > there's not much room for more than a notification that events have > occurred. You can fit far more into an MMS (with all the cost > implications) With MMS, generally a notification is sent to the client, with advice from the server as to if the client should immediately retrieve the message or defer it. So to send notification of new mail over MMS would be convoluted, since: (1) new mail arrives at message store (2) notification sent as MMS to client (3) MMS arrives at server (4) MMS server sends notification to client (5) client brings up traffic channel and fetches MMS (6) MMS client hands MMS to mail client (7) mail client brings up traffic channel and fetches mail Whew! > However, I think that the decisions on (a) when to retrieve mail and (b) > how much to retrieve are better made by the client. For example, if the > client can tell that the email is low-priority, or that it is in an area > where network access is slow and expensive, it may choose to retrieve > messages only once per hour, and to retrieve only the headers. Or, if > it detects that it is in range of a usable wi-fi connection, and thus > has high-speed and low-cost access, it might choose to retrieve the > header and message text of new emails. In the mobile phone environment, > I think there are many factors, which vary with time and location and > that are detectable only by the client, which might affect the client's > decisions about how to respond to the information that new messages (or > changes to messages) are available. I'd agree with this. We should keep the client in control as much as possible. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Every word is like an unnecessary stain on silence and nothingness. --Beckett _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Aug 11 18:40:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBffe-0004ke-U9; Fri, 11 Aug 2006 18:40:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBffd-0004kP-1V for lemonade@ietf.org; Fri, 11 Aug 2006 18:40:01 -0400 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBffb-0006rz-Cz for lemonade@ietf.org; Fri, 11 Aug 2006 18:40:00 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M5VD74YFTS00KQIF@mauve.mrochek.com> for lemonade@ietf.org; Fri, 11 Aug 2006 15:39:57 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M5VA17Y2KW0008CX@mauve.mrochek.com>; Fri, 11 Aug 2006 15:39:54 -0700 (PDT) Date: Fri, 11 Aug 2006 14:48:39 -0700 (PDT) From: Ned Freed Subject: Re: [lemonade] Standards Process (was 'Notifications for multiple devices per user') To: Randall Gellens Message-id: <01M5VD73ZFE40008CX@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-transfer-encoding: QUOTED-PRINTABLE DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1155335996; h=MIME-version: Content-transfer-encoding:Content-type:Date:From:Subject; b=0Lvc1pE R0/7NnTL2Jn90ViDPdPUZ5aZ7UmW1b9uajHe9yr6Pmk3azQ7/wvQd0jvGRM4xlk0ESC EjM/vbuqxhdw== References: <0FA975F2D8295A448BE3ADC161244657A9EA56@esebe199.NOE.Nokia.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: lemonade@ietf.org, mrc@CAC.Washington.EDU, 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 > At 12:06 PM +0300 8/4/06, wrote: > > [Z=D6r] I disagree. This is the basis for > > standardization - people come up with ideas, > > and present them. Some people do not like it, > > fine. Later on someone else comes with the same > > idea, so these two agree that "hey: if they > > don't want to standardize it, fine: we will > > implement it anyway". So these guys implement > > it, and make a better service than anyone else > > and then You wish You have made it a standard. > > I believe everything should be standardized - > > so if someone decides to implement it then the > > solution will be available for the taking and > > it will be interoperable with others. > That behavior is problematic for standardized > protocols. Just because two people agree to > implement a bad idea does not make it a good > idea. It leads to poor interoperability as some > people do it one way and others do it another. > The two people who went off in a huff and > implemented what they want after their specific > proposal was not accepted are guilty of the same > attitude they accuse the other participants of > engaging in: ignoring what others are saying. Exactly so. > If someone comes in with a problem he or she > wants to solve, the group should indeed listen > and see if it can be solved and if so what is the > best way. The group shouldn't dismiss the person > out of hand. But if the person proposes a very > specific approach to the problem and the group > points out fundamental difficulties with that > approach, the person should likewise listen to > the objections and work together to find better > solutions. There's an important caveat here: The problem has to fit within the c= harter of the group. Proposals the group is not chartered to consider have no b= usiness being brought up as potential group activities. They can of course be= brought up as topics for a different group where the problem is in scope, or = a character for a new group can be proposed, or the problem can be purs= ued as a individual submission. In the current discussion I cannot see how trash folder handling can = be construed to be in scope for LEMONADE. I hereby raise a point of orde= r asking for discussion of this topic be curtailed on this list. As for MOVE, I suppose an argument can be made that this is a bandwid= th saving mechanism and hence in scope. But I think it's a bit of a stretch. I= think that in order for there to be further discussion of this there needs = to be a concrete proposal on the table that spells out why this is relevant t= o LEMONADE. Notifications about moved messages, OTOH, appear to be in scope. But = again, a concrete proposal would be nice... =09=09=09=09Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Aug 11 21:32:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBiM4-0001Id-2U; Fri, 11 Aug 2006 21:32:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBiM2-00018Q-Li for lemonade@ietf.org; Fri, 11 Aug 2006 21:31:58 -0400 Received: from mxout7.cac.washington.edu ([140.142.32.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBiM1-0003gM-9z for lemonade@ietf.org; Fri, 11 Aug 2006 21:31:58 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7C1Vt4b025079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Aug 2006 18:31:56 -0700 X-Auth-Received: from Shimo-Tomobiki.panda.com ([65.122.177.186]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7C1Vqmx012124 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 11 Aug 2006 18:31:55 -0700 Date: Fri, 11 Aug 2006 18:31:46 -0700 From: Mark Crispin To: Ned Freed Subject: Re: [lemonade] Standards Process (was 'Notifications for multiple devices per user') In-Reply-To: <01M5VD73ZFE40008CX@mauve.mrochek.com> Message-ID: References: <0FA975F2D8295A448BE3ADC161244657A9EA56@esebe199.NOE.Nokia.com> <01M5VD73ZFE40008CX@mauve.mrochek.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.11.181434 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: 79899194edc4f33a41f49410777972f8 Cc: Randall Gellens , 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 Fri, 11 Aug 2006, Ned Freed wrote: > Notifications about moved messages, OTOH, appear to be in scope. But again, > a concrete proposal would be nice... I agree; although this should be in the context of notifications of copied messages. It would be nice if we could use Message-ID for this. I am aware of problems in the past with doing so. Are those problems still relevant in today's world? If we can't use Message-ID, then we probably want some sort of mailbox journal to note events such as COPY. Disconnected clients may find a journal to be useful for other reasons too. -- 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 Sat Aug 12 04:18:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBohA-0000Wi-Cx; Sat, 12 Aug 2006 04:18:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBoh9-0000WT-1S for lemonade@ietf.org; Sat, 12 Aug 2006 04:18:11 -0400 Received: from smtp105.biz.mail.re2.yahoo.com ([206.190.52.174]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GBobv-0005TT-Bj for lemonade@ietf.org; Sat, 12 Aug 2006 04:12:49 -0400 Received: (qmail 67011 invoked from network); 12 Aug 2006 08:12:41 -0000 Received: from unknown (HELO ?192.168.1.64?) (jii@hexsoftware.net@85.220.116.149 with plain) by smtp105.biz.mail.re2.yahoo.com with SMTP; 12 Aug 2006 08:12:40 -0000 Message-ID: <44DD8D6D.3030105@skeyti.com> Date: Sat, 12 Aug 2006 08:12:29 +0000 From: Jon Ingi User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: lemonade@ietf.org Subject: Re: [lemonade] some questions in draft-ietf-lemonade-notifications-03 References: <22C8A0D5D5E095449AB509FE777B5F8002A8BF74@svr-exchange.avocado.emccsof t.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jii@skeyti.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 > At 9:36 AM +0100 8/9/06, Ben Last wrote: > >> You can fit 140 bytes into an SMS, so >> there's not much room for more than a notification that events have >> occurred. You can fit far more into an MMS (with all the cost >> implications) SMS supports concatenation which allows the notification to be larger then 140 bytes. This is required for MMS notifications which are sent over SMS and are usually are larger then 1 SMS, especially due to legacy issues with clients who did not support specific WSP tokens and therefore require string encoding of those tokens. A MMS notification can contain the following (MMS version 1.3): * transaction-id * mms-version * from address * subject * delivery-report flag * storage flag * message class * priority * message-size * expiry value * reply charging * reply charging deadline * reply charging size * reply charging id * distribution indicator * element descriptor * recommended retrieval mode * recommended retrieval mode text * application id * reply application id * aux application info * content class * drm content * replace-id * content-location so as you can see a surprising amount of information is being squeezed in there over SMS :-) Most of this is optional and not used in any real deployment that I've seen. Randall Gellens wrote: > With MMS, generally a notification is sent to the client, with advice > from the server as to if the client should immediately retrieve the > message or defer it. So to send notification of new mail over MMS > would be convoluted, since: > (1) new mail arrives at message store > (2) notification sent as MMS to client > (3) MMS arrives at server > (4) MMS server sends notification to client > (5) client brings up traffic channel and fetches MMS and sends notification response to the MMS server which due to a design flaw in MMS forces the message store to be tightly coupled to MMS server configuration in the device. > (6) MMS client hands MMS to mail client > (7) mail client brings up traffic channel and fetches mail > > Whew! > I agree with others on this list that MMS is a poor choice for a notification protocol. In that case it would be more logical to use MMS as the access protocol and skip IMAP :-) wr, Jon Ingi _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Aug 12 20:03:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GC3S6-0007IC-8I; Sat, 12 Aug 2006 20:03:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GC3S4-0007I7-QR for lemonade@ietf.org; Sat, 12 Aug 2006 20:03:36 -0400 Received: from outbound.cantata.com ([208.236.123.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GC3S3-0002kZ-KH for lemonade@ietf.org; Sat, 12 Aug 2006 20:03:36 -0400 Received: from ma02exchtmp01.Cantata.com ([10.128.18.41]) by outbound.Cantata.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 12 Aug 2006 20:03:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 12 Aug 2006 20:03:43 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: lemonade-deployments Thread-Index: Aca+a/Bz7OS6fj3bSzeMWXIO/S+hhg== From: "Burger, Eric" To: "IETF LEMONADE" X-OriginalArrivalTime: 13 Aug 2006 00:03:43.0814 (UTC) FILETIME=[F0D88E60:01C6BE6B] X-Spam-Score: 1.9 (+) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [lemonade] lemonade-deployments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 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="===============1386313494==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============1386313494== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6BE6B.F073668A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6BE6B.F073668A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable WGLC is closed. Thanks! Sent from my Treo. Sorry if terse. ------_=_NextPart_001_01C6BE6B.F073668A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable lemonade-deployments

WGLC is closed. Thanks!

Sent from my Treo. Sorry if terse.

------_=_NextPart_001_01C6BE6B.F073668A-- --===============1386313494== 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 --===============1386313494==-- From lemonade-bounces@ietf.org Mon Aug 14 03:38:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCX2B-00031Q-DA; Mon, 14 Aug 2006 03:38:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCX2A-00031L-6h for lemonade@ietf.org; Mon, 14 Aug 2006 03:38:50 -0400 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCX25-00088L-37 for lemonade@ietf.org; Mon, 14 Aug 2006 03:38:50 -0400 Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.12]) by smarthost.yourcomms.net (8.11.7p1+Sun/8.11.6) with ESMTP id k7E7QcH27200 for ; Mon, 14 Aug 2006 08:26:38 +0100 (BST) 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] some questions in draft-ietf-lemonade-notifications-03 Date: Mon, 14 Aug 2006 08:38:05 +0100 Message-ID: <22C8A0D5D5E095449AB509FE777B5F8002ABEF47@svr-exchange.avocado.emccsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] some questions in draft-ietf-lemonade-notifications-03 Thread-Index: Aca9cWWYUy45/B6VSVy0OALQ6mvnvACAkvsQ From: "Ben Last" To: "Randall Gellens" , "Gang Liang" , X-Spam-Score: 1.1 (+) 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 Randall Gellens [mailto:randy@qualcomm.com] wrote, at 11 August 2006 19:09: >There's also the security implications: with a simple notification that an event has >occurred, the payload generally needs to be signed but not encrypted. When actual data >(such as subject, sender, or body of the mail) is included, it needs to be encrypted as well. Excellent point. >With MMS, ... to send notification of new mail over MMS would be convoluted, since: > (1) new mail arrives at message store > (2) notification sent as MMS to client > (3) MMS arrives at server > (4) MMS server sends notification to client > (5) client brings up traffic channel and fetches MMS > (6) MMS client hands MMS to mail client > (7) mail client brings up traffic channel and fetches mail (My omission in the first sentence for brevity) Actually, it's not as bad as that from the client point of view, at least on Symbian (S60 or UIQ), and I'm pretty sure on Windows Mobile too. The PIMAP client is just advised of the arrival of an MMS. Steps 4-6 are all dealt with by the base OS or messaging layers, which are opaque to an IMAP client application. Similarly, there are many MMS senders that will accept an MMS via HTTP, making steps 2-4 a single operation from the point of view of the mail server. So it need not be more complex than sending an SMS from the point of view of the P-IMAP systems (client and server). But as mentioned earlier, there are (currently) significant cost issues with use of MMS. Something I also didn't mention earlier is transit time: MMS messages seem to be subject to more and longer delays, at least in and between the UK/EU operators, than SMS. Since part of the rationale for using OOB notifications seems to be immediacy. Regards Ben EMCC Software Ltd _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Aug 14 06:45:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCZx7-0008UW-34; Mon, 14 Aug 2006 06:45:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCZx5-0008UQ-0i for lemonade@ietf.org; Mon, 14 Aug 2006 06:45:47 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCZx3-0007OX-Jg for lemonade@ietf.org; Mon, 14 Aug 2006 06:45:46 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id B8B3C4AC64; Mon, 14 Aug 2006 12:45:42 +0200 (CEST) Message-Id: Date: Mon, 14 Aug 2006 12:45:46 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] profile-bis and format=flowed (RFC 3676) Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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: > Perhaps profile-bis should recommend the use of format=flowed (RFC > 3676). After all, the ability to reflow text (regular and quoted) to > fit small screens was the primary motivation behind format=flowed. I second that. Strongly. Not only because of reflowing, but also because f=f allows a MUA to reliably identify and suppress display of quoted text. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Aug 14 13:42:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCgS7-00086A-68; Mon, 14 Aug 2006 13:42:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCgS5-000865-SM for lemonade@ietf.org; Mon, 14 Aug 2006 13:42:13 -0400 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCgS4-0004GN-He for lemonade@ietf.org; Mon, 14 Aug 2006 13:42:13 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M5Z9NWZ7U8007LJV@mauve.mrochek.com> for lemonade@ietf.org; Mon, 14 Aug 2006 10:42:07 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1155577326; h=Date: From:Subject:MIME-version:Content-type; b=af/TXNreotb/1K66py/h+B3QZ qWFORiNZNh3UO3768hInzpvbN0iJxybWS37hf4LatRK1ub2S8+EqjlT7MHMbg== Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M5VNMA0BYO0008CX@mauve.mrochek.com>; Mon, 14 Aug 2006 10:42:03 -0700 (PDT) To: Arnt Gulbrandsen Message-id: <01M5Z9NVJZIQ0008CX@mauve.mrochek.com> Date: Mon, 14 Aug 2006 10:38:57 -0700 (PDT) From: Ned Freed Subject: Re: [lemonade] profile-bis and format=flowed (RFC 3676) In-reply-to: "Your message dated Mon, 14 Aug 2006 12:45:46 +0200" MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 >> Perhaps profile-bis should recommend the use of format=flowed (RFC >> 3676). After all, the ability to reflow text (regular and quoted) to >> fit small screens was the primary motivation behind format=flowed. > I second that. Strongly. Not only because of reflowing, but also because > f=f allows a MUA to reliably identify and suppress display of quoted > text. I agree as well. f=f seems like a great candidate for inclusion in profile-bis. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Aug 15 06:08:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCvqB-0006Nk-N1; Tue, 15 Aug 2006 06:08:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCvqA-0006Ne-Ok for lemonade@ietf.org; Tue, 15 Aug 2006 06:08:06 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCvq8-00015q-9Z for lemonade@ietf.org; Tue, 15 Aug 2006 06:08:06 -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 k7FA7q8D018952; Tue, 15 Aug 2006 13:07:57 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Aug 2006 13:07:54 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Aug 2006 13:07:54 +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] Standards Process (was 'Notifications for multipledevices per user') Date: Tue, 15 Aug 2006 13:07:21 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657C1BF77@esebe199.NOE.Nokia.com> In-Reply-To: <01M5VD73ZFE40008CX@mauve.mrochek.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Standards Process (was 'Notifications for multipledevices per user') Thread-Index: Aca9lyynWtR3xeteSuS/FOXjbLC1cwCuE69w From: To: , X-OriginalArrivalTime: 15 Aug 2006 10:07:54.0048 (UTC) FILETIME=[AC7ECC00:01C6C052] X-Spam-Score: 0.2 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: lemonade@ietf.org, mrc@CAC.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 >> That behavior is problematic for standardized protocols. =20 >Just because=20 >> two people agree to implement a bad idea does not make it a=20 >good idea. =20 >> It leads to poor interoperability as some people do it one way and=20 >> others do it another. >> The two people who went off in a huff and implemented what they want=20 >> after their specific proposal was not accepted are guilty of=20 >the same=20 >> attitude they accuse the other participants of engaging in: ignoring=20 >> what others are saying. > >Exactly so. I also agree with the logic presented above - but unfortunately we need to implement what the market dictates. People do not pay for good ideas or bad ideas - they pay for a service that they like. Hence, I am here and complaining because implementing standardized solution (that satisfies everyone and does not cause problems to anyone) is preferred over working out a proprietary solution (that satisfies only one but might cause problems for others). >There's an important caveat here: The problem has to fit=20 >within the charter of the group. Proposals the group is not=20 >chartered to consider have no business being brought up as=20 >potential group activities. They can of course be brought up=20 >as topics for a different group where the problem is in scope,=20 >or a character for a new group can be proposed, or the problem=20 >can be pursued as a individual submission. LEMONADE=3DEnhancements to Internet email to support diverse service environments To me this looks just the right place for such improvements. Which part of those suggested improvements does not fit into the picture? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Aug 15 06:09:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCvrB-0006eI-Ei; Tue, 15 Aug 2006 06:09:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCvrA-0006eA-K1 for lemonade@ietf.org; Tue, 15 Aug 2006 06:09:08 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCvr9-0001Bj-6l for lemonade@ietf.org; Tue, 15 Aug 2006 06:09:08 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.7) with ESMTP id k7F98xbu010489; Tue, 15 Aug 2006 12:09:00 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Aug 2006 13:08:02 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Aug 2006 13:08: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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] some questions in draft-ietf-lemonade-notifications-03 Date: Tue, 15 Aug 2006 13:07:28 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657C1BF78@esebe199.NOE.Nokia.com> In-Reply-To: <22C8A0D5D5E095449AB509FE777B5F8002ABEF47@svr-exchange.avocado.emccsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] some questions in draft-ietf-lemonade-notifications-03 Thread-Index: Aca9cWWYUy45/B6VSVy0OALQ6mvnvACAkvsQADaXVDA= From: To: , , , X-OriginalArrivalTime: 15 Aug 2006 10:08:01.0744 (UTC) FILETIME=[B1151D00:01C6C052] X-Spam-Score: 1.3 (+) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 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 >Windows Mobile too. The PIMAP client is just advised of the=20 >arrival of an MMS. Steps What is this PIMAP client You mentioned? Thank You. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Aug 15 06:27:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCw99-0003ET-DF; Tue, 15 Aug 2006 06:27:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCw98-0003EO-NO for lemonade@ietf.org; Tue, 15 Aug 2006 06:27:42 -0400 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCw94-00031j-0R for lemonade@ietf.org; Tue, 15 Aug 2006 06:27:42 -0400 Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.12]) by smarthost.yourcomms.net (8.11.7p1+Sun/8.11.6) with ESMTP id k7FAFVN04614 for ; Tue, 15 Aug 2006 11:15:31 +0100 (BST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: RE: [lemonade] some questions in draft-ietf-lemonade-notifications-03 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Aug 2006 11:27:01 +0100 Message-ID: <22C8A0D5D5E095449AB509FE777B5F8002ABF49D@svr-exchange.avocado.emccsoft.com> In-Reply-To: <0FA975F2D8295A448BE3ADC161244657C1BF78@esebe199.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] some questions in draft-ietf-lemonade-notifications-03 Thread-Index: Aca9cWWYUy45/B6VSVy0OALQ6mvnvACAkvsQADaXVDAAAbA5QA== From: "Ben Last" To: , , , X-Spam-Score: 1.1 (+) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 wrote: >>Windows Mobile too. The PIMAP client is just advised of the arrival of=20 >>an MMS. Steps Zoltan.Ordogh@nokia.com asked: >What is this PIMAP client You mentioned? I'm not quite sure what you're asking: if it's "what do you mean by PIMAP", I mean "Push-IMAP", or "the variant of IMAP spoken by a Lemonade-compliant IMAP server". If you mean "what particular client do you mean", I mean, as an example, the Push-IMAP client that we're currently building for S60 (Symbian) phones, though the statement's applicable to any application, running on a Symbian handset, that wants to be able to detect the arrival of an MMS. Regards Ben EMCC Software Ltd _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Aug 15 06:50:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCwV2-0001TI-SF; Tue, 15 Aug 2006 06:50:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCwV1-0001TD-8d for lemonade@ietf.org; Tue, 15 Aug 2006 06:50:19 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCwUz-0006dc-Pw for lemonade@ietf.org; Tue, 15 Aug 2006 06:50:19 -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 k7FAo5ii003705; Tue, 15 Aug 2006 13:50:08 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Aug 2006 13:49:49 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Aug 2006 13:49: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] some questions in draft-ietf-lemonade-notifications-03 Date: Tue, 15 Aug 2006 13:49:16 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657C1C012@esebe199.NOE.Nokia.com> In-Reply-To: <22C8A0D5D5E095449AB509FE777B5F8002ABF49D@svr-exchange.avocado.emccsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] some questions in draft-ietf-lemonade-notifications-03 Thread-Index: Aca9cWWYUy45/B6VSVy0OALQ6mvnvACAkvsQADaXVDAAAbA5QAAAriSA From: To: , , , X-OriginalArrivalTime: 15 Aug 2006 10:49:49.0520 (UTC) FILETIME=[87D55D00:01C6C058] X-Spam-Score: 1.3 (+) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 Ben, I meant the "PIMAP client". So, I guess You mean a client based on the proprietary P-IMAP draft, = right? http://tools.ietf.org/wg/lemonade/draft-maes-lemonade-p-imap-12.txt Because if You mean a LEMONADE-compliant client, then it cannot be based = on P-IMAP (well, not right anyway now at least because there are too = many differences). Thank You. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 =20 >-----Original Message----- >From: ext Ben Last [mailto:Ben.Last@emccsoft.com]=20 >Sent: 15 August, 2006 13:27 >To: Ordogh Zoltan (Nokia-TP-MSW/Tampere); randy@qualcomm.com;=20 >lianggang79@huawei.com; lemonade@ietf.org >Subject: RE: [lemonade] some questions in=20 >draft-ietf-lemonade-notifications-03 > >>I wrote: >>>Windows Mobile too. The PIMAP client is just advised of the arrival >of=20 >>>an MMS. Steps > >Zoltan.Ordogh@nokia.com asked: >>What is this PIMAP client You mentioned? > >I'm not quite sure what you're asking: if it's "what do you=20 >mean by PIMAP", I mean "Push-IMAP", or "the variant of IMAP=20 >spoken by a Lemonade-compliant IMAP server". >If you mean "what particular client do you mean", I mean, as=20 >an example, the Push-IMAP client that we're currently building=20 >for S60 (Symbian) phones, though the statement's applicable to=20 >any application, running on a Symbian handset, that wants to=20 >be able to detect the arrival of an MMS. > >Regards >Ben >EMCC Software Ltd > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Aug 15 07:13:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCwrG-0007vk-9C; Tue, 15 Aug 2006 07:13:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCwrF-0007vZ-BV for lemonade@ietf.org; Tue, 15 Aug 2006 07:13:17 -0400 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCwrA-0000ZF-G7 for lemonade@ietf.org; Tue, 15 Aug 2006 07:13:17 -0400 Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.12]) by smarthost.yourcomms.net (8.11.7p1+Sun/8.11.6) with ESMTP id k7FB15N10630 for ; Tue, 15 Aug 2006 12:01:05 +0100 (BST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: RE: [lemonade] some questions in draft-ietf-lemonade-notifications-03 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Aug 2006 12:12:35 +0100 Message-ID: <22C8A0D5D5E095449AB509FE777B5F8002ABF590@svr-exchange.avocado.emccsoft.com> In-Reply-To: <0FA975F2D8295A448BE3ADC161244657C1C012@esebe199.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] some questions in draft-ietf-lemonade-notifications-03 Thread-Index: Aca9cWWYUy45/B6VSVy0OALQ6mvnvACAkvsQADaXVDAAAbA5QAAAriSAAABDlLA= From: "Ben Last" To: , , , X-Spam-Score: 1.1 (+) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 Zoltan.Ordogh@nokia.com [mailto:Zoltan.Ordogh@nokia.com] wrote at 15 August 2006 11:49: >Hi Ben, >I meant the "PIMAP client". >So, I guess You mean a client based on the proprietary P-IMAP draft, right? >http://tools.ietf.org/wg/lemonade/draft-maes-lemonade-p-imap-12.txt >Because if You mean a LEMONADE-compliant client, then it cannot be based on P-IMAP (well, >not right anyway now at least because there are too many differences). It makes no difference at all to the point I was making: whether it's a client based on any particular draft of P-IMAP, or Lemonade compliant to some level, the point is still true: a Symbian application doesn't need to be concerned with the complexities of receiving an MMS or SMS; that's all dealt with by the platform. However, to address your point: the Workgroup status page (http://tools.ietf.org/wg/lemonade/) references http://tools.ietf.org/wg/lemonade/draft-maes-lemonade-p-imap-12.txt, which is "a recommendation for interoperable intermediate implementations awaiting draft-ietf-lemonade-profile-bis-xx.txt" and "the P-IMAP specifications are expected to further converge towards the profile". Right now, a feasible way to implement a client is to implement it so that it supports P-IMAP, which overlaps with many parts of the Lemonade profiles. The client can then track the implementation of Lemonade compliance in commercial servers whilst also generating revenue from the installed base of users of those existing P-IMAP servers. So yes, there are differences between Lemonade (as expressed in the profile-bis-xx documents) and P-IMAP (as expressed in draft-maes-lemonade-p-imap-xx), but there's more than enough overlap to allow a client to progress towards supporting both. After all, a good general-use client will follow the capabilities of the server, and XPIMAPvX is just a way for a server to declare that it supports a particular set of capabilities; for example, XPIMAPv1r2 means that the server supports PIMAP version 1.2, which includes XPROVISION, XSETPIMAPPREF, XGETPIMAPPREF, XDELIVER, XZIP, XCONVERT, XVFOLDER, XENCRYPTED and BINARY and implies support for LITERAL+. We're working on a good general-use client, whose first release will include support for servers that speak P-IMAP. As implementations of other Lemonade-originated features appear in servers, support for those will be added (actually, it's usually already in the client, but until it's been tested with a real commercial implementation, it doesn't count). Anyway; P-IMAP isn't really proprietary, since the full details are available and anyone could implement it! Regards Ben EMCC Software Ltd _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Aug 15 08:40:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCyDd-0006tE-Ap; Tue, 15 Aug 2006 08:40:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCyDc-0006t9-Tf for lemonade@ietf.org; Tue, 15 Aug 2006 08:40:28 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCyDc-0007Km-Cd for lemonade@ietf.org; Tue, 15 Aug 2006 08:40:28 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.7) with ESMTP id k7FCe4mj001761; Tue, 15 Aug 2006 15:40:04 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Aug 2006 15:40:04 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Aug 2006 15:40:04 +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] LEMONADE vs. P-IMAP Date: Tue, 15 Aug 2006 15:39:30 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657C1C16F@esebe199.NOE.Nokia.com> In-Reply-To: <22C8A0D5D5E095449AB509FE777B5F8002ABF590@svr-exchange.avocado.emccsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] LEMONADE vs. P-IMAP Thread-Index: Aca9cWWYUy45/B6VSVy0OALQ6mvnvACAkvsQADaXVDAAAbA5QAAAriSAAABDlLAAApnVYA== From: To: , , , X-OriginalArrivalTime: 15 Aug 2006 12:40:04.0484 (UTC) FILETIME=[EEA8C440:01C6C067] X-Spam-Score: 0.2 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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 Ben, >It makes no difference at all to the point I was making:=20 >whether it's a client based on any particular draft of P-IMAP,=20 >or Lemonade compliant to some level, the point is still true:=20 >a Symbian application doesn't need to be concerned with the=20 >complexities of receiving an MMS or SMS; that's all dealt with=20 >by the platform. True indeed - I did not wish to engage in discussions on the notifications, I was merely curious what You mean by "PIMAP client". >However, to address your point: the Workgroup status page >(http://tools.ietf.org/wg/lemonade/) references=20 >http://tools.ietf.org/wg/lemonade/draft-maes-lemonade-p-imap-12.txt, >which is "a recommendation for interoperable intermediate=20 >implementations awaiting=20 >draft-ietf-lemonade-profile-bis-xx.txt" and "the P-IMAP=20 >specifications are expected to further converge towards the=20 >profile". Right now, a feasible way to implement a client is=20 >to implement it so that it supports P-IMAP, which overlaps=20 >with many parts of the Lemonade profiles. The client can then=20 >track the implementation of Lemonade compliance in commercial=20 >servers whilst also generating revenue from the installed base=20 >of users of those existing P-IMAP servers. >So yes, there are differences between Lemonade (as expressed=20 >in the profile-bis-xx documents) and P-IMAP (as expressed in=20 >draft-maes-lemonade-p-imap-xx), but there's more than enough=20 >overlap to allow a client to progress towards supporting both.=20 > After all, a good general-use client will follow the=20 >capabilities of the server, and XPIMAPvX is just a way for a=20 >server to declare that it supports a particular set of=20 >capabilities; for example, XPIMAPv1r2 means that the server=20 >supports PIMAP version 1.2, which includes XPROVISION,=20 >XSETPIMAPPREF, XGETPIMAPPREF, XDELIVER, XZIP, XCONVERT,=20 >XVFOLDER, XENCRYPTED and BINARY and implies support for=20 >LITERAL+. We're working on a good general-use client, whose=20 >first release will include support for servers that speak=20 >P-IMAP. As implementations of other Lemonade-originated=20 >features appear in servers, support for those will be added=20 >(actually, it's usually already in the client, but until it's=20 >been tested with a real commercial implementation, it doesn't count). > >Anyway; P-IMAP isn't really proprietary, since the full=20 >details are available and anyone could implement it! Yes, certainly. Anyone can upload drafts and recommendations. Even me about trash mailbox and move commands :-) but the fact that it is stored in the repository of an IETF working group does not make it a standard. Becoming an RFC does. Please do not get me wrong - I am not saying that P-IMAP is bad - I am simply saying that it is not a standard. I have already seen quite a few confused people both internally and externally - they are talking about P-IMAP and implementing LEMONADE (and vice versa) -, so my goal here was to clarify that You indeed are talking about a P-IMAP-based client. And then again I wonder (per Ned's email about what is in the scope of the charter and what is not) if P-IMAP actually falls into the charter since both LEMONADE and P-IMAP intends to solve the exact same problem with different specs. My history is quite short in IETF, so please forgive my ignorance but I have to ask: Is it a tradition in IETF to provide two solutions for the same problem? The answers I got regarding the move command/trash proposals did not back up this theory. Makes me wonder... Could someone actually clarify the intention with P-IMAP? Someone with a lot of experience in this WG, please? Is it going to: become a standard, is it going to become a separate WG in IETF, etc - and when exactly. Thank You. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Aug 15 20:17:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD95e-00040N-4F; Tue, 15 Aug 2006 20:16:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD95d-00040I-EW for lemonade@ietf.org; Tue, 15 Aug 2006 20:16:57 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD95c-0002Ui-4q for lemonade@ietf.org; Tue, 15 Aug 2006 20:16: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 k7G0GOce012235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 15 Aug 2006 17:16:26 -0700 Received: from [[192.168.1.13]] (loud.qualcomm.com [129.46.172.15]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7G0GMIE002287; Tue, 15 Aug 2006 17:16:23 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <22C8A0D5D5E095449AB509FE777B5F8002A8C049@svr-exchange.avocado.emccsof t.com> References: <22C8A0D5D5E095449AB509FE777B5F8002A8C049@svr-exchange.avocado.emccsof t.com> X-Mailer: Eudora for Mac OS X (dev alpha) X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Tue, 15 Aug 2006 17:12:41 -0700 To: "Ben Last" , , , From: Randall Gellens Subject: RE: [lemonade] some questions in draft-ietf-lemonade-notifications-03 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 1.1 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 11:10 AM +0100 8/9/06, Ben Last wrote: > Sure, it's more > complex from the OS's point of view, but that's hidden from the > programmer. I think it would be a mistake to make a protocol more complex and expensive simply because programmers can implement it by taking advantage of existing libraries and APIs. Good programmers understand, at least in general terms, what happens under the hood. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- We like because, we love although. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Aug 15 20:41:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD9TW-0004r3-Aa; Tue, 15 Aug 2006 20:41:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD9TV-0004qy-N9 for lemonade@ietf.org; Tue, 15 Aug 2006 20:41:37 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD9TU-0005DV-AW for lemonade@ietf.org; Tue, 15 Aug 2006 20:41:37 -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 k7G0fMIH032458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 15 Aug 2006 17:41:23 -0700 Received: from [[192.168.1.13]] (loud.qualcomm.com [129.46.172.15]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7G0fKr9002084; Tue, 15 Aug 2006 17:41:22 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <22C8A0D5D5E095449AB509FE777B5F8002ABEBFF@svr-exchange.avocado.emccsof t.com> References: <22C8A0D5D5E095449AB509FE777B5F8002ABEBFF@svr-exchange.avocado.emccsof t.com> X-Mailer: Eudora for Mac OS X (dev alpha) X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Tue, 15 Aug 2006 17:40:45 -0700 To: "Ben Last" , From: Randall Gellens Subject: RE: [lemonade] Special-Purpose Mailboxes (was 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.6 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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:58 AM +0100 8/11/06, Ben Last wrote: > Randall Gellens wrote, at 11 August 2006 02:19: > >> Given the widespread use of Trash mailboxes, I can also see >> benefit in having a way to identify to clients which mailboxes are >> so used by other clients. However, I can also see three reasons >> not to do this: (1) it seems unlikely that existing clients will >> be updated to specify the Trash mailbox they are using, so having >> a way for them to do so won't help; (2) since existing clients use >> different names for the Trash mailbox, anyone using multiple >> clients probably has multiple Trash mailboxes; (3) it is unclear >> that mobile clients will want to synchronize a Trash mailbox >> created by other clients: why waste bandwidth and memory caching >> messages that the user has already marked for deletion? > > Certainly my motivation for discussing this general area was issue (3) > above: we have no interest in implementing a Trash mailbox > (deleted/expunge works for us) but we do definitely want to avoid > showing other clients special-purpose mailboxes to the user, or > synchronzing them. > Randall: I respectfully disagree that your arguments above are arguments > against providing ways for clients to identify mailboxes. Specific > responses: > (1) But even if they don't use a Trash, they may use Sent > Items/Drafts/Outbox mailboxes. Sorry for not being more clear. My point above is that there are a lot of existing clients that use Trash mailboxes and it is not clear that such clients will be updated to start using a mechanism to mark such mailboxes. Having an extension for them to use doesn't help you if they don't use it. > (2) But if clients that currently do use a Trash mailbox could spot an > existing one and re-use it, that would avoid the proliferation of > Trash/Deleted Items/Wastebasket mailboxes that can occur. True, this is an argument in favor of defining a mechanism for this purpose. And pursonally I'm not opposed to it. But, if we more clearly identify the disadvantages of Trash mailboxes, and identify other mechanisms and/or techniques that clients can use to better achieve their goals, then when clients are updated they may well start using the alternative instead of the marking extension. > (3) If a client can identify other clients' Trash mailbox, it can avoid > synchronizing it. If it can't, there's the risk that it will be > synchronized inadvertently. That would also confuse the end user: seeing > a Trash mailbox that doesn't hold newly deleted messages. I agree. I'm just not sure that defining a way for other clients to tell you what they are doing will help you, unless we can make it attractive for those other clients to start using it. > > At least one of our use cases involves three clients in use for any one > account: > * A desktop client such as Eudora or Thunderbird > * A webmail client provided by the server vendor > * A mobile client > > This is actually not an unusual setup for users in our target market, so > anything that helps inter-client interoperability is key for us. > > ACAP would help with the Special-purpose Mailboxes problem, but as far > as I can tell, there are very few servers that implement it (and none of > the target server vendors for our client have any plans to implement > it). For a client developer, especially in the mobile phone market, the > assumption must always be that one must interoperate with what is out > there now. We have no control over the servers with which a customer > would expect our client to interoperate. But given that the Lemonade > profiles and standards have a fair degree of momentum now, raising > problems such as special-purpose mailboxes here is about the best chance > we have of making our lives easier in the future! -- 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 Tue Aug 15 21:06:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD9rc-0004tV-Kq; Tue, 15 Aug 2006 21:06:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD9rb-0004tM-HX for lemonade@ietf.org; Tue, 15 Aug 2006 21:06:31 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD9rY-0003s8-4p for lemonade@ietf.org; Tue, 15 Aug 2006 21:06:31 -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 k7G16P63003814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 15 Aug 2006 18:06:26 -0700 Received: from [[192.168.1.13]] (loud.qualcomm.com [129.46.172.15]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7G16MN1012743; Tue, 15 Aug 2006 18:06:24 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <0FA975F2D8295A448BE3ADC161244657B91000@esebe199.NOE.Nokia.com> References: <0FA975F2D8295A448BE3ADC161244657B91000@esebe199.NOE.Nokia.com> X-Mailer: Eudora for Mac OS X (dev alpha) X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Tue, 15 Aug 2006 18:01:57 -0700 To: , From: Randall Gellens Subject: RE: [lemonade] Standards Process (was '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.6 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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:30 PM +0300 8/11/06, wrote: > Users do not care what is beneath the surface as long as they get > what they want: > - they do not care how difficult it was to create something; > - they do not care about poor interoperability (they will just > stop using the "old" products and buy the newest gadgets from the > provider/manufacturer who gives them what they want and it works > with their friend's gadgets); > - and they do not care that their favourite product is based on a bad idea. All very true. Users don't care (and shouldn't need to care) about standards. The point of standards is to provide a way for users to not need to care. If the standard is poor, if it is ambiguous, or if it is contains elements that don't work, or are otherwise bad ideas, then the users are given implementations that aren't reliable and that don't work. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Democracy is a form of government in which it is permitted to wonder aloud what the country could do under first-class management. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Aug 15 21:06:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD9rZ-0004t8-GJ; Tue, 15 Aug 2006 21:06:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD9rY-0004t3-M4 for lemonade@ietf.org; Tue, 15 Aug 2006 21:06:28 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD9rW-0003r4-AH for lemonade@ietf.org; Tue, 15 Aug 2006 21:06:28 -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 k7G16Oj2003808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 15 Aug 2006 18:06:25 -0700 Received: from [[192.168.1.13]] (loud.qualcomm.com [129.46.172.15]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7G16MMx012743; Tue, 15 Aug 2006 18:06:23 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <0FA975F2D8295A448BE3ADC161244657B90F4F@esebe199.NOE.Nokia.com> References: <0FA975F2D8295A448BE3ADC161244657B90F4F@esebe199.NOE.Nokia.com> X-Mailer: Eudora for Mac OS X (dev alpha) X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Tue, 15 Aug 2006 18:03:20 -0700 To: , From: Randall Gellens Subject: RE: [lemonade] 'MOVE' (was 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.6 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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:08 PM +0300 8/11/06, wrote: > I would like to address this problem, but so far it seems that > other parties are happy with the solution available today, and see > no benefit of addressing it - this is the reason why I gave up. If > everyone agrees that this is the way to go, what can I do? Solve it > in OMA where the operator awareness is much stronger? I would like > to do it here in LEMONADE since this is the "natural home" of such > extensions. You mean propose an IMAP extension in OMA? > I am more concerned about bandwidth usage and the number of > roundtrips - these are major concerns on mobile networks because: > - the roundtrips and latencies are typically longer and > - the amount of data transmitted should be minimal, > hence my persistence regarding this issue. I don't think anyone here disagrees regarding the need to minimize roundtrips especially but also bandwidth. The disagreement is about the advisability of the proposed MOVE extension. > This is why I am saying that a simple MOVE command would solve it: > Client says: MOVE mailbox/UID to this mailbox > Servers says: OK done, here is the new UID. > or: > Client says: MOVE mailbox to this mailbox > Server says: OK > All done with one roundtrip. I do not think that there is a more > efficient way to do this. The current UIDPLUS does as much as this. Neither that nor MOVE is any help at all to other clients (those that sync the mailboxes involved but didn't issue the command). > Then, there is this version - which might be imporant when the user > wants to move all messages: > Client says: MOVE mailbox/* to this mailbox > Servers says: OK done, here are the new UIDs. > however, I am not sure how to solve this because there are several > UIDs involved (some kind of mapping of old UIDs to new UIDs is > necessary otherwise the client will re-download everything). > > I am not sure what You mean by working on the underlying problem What I mean is: identify the problem. We see if the problem itself is in scope. If it is, we identify requirements and discuss proposed solutions. As I understand the MOVE suggestion, it doesn't really help over what we have now. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Advertising is 85 percent confusion and 15 percent commission. --Fred Allen _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Aug 15 21:17:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDA1k-0007Ha-BO; Tue, 15 Aug 2006 21:17:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDA1j-0007HV-9X for lemonade@ietf.org; Tue, 15 Aug 2006 21:16:59 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDA1h-0006RF-Vr for lemonade@ietf.org; Tue, 15 Aug 2006 21:16:59 -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 k7G1GXGS020503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 15 Aug 2006 18:16:33 -0700 Received: from [[192.168.1.13]] (loud.qualcomm.com [129.46.172.15]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7G1GUw5020404; Tue, 15 Aug 2006 18:16:32 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <22C8A0D5D5E095449AB509FE777B5F8002ABEF47@svr-exchange.avocado.emccsof t.com> References: <22C8A0D5D5E095449AB509FE777B5F8002ABEF47@svr-exchange.avocado.emccsof t.com> X-Mailer: Eudora for Mac OS X (dev alpha) X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Tue, 15 Aug 2006 18:16:21 -0700 To: "Ben Last" , "Gang Liang" , From: Randall Gellens Subject: RE: [lemonade] some questions in draft-ietf-lemonade-notifications-03 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 1.1 (+) 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 At 8:38 AM +0100 8/14/06, Ben Last wrote: > Actually, it's not as bad as that from the client point of view > Steps 4-6 are all dealt with by the base OS or messaging layers The complexity and overhead are still there, even if the client doesn't necessarily see it. > But as mentioned earlier, there are (currently) significant cost issues > with use of MMS. Something I also didn't mention earlier is transit > time: MMS messages seem to be subject to more and longer delays, at > least in and between the UK/EU operators, than SMS. Since part of the > rationale for using OOB notifications seems to be immediacy. Good point. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Paranoids are the only ones who notice things anymore. --Anatole Broyard _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Aug 15 21:42:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDAQe-0007ZN-Kb; Tue, 15 Aug 2006 21:42:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDAQd-0007Ym-PM for lemonade@ietf.org; Tue, 15 Aug 2006 21:42:43 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDALV-0001KD-Dl for lemonade@ietf.org; Tue, 15 Aug 2006 21:37:26 -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 k7G1bMpT022766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 15 Aug 2006 18:37:23 -0700 Received: from [[192.168.1.13]] (loud.qualcomm.com [129.46.172.15]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7G1bKl3016931; Tue, 15 Aug 2006 18:37:21 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <0FA975F2D8295A448BE3ADC161244657B91000@esebe199.NOE.Nokia.com> References: <0FA975F2D8295A448BE3ADC161244657B91000@esebe199.NOE.Nokia.com> X-Mailer: Eudora for Mac OS X (dev alpha) X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Tue, 15 Aug 2006 18:35:27 -0700 To: , From: Randall Gellens Subject: RE: [lemonade] Standards Process (was '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.6 (/) 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 1:30 PM +0300 8/11/06, wrote: > they do not care about poor interoperability (they will just stop > using the "old" products and buy the newest gadgets from the > provider/manufacturer who gives them what they want and it works > with their friend's gadgets); What if the poor user has three friends, and each one has a different gadget and use different carriers? > - and they do not care that their favourite product is based on a bad idea. Please take a look at RFC 1925 ("Fundamental Truths of Networking"), especially Truth #3 (but really, the rest as well are very applicable to the discussion here). ftp://ftp.rfc-editor.org/in-notes/rfc1925.txt -- 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 Tue Aug 15 21:43:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDAR7-000840-3I; Tue, 15 Aug 2006 21:43:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDAR5-0007xI-QM for lemonade@ietf.org; Tue, 15 Aug 2006 21:43:11 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDADQ-0008V2-T3 for lemonade@ietf.org; Tue, 15 Aug 2006 21:29:06 -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 k7G1SYPh006268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 15 Aug 2006 18:28:35 -0700 Received: from [[192.168.1.13]] (loud.qualcomm.com [129.46.172.15]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7G1STl0018029; Tue, 15 Aug 2006 18:28:33 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <0FA975F2D8295A448BE3ADC161244657C1C16F@esebe199.NOE.Nokia.com> References: <0FA975F2D8295A448BE3ADC161244657C1C16F@esebe199.NOE.Nokia.com> X-Mailer: Eudora for Mac OS X (dev alpha) X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Tue, 15 Aug 2006 18:28:22 -0700 To: , , , From: Randall Gellens Subject: RE: [lemonade] LEMONADE vs. P-IMAP 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 3:39 PM +0300 8/15/06, wrote: > Is it going to: become a standard, Drafts which have someone's name as the second element are individual contributions. Drafts which have been accepted by a working group have "ietf" as the second element, and the working group name as the third element. In our case, they start with "draft-ietf-lemonade-". The authors of the P-IMAP draft are active participants in the group, and are the authors of several working group documents. The process of the IETF is based on drafts. People write drafts as individuals to make proposals, to critique proposals, to offer information. Often, specific parts of these drafts make it in to working group drafts. Working group drafts progress through revisions based on comments. > is it going to become a separate WG in IETF, etc - I have not seen any suggestions to form a new working group for P-IMAP. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Nothing in the world is more dangerous than sincere ignorance and conscientious stupidity. --Martin Luther King, Jr. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Aug 15 21:45:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDATO-0000nT-Hx; Tue, 15 Aug 2006 21:45:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDATM-0000nL-PT for lemonade@ietf.org; Tue, 15 Aug 2006 21:45:32 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDATK-0003L4-Dy for lemonade@ietf.org; Tue, 15 Aug 2006 21:45:32 -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 k7G1jR9q008129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 15 Aug 2006 18:45:28 -0700 Received: from [[192.168.1.13]] (loud.qualcomm.com [129.46.172.15]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7G1jPsC024419; Tue, 15 Aug 2006 18:45:26 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <01M5VD73ZFE40008CX@mauve.mrochek.com> References: <0FA975F2D8295A448BE3ADC161244657A9EA56@esebe199.NOE.Nokia.com> <01M5VD73ZFE40008CX@mauve.mrochek.com> X-Mailer: Eudora for Mac OS X (dev alpha) X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Tue, 15 Aug 2006 18:42:01 -0700 To: Ned Freed From: Randall Gellens Subject: Re: [lemonade] Standards Process (was '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.6 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: lemonade@ietf.org, mrc@CAC.Washington.EDU, 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 At 2:48 PM -0700 8/11/06, Ned Freed wrote: > In the current discussion I cannot see how trash folder handling can be > construed to be in scope for LEMONADE. I hereby raise a point of order asking > for discussion of this topic be curtailed on this list. I see benefit in looking at why so many clients use Trash mailboxes instead of delete/expunge, and trying to document a better way to achieve the user experience, including extensions if needed. In re-reading our charter, I can see arguments either way as to if this is in scope here or not. I think it comes down to how much the pain of the current situation is specific to mobiles. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- If we do not change our direction we are likely to end up where we are headed. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Aug 16 00:59:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDDUG-0002Tj-FA; Wed, 16 Aug 2006 00:58:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDDUF-0002Te-D8 for lemonade@ietf.org; Wed, 16 Aug 2006 00:58: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 1GD9QN-0004TT-UT for lemonade@ietf.org; Tue, 15 Aug 2006 20:38:23 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GD9E0-0003rn-65 for lemonade@ietf.org; Tue, 15 Aug 2006 20:25:38 -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 k7G0PML1030318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 15 Aug 2006 17:25:22 -0700 Received: from [[192.168.1.13]] (loud.qualcomm.com [129.46.172.15]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7G0PKM0003489; Tue, 15 Aug 2006 17:25:21 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <22C8A0D5D5E095449AB509FE777B5F8002ABEBF6@svr-exchange.avocado.emccsof t.com> References: <22C8A0D5D5E095449AB509FE777B5F8002ABEBF6@svr-exchange.avocado.emccsof t.com> X-Mailer: Eudora for Mac OS X (dev alpha) X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Tue, 15 Aug 2006 17:24:53 -0700 To: "Ben Last" , lemonade@ietf.org From: Randall Gellens Subject: RE: [lemonade] profile-bis and format=flowed (RFC 3676) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: -2.5 (--) 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 At 7:35 AM +0100 8/11/06, Ben Last wrote: > Randall Gellens [mailto:randy@qualcomm.com] wrote, at 10 August 2006 > 23:58: >> Perhaps profile-bis should recommend the use of format=flowed >> (RFC3676). After all, the ability to reflow text (regular and >> quoted) to fit small screens was the primary motivation >> behind format=flowed. > > I'm not clear: do you mean that outgoing email messages from a > (small-screen) client should use format=flowed? Or that the server > re-format text/plain messages to be text/plain;format=flowed (which > surely covers more server behaviour than in the scope of profile-bis)? This is strictly client-side behavior. The server should stay out of it. I mean that mobile clients especially should generate messages using format=flowed, and should interpret format=flowed when displaying messages. If mobile as well as desktop/laptop/web clients use f=f, the experience will be much more pleasant for users with small screens. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- To define recursion, we must first define recursion. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Aug 16 03:07:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDFUd-0005Dt-PZ; Wed, 16 Aug 2006 03:07:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDFUd-0005Do-65 for lemonade@ietf.org; Wed, 16 Aug 2006 03:07:11 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDFUb-0000YQ-NN for lemonade@ietf.org; Wed, 16 Aug 2006 03:07:11 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.7) with ESMTP id k7G777kr018169; Wed, 16 Aug 2006 10:07:08 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Aug 2006 10:07:05 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Aug 2006 10:07: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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] 'MOVE' (was Notifications for multiple devices per user) Date: Wed, 16 Aug 2006 10:06:31 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657C79AD9@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] 'MOVE' (was Notifications for multiple devices per user) Thread-Index: AcbA0otcBsgseRQmRIyUwW0nuCmi4AALTMGA From: To: , X-OriginalArrivalTime: 16 Aug 2006 07:07:05.0278 (UTC) FILETIME=[94899DE0:01C6C102] X-Spam-Score: 0.8 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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, >> I would like to address this problem, but so far it seems=20 >that other=20 >> parties are happy with the solution available today, and see no=20 >> benefit of addressing it - this is the reason why I gave up. If=20 >> everyone agrees that this is the way to go, what can I do?=20 >Solve it in=20 >> OMA where the operator awareness is much stronger? I would=20 >like to do=20 >> it here in LEMONADE since this is the "natural home" of such=20 >> extensions. > >You mean propose an IMAP extension in OMA? I am not saying it wiil, I am saying it might. You see, in OMA the operator presence is very strong - if there is enough operator demand for some feature, it will be done (one way or another). So far we did not go into too much detail in how the email service will look like - I guess everyone is waiting for the LEMONADE specs to see what's there and what's missing. One thing I noticed whil talking with people is that some talk about pure IMAP serivce, some talk about "Outlook"-like service where You do have all those special mailboxes (including trash) and for these people identification of the TRASH mailbox might be quite important. My worry here is: if it's not in the LEMONADE Profile, it will have to be done in OMA. If it's done in OMA, only the OMA-Complicant clients will be completely interoperable (e.g. when the same mailbox is accessed from a LEMONADE client, it might mess up the user's mailbox for the OMA client - for "mess" I mean leaving around flagged messages and not placing them into the trash). Then, there is the DS-based email (I am not sure whether You know about this): There will be a DS-based (Data Synch - formerly known as SyncML) email solution as well - where they indeed identify the trash (well, in a proposal I saw it was included). Now, if I accessed the same mailbox from my office via LEMONADE and during travelling via DS, I (as a user) might not like what I see. I would like to emphasize that these things are not important at this point because we did not go into such detail yet in OMA. But in the near future they might - and then I would rather have this particular problem solved in LEMONADE than in OMA. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Aug 16 03:31:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDFsJ-0005b5-Cf; Wed, 16 Aug 2006 03:31:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDFsI-0005at-NY for lemonade@ietf.org; Wed, 16 Aug 2006 03:31:38 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDFsG-0002as-88 for lemonade@ietf.org; Wed, 16 Aug 2006 03:31:38 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.7) with ESMTP id k7G7VJVT020023; Wed, 16 Aug 2006 10:31:21 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Aug 2006 10:30: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, 16 Aug 2006 10:30: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] LEMONADE vs. P-IMAP Date: Wed, 16 Aug 2006 10:29:49 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657C79B31@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] LEMONADE vs. P-IMAP Thread-Index: AcbA0+k25Q14iQEwRr2+xMooytOc1gALwvJQ From: To: , , , X-OriginalArrivalTime: 16 Aug 2006 07:30:23.0547 (UTC) FILETIME=[D5F888B0:01C6C105] X-Spam-Score: 0.2 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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 clarification Randall, it confirms that my understanding about the way of working in IETF is = correct. However, I was looking for a different answer. I see confused people every day who think that P-IMAP is actually the = LEMONADE standard. This is the reason why I asked Ben for clarification. = I would like to end this confusion - it is not good for anyone(*) I = believe - and this is the exact reason why I asked about P-IMAP (will it = become standard, will it be in LEMONADE or should it be separate WG, = etc). Does the WG have a solid opinion on this issue at all? The LEMONADE standard is called LEMONADE Profile and not P-IMAP, right? = Or, maybe both? I would really appreciate if someone could clarify this = in a way that everyone agrees to. Thank You. (*) Including me. Personally, I got tired of explaining over and over = again that P-IMAP is not the LEMONADE stardard, the LEMONADE standard is = LEMONADE Profile. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 =20 >-----Original Message----- >From: ext Randall Gellens [mailto:randy@qualcomm.com]=20 >Sent: 16 August, 2006 04:28 >To: Ordogh Zoltan (Nokia-TP-MSW/Tampere);=20 >Ben.Last@emccsoft.com; lianggang79@huawei.com; lemonade@ietf.org >Subject: RE: [lemonade] LEMONADE vs. P-IMAP > >At 3:39 PM +0300 8/15/06, wrote: > >> Is it going to: become a standard, > >Drafts which have someone's name as the second element are=20 >individual contributions. Drafts which have been accepted by=20 >a working group have "ietf" as the second element, and the=20 >working group name as the third element. In our case, they=20 >start with "draft-ietf-lemonade-". > >The authors of the P-IMAP draft are active participants in the=20 >group, and are the authors of several working group documents. > >The process of the IETF is based on drafts. People write=20 >drafts as individuals to make proposals, to critique=20 >proposals, to offer information. Often, specific parts of=20 >these drafts make it in to working group drafts. Working=20 >group drafts progress through revisions based on comments. > >> is it going to become a separate WG in IETF, etc - > >I have not seen any suggestions to form a new working group for P-IMAP. >-- >Randall Gellens >Opinions are personal; facts are suspect; I speak for myself only >-------------- Randomly-selected tag: --------------- Nothing=20 >in the world is more dangerous than sincere ignorance and=20 >conscientious stupidity. > --Martin Luther King, Jr. > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Aug 16 03:37:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDFyD-0007WZ-1J; Wed, 16 Aug 2006 03:37:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDFyB-0007WU-U3 for lemonade@ietf.org; Wed, 16 Aug 2006 03:37:43 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDFyA-00036u-EN for lemonade@ietf.org; Wed, 16 Aug 2006 03:37:43 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.7) with ESMTP id k7G7bZNe024809; Wed, 16 Aug 2006 10:37:38 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Aug 2006 10:36:43 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Aug 2006 10:36:42 +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] Standards Process (was 'Notifications formultiple devices per user') Date: Wed, 16 Aug 2006 10:36:08 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657C79B5B@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Standards Process (was 'Notifications formultiple devices per user') Thread-Index: AcbA1ZZ9Hz+YO33yQc+HtRgBgNVXBwAMMJyA From: To: , X-OriginalArrivalTime: 16 Aug 2006 07:36:42.0418 (UTC) FILETIME=[B7CBA920:01C6C106] X-Spam-Score: 0.8 (/) 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 Good one :-) 10 and 11 (which in the end directs You to 6) might apply here as well. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 =20 >-----Original Message----- >From: ext Randall Gellens [mailto:randy@qualcomm.com]=20 >Sent: 16 August, 2006 04:35 >To: Ordogh Zoltan (Nokia-TP-MSW/Tampere); mrc@CAC.Washington.EDU >Cc: lemonade@ietf.org >Subject: RE: [lemonade] Standards Process (was 'Notifications=20 >formultiple devices per user') > >At 1:30 PM +0300 8/11/06, wrote: > >> they do not care about poor interoperability (they will just stop=20 >> using the "old" products and buy the newest gadgets from the=20 >> provider/manufacturer who gives them what they want and it=20 >works with=20 >> their friend's gadgets); > >What if the poor user has three friends, and each one has a=20 >different gadget and use different carriers? > >> - and they do not care that their favourite product is=20 >based on a bad idea. > >Please take a look at RFC 1925 ("Fundamental Truths of=20 >Networking"), especially Truth #3 (but really, the rest as=20 >well are very applicable to the discussion here). > >ftp://ftp.rfc-editor.org/in-notes/rfc1925.txt >-- >Randall Gellens >Opinions are personal; facts are suspect; I speak for myself only >-------------- Randomly-selected tag: --------------- The=20 >fewer episodes of a TV show one has seen, the greater the=20 >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 > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Aug 16 14:15:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDPuv-0000fl-Tj; Wed, 16 Aug 2006 14:15:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDPuu-0000fc-GX for lemonade@ietf.org; Wed, 16 Aug 2006 14:15:00 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDPum-0007rI-Tq for lemonade@ietf.org; Wed, 16 Aug 2006 14:15:00 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1GDPum-0004Z4-03; Wed, 16 Aug 2006 18:14:52 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id CE38B498003; Wed, 16 Aug 2006 19:22: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 30713-10; Wed, 16 Aug 2006 19:21:46 +0100 (BST) Received: from invsysm1 (unknown [213.205.222.137]) by turner.dave.cridland.net (Postfix) with ESMTP id A360C498002; Wed, 16 Aug 2006 19:21:43 +0100 (BST) Date: Wed, 16 Aug 2006 19:13:00 +0100 Subject: RE: [lemonade] 'MOVE' (was Notifications for multiple devices per user) References: <0FA975F2D8295A448BE3ADC161244657C79AD9@esebe199.NOE.Nokia.com> In-Reply-To: <0FA975F2D8295A448BE3ADC161244657C79AD9@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Message-Id: <5386.1155752063.725602@invsysm1> 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: 8b431ad66d60be2d47c7bfeb879db82c Cc: Enhancements to Internet email to support diverse service enivronments , Randall Gellens , Philip Guenther X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 Aug 16 08:06:31 2006, Zoltan.Ordogh@nokia.com wrote: > what's missing. One thing I noticed whil talking with people is that > some talk about pure IMAP serivce, some talk about "Outlook"-like > service where You do have all those special mailboxes (including > trash) > and for these people identification of the TRASH mailbox might be > quite > important. The problem is it probably wouldn't, in practise, because you'd have to manually mark which mailbox the third-party client was using, and manually configure your desktop client to use the same one as your webmail. > from a LEMONADE client, it might mess up the user's mailbox for the > OMA > client - for "mess" I mean leaving around flagged messages and not > placing them into the trash). From an interop standpoint, any trash mailbox using client has to deal with \Deleted messages in normal folders anyway. > Then, there is the DS-based email (I am not sure whether You know > about > this): There will be a DS-based (Data Synch - formerly known as > SyncML) > email solution as well - where they indeed identify the trash > (well, in > a proposal I saw it was included). Now, if I accessed the same > mailbox > from my office via LEMONADE and during travelling via DS, I (as a > user) > might not like what I see. Well, the DS service can present all the deleted messages as being in a seperate folder, much like I'm arguing that any other client can. If it doesn't, then this is a poor DS service. Now, if we can figure out a way clients can present this metaphor efficiently, and I think we can, then we can move forward from there to seeking ways of making this metaphor more efficient by providing suitable extensions. That latter is absolutely in scope for this WG, of course. 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 Aug 17 05:38:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDeKc-0006Pc-FX; Thu, 17 Aug 2006 05:38:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDeKa-0006PX-Qr for lemonade@ietf.org; Thu, 17 Aug 2006 05:38:28 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDeKZ-000675-Ba for lemonade@ietf.org; Thu, 17 Aug 2006 05:38:28 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.7) with ESMTP id k7H8cL86006334; Thu, 17 Aug 2006 11:38:26 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Aug 2006 12:35:34 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Aug 2006 12:35: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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] 'MOVE' (was Notifications for multiple devices per user) Date: Thu, 17 Aug 2006 12:35:00 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657C7A5C5@esebe199.NOE.Nokia.com> In-Reply-To: <5386.1155752063.725602@invsysm1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] 'MOVE' (was Notifications for multiple devices per user) Thread-Index: AcbBX+xTxsQWGc7cSl+kcsy5UnXcVwAfvFVw From: To: X-OriginalArrivalTime: 17 Aug 2006 09:35:34.0605 (UTC) FILETIME=[7D52C7D0:01C6C1E0] X-Spam-Score: 0.2 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: lemonade@ietf.org, randy@qualcomm.com, guenther+lemonade@sendmail.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, Thank You. >On Wed Aug 16 08:06:31 2006, Zoltan.Ordogh@nokia.com wrote: >> what's missing. One thing I noticed whil talking with people is that=20 >> some talk about pure IMAP serivce, some talk about "Outlook"-like=20 >> service where You do have all those special mailboxes (including >> trash) >> and for these people identification of the TRASH mailbox might be=20 >> quite important. > >The problem is it probably wouldn't, in practise, because=20 >you'd have to manually mark which mailbox the third-party=20 >client was using, and manually configure your desktop client=20 >to use the same one as your webmail. But if the relevant setting was stored on the server, it would not need to be configured at all except for the first time (and ultimately all clients would behave the same way using the same configuration). >> from a LEMONADE client, it might mess up the user's mailbox for the=20 >> OMA client - for "mess" I mean leaving around flagged=20 >messages and not=20 >> placing them into the trash). > > From an interop standpoint, any trash mailbox using client=20 >has to deal with \Deleted messages in normal folders anyway. Certainly. I am not worried about the protocol level - I am worried showing a mixed mailbox to the user (where some mails are in the trash as expected and some are not). >> Then, there is the DS-based email (I am not sure whether You know=20 >> about >> this): There will be a DS-based (Data Synch - formerly known as=20 >> SyncML) >> email solution as well - where they indeed identify the trash=20 >> (well, in >> a proposal I saw it was included). Now, if I accessed the same=20 >> mailbox >> from my office via LEMONADE and during travelling via DS, I (as a=20 >> user) >> might not like what I see. > >Well, the DS service can present all the deleted messages as being in=20 >a seperate folder, much like I'm arguing that any other client can.=20 >If it doesn't, then this is a poor DS service. One can say that the IMAP<->DS adapter needs to take care of this, yes. However, the DS-based solution is not limited to IMAP. What if one user is using DS to access two different mailboxes (one with IMAP and one with WebDAV/POP/etc)? In this case, the mailboxes are going to behave differently - and I would prefer delivering the exact same look and feel independently of the underlying technologies. >Now, if we can figure out a way clients can present this metaphor=20 >efficiently, and I think we can, then we can move forward from there=20 >to seeking ways of making this metaphor more efficient by providing=20 >suitable extensions. That latter is absolutely in scope for this WG,=20 >of course. I agree, of course. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Aug 17 19:19:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDr8j-0004Nk-3g; Thu, 17 Aug 2006 19:19:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDr8i-0004Nf-Al for lemonade@ietf.org; Thu, 17 Aug 2006 19:19:04 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDr8g-0007zm-VU for lemonade@ietf.org; Thu, 17 Aug 2006 19:19:04 -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 k7HNIk19026949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 17 Aug 2006 16:18:46 -0700 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.172.15]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7HNIiaH005549; Thu, 17 Aug 2006 16:18:45 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <0FA975F2D8295A448BE3ADC161244657C79B31@esebe199.NOE.Nokia.com> References: <0FA975F2D8295A448BE3ADC161244657C79B31@esebe199.NOE.Nokia.com> X-Mailer: Eudora for Mac OS X (dev alpha) X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Thu, 17 Aug 2006 16:17:17 -0700 To: , , , From: Randall Gellens Subject: RE: [lemonade] LEMONADE vs. P-IMAP 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: a7d6aff76b15f3f56fcb94490e1052e4 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:29 AM +0300 8/16/06, wrote: > However, I was looking for a different answer. > I see confused people every day who think that P-IMAP is actually > the LEMONADE standard. This is the reason why I asked Ben for > clarification. I would like to end this confusion - it is not good > for anyone(*) I believe - and this is the exact reason why I asked > about P-IMAP (will it become standard, will it be in LEMONADE or > should it be separate WG, etc). > Does the WG have a solid opinion on this issue at all? > The LEMONADE standard is called LEMONADE Profile and not P-IMAP, > right? Or, maybe both? I would really appreciate if someone could > clarify this in a way that everyone agrees to. > Thank You. The lemonade working group charter includes enhancing Internet mail submission and retrieval protocols. These enhancements are published as standards-track RFCs after having been produced by the lemonade working group. To simplify things, the group is also producing a document called "Lemonade Profile". This profile document describes how lemonade clients take advantage of the specific extensions, and specifies a minimum set of extensions that are supported by lemonade-compliant implementations. The profile document references each of the specific extension (or other) documents. In this way, we can speak of "IETF lemonade" and mean what is included in or referenced by the profile document. The first version of the profile document has been published as RFC 4550. An updated version is being currently developed. The term "P-IMAP" has no official meaning within the lemonade working group. The lemonade charter is at . RFC 3440 is available at . -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Every word is like an unnecessary stain on silence and nothingness. --Beckett _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Aug 17 19:30:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDrJG-00020y-MG; Thu, 17 Aug 2006 19:29:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDrJF-00020t-HE for lemonade@ietf.org; Thu, 17 Aug 2006 19:29:57 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDrJE-0000Ic-72 for lemonade@ietf.org; Thu, 17 Aug 2006 19:29:57 -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 k7HNTmcM028354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 17 Aug 2006 16:29:49 -0700 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.172.15]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7HNTlnF008795; Thu, 17 Aug 2006 16:29:48 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <0FA975F2D8295A448BE3ADC161244657C7A5C5@esebe199.NOE.Nokia.com> References: <0FA975F2D8295A448BE3ADC161244657C7A5C5@esebe199.NOE.Nokia.com> X-Mailer: Eudora for Mac OS X (dev alpha) X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Thu, 17 Aug 2006 16:26:29 -0700 To: , From: Randall Gellens Subject: RE: [lemonade] 'MOVE' (was 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.6 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: lemonade@ietf.org, guenther+lemonade@sendmail.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 At 12:35 PM +0300 8/17/06, wrote: > I am not worried about the protocol level - I am worried > showing a mixed mailbox to the user (where some mails are in the trash > as expected and some are not). There's a difference between where a message is on the server, and how the message is presented to the user. If clients want to present a distinct "Trash" mailbox to the user, that is fine. Forcing the metaphor to be literally true is a poor use of IMAP and causes problems. Making it easy for clients to efficiently present a Trash metaphor to users is a good thing. I assume the users don't care which elements of the protocol are used in which ways by the client. They want to manage messages in a way that feels natural for them. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- "SFPD Homicide: Our Day Begins when Yours End" --Slogan seen on back of San Francisco Police Jacket, as reported by Herb Cain in SF Chronicle _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Aug 17 19:51:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDrdy-0002jx-LY; Thu, 17 Aug 2006 19:51:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDrdx-0002jI-1c for lemonade@ietf.org; Thu, 17 Aug 2006 19:51:21 -0400 Received: from mxout1.cac.washington.edu ([140.142.32.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDrdd-0002fG-0Q for lemonade@ietf.org; Thu, 17 Aug 2006 19:51:03 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout1.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7HNp0QY021993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Aug 2006 16:51: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.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7HNoxuI017668 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 17 Aug 2006 16:50:59 -0700 Date: Thu, 17 Aug 2006 16:51:01 -0700 (Pacific Daylight Time) From: Mark Crispin To: Randall Gellens Subject: RE: [lemonade] 'MOVE' (was Notifications for multiple devices per user) In-Reply-To: Message-ID: References: <0FA975F2D8295A448BE3ADC161244657C7A5C5@esebe199.NOE.Nokia.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.17.162942 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: 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 On Thu, 17 Aug 2006, Randall Gellens wrote: > There's a difference between where a message is on the server, and how the > message is presented to the user. If clients want to present a distinct > "Trash" mailbox to the user, that is fine. Forcing the metaphor to be > literally true is a poor use of IMAP and causes problems. Making it easy for > clients to efficiently present a Trash metaphor to users is a good thing. I > assume the users don't care which elements of the protocol are used in which > ways by the client. They want to manage messages in a way that feels natural > for them. Strongly agree on all points. A Trash mailbox (in the IMAP sense, not the user experience) is an inadequate kludge to approximate the user experience of a Trash metaphor. The solution-task therefore is to come up with a method that: . makes it easy for clients to present a Trash metaphor . is not a kludge . is easy for clients and efficient . uses IMAP well . does not cause problems . interoperates well with IMAP clients that do not present a Trash metaphor. A Trash mailbox (in the IMAP sense) fails all of these criteria with the possible (and only as a kludge) exception of the first. Attempts at remediation within the context of a Trash mailbox (in the IMAP sense) will result in what we call a "kludge tower". Each subsequent kludge of the kludge tower is intended to overcome a weakness of the previous kludge. The tower is fragile and complex, and eventually collapses. I strongly feel that it is better to produce a new mechanism, designed explicitly to support the Trash metaphor within IMAP. Such a mechanism would have the following characteristics: . keeps track of which mailboxes have deleted messages; clients should not be required to scan all mailboxes. . maintain a means (perhaps through LISTEXT) to record which mailboxes are "in the Trash" without actually doing a DELETE command; and alter LIST results based upon this status. . possibly also an "empty Trash" operation, which executes the DELETE command(s) and SELECT/EXPUNGE command(s) for items in the Trash. I think, but am not certain, that this operation does not need to be atomic. There are plenty of details to work out (e.g., if a non-trash client deletes a message, is that message in the Trash? What if it's a mailbox that is not in the default tree?). But that can be discussed after we agree to undertake the effort. That effort does not belong in Lemonade; it is out of charter. It belongs in IMAPEXT, or perhaps a new WG. -- 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 Aug 18 04:54:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE07Y-00047Z-9Q; Fri, 18 Aug 2006 04:54:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE07W-00047R-RI for lemonade@ietf.org; Fri, 18 Aug 2006 04:54:26 -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 1GDzxb-0004QG-RB for lemonade@ietf.org; Fri, 18 Aug 2006 04:44:11 -0400 Received: from smarthost.yourcomms.net ([195.8.160.124]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GDzon-0004Y4-KH for lemonade@ietf.org; Fri, 18 Aug 2006 04:35:11 -0400 Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.12]) by smarthost.yourcomms.net (8.11.7p1+Sun/8.11.6) with ESMTP id k7I8MqQ02683 for ; Fri, 18 Aug 2006 09:22:52 +0100 (BST) 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, 18 Aug 2006 09:22:23 +0100 Message-ID: <22C8A0D5D5E095449AB509FE777B5F8002B1DE9D@svr-exchange.avocado.emccsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC4550 servers Thread-Index: AcbCmvrXxvasSR/gTFqXBLyGsPkTTw== From: "Ben Last" To: X-Spam-Score: -2.0 (--) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [lemonade] RFC4550 servers X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Apologies if this isn't an appropriate forum to ask this question, but does anybody have a good list of currently available/upcoming RFC4550-compliant servers? That would include those that are partially compliant. We're working on the planning for migrating our existing P-IMAP client to provide full RFC4550 support, and want to ensure we cover as many servers as possible. Even reference (non-commercial) implementations would be useful. Regards to all Ben Ben Last EMCC Software _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Aug 20 12:34:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEqFa-00067C-1U; Sun, 20 Aug 2006 12:34:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDBbd-0007SY-Qm for lemonade@ietf.org; Tue, 15 Aug 2006 22:58:09 -0400 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDBbc-0000y1-GG for lemonade@ietf.org; Tue, 15 Aug 2006 22:58:09 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M617DJ4ZSG00FDZO@mauve.mrochek.com> for lemonade@ietf.org; Tue, 15 Aug 2006 19:58:04 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1155697083; h=Date: From:Subject:MIME-version:Content-type; b=xal/ts5qo5yej1jVZMZRIho3l bUQJfcxx0oB+CRChc9OThOymjyMXIeWfol7du/n/DZP8UgDp34Ucz13B9ACKQ== Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M5ZSGYCL9S0008CX@mauve.mrochek.com>; Tue, 15 Aug 2006 19:58:01 -0700 (PDT) To: Randall Gellens Message-id: <01M617DI5OBE0008CX@mauve.mrochek.com> Date: Tue, 15 Aug 2006 19:49:55 -0700 (PDT) From: Ned Freed Subject: Re: [lemonade] Standards Process (was 'Notifications for multiple devices per user') MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <0FA975F2D8295A448BE3ADC161244657A9EA56@esebe199.NOE.Nokia.com> <01M5VD73ZFE40008CX@mauve.mrochek.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-Mailman-Approved-At: Sun, 20 Aug 2006 12:34:12 -0400 Cc: lemonade@ietf.org, mrc@CAC.Washington.EDU, Ned Freed , 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 > At 2:48 PM -0700 8/11/06, Ned Freed wrote: > > In the current discussion I cannot see how trash folder handling can be > > construed to be in scope for LEMONADE. I hereby raise a point of order asking > > for discussion of this topic be curtailed on this list. > I see benefit in looking at why so many clients use Trash mailboxes > instead of delete/expunge, and trying to document a better way to > achieve the user experience, including extensions if needed. Perhaps as a new work item in IMAPEXT. Not here. > In re-reading our charter, I can see arguments either way as to if this > is in scope here or not. I think such a reading has to be _extremely_ creative, and charters are intended to be narrowly interpreted. Expect to see far more proscriptive charters in the future if this proves not to be the case. > I think it comes down to how much the pain > of the current situation is specific to mobiles. None of the discussion I've seen so far has given any indication of this being specific to mobile devices. But feel free to prove me wrong - write a draft that explains the aspect of this issue that is of particular relevance to mobile devices. Until and unless that happens I see no point in continuing this discussion. This WG already has lots of work on its plate and this isn't helping move any of it forward. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Aug 20 12:35:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEqFa-00067M-9d; Sun, 20 Aug 2006 12:34:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDHnQ-0000qG-0A for lemonade@ietf.org; Wed, 16 Aug 2006 05:34:44 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDHnO-0002Gq-IP for lemonade@ietf.org; Wed, 16 Aug 2006 05:34:43 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id ED1AB4AD06; Wed, 16 Aug 2006 11:34:34 +0200 (CEST) Message-Id: Date: Wed, 16 Aug 2006 11:34:38 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] some questions in draft-ietf-lemonade-notifications-03 Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 1.1 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-Mailman-Approved-At: Sun, 20 Aug 2006 12:34:12 -0400 Cc: Randall Gellens , 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 writes: > At 11:10 AM +0100 8/9/06, Ben Last wrote: >> Sure, it's more complex from the OS's point of view, but that's >> hidden from the programmer. > > I think it would be a mistake to make a protocol more complex and > expensive simply because programmers can implement it by taking > advantage of existing libraries and APIs. Good programmers > understand, at least in general terms, what happens under the hood. So do bad programmers when there's a bug. Consider fixing something which can be reproduced by doing x using server y and client z . A fairly common task for the maintainers of y and z, ie. for everyone. The very first step is necessarily protocol-level analysis, so all that "hidden" complexity is uncovered right away. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Aug 20 12:35:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEqFa-00067R-Dj; Sun, 20 Aug 2006 12:34:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDrI4-0000hW-Pa for lemonade@ietf.org; Thu, 17 Aug 2006 19:28:44 -0400 Received: from rgminet01.oracle.com ([148.87.113.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDrI3-0000DV-E3 for lemonade@ietf.org; Thu, 17 Aug 2006 19:28:44 -0400 Received: from rcsmt250.oracle.com (rcsmt250.oracle.com [148.87.90.195]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k7GFAKJ8028004; Thu, 17 Aug 2006 17:28:21 -0600 Received: from dhcp-amer-csvpn-gw2-141-144-73-143.vpn.oracle.com by rcsmt251.oracle.com with ESMTP id 1753686571155857280; Thu, 17 Aug 2006 17:28:00 -0600 From: "Stephane H. Maes" To: "Randall Gellens" , "Zoltan.Ordogh@nokia.com" , "Ben.Last@emccsoft.com" , "lianggang79@huawei.com" , "lemonade@ietf.org" Subject: RE: [lemonade] LEMONADE vs. P-IMAP Date: Thu, 17 Aug 2006 16:27:53 -0700 Organization: Oracle Message-ID: <20060817162753640.00000004604@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-Whitelist: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 X-Mailman-Approved-At: Sun, 20 Aug 2006 12:34:12 -0400 Cc: 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 It should have been clear to all and was clear stated for example in the la= test published version that P-IMAP was our submission to the IETF and OMA p= rocess as well as an interim solution awaiting the standard. P-IMAp is not the object of any separate standardization activity. IETF Lem= onade and OMA MEM are where this is happening. P-IMAP 13 is pointing to Lemonade profile bis and only to P-IMAp for backwa= rd compatibility purposes. I hope it clarifies. 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: Randall Gellens [mailto:randy@qualcomm.com] = Sent: Thursday, August 17, 2006 4:17 PM To: Zoltan.Ordogh@nokia.com; Ben.Last@emccsoft.com; lianggang79@huawei.com;= lemonade@ietf.org Subject: RE: [lemonade] LEMONADE vs. P-IMAP At 10:29 AM +0300 8/16/06, wrote: > However, I was looking for a different answer. > I see confused people every day who think that P-IMAP is actually the = > LEMONADE standard. This is the reason why I asked Ben for = > clarification. I would like to end this confusion - it is not good for = > anyone(*) I believe - and this is the exact reason why I asked about = > P-IMAP (will it become standard, will it be in LEMONADE or should it = > be separate WG, etc). > Does the WG have a solid opinion on this issue at all? > The LEMONADE standard is called LEMONADE Profile and not P-IMAP, = > right? Or, maybe both? I would really appreciate if someone could = > clarify this in a way that everyone agrees to. > Thank You. The lemonade working group charter includes enhancing Internet mail submiss= ion and retrieval protocols. These enhancements are published as standards= -track RFCs after having been produced by the lemonade working group. To s= implify things, the group is also producing a document called "Lemonade Pro= file". This profile document describes how lemonade clients take advantage= of the specific extensions, and specifies a minimum set of extensions that= are supported by lemonade-compliant implementations. The profile document= references each of the specific extension (or other) documents. In this w= ay, we can speak of "IETF lemonade" and mean what is included in or referen= ced by the profile document. The first version of the profile document has been published as RFC 4550. = An updated version is being currently developed. The term "P-IMAP" has no official meaning within the lemonade working group= .= The lemonade charter is at . RFC 3440 is available at . -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Every word is like an= unnecessary stain on silence and nothingness. --Beckett _______________________________________________ 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 Sun Aug 20 12:35:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEqFa-00067M-9d; Sun, 20 Aug 2006 12:34:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDHnQ-0000qG-0A for lemonade@ietf.org; Wed, 16 Aug 2006 05:34:44 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDHnO-0002Gq-IP for lemonade@ietf.org; Wed, 16 Aug 2006 05:34:43 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id ED1AB4AD06; Wed, 16 Aug 2006 11:34:34 +0200 (CEST) Message-Id: Date: Wed, 16 Aug 2006 11:34:38 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] some questions in draft-ietf-lemonade-notifications-03 Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 1.1 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-Mailman-Approved-At: Sun, 20 Aug 2006 12:34:12 -0400 Cc: Randall Gellens , 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 writes: > At 11:10 AM +0100 8/9/06, Ben Last wrote: >> Sure, it's more complex from the OS's point of view, but that's >> hidden from the programmer. > > I think it would be a mistake to make a protocol more complex and > expensive simply because programmers can implement it by taking > advantage of existing libraries and APIs. Good programmers > understand, at least in general terms, what happens under the hood. So do bad programmers when there's a bug. Consider fixing something which can be reproduced by doing x using server y and client z . A fairly common task for the maintainers of y and z, ie. for everyone. The very first step is necessarily protocol-level analysis, so all that "hidden" complexity is uncovered right away. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Aug 20 12:35:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEqFa-00067R-Dj; Sun, 20 Aug 2006 12:34:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDrI4-0000hW-Pa for lemonade@ietf.org; Thu, 17 Aug 2006 19:28:44 -0400 Received: from rgminet01.oracle.com ([148.87.113.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDrI3-0000DV-E3 for lemonade@ietf.org; Thu, 17 Aug 2006 19:28:44 -0400 Received: from rcsmt250.oracle.com (rcsmt250.oracle.com [148.87.90.195]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k7GFAKJ8028004; Thu, 17 Aug 2006 17:28:21 -0600 Received: from dhcp-amer-csvpn-gw2-141-144-73-143.vpn.oracle.com by rcsmt251.oracle.com with ESMTP id 1753686571155857280; Thu, 17 Aug 2006 17:28:00 -0600 From: "Stephane H. Maes" To: "Randall Gellens" , "Zoltan.Ordogh@nokia.com" , "Ben.Last@emccsoft.com" , "lianggang79@huawei.com" , "lemonade@ietf.org" Subject: RE: [lemonade] LEMONADE vs. P-IMAP Date: Thu, 17 Aug 2006 16:27:53 -0700 Organization: Oracle Message-ID: <20060817162753640.00000004604@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-Whitelist: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 X-Mailman-Approved-At: Sun, 20 Aug 2006 12:34:12 -0400 Cc: 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 It should have been clear to all and was clear stated for example in the la= test published version that P-IMAP was our submission to the IETF and OMA p= rocess as well as an interim solution awaiting the standard. P-IMAp is not the object of any separate standardization activity. IETF Lem= onade and OMA MEM are where this is happening. P-IMAP 13 is pointing to Lemonade profile bis and only to P-IMAp for backwa= rd compatibility purposes. I hope it clarifies. 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: Randall Gellens [mailto:randy@qualcomm.com] = Sent: Thursday, August 17, 2006 4:17 PM To: Zoltan.Ordogh@nokia.com; Ben.Last@emccsoft.com; lianggang79@huawei.com;= lemonade@ietf.org Subject: RE: [lemonade] LEMONADE vs. P-IMAP At 10:29 AM +0300 8/16/06, wrote: > However, I was looking for a different answer. > I see confused people every day who think that P-IMAP is actually the = > LEMONADE standard. This is the reason why I asked Ben for = > clarification. I would like to end this confusion - it is not good for = > anyone(*) I believe - and this is the exact reason why I asked about = > P-IMAP (will it become standard, will it be in LEMONADE or should it = > be separate WG, etc). > Does the WG have a solid opinion on this issue at all? > The LEMONADE standard is called LEMONADE Profile and not P-IMAP, = > right? Or, maybe both? I would really appreciate if someone could = > clarify this in a way that everyone agrees to. > Thank You. The lemonade working group charter includes enhancing Internet mail submiss= ion and retrieval protocols. These enhancements are published as standards= -track RFCs after having been produced by the lemonade working group. To s= implify things, the group is also producing a document called "Lemonade Pro= file". This profile document describes how lemonade clients take advantage= of the specific extensions, and specifies a minimum set of extensions that= are supported by lemonade-compliant implementations. The profile document= references each of the specific extension (or other) documents. In this w= ay, we can speak of "IETF lemonade" and mean what is included in or referen= ced by the profile document. The first version of the profile document has been published as RFC 4550. = An updated version is being currently developed. The term "P-IMAP" has no official meaning within the lemonade working group= .= The lemonade charter is at . RFC 3440 is available at . -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Every word is like an= unnecessary stain on silence and nothingness. --Beckett _______________________________________________ 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 Sun Aug 20 12:35:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEqFa-00067H-5W; Sun, 20 Aug 2006 12:34:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDF4v-00065k-RG for lemonade@ietf.org; Wed, 16 Aug 2006 02:40:37 -0400 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDF4p-0006e8-7T for lemonade@ietf.org; Wed, 16 Aug 2006 02:40:37 -0400 Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.12]) by smarthost.yourcomms.net (8.11.7p1+Sun/8.11.6) with ESMTP id k7G6SNs24063 for ; Wed, 16 Aug 2006 07:28:23 +0100 (BST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: RE: [lemonade] Standards Process (was 'Notifications formultiple devices per user') MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Aug 2006 07:40:42 +0100 Message-ID: <22C8A0D5D5E095449AB509FE777B5F8002B1D17E@svr-exchange.avocado.emccsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Standards Process (was 'Notifications formultiple devices per user') Thread-Index: AcbA1aQaAvZy+OHcQ86dVpii3/M5VwAJ5pqA From: "Ben Last" To: "Randall Gellens" , "Ned Freed" X-Spam-Score: 0.6 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-Mailman-Approved-At: Sun, 20 Aug 2006 12:34:12 -0400 Cc: lemonade@ietf.org, mrc@CAC.Washington.EDU, 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 [mailto:randy@qualcomm.com] wrote, at 16 August 2006 02:42: >I see benefit in looking at why so many clients use Trash mailboxes instead of delete/expunge, >and trying to document a better way to achieve the user experience, including extensions if >needed. In re-reading our charter, I can see arguments either way as to if this is in scope >here or not. I think it comes down to how much the pain of the current situation is specific >to mobiles. Well, one might argue that: a) A proliferation of Trash mailboxes from other clients affects a device with a small screen more, since screen real-estate is much more limited. b) Any extra bandwidth required to deal with the fact that there are such mailboxes (including responses to LIST, extra yet unnecessary synchronizations when other clients move messages to the Trash, etc) is usually more costly on a mobile device (in terms of both battery life and real money). c) I have heard arguments that the Trash metaphor is more familiar now to more users (because it follows Outlook/Thunderbird, etc) and thus better on small screen devices where simplicity of interface is important. If one grants the above, then the discussion might fall under the charter. Regards Ben EMCC Software Ltd _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Aug 20 12:35:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEqFZ-000677-TS; Sun, 20 Aug 2006 12:34:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD898-0000lF-0h for lemonade@ietf.org; Tue, 15 Aug 2006 19:16:30 -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 1GD2BC-0008Dy-AC for lemonade@ietf.org; Tue, 15 Aug 2006 12:54:14 -0400 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GD1ux-0003CS-15 for lemonade@ietf.org; Tue, 15 Aug 2006 12:37:30 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M60LOVK6B400LS9B@mauve.mrochek.com> for lemonade@ietf.org; Tue, 15 Aug 2006 09:37:17 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1155659836; h=Date: From:Subject:MIME-version:Content-type; b=ljX44YSHISKAtZxuvxFmSRbOp TKlY5Kkoh030m4RGE9302dOO3eJQoYqv020p8WZ33+HavVeDEXgtRH/4hVv7Q== Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M5ZSGYCL9S0008CX@mauve.mrochek.com>; Tue, 15 Aug 2006 09:37:14 -0700 (PDT) To: Zoltan.Ordogh@nokia.com Message-id: <01M60LOUJRA00008CX@mauve.mrochek.com> Date: Tue, 15 Aug 2006 09:18:24 -0700 (PDT) From: Ned Freed Subject: RE: [lemonade] Standards Process (was 'Notifications for multipledevices per user') In-reply-to: "Your message dated Tue, 15 Aug 2006 13:07:21 +0300" <0FA975F2D8295A448BE3ADC161244657C1BF77@esebe199.NOE.Nokia.com> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <01M5VD73ZFE40008CX@mauve.mrochek.com> <0FA975F2D8295A448BE3ADC161244657C1BF77@esebe199.NOE.Nokia.com> X-Spam-Score: -2.6 (--) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 X-Mailman-Approved-At: Sun, 20 Aug 2006 12:34:12 -0400 Cc: randy@qualcomm.com, lemonade@ietf.org, ned.freed@mrochek.com, mrc@CAC.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 > > > That behavior is problematic for standardized protocols. Just because > > > two people agree to implement a bad idea does not make it a good idea. > > > It leads to poor interoperability as some people do it one way and > > > others do it another. > > > The two people who went off in a huff and implemented what they want > > > after their specific proposal was not accepted are guilty of the same > > > attitude they accuse the other participants of engaging in: ignoring > > > what others are saying. > > Exactly so. > I also agree with the logic presented above - but unfortunately we need > to implement what the market dictates. Excuse me, but what you need to implement is tangentially related at best to what this group is supposed to be specifying. > People do not pay for good ideas > or bad ideas - they pay for a service that they like. > Hence, I am here and complaining because implementing standardized > solution (that satisfies everyone and does not cause problems to anyone) > is preferred over working out a proprietary solution (that satisfies > only one but might cause problems for others). With all due respect, you're not the first to make these sorts of market-related arguments - I've seen similar statemetns made dozens if not hundreds of times in the past 16 years that I've been working in the IETF. However, the number of cases I've seen where the sorts of comments you are making gained any sort of traction can be counted on the fingers of one hand with some digits left over. If you want to gain traction for your ideas, I strongly recommend that you focus on items that are in scope for the group, and for those items you need to argue based on cogent technical grounds. > > There's an important caveat here: The problem has to fit > > within the charter of the group. Proposals the group is not > > chartered to consider have no business being brought up as > > potential group activities. They can of course be brought up > > as topics for a different group where the problem is in scope, > > or a character for a new group can be proposed, or the problem > > can be pursued as a individual submission. > LEMONADE=Enhancements to Internet email to support diverse service > environments Not hardly. LEMONADE = the items we're chartered to do and nothing more. The charter is here: http://www.ietf.org/html.charters/lemonade-charter.html I suggest you read it carefully. > To me this looks just the right place for such improvements. Which part > of those suggested improvements does not fit into the picture? Whether or not it fits into the picture painted by the WG title is largely irrelevant. Working group titles are necessarily general in nature - a title running into hundreds of words would be (obviously) unmanageable. This why we have charters: They specify fairly precisely what the group is supposed to be working on, and by omission, what the group is NOT supposed to be doing. To pick another example, the amount of stuff that could fall under the title "Open Pluggable Edge Services" is vast, but if you look at the OPES WG charter you will see that they are currently focusing on a very specific subset of the edge service problem as it pertains to SMTP. This is how things work in the IETF. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Aug 20 12:56:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEqbK-0004dL-0j; Sun, 20 Aug 2006 12:56:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEqbJ-0004dC-B9 for lemonade@ietf.org; Sun, 20 Aug 2006 12:56:41 -0400 Received: from outbound.cantata.com ([208.236.123.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEqN6-00077e-9G for lemonade@ietf.org; Sun, 20 Aug 2006 12:42:01 -0400 Received: from ma02exchtmp01.Cantata.com ([10.128.18.41]) by outbound.Cantata.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 20 Aug 2006 12:42:17 -0400 Received: from 10.128.41.1 ([10.128.41.1]) by ma02exchtmp01.Cantata.com ([10.128.18.41]) with Microsoft Exchange Server HTTP-DAV ; Sun, 20 Aug 2006 16:42:16 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Sun, 20 Aug 2006 12:41:52 -0400 From: Eric Burger To: IETF LEMONADE Message-ID: Thread-Topic: Too Many Recipients Thread-Index: AcbEd4ngyK4Q5DBqEdu1EAAWy5cvmw== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Aug 2006 16:42:17.0307 (UTC) FILETIME=[98F652B0:01C6C477] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [lemonade] Too Many Recipients X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 you may have figured out from my less-than-ideal MUA, I've been away for a week. I will be commenting on the substance of some of the discussions that have been going on in my absence. However, I did want to raise one issue. There were a number of messages held in the spam bucket that the spam system held because the message had too many recipients. PLEASE, if you do a Reply-All in your MUA, try to prune the address list to those you REALLY want to get the message in their inbox. If A replies to B who replies to C, when D replies, we end up with a To: list with A, B, C, D, and lemonade (if not other lists, too). If you are D, replying with a comment directed at C, remember to trim off A and B. They are list subscribers, so they will see the message! Thanks. -- Humble Chair and List Lackey, Eric _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Aug 20 13:59:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GErZi-000743-6B; Sun, 20 Aug 2006 13:59:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GErZg-00073y-Tt for lemonade@ietf.org; Sun, 20 Aug 2006 13:59:04 -0400 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GErZf-0007m0-K8 for lemonade@ietf.org; Sun, 20 Aug 2006 13:59:04 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M67O0W64K000KTSG@mauve.mrochek.com> for lemonade@ietf.org; Sun, 20 Aug 2006 10:58:59 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1156096739; h=Date: From:Subject:MIME-version:Content-type; b=opWu3SxuypYl6NKhjD+eWJu7C Lq8Kb3lsmqgYzvMybEh8/c7ccE6wcFHdpPQ0pd5tLBWUS0+HnxUwYIp2UfgGQ== Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M65IB58TWW0008CX@mauve.mrochek.com>; Sun, 20 Aug 2006 10:58:57 -0700 (PDT) To: Eric Burger Message-id: <01M67O0V0MK40008CX@mauve.mrochek.com> Date: Sun, 20 Aug 2006 10:57:42 -0700 (PDT) From: Ned Freed Subject: Re: [lemonade] Too Many Recipients In-reply-to: "Your message dated Sun, 20 Aug 2006 12:41:52 -0400" MIME-version: 1.0 Content-type: TEXT/PLAIN References: X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: IETF LEMONADE X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 you may have figured out from my less-than-ideal MUA, I've been away for > a week. > I will be commenting on the substance of some of the discussions that have > been going on in my absence. However, I did want to raise one issue. There > were a number of messages held in the spam bucket that the spam system held > because the message had too many recipients. > PLEASE, if you do a Reply-All in your MUA, try to prune the address list to > those you REALLY want to get the message in their inbox. If A replies to B > who replies to C, when D replies, we end up with a To: list with A, B, C, D, > and lemonade (if not other lists, too). If you are D, replying with a > comment directed at C, remember to trim off A and B. They are list > subscribers, so they will see the message! How about we fix the mailing list software to behave competently instead? This sort of recipient limit restriction is an exceptionally poor choice of filtering mechanism. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Aug 20 14:17:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GErrb-0004qP-Ga; Sun, 20 Aug 2006 14:17:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GErrZ-0004pN-8G for lemonade@ietf.org; Sun, 20 Aug 2006 14:17:33 -0400 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GErkr-0001Fl-76 for lemonade@ietf.org; Sun, 20 Aug 2006 14:10:38 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M67OF91FJK00K3OD@mauve.mrochek.com> for lemonade@ietf.org; Sun, 20 Aug 2006 11:10:34 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1156097433; h=Date: From:Subject:MIME-version:Content-type; b=kw2DoNND0FjUFAWr1p5VpjUfQ m/05gExUPvaZXlkWEFL8enDxxZK9lfhY/hO/+xE9c5bDAAVqdob9rcHppdq9w== Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M65IB58TWW0008CX@mauve.mrochek.com> for lemonade@ietf.org; Sun, 20 Aug 2006 11:10:31 -0700 (PDT) To: lemonade@ietf.org Message-id: <01M67OF81I5W0008CX@mauve.mrochek.com> Date: Sun, 20 Aug 2006 11:00:17 -0700 (PDT) From: Ned Freed Subject: Re: [lemonade] some questions in draft-ietf-lemonade-notifications-03 In-reply-to: "Your message dated Wed, 16 Aug 2006 11:34:38 +0200" MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: X-Spam-Score: 1.2 (+) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 11:10 AM +0100 8/9/06, Ben Last wrote: > >> Sure, it's more complex from the OS's point of view, but that's > >> hidden from the programmer. > > > > I think it would be a mistake to make a protocol more complex and > > expensive simply because programmers can implement it by taking > > advantage of existing libraries and APIs. Good programmers > > understand, at least in general terms, what happens under the hood. Another problem IMO is that it is quite rare for those "existing libraries and APIs" to actually exist on all platforms of interest. And this is especially true here, where we're supposed to be dealing with an even wider range of devices than is perhaps the norm. Let's please not forget the "diverse service endpoints" phrase that appears in the title of this group. Mind you, this doesn't mean we should attempt to cater to the vagarities of devices that fail to either implement or provide access to basic lower layer services like TCP, at least not in our standards-track work. There has to be a nontrivial lowest common denominator in there somewhere. > So do bad programmers when there's a bug. Consider fixing something > which can be reproduced by doing x using server y and client z . A > fairly common task for the maintainers of y and z, ie. for everyone. > The very first step is necessarily protocol-level analysis, so all that > "hidden" complexity is uncovered right away. Quite true. And when the problem actually turns out to be in one of those libraries (as it does all too often) gettting it fixed can be a major undertaking. Indeed, the situation in regards to library dependencies has gotten so bad in some quarters I often hope for the issue to be in my own code, because at least that way I can find and fix it. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Aug 20 14:17:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GErrs-0004xy-6I; Sun, 20 Aug 2006 14:17:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GErrq-0004xh-Io for lemonade@ietf.org; Sun, 20 Aug 2006 14:17:50 -0400 Received: from mxout5.cac.washington.edu ([140.142.32.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GErcx-00007S-Ue for lemonade@ietf.org; Sun, 20 Aug 2006 14:02:32 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7KI2Qjl005810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 20 Aug 2006 11:02:27 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7KI2PDq016722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 20 Aug 2006 11:02:26 -0700 Date: Sun, 20 Aug 2006 11:02:25 -0700 (PDT) From: Mark Crispin To: Ned Freed Subject: Re: [lemonade] Too Many Recipients In-Reply-To: <01M67O0V0MK40008CX@mauve.mrochek.com> Message-ID: References: <01M67O0V0MK40008CX@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.20.104443 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: IETF LEMONADE X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 On Sun, 20 Aug 2006, Ned Freed wrote: > How about we fix the mailing list software to behave competently instead? > This sort of recipient limit restriction is an exceptionally poor choice > of filtering mechanism. -- 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 Sun Aug 20 15:46:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEtFP-0000dO-7n; Sun, 20 Aug 2006 15:46:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEtFO-0000dJ-5r for lemonade@ietf.org; Sun, 20 Aug 2006 15:46:14 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEtFM-0003QT-PH for lemonade@ietf.org; Sun, 20 Aug 2006 15:46:14 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id A8D974ADB9 for ; Sun, 20 Aug 2006 21:45:59 +0200 (CEST) Message-Id: Date: Sun, 20 Aug 2006 21:46:00 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Too Many Recipients References: In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 will be commenting on the substance of some of the discussions that > have been going on in my absence. However, I did want to raise one > issue. There were a number of messages held in the spam bucket that > the spam system held because the message had too many recipients. Hi Eric, so far, how many of the messages with 5-10 recipients have been spam? 11-50? 50 or more? Depending on the answers, I suggest raising the limit to 10, 50 or infinity. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Aug 20 16:27:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEtrp-0004zC-Hs; Sun, 20 Aug 2006 16:25:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEtro-0004wq-53 for lemonade@ietf.org; Sun, 20 Aug 2006 16:25:56 -0400 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEtes-0000aA-HR for lemonade@ietf.org; Sun, 20 Aug 2006 16:12:35 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M67SOG2I0G00LI9S@mauve.mrochek.com> for lemonade@ietf.org; Sun, 20 Aug 2006 13:12:32 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1156104750; h=Date: From:Subject:MIME-version:Content-type; b=UsHGv4dRERgfJavUOsdRIXHal m3L4ybY2epfasTx6X02BqHrNlPTMegCD2j5AmGXDaudMYessqHQjtWK0v00PQ== Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M65IB58TWW0008CX@mauve.mrochek.com> for lemonade@ietf.org; Sun, 20 Aug 2006 13:12:26 -0700 (PDT) To: lemonade@ietf.org Message-id: <01M67SODRIR60008CX@mauve.mrochek.com> Date: Sun, 20 Aug 2006 13:02:10 -0700 (PDT) From: Ned Freed Subject: Re: [lemonade] Too Many Recipients In-reply-to: "Your message dated Sun, 20 Aug 2006 21:46:00 +0200" MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 will be commenting on the substance of some of the discussions that > > have been going on in my absence. However, I did want to raise one > > issue. There were a number of messages held in the spam bucket that > > the spam system held because the message had too many recipients. > Hi Eric, > so far, how many of the messages with 5-10 recipients have been spam? > 11-50? 50 or more? I don't see how this is relevant. The relevant question is whether or not there's a significant amount of spam that is only caught because the number of recipients limit was exceeded. The limit only makes sense if this number (which may or may not be measurable in a given setup) is nonnegligable, and given the annoyance factor quite possibly not even then. I run several IETF lists, and the vast majority of the very large number of spam messages these lists receive only have a single recipient address in the message headers. If anything the presence of small number of additional recippients seems correlated with non-spam, not spam. I don't implement a number of recipients limit, and (a) The number of spams that make it through to the list is quite small and (b) Those that do are not ones loaded with additional recipient addresses. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Aug 20 17:08:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEuWg-0001Ul-Br; Sun, 20 Aug 2006 17:08:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEuWe-0001Ug-MH for lemonade@ietf.org; Sun, 20 Aug 2006 17:08:08 -0400 Received: from outbound.cantata.com ([208.236.123.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEuWd-00083q-Fd for lemonade@ietf.org; Sun, 20 Aug 2006 17:08:08 -0400 Received: from ma02exchtmp01.Cantata.com ([10.128.18.41]) by outbound.Cantata.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 20 Aug 2006 17:08:25 -0400 Received: from 10.128.41.1 ([10.128.41.1]) by ma02exchtmp01.Cantata.com ([10.128.18.41]) with Microsoft Exchange Server HTTP-DAV ; Sun, 20 Aug 2006 21:08:23 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Sun, 20 Aug 2006 16:29:03 -0400 From: Eric Burger To: IETF LEMONADE Message-ID: Thread-Topic: WGLC IMAP4 Extensions for Quick Mailbox Resynchronization Thread-Index: AcbEl0aWhWC/nDCKEduxFQAWy5cvmw== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Aug 2006 21:08:25.0301 (UTC) FILETIME=[C6A0D850:01C6C49C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [lemonade] WGLC IMAP4 Extensions for Quick Mailbox Resynchronization X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 serves as notice of the start of the Work Group Last Call for "IMAP4 Extensions for Quick Mailbox Resynchronization", found at: WGLC will close on 5 September 2006. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Aug 20 17:08:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEuWa-0001UT-7E; Sun, 20 Aug 2006 17:08:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEuWZ-0001UO-BH for lemonade@ietf.org; Sun, 20 Aug 2006 17:08:03 -0400 Received: from outbound.cantata.com ([208.236.123.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEuWY-00083j-5K for lemonade@ietf.org; Sun, 20 Aug 2006 17:08:03 -0400 Received: from ma02exchtmp01.Cantata.com ([10.128.18.41]) by outbound.Cantata.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 20 Aug 2006 17:08:19 -0400 Received: from 10.128.41.1 ([10.128.41.1]) by ma02exchtmp01.Cantata.com ([10.128.18.41]) with Microsoft Exchange Server HTTP-DAV ; Sun, 20 Aug 2006 21:08:18 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Sun, 20 Aug 2006 16:15:20 -0400 From: Eric Burger To: IETF LEMONADE Message-ID: Thread-Topic: Scheduling for IETF 67 Thread-Index: AcbElVwKmlHq6jCIEduxFQAWy5cvmw== X-Priority: 1 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Aug 2006 21:08:19.0832 (UTC) FILETIME=[C35E5780:01C6C49C] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [lemonade] Scheduling for IETF 67 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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, work groups you would NOT want to see conflict with lemonade? For example, at IETF 66, Alexey had a conflict with SASL which neither of the chairs felt until it was too late. Due to another commitment, I will be going Solo at IETF 67. Glenn will be in Europe during IETF 67. Because of time zones, I will be requesting early morning slots. Please get back to me ASAP, as I plan on submitting our initial request this upcoming Friday. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Aug 20 17:47:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEv8L-0005se-GB; Sun, 20 Aug 2006 17:47:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEv8K-0005sZ-NE for lemonade@ietf.org; Sun, 20 Aug 2006 17:47:04 -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 1GEsZw-0003OQ-BF for lemonade@ietf.org; Sun, 20 Aug 2006 15:03:24 -0400 Received: from mxout4.cac.washington.edu ([140.142.33.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GEsPn-0003SW-FF for lemonade@ietf.org; Sun, 20 Aug 2006 14:52:56 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout4.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7KIqq5b028349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 20 Aug 2006 11:52:52 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7KIqp5u004928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 20 Aug 2006 11:52:51 -0700 Date: Sun, 20 Aug 2006 11:52:50 -0700 (PDT) From: Mark Crispin To: Ned Freed Subject: Re: [lemonade] some questions in draft-ietf-lemonade-notifications-03 In-Reply-To: <01M67OF81I5W0008CX@mauve.mrochek.com> Message-ID: References: <01M67OF81I5W0008CX@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.20.112943 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: -1.9 (-) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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 Sun, 20 Aug 2006, Ned Freed wrote: > Another problem IMO is that it is quite rare for those "existing > libraries and APIs" to actually exist on all platforms of interest. And > this is especially true here, where we're supposed to be dealing with an > even wider range of devices than is perhaps the norm. Indeed. It is singularly unhelpful to tell someone to use an API that is unobtainable on that person's platform. In fact, I would go so far as to propose an IETF BCP that protocol specifications MUST NOT be defined to use any API unless the proponent commits to provide, and support, an implementation of that API free of charge for all platforms; and to post a security bond sufficient to fund such provision and support should the proponent become unable to fufill this responsibility. If someone were to say "no problem", then I have a couple of TOPS-20 systems that need provisioning... ;-) Hey, it's got a C compiler. ;-) > Quite true. And when the problem actually turns out to be in one of > those libraries (as it does all too often) gettting it fixed can be a > major undertaking. Indeed, the situation in regards to library > dependencies has gotten so bad in some quarters I often hope for the > issue to be in my own code, because at least that way I can find and fix > it. True story: The UW IMAP and POP3 servers were broken by the GSSAPI in krb5-1.5. It keels over deep in the internals of GSSAPI with an assertion failure. It's their bug, they've fixed it in 1.5.1, and in all fairness they were fairly quick in saying "mea culpa" and getting a fix out. Nonetheless... It happened while I was on a one-month vacation. I got egg on my face for something that was not my fault, and had nothing to do with. Why didn't my "buggy" code properly initialize GSSAPI, etc. [Because there is no "initialize GSSAPI", that's why! And by the way, that thing that wasn't initialized was creeping featurism in GSSAPI that is completely orthogonal to the purpose of GSSAPI and Kerberos!!] I did what I could. I put out a posting on the UW IMAP user list warning people about upgrading to krb5-1.5, suggesting that they wait until krb5-1.5.1, and providing the patch to krb-1.5 that fixes the problem. Above all else, (thankfully!) krb5-1.5 is new enough that most people do not run it and hopefully never will since 1.5.1 is coming. Still, I expect some more incoming eggs before it blows over. APIs can be a very good and useful thing. I wrote (and use) the c-client API. UW imapd uses c-client along with the GSSAPI and OpenSSL APIs. Pine adds two APIs (pico and pith) of its own, and uses some others (such as LDAP). So I'm not anti-API. However, I am VERY cautious when adding new APIs to the mix. Even with your own APIs, you stand the risk of a cascading regression. External APIs are a much greater risk. I'm even more cautious when adding APIs to a protocol specification. The SASL profile for Kerberos 5 is defined by GSSAPI. This may be a good thing in some ways, but in other ways it's quite a problem. -- 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 Sun Aug 20 21:54:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEyzC-0007N6-S6; Sun, 20 Aug 2006 21:53:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEyzB-0007Ml-IB for lemonade@ietf.org; Sun, 20 Aug 2006 21:53:53 -0400 Received: from rgminet01.oracle.com ([148.87.113.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEyz9-0006TU-5H for lemonade@ietf.org; Sun, 20 Aug 2006 21:53:53 -0400 Received: from rcsmt250.oracle.com (rcsmt250.oracle.com [148.87.90.195]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k7KCpmqK020708 for ; Sun, 20 Aug 2006 19:53:43 -0600 Received: from dhcp-apac-jp-csvpn-gw9-141-144-144-251.vpn.oracle.com by rcsmt250.oracle.com with ESMTP id 1759538581156125159; Sun, 20 Aug 2006 19:52:39 -0600 From: "Stephane H. Maes" To: "lemonade@ietf.org" Subject: RE: [lemonade] LEMONADE vs. P-IMAP Date: Sun, 20 Aug 2006 18:52:29 -0700 Organization: Oracle Message-ID: <20060820185229187.00000005420@smaes-lap3> In-Reply-To: <893AE265F4ADF94AB7FB26D31A788E410283436F@mvebe101.NOE.Nokia.com> 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-Whitelist: TRUE X-Spam-Score: 0.5 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d 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 Are you saying something different? I think that's what I said... 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: Dorothy.Gellert@nokia.com [mailto:Dorothy.Gellert@nokia.com] = Sent: Sunday, August 20, 2006 6:49 PM To: stephane.maes@oracle.com; randy@qualcomm.com; Zoltan.Ordogh@nokia.com; = Ben.Last@emccsoft.com; lianggang79@huawei.com; lemonade@ietf.org Subject: RE: [lemonade] LEMONADE vs. P-IMAP OMA is standardizing on the Lemonade profile bis, not P-IMAP. We leave it to the IETF Lemonade WG to decide on what goes into that profile. = -Dorothy = -----Original Message----- From: ext Stephane H. Maes [mailto:stephane.maes@oracle.com] Sent: Thursday, August 17, 2006 4:28 PM To: Randall Gellens; Ordogh Zoltan (Nokia-TP-MSW/Tampere); Ben.Last@emccsof= t.com; lianggang79@huawei.com; lemonade@ietf.org Subject: RE: [lemonade] LEMONADE vs. P-IMAP It should have been clear to all and was clear stated for example in the la= test published version that P-IMAP was our submission to the IETF and OMA p= rocess as well as an interim solution awaiting the standard. P-IMAp is not the object of any separate standardization activity. IETF Lem= onade and OMA MEM are where this is happening. P-IMAP 13 is pointing to Lemonade profile bis and only to P-IMAp for backwa= rd compatibility purposes. I hope it clarifies. 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: Randall Gellens [mailto:randy@qualcomm.com] Sent: Thursday, August 17, 2006 4:17 PM To: Zoltan.Ordogh@nokia.com; Ben.Last@emccsoft.com; lianggang79@huawei.com;= lemonade@ietf.org Subject: RE: [lemonade] LEMONADE vs. P-IMAP At 10:29 AM +0300 8/16/06, wrote: > However, I was looking for a different answer. > I see confused people every day who think that P-IMAP is actually the > LEMONADE standard. This is the reason why I asked Ben for = > clarification. I would like to end this confusion - it is not good for > anyone(*) I believe - and this is the exact reason why I asked about = > P-IMAP (will it become standard, will it be in LEMONADE or should it = > be separate WG, etc). > Does the WG have a solid opinion on this issue at all? > The LEMONADE standard is called LEMONADE Profile and not P-IMAP, = > right? Or, maybe both? I would really appreciate if someone could = > clarify this in a way that everyone agrees to. > Thank You. The lemonade working group charter includes enhancing Internet mail submiss= ion and retrieval protocols. These enhancements are published as standards= -track RFCs after having been produced by the lemonade working group. To s= implify things, the group is also producing a document called "Lemonade Pro= file". This profile document describes how lemonade clients take advantage= of the specific extensions, and specifies a minimum set of extensions that= are supported by lemonade-compliant implementations. The profile document= references each of the specific extension (or other) documents. In this w= ay, we can speak of "IETF lemonade" and mean what is included in or referen= ced by the profile document. The first version of the profile document has been published as RFC 4550. = An updated version is being currently developed. The term "P-IMAP" has no official meaning within the lemonade working group= .= The lemonade charter is at . RFC 3440 is available at . -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Every word is like an= unnecessary stain on silence and nothingness. --Beckett _______________________________________________ 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 Sun Aug 20 22:18:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEzNQ-0007Fs-4L; Sun, 20 Aug 2006 22:18:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEzNP-0007ED-E4 for lemonade@ietf.org; Sun, 20 Aug 2006 22:18:55 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEzNO-00019a-Pv for lemonade@ietf.org; Sun, 20 Aug 2006 22:18:55 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.7) with ESMTP id k7L1Isxl031882 for ; Mon, 21 Aug 2006 04:18:55 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Aug 2006 05:18:53 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 20 Aug 2006 21:18:51 -0500 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: FW: [lemonade] LEMONADE vs. P-IMAP Date: Sun, 20 Aug 2006 19:18:48 -0700 Message-ID: <893AE265F4ADF94AB7FB26D31A788E4102834379@mvebe101.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] LEMONADE vs. P-IMAP Thread-Index: AcbExVqCpaa+TROBS9KGtZhFdJ/4GwAAjWxQAAAfTvA= From: To: X-OriginalArrivalTime: 21 Aug 2006 02:18:51.0433 (UTC) FILETIME=[24AB0990:01C6C4C8] X-Spam-Score: 0.2 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Sorry, forgot to copy the group...! -Dorothy -----Original Message----- From: Gellert Dorothy (Nokia-ES/MtView)=20 Sent: Sunday, August 20, 2006 7:18 PM To: 'stephane.maes@oracle.com' Subject: RE: [lemonade] LEMONADE vs. P-IMAP Maybe not, but what the P-IMAP draft points to is not relevant to OMA... It just confuses matters. From an OMA perspective we look at Lemonade profile bis only. What is in there is relevant to OMA. -Dorothy =20 -----Original Message----- From: ext Stephane H. Maes [mailto:stephane.maes@oracle.com] Sent: Sunday, August 20, 2006 6:52 PM To: lemonade@ietf.org Subject: RE: [lemonade] LEMONADE vs. P-IMAP Are you saying something different? I think that's what I said... 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: Dorothy.Gellert@nokia.com [mailto:Dorothy.Gellert@nokia.com] Sent: Sunday, August 20, 2006 6:49 PM To: stephane.maes@oracle.com; randy@qualcomm.com; Zoltan.Ordogh@nokia.com; Ben.Last@emccsoft.com; lianggang79@huawei.com; lemonade@ietf.org Subject: RE: [lemonade] LEMONADE vs. P-IMAP OMA is standardizing on the Lemonade profile bis, not P-IMAP. We leave it to the IETF Lemonade WG to decide on what goes into that profile. =20 -Dorothy =20 -----Original Message----- From: ext Stephane H. Maes [mailto:stephane.maes@oracle.com] Sent: Thursday, August 17, 2006 4:28 PM To: Randall Gellens; Ordogh Zoltan (Nokia-TP-MSW/Tampere); Ben.Last@emccsoft.com; lianggang79@huawei.com; lemonade@ietf.org Subject: RE: [lemonade] LEMONADE vs. P-IMAP It should have been clear to all and was clear stated for example in the latest published version that P-IMAP was our submission to the IETF and OMA process as well as an interim solution awaiting the standard. P-IMAp is not the object of any separate standardization activity. IETF Lemonade and OMA MEM are where this is happening. P-IMAP 13 is pointing to Lemonade profile bis and only to P-IMAp for backward compatibility purposes. I hope it clarifies. 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: Randall Gellens [mailto:randy@qualcomm.com] Sent: Thursday, August 17, 2006 4:17 PM To: Zoltan.Ordogh@nokia.com; Ben.Last@emccsoft.com; lianggang79@huawei.com; lemonade@ietf.org Subject: RE: [lemonade] LEMONADE vs. P-IMAP At 10:29 AM +0300 8/16/06, wrote: > However, I was looking for a different answer. > I see confused people every day who think that P-IMAP is actually the > LEMONADE standard. This is the reason why I asked Ben for=20 > clarification. I would like to end this confusion - it is not good for > anyone(*) I believe - and this is the exact reason why I asked about=20 > P-IMAP (will it become standard, will it be in LEMONADE or should it=20 > be separate WG, etc). > Does the WG have a solid opinion on this issue at all? > The LEMONADE standard is called LEMONADE Profile and not P-IMAP,=20 > right? Or, maybe both? I would really appreciate if someone could=20 > clarify this in a way that everyone agrees to. > Thank You. The lemonade working group charter includes enhancing Internet mail submission and retrieval protocols. These enhancements are published as standards-track RFCs after having been produced by the lemonade working group. To simplify things, the group is also producing a document called "Lemonade Profile". This profile document describes how lemonade clients take advantage of the specific extensions, and specifies a minimum set of extensions that are supported by lemonade-compliant implementations. The profile document references each of the specific extension (or other) documents. In this way, we can speak of "IETF lemonade" and mean what is included in or referenced by the profile document. The first version of the profile document has been published as RFC 4550. An updated version is being currently developed. The term "P-IMAP" has no official meaning within the lemonade working group. The lemonade charter is at . RFC 3440 is available at . -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Every word is like an unnecessary stain on silence and nothingness. --Beckett _______________________________________________ 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 Mon Aug 21 10:02:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFAMW-0000BU-RH; Mon, 21 Aug 2006 10:02:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEyvB-0005yA-D8 for lemonade@ietf.org; Sun, 20 Aug 2006 21:49:45 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEyv9-0005yk-SO for lemonade@ietf.org; Sun, 20 Aug 2006 21:49:45 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.7) with ESMTP id k7L1nSIL029700; Mon, 21 Aug 2006 04:49:33 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Aug 2006 04:49:28 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 20 Aug 2006 20:49:26 -0500 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] LEMONADE vs. P-IMAP Date: Sun, 20 Aug 2006 18:49:23 -0700 Message-ID: <893AE265F4ADF94AB7FB26D31A788E410283436F@mvebe101.NOE.Nokia.com> In-Reply-To: <20060817162753640.00000004604@smaes-lap3> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] LEMONADE vs. P-IMAP Thread-Index: AcbEeZe/Fo8BPZFZQMKrff7ldnrepAASiPgA From: To: , , , , , X-OriginalArrivalTime: 21 Aug 2006 01:49:26.0179 (UTC) FILETIME=[087EA730:01C6C4C4] X-Spam-Score: 0.2 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b X-Mailman-Approved-At: Mon, 21 Aug 2006 10:02:42 -0400 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 OMA is standardizing on the Lemonade profile bis, not P-IMAP. We leave it to the IETF Lemonade WG to decide on what goes into that profile. =20 -Dorothy =20 -----Original Message----- From: ext Stephane H. Maes [mailto:stephane.maes@oracle.com]=20 Sent: Thursday, August 17, 2006 4:28 PM To: Randall Gellens; Ordogh Zoltan (Nokia-TP-MSW/Tampere); Ben.Last@emccsoft.com; lianggang79@huawei.com; lemonade@ietf.org Subject: RE: [lemonade] LEMONADE vs. P-IMAP It should have been clear to all and was clear stated for example in the latest published version that P-IMAP was our submission to the IETF and OMA process as well as an interim solution awaiting the standard. P-IMAp is not the object of any separate standardization activity. IETF Lemonade and OMA MEM are where this is happening. P-IMAP 13 is pointing to Lemonade profile bis and only to P-IMAp for backward compatibility purposes. I hope it clarifies. 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: Randall Gellens [mailto:randy@qualcomm.com] Sent: Thursday, August 17, 2006 4:17 PM To: Zoltan.Ordogh@nokia.com; Ben.Last@emccsoft.com; lianggang79@huawei.com; lemonade@ietf.org Subject: RE: [lemonade] LEMONADE vs. P-IMAP At 10:29 AM +0300 8/16/06, wrote: > However, I was looking for a different answer. > I see confused people every day who think that P-IMAP is actually the > LEMONADE standard. This is the reason why I asked Ben for=20 > clarification. I would like to end this confusion - it is not good for > anyone(*) I believe - and this is the exact reason why I asked about=20 > P-IMAP (will it become standard, will it be in LEMONADE or should it=20 > be separate WG, etc). > Does the WG have a solid opinion on this issue at all? > The LEMONADE standard is called LEMONADE Profile and not P-IMAP,=20 > right? Or, maybe both? I would really appreciate if someone could=20 > clarify this in a way that everyone agrees to. > Thank You. The lemonade working group charter includes enhancing Internet mail submission and retrieval protocols. These enhancements are published as standards-track RFCs after having been produced by the lemonade working group. To simplify things, the group is also producing a document called "Lemonade Profile". This profile document describes how lemonade clients take advantage of the specific extensions, and specifies a minimum set of extensions that are supported by lemonade-compliant implementations. The profile document references each of the specific extension (or other) documents. In this way, we can speak of "IETF lemonade" and mean what is included in or referenced by the profile document. The first version of the profile document has been published as RFC 4550. An updated version is being currently developed. The term "P-IMAP" has no official meaning within the lemonade working group. The lemonade charter is at . RFC 3440 is available at . -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Every word is like an unnecessary stain on silence and nothingness. --Beckett _______________________________________________ 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 Mon Aug 21 15:47:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFFjz-00006v-2d; Mon, 21 Aug 2006 15:47:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFFjy-00006B-6z for lemonade@ietf.org; Mon, 21 Aug 2006 15:47:18 -0400 Received: from outbound.cantata.com ([208.236.123.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFFjt-00006z-S8 for lemonade@ietf.org; Mon, 21 Aug 2006 15:47:18 -0400 Received: from ma02exchtmp01.Cantata.com ([10.128.18.41]) by outbound.Cantata.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Aug 2006 15:47:29 -0400 Received: from 10.128.41.3 ([10.128.41.3]) by ma02exchtmp01.Cantata.com ([10.128.18.41]) with Microsoft Exchange Server HTTP-DAV ; Mon, 21 Aug 2006 19:47:28 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Mon, 21 Aug 2006 15:43:37 -0400 Subject: Re: [lemonade] RFC4550 servers From: Eric Burger To: Ben Last , IETF LEMONADE Message-ID: Thread-Topic: [lemonade] RFC4550 servers Thread-Index: AcbCmvrXxvasSR/gTFqXBLyGsPkTTwCvx1WL In-Reply-To: <22C8A0D5D5E095449AB509FE777B5F8002B1DE9D@svr-exchange.avocado.emccsoft.com> Mime-version: 1.0 X-OriginalArrivalTime: 21 Aug 2006 19:47:29.0042 (UTC) FILETIME=[A27C4720:01C6C55A] X-Spam-Score: 0.1 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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: , Content-Type: multipart/mixed; boundary="===============1410419222==" Errors-To: lemonade-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1410419222== Content-type: multipart/alternative; boundary="B_3239020021_4838509" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3239020021_4838509 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Check out the supplemental web site: and the Lemonade for Mobiles web site: On 8/18/06 4:22 AM, "Ben Last" wrote: > Apologies if this isn't an appropriate forum to ask this question, but > does anybody have a good list of currently available/upcoming > RFC4550-compliant servers? That would include those that are partially > compliant. We're working on the planning for migrating our existing > P-IMAP client to provide full RFC4550 support, and want to ensure we > cover as many servers as possible. > > Even reference (non-commercial) implementations would be useful. > > Regards to all > Ben > > Ben Last > EMCC Software > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade > --B_3239020021_4838509 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [lemonade] RFC4550 servers Check= out the supplemental web site:
<= ;http://flyingfox.cantata.com/i-d/lemonade/Lemonade-Plans.html>

and the Lemonade for Mobiles web site:
<http://www.= lemonadeformobiles.com/supporters.html>



On 8/18/06 4:22 AM, "Ben Last" <Ben.Last@emccsoft.com> wrot= e:

Apologies if this isn't an appropriate forum to ask thi= s question, but
does anybody have a good list of currently available/upcoming
RFC4550-compliant servers?  That would include those that are partiall= y
compliant.  We're working on the planning for migrating our existing P-IMAP client to provide full RFC4550 support, and want to ensure we
cover as many servers as possible.

Even reference (non-commercial) implementations would be useful.

Regards to all
Ben

Ben Last
EMCC Software

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade


 --B_3239020021_4838509-- --===============1410419222== 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 --===============1410419222==-- From lemonade-bounces@ietf.org Mon Aug 21 15:47:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFFjs-00005C-Ph; Mon, 21 Aug 2006 15:47:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFFjs-000057-B1 for lemonade@ietf.org; Mon, 21 Aug 2006 15:47:12 -0400 Received: from outbound.cantata.com ([208.236.123.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFFjr-00006z-4i for lemonade@ietf.org; Mon, 21 Aug 2006 15:47:12 -0400 Received: from ma02exchtmp01.Cantata.com ([10.128.18.41]) by outbound.Cantata.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Aug 2006 15:47:26 -0400 Received: from 10.128.41.3 ([10.128.41.3]) by ma02exchtmp01.Cantata.com ([10.128.18.41]) with Microsoft Exchange Server HTTP-DAV ; Mon, 21 Aug 2006 19:47:25 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Mon, 21 Aug 2006 15:00:41 -0400 From: Eric Burger To: IETF LEMONADE Message-ID: Thread-Topic: Chairs Decisions Thread-Index: AcbFVBjDVyU8fjFHEduxFQAWy5cvmw== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 21 Aug 2006 19:47:26.0120 (UTC) FILETIME=[A0BE6A80:01C6C55A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [lemonade] Chairs Decisions X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Sometimes being away for a week lets all sides weigh in. I personally have had the luxury of reading all of the arguments for a number of controversial proposals all at one sitting. Shortly you will see a number of messages presenting the Chairs' decisions as to whether the lemonade work group, as a work group, will pursue work on various proposed extensions to IMAP. The chairs really appreciate all of the good discussion that has been on the list recently. We are at some of our highest volumes ever. I am also very happy that wFrom lemonade-bounces@ietf.org Mon Aug 21 15:47:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFFjz-00006v-2d; Mon, 21 Aug 2006 15:47:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFFjy-00006B-6z for lemonade@ietf.org; Mon, 21 Aug 2006 15:47:18 -0400 Received: from outbound.cantata.com ([208.236.123.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFFjt-00006z-S8 for lemonade@ietf.org; Mon, 21 Aug 2006 15:47:18 -0400 Received: from ma02exchtmp01.Cantata.com ([10.128.18.41]) by outbound.Cantata.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Aug 2006 15:47:29 -0400 Received: from 10.128.41.3 ([10.128.41.3]) by ma02exchtmp01.Cantata.com ([10.128.18.41]) with Microsoft Exchange Server HTTP-DAV ; Mon, 21 Aug 2006 19:47:28 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Mon, 21 Aug 2006 15:43:37 -0400 Subject: Re: [lemonade] RFC4550 servers From: Eric Burger To: Ben Last , IETF LEMONADE Message-ID: Thread-Topic: [lemonade] RFC4550 servers Thread-Index: AcbCmvrXxvasSR/gTFqXBLyGsPkTTwCvx1WL In-Reply-To: <22C8A0D5D5E095449AB509FE777B5F8002B1DE9D@svr-exchange.avocado.emccsoft.com> Mime-version: 1.0 X-OriginalArrivalTime: 21 Aug 2006 19:47:29.0042 (UTC) FILETIME=[A27C4720:01C6C55A] X-Spam-Score: 0.1 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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: , Content-Type: multipart/mixed; boundary="===============1410419222==" Errors-To: lemonade-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1410419222== Content-type: multipart/alternative; boundary="B_3239020021_4838509" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3239020021_4838509 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Check out the supplemental web site: and the Lemonade for Mobiles web site: On 8/18/06 4:22 AM, "Ben Last" wrote: > Apologies if this isn't an appropriate forum to ask this question, but > does anybody have a good list of currently available/upcoming > RFC4550-compliant servers? That would include those that are partially > compliant. We're working on the planning for migrating our existing > P-IMAP client to provide full RFC4550 support, and want to ensure we > cover as many servers as possible. > > Even reference (non-commercial) implementations would be useful. > > Regards to all > Ben > > Ben Last > EMCC Software > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade > --B_3239020021_4838509 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [lemonade] RFC4550 servers Check= out the supplemental web site:
<= ;http://flyingfox.cantata.com/i-d/lemonade/Lemonade-Plans.html>

and the Lemonade for Mobiles web site:
<http://www.= lemonadeformobiles.com/supporters.html>



On 8/18/06 4:22 AM, "Ben Last" <Ben.Last@emccsoft.com> wrot= e:

Apologies if this isn't an appropriate forum to ask thi= s question, but
does anybody have a good list of currently available/upcoming
RFC4550-compliant servers?  That would include those that are partiall= y
compliant.  We're working on the planning for migrating our existing P-IMAP client to provide full RFC4550 support, and want to ensure we
cover as many servers as possible.

Even reference (non-commercial) implementations would be useful.

Regards to all
Ben

Ben Last
EMCC Software

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade


 --B_3239020021_4838509-- --===============1410419222== 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 --===============1410419222==-- From lemonade-bounces@ietf.org Mon Aug 21 15:47:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFFjs-00005C-Ph; Mon, 21 Aug 2006 15:47:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFFjs-000057-B1 for lemonade@ietf.org; Mon, 21 Aug 2006 15:47:12 -0400 Received: from outbound.cantata.com ([208.236.123.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFFjr-00006z-4i for lemonade@ietf.org; Mon, 21 Aug 2006 15:47:12 -0400 Received: from ma02exchtmp01.Cantata.com ([10.128.18.41]) by outbound.Cantata.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Aug 2006 15:47:26 -0400 Received: from 10.128.41.3 ([10.128.41.3]) by ma02exchtmp01.Cantata.com ([10.128.18.41]) with Microsoft Exchange Server HTTP-DAV ; Mon, 21 Aug 2006 19:47:25 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Mon, 21 Aug 2006 15:00:41 -0400 From: Eric Burger To: IETF LEMONADE Message-ID: Thread-Topic: Chairs Decisions Thread-Index: AcbFVBjDVyU8fjFHEduxFQAWy5cvmw== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 21 Aug 2006 19:47:26.0120 (UTC) FILETIME=[A0BE6A80:01C6C55A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [lemonade] Chairs Decisions X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Sometimes being away for a week lets all sides weigh in. I personally have had the luxury of reading all of the arguments for a number of controversial proposals all at one sitting. Shortly you will see a number of messages presenting the Chairs' decisions as to whether the lemonade work group, as a work group, will pursue work on various proposed extensions to IMAP. The chairs really appreciate all of the good discussion that has been on the list recently. We are at some of our highest volumes ever. I am also very happy that we have not delved into ad hominem attacks. Just about all of the arguments have been about the technical merits of the approaches, which is excellent to see. Like many things in engineering, these issues do not have a purely right or wrong choice. If they did, we would all agree and make the choice. I would suggest following-up directly with the chairs, and not on the list, if you would like to discuss the decision further. -- Eric Burger, eburger@cantata.com Glenn Parsons, gparsons@nortel.com _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Aug 21 15:47:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFFjr-00004z-LS; Mon, 21 Aug 2006 15:47:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFFjq-0008VA-W9 for lemonade@ietf.org; Mon, 21 Aug 2006 15:47:10 -0400 Received: from outbound.cantata.com ([208.236.123.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFFjp-00006z-Q5 for lemonade@ietf.org; Mon, 21 Aug 2006 15:47:10 -0400 Received: from ma02exchtmp01.Cantata.com ([10.128.18.41]) by outbound.Cantata.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Aug 2006 15:47:25 -0400 Received: from 10.128.41.3 ([10.128.41.3]) by ma02exchtmp01.Cantata.com ([10.128.18.41]) with Microsoft Exchange Server HTTP-DAV ; Mon, 21 Aug 2006 19:47:25 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Mon, 21 Aug 2006 14:10:15 -0400 From: Eric Burger To: IETF LEMONADE Message-ID: Thread-Topic: Chairs Decision on MOVE Thread-Index: AcbFTQ0gS+Su3TFAEduxFQAWy5cvmw== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 21 Aug 2006 19:47:25.0932 (UTC) FILETIME=[A0A1BAC0:01C6C55A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [lemonade] Chairs Decision on MOVE X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org For filing purposes (moving an object between mailboxes), as we have seen requested on the list, a move operation does not fit the IMAP model, namely we know that UID's will get changed, which will hint to the client to resync the object, which is a waste. We would offer that such a fundamental change to IMAP is way outside the scope of the lemonade charter. Note that this is not the last word on MOVE. Our suggestion is that if one wishes to have a move primitive in IMAP, one should write a draft. We would suggest discussing the draft on IMAP-EXT. MOVE is outside the current charter of IMAP-EXT, as well, but (1) more IMAP experts live there and (2) we would like to see the discussion move off of the lemonade list, for the time being. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Aug 21 15:47:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFFjq-0008V5-H7; Mon, 21 Aug 2006 15:47:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFFjp-0008V0-Lb for lemonade@ietf.org; Mon, 21 Aug 2006 15:47:09 -0400 Received: from outbound.cantata.com ([208.236.123.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFFjn-00006z-Eq for lemonade@ietf.org; Mon, 21 Aug 2006 15:47:09 -0400 Received: from ma02exchtmp01.Cantata.com ([10.128.18.41]) by outbound.Cantata.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Aug 2006 15:47:25 -0400 Received: from 10.128.41.3 ([10.128.41.3]) by ma02exchtmp01.Cantata.com ([10.128.18.41]) with Microsoft Exchange Server HTTP-DAV ; Mon, 21 Aug 2006 19:47:24 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Mon, 21 Aug 2006 13:55:11 -0400 From: Eric Burger To: IETF LEMONADE Message-ID: Thread-Topic: Chair Decision on Notifications Thread-Index: AcbFSvJMMJB+From lemonade-bounces@ietf.org Mon Aug 21 15:47:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFFjr-00004z-LS; Mon, 21 Aug 2006 15:47:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFFjq-0008VA-W9 for lemonade@ietf.org; Mon, 21 Aug 2006 15:47:10 -0400 Received: from outbound.cantata.com ([208.236.123.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFFjp-00006z-Q5 for lemonade@ietf.org; Mon, 21 Aug 2006 15:47:10 -0400 Received: from ma02exchtmp01.Cantata.com ([10.128.18.41]) by outbound.Cantata.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Aug 2006 15:47:25 -0400 Received: from 10.128.41.3 ([10.128.41.3]) by ma02exchtmp01.Cantata.com ([10.128.18.41]) with Microsoft Exchange Server HTTP-DAV ; Mon, 21 Aug 2006 19:47:25 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Mon, 21 Aug 2006 14:10:15 -0400 From: Eric Burger To: IETF LEMONADE Message-ID: Thread-Topic: Chairs Decision on MOVE Thread-Index: AcbFTQ0gS+Su3TFAEduxFQAWy5cvmw== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 21 Aug 2006 19:47:25.0932 (UTC) FILETIME=[A0A1BAC0:01C6C55A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [lemonade] Chairs Decision on MOVE X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org For filing purposes (moving an object between mailboxes), as we have seen requested on the list, a move operation does not fit the IMAP model, namely we know that UID's will get changed, which will hint to the client to resync the object, which is a waste. We would offer that such a fundamental change to IMAP is way outside the scope of the lemonade charter. Note that this is not the last word on MOVE. Our suggestion is that if one wishes to have a move primitive in IMAP, one should write a draft. We would suggest discussing the draft on IMAP-EXT. MOVE is outside the current charter of IMAP-EXT, as well, but (1) more IMAP experts live there and (2) we would like to see the discussion move off of the lemonade list, for the time being. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Aug 21 15:47:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFFjq-0008V5-H7; Mon, 21 Aug 2006 15:47:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFFjp-0008V0-Lb for lemonade@ietf.org; Mon, 21 Aug 2006 15:47:09 -0400 Received: from outbound.cantata.com ([208.236.123.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFFjn-00006z-Eq for lemonade@ietf.org; Mon, 21 Aug 2006 15:47:09 -0400 Received: from ma02exchtmp01.Cantata.com ([10.128.18.41]) by outbound.Cantata.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Aug 2006 15:47:25 -0400 Received: from 10.128.41.3 ([10.128.41.3]) by ma02exchtmp01.Cantata.com ([10.128.18.41]) with Microsoft Exchange Server HTTP-DAV ; Mon, 21 Aug 2006 19:47:24 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Mon, 21 Aug 2006 13:55:11 -0400 From: Eric Burger To: IETF LEMONADE Message-ID: Thread-Topic: Chair Decision on Notifications Thread-Index: AcbFSvJMMJB+sjE+EduxFQAWy5cvmw== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 21 Aug 2006 19:47:25.0167 (UTC) FILETIME=[A02CFFF0:01C6C55A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [lemonade] Chair Decision on Notifications X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Notification throttling is extremely complex and is a very hard problem. For example, we would urge people to review the throttling work that has been done in the SIP and SIPPING work groups on throttling NOTIFY messages (a.k.a. notifications). Everything (and more) that we have been discussing, including number of bytes transferred per unit time, number of messages, consolidation of messages, number of messages sent per unit time, number of messages * bytes sent per unit time, schedules for different throttling parameters, throttling based on network throughput, throttling based on device capability, etc., etc., etc. We would offer that notification throttling is EXPLICITLY outside our charter at this time. AFTER we finish the bulk of our deliverables, we can explore if we can safely punt the topic (i.e., because we are using SIP NOTIFY, which has its own throttling mechanism), we need to recharter, or we need to form a new work group (e.g., a NOTIFICATIONS work group). _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade sjE+EduxFQAWy5cvmw== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 21 Aug 2006 19:47:25.0167 (UTC) FILETIME=[A02CFFF0:01C6C55A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [lemonade] Chair Decision on Notifications X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Notification throttling is extremely complex and is a very hard problem. For example, we would urge people to review the throttling work that has been done in the SIP and SIPPING work groups on throttling NOTIFY messages (a.k.a. notifications). Everything (and more) that we have been discussing, including number of bytes transferred per unit time, number of messages, consolidation of messages, number of messages sent per unit time, number of messages * bytes sent per unit time, schedules for different throttling parameters, throttling based on network throughput, throttling based on device capability, etc., etc., etc. We would offer that notification throttling is EXPLICITLY outside our charter at this time. AFTER we finish the bulk of our deliverables, we can explore if we can safely punt the topic (i.e., because we are using SIP NOTIFY, which has its own throttling mechanism), we need to recharter, or we need to form a new work group (e.g., a NOTIFICATIONS work group). _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Aug 21 15:47:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFFju-000060-Tw; Mon, 21 Aug 2006 15:47:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFFjt-00005c-OC for lemonade@ietf.org; Mon, 21 Aug 2006 15:47:13 -0400 Received: from outbound.cantata.com ([208.236.123.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFFjs-00006z-HR for lemonade@ietf.org; Mon, 21 Aug 2006 15:47:13 -0400 Received: from ma02exchtmp01.Cantata.com ([10.128.18.41]) by outbound.Cantata.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Aug 2006 15:47:26 -0400 Received: from 10.128.41.3 ([10.128.41.3]) by ma02exchtmp01.Cantata.com ([10.128.18.41]) with Microsoft Exchange Server HTTP-DAV ; Mon, 21 Aug 2006 19:47:26 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Mon, 21 Aug 2006 15:36:30 -0400 From: Eric Burger To: IETF LEMONADE Message-ID: Thread-Topic: Chairs Thoughts on TRASH Thread-Index: AcbFWRmqWFWSJDFMEduxFQAWy5cvmw== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 21 Aug 2006 19:47:26.0698 (UTC) FILETIME=[A1169CA0:01C6C55A] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [lemonade] Chairs Thoughts on TRASH X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 a tough one. Changing the behavior of IMAP in such a radical way, like introducing MOVE to place items into a trash mailbox, is clearly way out of scope for lemonade. However, keeping the marketplace happy is important for the acceptance of the lemonade suite, as well. Do keep in mind that ONLY proprietary messaging systems implement trash mailboxes. NO IMAP SERVER, following RFC3501, implements a trash folder. MANY clients implement trash folders/mailboxes, either by keeping track themselves (POP3, IMAP) or by using native IMAP mechanisms (\DELETED). Before we rule such work out of scope, the chairs would like to see concrete proposals. That said, we have a bunch of WGLC's coming up immediately. Thus, we request a moratorium on discussing special folders until after we see some drafts published. Thanks. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Aug 22 00:56:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFOIq-00035x-SD; Tue, 22 Aug 2006 00:55:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFOIo-00035q-Ls for lemonade@ietf.org; Tue, 22 Aug 2006 00:55:50 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFOIn-0006Co-7N for lemonade@ietf.org; Tue, 22 Aug 2006 00:55:50 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.7) with ESMTP id k7M4qWHt029265; Tue, 22 Aug 2006 07:52:37 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Aug 2006 07:51:30 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Aug 2006 07:51:29 +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] Too Many Recipients Date: Tue, 22 Aug 2006 07:50:53 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657CD7041@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Too Many Recipients Thread-Index: AcbEkZjpaEzgONA+RJuC90fTxpRF1QBFOmtQ From: To: , X-OriginalArrivalTime: 22 Aug 2006 04:51:30.0191 (UTC) FILETIME=[A22059F0:01C6C5A6] X-Spam-Score: 0.2 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 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 >Depending on the answers, I suggest raising the limit to 10,=20 >50 or infinity. ++support _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Aug 22 00:56:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFOJm-0003qi-FI; Tue, 22 Aug 2006 00:56:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFOJl-0003qd-1D for lemonade@ietf.org; Tue, 22 Aug 2006 00:56:49 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFOJj-0006Po-ID for lemonade@ietf.org; Tue, 22 Aug 2006 00:56:49 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.7) with ESMTP id k7M4uh9j010936; Tue, 22 Aug 2006 07:56:43 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Aug 2006 07:56:42 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Aug 2006 07:56:42 +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] 'MOVE' (was Notifications for multiple devicesper user) Date: Tue, 22 Aug 2006 07:56:07 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657CD7047@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] 'MOVE' (was Notifications for multiple devicesper user) Thread-Index: AcbCVTDDpfTxgEUDS1yTOHSNQP4CugDUWhnQ From: To: , X-OriginalArrivalTime: 22 Aug 2006 04:56:42.0132 (UTC) FILETIME=[5C0EC540:01C6C5A7] X-Spam-Score: 0.8 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: lemonade@ietf.org, guenther+lemonade@sendmail.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 am not worried about the protocol level - I am worried showing a=20 >> mixed mailbox to the user (where some mails are in the trash as=20 >> expected and some are not). > >There's a difference between where a message is on the server,=20 >and how the message is presented to the user. If clients want=20 >to present a distinct "Trash" mailbox to the user, that is=20 >fine. Forcing the metaphor to be literally true is a poor use=20 >of IMAP and causes problems. Making it easy for clients to=20 >efficiently present a Trash metaphor to users is a good thing.=20 > I assume the users don't care which elements of the protocol=20 >are used in which ways by the client.=20 >They want to manage messages in a way that feels natural for them. Somehow this thread went back to discussing Trash instead of MOVE. I read through Mark's email as well. I accept what You are saying - my worry is that the operators will say at the last minute (when LEMONADE is already done) that they want a separate trash and force us to do something proprietary (I mean it will be a standard anyway in OMA, but might not be in line with LEMONADE). _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Aug 22 01:04:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFOQn-0005eg-8U; Tue, 22 Aug 2006 01:04:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFOQl-0005cg-Bx for lemonade@ietf.org; Tue, 22 Aug 2006 01:04:03 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFOQj-00088E-Ta for lemonade@ietf.org; Tue, 22 Aug 2006 01:04:03 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.7) with ESMTP id k7M53wl5014854; Tue, 22 Aug 2006 08:04:00 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Aug 2006 08:03:14 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Aug 2006 08:03: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="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] LEMONADE vs. P-IMAP Date: Tue, 22 Aug 2006 08:02:38 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657CD704E@esebe199.NOE.Nokia.com> In-Reply-To: <20060817162753640.00000004604@smaes-lap3> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] LEMONADE vs. P-IMAP Thread-Index: AcbCVO0bFJR6nDQiTseAjBstZuTJYQDUn8kg From: To: , , X-OriginalArrivalTime: 22 Aug 2006 05:03:14.0211 (UTC) FILETIME=[45C14730:01C6C5A8] X-Spam-Score: 0.2 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 Stephane, >It should have been clear to all and was clear stated for=20 >example in the latest published version that P-IMAP was our=20 >submission to the IETF and OMA process as well as an interim=20 >solution awaiting the standard. Are You suggesting that there will be a third solution in OMA (beside LEMONADE and DS -based MEM)? >P-IMAp is not the object of any separate standardization=20 >activity. IETF Lemonade and OMA MEM are where this is happening. P-IMAP is separate in LEMONADE - so it is not LEMONADE as pointed out by Randall - or is Randall's statement incorrect? In OMA, MEM is based on LEMONADE and DS - but not P-IMAP (hence my question above about a third MEM solution in OMA). It seems to me that there is a confusion about it in LEMONADE as well. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Aug 22 01:07:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFOUJ-0006RC-82; Tue, 22 Aug 2006 01:07:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFOUH-0006R6-GO for lemonade@ietf.org; Tue, 22 Aug 2006 01:07:41 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFOUE-0000Jr-12 for lemonade@ietf.org; Tue, 22 Aug 2006 01:07:41 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.7) with ESMTP id k7M57Yf6017791 for ; Tue, 22 Aug 2006 08:07:37 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Aug 2006 08:07: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, 22 Aug 2006 08:07: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="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] LEMONADE vs. P-IMAP Date: Tue, 22 Aug 2006 08:06:31 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657CD7051@esebe199.NOE.Nokia.com> In-Reply-To: <893AE265F4ADF94AB7FB26D31A788E410283436F@mvebe101.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] LEMONADE vs. P-IMAP Thread-Index: AcbEeZe/Fo8BPZFZQMKrff7ldnrepAASiPgAADkgJnA= From: To: X-OriginalArrivalTime: 22 Aug 2006 05:07:06.0015 (UTC) FILETIME=[CFEBC2F0:01C6C5A8] X-Spam-Score: 0.2 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 Dorothy, >OMA is standardizing on the Lemonade profile bis, not P-IMAP. We leave >it to the IETF Lemonade WG to decide on what goes into that=20 >profile. =20 Yes, this is my understanding as well regarding OMA standardization activities. But Stephane in another email is saying that OMA MEM is based on P-IMAP. The emails on this mailing list seem to confirm that there are some misunderstandings that I believe should be clarified as soon as possible. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Aug 22 01:23:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFOjn-0003Je-Jk; Tue, 22 Aug 2006 01:23:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFOjm-0003JR-AB for lemonade@ietf.org; Tue, 22 Aug 2006 01:23:42 -0400 Received: from rgminet01.oracle.com ([148.87.113.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFOjj-0002xo-WF for lemonade@ietf.org; Tue, 22 Aug 2006 01:23:42 -0400 Received: from rcsmt251.oracle.com (rcsmt251.oracle.com [148.87.90.196]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k7LH4bZv030952; Mon, 21 Aug 2006 23:23:38 -0600 Received: from dhcp-amer-whq-csvpn-gw3-141-144-81-228.vpn.oracle.com by rcsmt250.oracle.com with ESMTP id 1765846401156224130; Mon, 21 Aug 2006 23:22:10 -0600 From: "Stephane H. Maes" To: "Zoltan.Ordogh@nokia.com" , "randy@qualcomm.com" , "lemonade@ietf.org" Subject: RE: [lemonade] LEMONADE vs. P-IMAP Date: Mon, 21 Aug 2006 22:21:56 -0700 Organization: Oracle Message-ID: <20060821222156968.00000003748@smaes-lap3> In-Reply-To: <0FA975F2D8295A448BE3ADC161244657CD704E@esebe199.NOE.Nokia.com> 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-Whitelist: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: 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 I frankly do not understand the discussion that is taking place. We have propsoed P-IMAp as input to IETF and as a group at lemonade we work= on lemonade profile an dprofile bis That is the output of the work and the= resulting standard. We have similarly brought the use cases, features, requiremenst and design = point to OMA and the output is the OMA MEM enabler. We are pushing for having a MEM realization based on Lemonade profile bis. What is not understood in these steps. Why create FUD around P-IMAP, Lemona= de profile or OMA MEM that is not needed nor called for? 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: Zoltan.Ordogh@nokia.com [mailto:Zoltan.Ordogh@nokia.com] = Sent: Monday, August 21, 2006 10:03 PM To: stephane.maes@oracle.com; randy@qualcomm.com; lemonade@ietf.org Subject: RE: [lemonade] LEMONADE vs. P-IMAP Hi Stephane, >It should have been clear to all and was clear stated for example in = >the latest published version that P-IMAP was our submission to the IETF = >and OMA process as well as an interim solution awaiting the standard. Are You suggesting that there will be a third solution in OMA (beside LEMON= ADE and DS -based MEM)? >P-IMAp is not the object of any separate standardization activity. IETF = >Lemonade and OMA MEM are where this is happening. P-IMAP is separate in LEMONADE - so it is not LEMONADE as pointed out by Ra= ndall - or is Randall's statement incorrect? In OMA, MEM is based on LEMONADE and DS - but not P-IMAP (hence my question= above about a third MEM solution in OMA). It seems to me that there is a confusion about it in LEMONADE as well. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Aug 22 03:19:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFQXI-0004X3-Af; Tue, 22 Aug 2006 03:18:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFQXH-0004Wy-1R for lemonade@ietf.org; Tue, 22 Aug 2006 03:18:55 -0400 Received: from pathbreaker.com ([64.71.130.73]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GFQXF-00049O-LU for lemonade@ietf.org; Tue, 22 Aug 2006 03:18:55 -0400 Received: (qmail 12415 invoked by uid 89); 22 Aug 2006 07:17:08 -0000 Received: from localhost (HELO ?192.168.1.100?) (ray%logicaldepth.com@127.0.0.1) by 0 with SMTP; 22 Aug 2006 07:17:08 -0000 Message-ID: <44EAAFCA.9040304@pathbreaker.com> Date: Tue, 22 Aug 2006 00:18:34 -0700 From: Ray Cromwell User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: "lemonade@ietf.org" Subject: Re: [lemonade] LEMONADE vs. P-IMAP References: <20060821222156968.00000003748@smaes-lap3> In-Reply-To: <20060821222156968.00000003748@smaes-lap3> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 situation isn't so complicated. P-IMAP is just an input document, an informational reference, just like many of the other drafts submitted to Lemonade for discussion of ideas and techniques. For example, all the draft-smaes documents, the OMA materials on the Supplemental Page, stuff like clearidle, videomsg, etc. Some stuff gets pick up in discussion, refined, and makes it into draft-ietf-lemonade-* documents, and alot more expires and disappears. Look at the Lemonade drafts archive and all of those dead non-Lemonade drafts. :) -Ray _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Aug 22 05:29:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFSYx-0001B2-Nl; Tue, 22 Aug 2006 05:28:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFSYw-0001Aq-3y for lemonade@ietf.org; Tue, 22 Aug 2006 05:28:46 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFSYu-0006CS-La for lemonade@ietf.org; Tue, 22 Aug 2006 05:28:46 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.7) with ESMTP id k7M8Sh24022434; Tue, 22 Aug 2006 11:28:45 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Aug 2006 12:28:28 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Aug 2006 12:28:28 +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] LEMONADE vs. P-IMAP Date: Tue, 22 Aug 2006 12:27:51 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657D52DFB@esebe199.NOE.Nokia.com> In-Reply-To: <20060821222156968.00000003748@smaes-lap3> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] LEMONADE vs. P-IMAP Thread-Index: AcbFqzurNkFevdssTluZ442oZhxcQwAH6Vzg From: To: , , X-OriginalArrivalTime: 22 Aug 2006 09:28:28.0074 (UTC) FILETIME=[532810A0:01C6C5CD] X-Spam-Score: 0.2 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 Stephane, Thank You for Your responses. Please read what I wrote below to confirm that my understanding is correct. >I frankly do not understand the discussion that is taking place. I thought that this would be clear from the original mail I sent. I see people referring to P-IMAP sometimes as if it was the LEMONADE solution. This creates confusion. I would like to clarify this confusion. Simple as that. >We have propsoed P-IMAp as input to IETF and as a group at=20 >lemonade we work on lemonade profile an dprofile bis That is=20 >the output of the work and the resulting standard. Understood, but the draft is not being discussed - it is a draft hanging around - and according to Randall it is not the LEMONADE solution. Thus, I think asking what is its purpose is a logical question. So, what You are saying that it is not a standard but a form of input - I can accept this - but the problem is some people refer to it as if it was going to be a standard. >We have similarly brought the use cases, features,=20 >requiremenst and design point to OMA and the output is the OMA=20 >MEM enabler. To my knowledge OMA solution will be based on LEMONADE Profile. Hence my question about having a third solution (based on P-IMAP) to be done in OMA. >We are pushing for having a MEM realization based on Lemonade=20 >profile bis. Yes, this I understand. What is not clear is the intent with P-IMAP. But from Your statement above I understand it is a form of contributing input to the LEMONADE standard, and P-IMAP is not a standard. >What is not understood in these steps. Why create FUD around=20 >P-IMAP, Lemonade profile or OMA MEM that is not needed nor called for? No, there is no such intent. My intent is the exact opposite: clarification. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Aug 22 11:27:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFYA5-0002mR-Cz; Tue, 22 Aug 2006 11:27:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFYA4-0002mI-3T for lemonade@ietf.org; Tue, 22 Aug 2006 11:27:28 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFYA2-0004wy-IK for lemonade@ietf.org; Tue, 22 Aug 2006 11:27:28 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.7) with ESMTP id k7MERPCK027201; Tue, 22 Aug 2006 17:27:26 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Aug 2006 18:26: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, 22 Aug 2006 18:26:21 +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] Standards Process (was 'Notifications formultipledevices per user') Date: Tue, 22 Aug 2006 18:25:46 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657D531B8@esebe199.NOE.Nokia.com> In-Reply-To: <01M60LOUJRA00008CX@mauve.mrochek.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Standards Process (was 'Notifications formultipledevices per user') Thread-Index: AcbEeb/O5C0itNNSTNOYCEmGDDE4SwBgW4dw From: To: X-OriginalArrivalTime: 22 Aug 2006 15:26:21.0546 (UTC) FILETIME=[5257DCA0:01C6C5FF] X-Spam-Score: 0.2 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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 Ned, >Excuse me, but what you need to implement is tangentially=20 >related at best to what this group is supposed to be specifying. I think that this statement is valid only if one implements the pure LEMONADE specifications. OMA on the other hand provides an Enabler based on LEMONADE, where additional features/funtionalities might be introduced. >With all due respect, you're not the first to make these sorts=20 >of market-related arguments - I've seen similar statemetns=20 >made dozens if not hundreds of times in the past 16 years that=20 >I've been working in the IETF. >However, the number of cases I've seen where the sorts of=20 >comments you are making gained any sort of traction can be=20 >counted on the fingers of one hand with some digits left over.=20 >If you want to gain traction for your ideas, I strongly=20 >recommend that you focus on items that are in scope for the=20 >group, and for those items you need to argue based on cogent=20 >technical grounds. I am not here to tell You that You should do what the market demands. I prefer to leave these decisions to LEMONADE group. Speaking of previous market-related arguments: if You consider operator presence in IETF, I think that the message is pretty clear. What I mean to tell You (all) is an early indication that such demand might indeed pop up and when it does, I would rather see a solution for the problem standardized here, in LEMONADE/IETF. How You deal with such "early warnings" is up to the LEMONADE group. Should the group decide that it is not in the scope, not worth doing, or any other reason, I accept it. Until this decision though I pursue the issue for the reason above. I do believe that it is in the scope - the arguments have been presented already. >Not hardly. LEMONADE =3D the items we're chartered to do and=20 >nothing more. The charter is here: > > http://www.ietf.org/html.charters/lemonade-charter.html > >I suggest you read it carefully. I do not understand why I need to read it (or how to read it) carefully - if careful reading is needed, then it means that the charter is not good because the details are hidden. I read it (well, at least I read what was readable, the hidden details remain hidden to me). This part: "operation on platforms with constrained resources, or=20 communications links with high latency or limited bandwidth" tells me that it is in the scope. There is no goal or milestone after 2005 Aug, so does it mean that there is nothing on the charter? In any case, I do not think that our arguments should be based on whether if it is in the scope or not. >Whether or not it fits into the picture painted by the WG=20 >title is largely irrelevant. Working group titles are=20 >necessarily general in nature - a title running into hundreds=20 >of words would be (obviously) unmanageable. This why we have=20 >charters: They specify fairly precisely what the group is=20 >supposed to be working on, and by omission, what the group is=20 >NOT supposed to be doing. No, it is not about the title. I quoted above a small portion of the charter. >To pick another example, the amount of stuff that could fall=20 >under the title "Open Pluggable Edge Services" is vast, but if=20 >you look at the OPES WG charter you will see that they are=20 >currently focusing on a very specific subset of the edge=20 >service problem as it pertains to SMTP. This is how things=20 >work in the IETF. Thank You for pointing this out, however I did not see such limitation in the LEMONADE charter. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Aug 22 17:05:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFdR8-0003Zj-JK; Tue, 22 Aug 2006 17:05:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFdR7-0003Ze-Sl for lemonade@ietf.org; Tue, 22 Aug 2006 17:05:25 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFdR6-0002Mi-I1 for lemonade@ietf.org; Tue, 22 Aug 2006 17:05: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 k7ML5N4R031872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 22 Aug 2006 14:05:23 -0700 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.172.15]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7ML5LrX007087; Tue, 22 Aug 2006 14:05:22 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <0FA975F2D8295A448BE3ADC161244657CD7047@esebe199.NOE.Nokia.com> References: <0FA975F2D8295A448BE3ADC161244657CD7047@esebe199.NOE.Nokia.com> X-Mailer: Eudora for Mac OS X (dev alpha) X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Tue, 22 Aug 2006 14:03:12 -0700 To: From: Randall Gellens Subject: RE: [lemonade] 'MOVE' (was Notifications for multiple devicesper 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: 8abaac9e10c826e8252866cbe6766464 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 7:56 AM +0300 8/22/06, wrote: > >There's a difference between where a message is on the server, >>and how the message is presented to the user. If clients want >>to present a distinct "Trash" mailbox to the user, that is >>fine. Forcing the metaphor to be literally true is a poor use >>of IMAP and causes problems. Making it easy for clients to >>efficiently present a Trash metaphor to users is a good thing. >> I assume the users don't care which elements of the protocol >>are used in which ways by the client. >>They want to manage messages in a way that feels natural for them. > > Somehow this thread went back to discussing Trash instead of MOVE. > I read through Mark's email as well. I accept what You are saying - my > worry is that the operators will say at the last minute (when LEMONADE > is already done) that they want a separate trash and force us to do > something proprietary (I mean it will be a standard anyway in OMA, but > might not be in line with LEMONADE). If operators try to mandate a Trash mailbox in OMA, my advise would be to try and focus the requirement on what is necessary to permit the desired user experience and on interoperability. In other words, if operators want to be sure that their users will see a trash metaphor, it should not matter to them if this is implemented with a distinct trash mailbox on the server or on the client, as long as the solution interoperates. Doing it on the client is actually more interoperable, since it is reversible by any client. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- An algorithm must be seen to be believed. -- Donald Knuth _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Aug 22 21:01:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFh7p-0000rf-BD; Tue, 22 Aug 2006 21:01:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFh7n-0000rX-88 for lemonade@ietf.org; Tue, 22 Aug 2006 21:01:43 -0400 Received: from outbound.cantata.com ([208.236.123.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFh7m-0002xk-1r for lemonade@ietf.org; Tue, 22 Aug 2006 21:01:43 -0400 Received: from ma02exchtmp01.Cantata.com ([10.128.18.41]) by outbound.Cantata.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Aug 2006 21:02:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Aug 2006 21:01:59 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: profile-bis and format=flowed (RFC 3676) Thread-Index: AcbGT7y7RnkRhzqxSE+V/V4v9+3oBw== From: "Burger, Eric" To: X-OriginalArrivalTime: 23 Aug 2006 01:02:00.0473 (UTC) FILETIME=[BD25E090:01C6C64F] X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [lemonade] profile-bis and format=flowed (RFC 3676) X-BeenThere: lemonade@ietf.org X-Mailman-Version: 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="===============0142637810==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============0142637810== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6C64F.BCBB5410" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6C64F.BCBB5410 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW55IHJlYXNvbiBub3QgdG8gcHV0IGZvcm1hdD1mbG93ZWQgaW50byBwcm9maWxlLWJpcz8gIFVu bGVzcyB3ZSBoZWFyIG90aGVyd2lzZSwgaXQgaXMgZ29pbmcgaW4uDQoNCi0tDQpTZW50IGZyb20g bXkgbGVzcy10aGFuLWlkZWFsLCBub24tUGFsbSB3aXJlbGVzcyBkZXZpY2U7IEkgY2FuJ3Qgd2Fp dCBmb3IgTEVNT05BREUhISENCg== ------_=_NextPart_001_01C6C64F.BCBB5410 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMg RXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNi41Ljc2MzguMSI+DQo8VElUTEU+cHJvZmlsZS1iaXMg YW5kIGZvcm1hdD1mbG93ZWQgKFJGQyAzNjc2KTwvVElUTEU+DQo8L0hFQUQ+DQo8Qk9EWT4NCjwh LS0gQ29udmVydGVkIGZyb20gdGV4dC9wbGFpbiBmb3JtYXQgLS0+DQoNCjxQPjxGT05UIFNJWkU9 Mj5BbnkgcmVhc29uIG5vdCB0byBwdXQgZm9ybWF0PWZsb3dlZCBpbnRvIHByb2ZpbGUtYmlzPyZu YnNwOyBVbmxlc3Mgd2UgaGVhciBvdGhlcndpc2UsIGl0IGlzIGdvaW5nIGluLjxCUj4NCjxCUj4N Ci0tPEJSPg0KU2VudCBmcm9tIG15IGxlc3MtdGhhbi1pZGVhbCwgbm9uLVBhbG0gd2lyZWxlc3Mg ZGV2aWNlOyBJIGNhbid0IHdhaXQgZm9yIExFTU9OQURFISEhPC9GT05UPg0KPC9QPg0KDQo8L0JP RFk+DQo8L0hUTUw+ ------_=_NextPart_001_01C6C64F.BCBB5410-- --===============0142637810== 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 --===============0142637810==-- From lemonade-bounces@ietf.org Tue Aug 22 21:57:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFhzZ-0007ls-BO; Tue, 22 Aug 2006 21:57:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFhzX-0007le-Ph for lemonade@ietf.org; Tue, 22 Aug 2006 21:57:15 -0400 Received: from outbound.cantata.com ([208.236.123.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFhzX-0000Lw-BF for lemonade@ietf.org; Tue, 22 Aug 2006 21:57:15 -0400 Received: from ma02exchtmp01.Cantata.com ([10.128.18.41]) by outbound.Cantata.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Aug 2006 21:57:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Re: [lemonade] 'MOVE' (was Notifications for multiple devicesper user) Date: Tue, 22 Aug 2006 21:57:32 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] 'MOVE' (was Notifications for multiple devicesper user) Thread-Index: AcbGLvtyIqOu02rFQAKr3lbQ5m+qwQAKIPGQ From: "Burger, Eric" To: X-OriginalArrivalTime: 23 Aug 2006 01:57:33.0850 (UTC) FILETIME=[7FFED7A0:01C6C657] X-Spam-Score: 0.5 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de 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: , Content-Type: multipart/mixed; boundary="===============0647297239==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============0647297239== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6C657.7F79C322" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6C657.7F79C322 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 W1NwZWFraW5nIGFzIGEgcGFyaWNpcGFudCwgTk9UIGFzIGEgQ2hhaXJdDQoNCkkgaGF2ZSBuZXZl ciwgRVZFUiwgaW4gbXkgZXhwZXJpZW5jZSBoYWQgYSBzZXJ2aWNlIHByb3ZpZGVyIG9yIG5ldG93 cmsgb3BlcmF0b3IgbWFuZGF0ZSB0aGF0IGxldmVsIG9mIHByb3RvY29sIG9wZXJhdGlvbi4gIE1h bmRhdGluZyBhIHByb3RvY29sIHN1aXRlLCB5ZXMuICBEaWN0YXRpbmcgdGhlIG1lY2hhbmljcyBv ZiB0aGUgc3VpdGUsIE5FVkVSLiAgT0ssIHRoZXJlIGlzIG9uZSBjYXZlYXQ6IHdoZW4gYSBzZXJ2 aWNlIHByb3ZpZGVyIG9yIG9wZXJhdG9yIGNhcmVzIHRoYXQgbXVjaCBhYm91dCB0aGUgb3BlcmF0 aW9uIG9mIGEgcHJvdG9jb2wsIHlvdSB3aWxsIHVzdWFsbGx5IHNlZSB0aGV5IGFyZSBvbmUgb2Yg dGhlIGF1dGhvcnMgb2YgdGhlIHByb3RvY29sLg0KDQpNdWNoIHRvIG15IGNoYWdyaW4gKG9yLCBh ZG1pdHRlZGx5LCBzb21ldGltZXMgdG8gbXkgYmVuZWZpdCksIG1vc3Qgb3BlcmF0b3JzLCB3aGVu IGFza2VkIGFib3V0IHRoZWlyIHN0YW5kYXJkcyBwYXJ0aWNpcGF0aW9uLCBzYXksICJ3ZSBtb25p dG9yIHRoZSBzdGFuZGFyZHMgYm9kaWVzLCBidXQgd2UgcmVseSBvbiBvdXIgdmVuZG9ycyB0byB0 ZWxsIHVzIHdoYXQgaXMgaW1wb3J0YW50LiINCg0KV0hZIHdvdWxkIHRoZXkgY2FyZSBhYm91dCBh IHRyYXNoIG1haWxib3g/ICBUaGVpciBzcGVjaWZ5aW5nIHRoZSB1c2VyIGludGVyZmFjZSBJIHdv dWxkIGJlbGlldmUuICBIb3dldmVyLCB0aGVpciBzcGVjaWZ5aW5nIHRoZSB1bmRlcmx5aW5nIHBy b3RvY29sIG1lY2hhbmljcyBpcyB3YXkgYmV5b25kIG15IGV4cGVyaWVuY2UuICBIb3cgd291bGQg dGhleSBrbm93PyAgV2hvIGlzIGRyaXZpbmcgdGhlbSB0byB3YW50IHRoaXMgb25lIGZlYXR1cmUs IHdoaWNoIGJ5IHRoZSB3YXkgcmVkdWNlcyB0aGVpciBjaG9pY2Ugb2YgSU1BUC1jb21wbGllbnQg c2VydmVycyBhbmQgaW5kZXBlbmRlbnQgSU1BUC1jb21wbGlhbnQgY2xpZW50cyB0byBleGFjdGx5 IHplcm8/DQoNCkkgd2lsbCBoYXBwaWx5IGJlbmQgb3ZlciB0byBkbyB0aGlzIGlmIG9uZSBjb3Vs ZCBwcm9kdWNlIHRocmVlIHNlcnZpY2UgcHJpdmlkZXJzIG9yIG9wZXJhdG9ycyB0aGF0IHJlYWxs eSB3YW50IHRvIGRpY3RhdGUgdGhlIHByb3RvY29sIG9wZXJhdGlvbiBhdCB0aGF0IGxldmVsIEFO RCBVTkRFUlNUQU5EIFRIRSBJTVBMSUNBVElPTlMgdG8gZGVtYW5kIHRyYXNoIG1haWxib3hlcy4N Cg0KDQotLQ0KU2VudCBmcm9tIG15IGxlc3MtdGhhbi1pZGVhbCwgbm9uLVBhbG0gd2lyZWxlc3Mg ZGV2aWNlOyBJIGNhbid0IHdhaXQgZm9yIExFTU9OQURFISEhDQoNCi0tLS0tIE9yaWdpbmFsIE1l c3NhZ2UgLS0tLS0NCkZyb206IFJhbmRhbGwgR2VsbGVucyA8cmFuZHlAcXVhbGNvbW0uY29tPg0K VG86IFpvbHRhbi5PcmRvZ2hAbm9raWEuY29tIDxab2x0YW4uT3Jkb2doQG5va2lhLmNvbT4NCkNj OiBsZW1vbmFkZUBpZXRmLm9yZyA8bGVtb25hZGVAaWV0Zi5vcmc+DQpTZW50OiBUdWUgQXVnIDIy IDE3OjAzOjEyIDIwMDYNClN1YmplY3Q6IFJFOiBbbGVtb25hZGVdICdNT1ZFJyAod2FzIE5vdGlm aWNhdGlvbnMgZm9yIG11bHRpcGxlIGRldmljZXNwZXIgdXNlcikNCg0KQXQgNzo1NiBBTSArMDMw MCA4LzIyLzA2LCA8Wm9sdGFuLk9yZG9naEBub2tpYS5jb20+IHdyb3RlOg0KDQo+ICAgPlRoZXJl J3MgYSBkaWZmZXJlbmNlIGJldHdlZW4gd2hlcmUgYSBtZXNzYWdlIGlzIG9uIHRoZSBzZXJ2ZXIs DQo+PmFuZCBob3cgdGhlIG1lc3NhZ2UgaXMgcHJlc2VudGVkIHRvIHRoZSB1c2VyLiAgSWYgY2xp ZW50cyB3YW50DQo+PnRvIHByZXNlbnQgYSBkaXN0aW5jdCAiVHJhc2giIG1haWxib3ggdG8gdGhl IHVzZXIsIHRoYXQgaXMNCj4+ZmluZS4gIEZvcmNpbmcgdGhlIG1ldGFwaG9yIHRvIGJlIGxpdGVy YWxseSB0cnVlIGlzIGEgcG9vciB1c2UNCj4+b2YgSU1BUCBhbmQgY2F1c2VzIHByb2JsZW1zLiAg TWFraW5nIGl0IGVhc3kgZm9yIGNsaWVudHMgdG8NCj4+ZWZmaWNpZW50bHkgcHJlc2VudCBhIFRy YXNoIG1ldGFwaG9yIHRvIHVzZXJzIGlzIGEgZ29vZCB0aGluZy4NCj4+ICBJIGFzc3VtZSB0aGUg dXNlcnMgZG9uJ3QgY2FyZSB3aGljaCBlbGVtZW50cyBvZiB0aGUgcHJvdG9jb2wNCj4+YXJlIHVz ZWQgaW4gd2hpY2ggd2F5cyBieSB0aGUgY2xpZW50Lg0KPj5UaGV5IHdhbnQgdG8gbWFuYWdlIG1l c3NhZ2VzIGluIGEgd2F5IHRoYXQgZmVlbHMgbmF0dXJhbCBmb3IgdGhlbS4NCj4NCj4gIFNvbWVo b3cgdGhpcyB0aHJlYWQgd2VudCBiYWNrIHRvIGRpc2N1c3NpbmcgVHJhc2ggaW5zdGVhZCBvZiBN T1ZFLg0KPiAgSSByZWFkIHRocm91Z2ggTWFyaydzIGVtYWlsIGFzIHdlbGwuIEkgYWNjZXB0IHdo YXQgWW91IGFyZSBzYXlpbmcgLSBteQ0KPiAgd29ycnkgaXMgdGhhdCB0aGUgb3BlcmF0b3JzIHdp bGwgc2F5IGF0IHRoZSBsYXN0IG1pbnV0ZSAod2hlbiBMRU1PTkFERQ0KPiAgaXMgYWxyZWFkeSBk b25lKSB0aGF0IHRoZXkgd2FudCBhIHNlcGFyYXRlIHRyYXNoIGFuZCBmb3JjZSB1cyB0byBkbw0K PiAgc29tZXRoaW5nIHByb3ByaWV0YXJ5IChJIG1lYW4gaXQgd2lsbCBiZSBhIHN0YW5kYXJkIGFu eXdheSBpbiBPTUEsIGJ1dA0KPiAgbWlnaHQgbm90IGJlIGluIGxpbmUgd2l0aCBMRU1PTkFERSku DQoNCklmIG9wZXJhdG9ycyB0cnkgdG8gbWFuZGF0ZSBhIFRyYXNoIG1haWxib3ggaW4gT01BLCBt eSBhZHZpc2Ugd291bGQgDQpiZSB0byB0cnkgYW5kIGZvY3VzIHRoZSByZXF1aXJlbWVudCBvbiB3 aGF0IGlzIG5lY2Vzc2FyeSB0byBwZXJtaXQgDQp0aGUgZGVzaXJlZCB1c2VyIGV4cGVyaWVuY2Ug YW5kIG9uIGludGVyb3BlcmFiaWxpdHkuICBJbiBvdGhlciB3b3JkcywgDQppZiBvcGVyYXRvcnMg d2FudCB0byBiZSBzdXJlIHRoYXQgdGhlaXIgdXNlcnMgd2lsbCBzZWUgYSB0cmFzaCANCm1ldGFw aG9yLCBpdCBzaG91bGQgbm90IG1hdHRlciB0byB0aGVtIGlmIHRoaXMgaXMgaW1wbGVtZW50ZWQg d2l0aCBhIA0KZGlzdGluY3QgdHJhc2ggbWFpbGJveCBvbiB0aGUgc2VydmVyIG9yIG9uIHRoZSBj bGllbnQsIGFzIGxvbmcgYXMgdGhlIA0Kc29sdXRpb24gaW50ZXJvcGVyYXRlcy4gIERvaW5nIGl0 IG9uIHRoZSBjbGllbnQgaXMgYWN0dWFsbHkgbW9yZSANCmludGVyb3BlcmFibGUsIHNpbmNlIGl0 IGlzIHJldmVyc2libGUgYnkgYW55IGNsaWVudC4NCi0tIA0KUmFuZGFsbCBHZWxsZW5zDQpPcGlu aW9ucyBhcmUgcGVyc29uYWw7ICAgIGZhY3RzIGFyZSBzdXNwZWN0OyAgICBJIHNwZWFrIGZvciBt eXNlbGYgb25seQ0KLS0tLS0tLS0tLS0tLS0gUmFuZG9tbHktc2VsZWN0ZWQgdGFnOiAtLS0tLS0t LS0tLS0tLS0NCkFuIGFsZ29yaXRobSBtdXN0IGJlIHNlZW4gdG8gYmUgYmVsaWV2ZWQuICAtLSBE b25hbGQgS251dGgNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCmxlbW9uYWRlIG1haWxpbmcgbGlzdA0KbGVtb25hZGVAaWV0Zi5vcmcNCmh0dHBzOi8v d3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xlbW9uYWRlDQo= ------_=_NextPart_001_01C6C657.7F79C322 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMg RXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNi41Ljc2MzguMSI+DQo8VElUTEU+UmU6IFtsZW1vbmFk ZV0gJ01PVkUnICh3YXMgTm90aWZpY2F0aW9ucyBmb3IgbXVsdGlwbGUgZGV2aWNlc3BlciB1c2Vy KTwvVElUTEU+DQo8L0hFQUQ+DQo8Qk9EWT4NCjwhLS0gQ29udmVydGVkIGZyb20gdGV4dC9wbGFp biBmb3JtYXQgLS0+DQoNCjxQPjxGT05UIFNJWkU9Mj5bU3BlYWtpbmcgYXMgYSBwYXJpY2lwYW50 LCBOT1QgYXMgYSBDaGFpcl08QlI+DQo8QlI+DQpJIGhhdmUgbmV2ZXIsIEVWRVIsIGluIG15IGV4 cGVyaWVuY2UgaGFkIGEgc2VydmljZSBwcm92aWRlciBvciBuZXRvd3JrIG9wZXJhdG9yIG1hbmRh dGUgdGhhdCBsZXZlbCBvZiBwcm90b2NvbCBvcGVyYXRpb24uJm5ic3A7IE1hbmRhdGluZyBhIHBy b3RvY29sIHN1aXRlLCB5ZXMuJm5ic3A7IERpY3RhdGluZyB0aGUgbWVjaGFuaWNzIG9mIHRoZSBz dWl0ZSwgTkVWRVIuJm5ic3A7IE9LLCB0aGVyZSBpcyBvbmUgY2F2ZWF0OiB3aGVuIGEgc2Vydmlj ZSBwcm92aWRlciBvciBvcGVyYXRvciBjYXJlcyB0aGF0IG11Y2ggYWJvdXQgdGhlIG9wZXJhdGlv biBvZiBhIHByb3RvY29sLCB5b3Ugd2lsbCB1c3VhbGxseSBzZWUgdGhleSBhcmUgb25lIG9mIHRo ZSBhdXRob3JzIG9mIHRoZSBwcm90b2NvbC48QlI+DQo8QlI+DQpNdWNoIHRvIG15IGNoYWdyaW4g KG9yLCBhZG1pdHRlZGx5LCBzb21ldGltZXMgdG8gbXkgYmVuZWZpdCksIG1vc3Qgb3BlcmF0b3Jz LCB3aGVuIGFza2VkIGFib3V0IHRoZWlyIHN0YW5kYXJkcyBwYXJ0aWNpcGF0aW9uLCBzYXksICZx dW90O3dlIG1vbml0b3IgdGhlIHN0YW5kYXJkcyBib2RpZXMsIGJ1dCB3ZSByZWx5IG9uIG91ciB2 ZW5kb3JzIHRvIHRlbGwgdXMgd2hhdCBpcyBpbXBvcnRhbnQuJnF1b3Q7PEJSPg0KPEJSPg0KV0hZ IHdvdWxkIHRoZXkgY2FyZSBhYm91dCBhIHRyYXNoIG1haWxib3g/Jm5ic3A7IFRoZWlyIHNwZWNp ZnlpbmcgdGhlIHVzZXIgaW50ZXJmYWNlIEkgd291bGQgYmVsaWV2ZS4mbmJzcDsgSG93ZXZlciwg dGhlaXIgc3BlY2lmeWluZyB0aGUgdW5kZXJseWluZyBwcm90b2NvbCBtZWNoYW5pY3MgaXMgd2F5 IGJleW9uZCBteSBleHBlcmllbmNlLiZuYnNwOyBIb3cgd291bGQgdGhleSBrbm93PyZuYnNwOyBX aG8gaXMgZHJpdmluZyB0aGVtIHRvIHdhbnQgdGhpcyBvbmUgZmVhdHVyZSwgd2hpY2ggYnkgdGhl IHdheSByZWR1Y2VzIHRoZWlyIGNob2ljZSBvZiBJTUFQLWNvbXBsaWVudCBzZXJ2ZXJzIGFuZCBp bmRlcGVuZGVudCBJTUFQLWNvbXBsaWFudCBjbGllbnRzIHRvIGV4YWN0bHkgemVybz88QlI+DQo8 QlI+DQpJIHdpbGwgaGFwcGlseSBiZW5kIG92ZXIgdG8gZG8gdGhpcyBpZiBvbmUgY291bGQgcHJv ZHVjZSB0aHJlZSBzZXJ2aWNlIHByaXZpZGVycyBvciBvcGVyYXRvcnMgdGhhdCByZWFsbHkgd2Fu dCB0byBkaWN0YXRlIHRoZSBwcm90b2NvbCBvcGVyYXRpb24gYXQgdGhhdCBsZXZlbCBBTkQgVU5E RVJTVEFORCBUSEUgSU1QTElDQVRJT05TIHRvIGRlbWFuZCB0cmFzaCBtYWlsYm94ZXMuPEJSPg0K PEJSPg0KPEJSPg0KLS08QlI+DQpTZW50IGZyb20gbXkgbGVzcy10aGFuLWlkZWFsLCBub24tUGFs bSB3aXJlbGVzcyBkZXZpY2U7IEkgY2FuJ3Qgd2FpdCBmb3IgTEVNT05BREUhISE8QlI+DQo8QlI+ DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tPEJSPg0KRnJvbTogUmFuZGFsbCBHZWxsZW5z ICZsdDtyYW5keUBxdWFsY29tbS5jb20mZ3Q7PEJSPg0KVG86IFpvbHRhbi5PcmRvZ2hAbm9raWEu Y29tICZsdDtab2x0YW4uT3Jkb2doQG5va2lhLmNvbSZndDs8QlI+DQpDYzogbGVtb25hZGVAaWV0 Zi5vcmcgJmx0O2xlbW9uYWRlQGlldGYub3JnJmd0OzxCUj4NClNlbnQ6IFR1ZSBBdWcgMjIgMTc6 MDM6MTIgMjAwNjxCUj4NClN1YmplY3Q6IFJFOiBbbGVtb25hZGVdICdNT1ZFJyAod2FzIE5vdGlm aWNhdGlvbnMgZm9yIG11bHRpcGxlIGRldmljZXNwZXIgdXNlcik8QlI+DQo8QlI+DQpBdCA3OjU2 IEFNICswMzAwIDgvMjIvMDYsICZsdDtab2x0YW4uT3Jkb2doQG5va2lhLmNvbSZndDsgd3JvdGU6 PEJSPg0KPEJSPg0KJmd0OyZuYnNwOyZuYnNwOyAmZ3Q7VGhlcmUncyBhIGRpZmZlcmVuY2UgYmV0 d2VlbiB3aGVyZSBhIG1lc3NhZ2UgaXMgb24gdGhlIHNlcnZlciw8QlI+DQomZ3Q7Jmd0O2FuZCBo b3cgdGhlIG1lc3NhZ2UgaXMgcHJlc2VudGVkIHRvIHRoZSB1c2VyLiZuYnNwOyBJZiBjbGllbnRz IHdhbnQ8QlI+DQomZ3Q7Jmd0O3RvIHByZXNlbnQgYSBkaXN0aW5jdCAmcXVvdDtUcmFzaCZxdW90 OyBtYWlsYm94IHRvIHRoZSB1c2VyLCB0aGF0IGlzPEJSPg0KJmd0OyZndDtmaW5lLiZuYnNwOyBG b3JjaW5nIHRoZSBtZXRhcGhvciB0byBiZSBsaXRlcmFsbHkgdHJ1ZSBpcyBhIHBvb3IgdXNlPEJS Pg0KJmd0OyZndDtvZiBJTUFQIGFuZCBjYXVzZXMgcHJvYmxlbXMuJm5ic3A7IE1ha2luZyBpdCBl YXN5IGZvciBjbGllbnRzIHRvPEJSPg0KJmd0OyZndDtlZmZpY2llbnRseSBwcmVzZW50IGEgVHJh c2ggbWV0YXBob3IgdG8gdXNlcnMgaXMgYSBnb29kIHRoaW5nLjxCUj4NCiZndDsmZ3Q7Jm5ic3A7 IEkgYXNzdW1lIHRoZSB1c2VycyBkb24ndCBjYXJlIHdoaWNoIGVsZW1lbnRzIG9mIHRoZSBwcm90 b2NvbDxCUj4NCiZndDsmZ3Q7YXJlIHVzZWQgaW4gd2hpY2ggd2F5cyBieSB0aGUgY2xpZW50LjxC Uj4NCiZndDsmZ3Q7VGhleSB3YW50IHRvIG1hbmFnZSBtZXNzYWdlcyBpbiBhIHdheSB0aGF0IGZl ZWxzIG5hdHVyYWwgZm9yIHRoZW0uPEJSPg0KJmd0OzxCUj4NCiZndDsmbmJzcDsgU29tZWhvdyB0 aGlzIHRocmVhZCB3ZW50IGJhY2sgdG8gZGlzY3Vzc2luZyBUcmFzaCBpbnN0ZWFkIG9mIE1PVkUu PEJSPg0KJmd0OyZuYnNwOyBJIHJlYWQgdGhyb3VnaCBNYXJrJ3MgZW1haWwgYXMgd2VsbC4gSSBh Y2NlcHQgd2hhdCBZb3UgYXJlIHNheWluZyAtIG15PEJSPg0KJmd0OyZuYnNwOyB3b3JyeSBpcyB0 aGF0IHRoZSBvcGVyYXRvcnMgd2lsbCBzYXkgYXQgdGhlIGxhc3QgbWludXRlICh3aGVuIExFTU9O QURFPEJSPg0KJmd0OyZuYnNwOyBpcyBhbHJlYWR5IGRvbmUpIHRoYXQgdGhleSB3YW50IGEgc2Vw YXJhdGUgdHJhc2ggYW5kIGZvcmNlIHVzIHRvIGRvPEJSPg0KJmd0OyZuYnNwOyBzb21ldGhpbmcg cHJvcHJpZXRhcnkgKEkgbWVhbiBpdCB3aWxsIGJlIGEgc3RhbmRhcmQgYW55d2F5IGluIE9NQSwg YnV0PEJSPg0KJmd0OyZuYnNwOyBtaWdodCBub3QgYmUgaW4gbGluZSB3aXRoIExFTU9OQURFKS48 QlI+DQo8QlI+DQpJZiBvcGVyYXRvcnMgdHJ5IHRvIG1hbmRhdGUgYSBUcmFzaCBtYWlsYm94IGlu IE9NQSwgbXkgYWR2aXNlIHdvdWxkPEJSPg0KYmUgdG8gdHJ5IGFuZCBmb2N1cyB0aGUgcmVxdWly ZW1lbnQgb24gd2hhdCBpcyBuZWNlc3NhcnkgdG8gcGVybWl0PEJSPg0KdGhlIGRlc2lyZWQgdXNl ciBleHBlcmllbmNlIGFuZCBvbiBpbnRlcm9wZXJhYmlsaXR5LiZuYnNwOyBJbiBvdGhlciB3b3Jk cyw8QlI+DQppZiBvcGVyYXRvcnMgd2FudCB0byBiZSBzdXJlIHRoYXQgdGhlaXIgdXNlcnMgd2ls bCBzZWUgYSB0cmFzaDxCUj4NCm1ldGFwaG9yLCBpdCBzaG91bGQgbm90IG1hdHRlciB0byB0aGVt IGlmIHRoaXMgaXMgaW1wbGVtZW50ZWQgd2l0aCBhPEJSPg0KZGlzdGluY3QgdHJhc2ggbWFpbGJv eCBvbiB0aGUgc2VydmVyIG9yIG9uIHRoZSBjbGllbnQsIGFzIGxvbmcgYXMgdGhlPEJSPg0Kc29s dXRpb24gaW50ZXJvcGVyYXRlcy4mbmJzcDsgRG9pbmcgaXQgb24gdGhlIGNsaWVudCBpcyBhY3R1 YWxseSBtb3JlPEJSPg0KaW50ZXJvcGVyYWJsZSwgc2luY2UgaXQgaXMgcmV2ZXJzaWJsZSBieSBh bnkgY2xpZW50LjxCUj4NCi0tPEJSPg0KUmFuZGFsbCBHZWxsZW5zPEJSPg0KT3BpbmlvbnMgYXJl IHBlcnNvbmFsOyZuYnNwOyZuYnNwOyZuYnNwOyBmYWN0cyBhcmUgc3VzcGVjdDsmbmJzcDsmbmJz cDsmbmJzcDsgSSBzcGVhayBmb3IgbXlzZWxmIG9ubHk8QlI+DQotLS0tLS0tLS0tLS0tLSBSYW5k b21seS1zZWxlY3RlZCB0YWc6IC0tLS0tLS0tLS0tLS0tLTxCUj4NCkFuIGFsZ29yaXRobSBtdXN0 IGJlIHNlZW4gdG8gYmUgYmVsaWV2ZWQuJm5ic3A7IC0tIERvbmFsZCBLbnV0aDxCUj4NCjxCUj4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPg0KbGVt b25hZGUgbWFpbGluZyBsaXN0PEJSPg0KbGVtb25hZGVAaWV0Zi5vcmc8QlI+DQo8QSBIUkVGPSJo dHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sZW1vbmFkZSI+aHR0cHM6Ly93 d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbGVtb25hZGU8L0E+PEJSPg0KPC9GT05UPg0K PC9QPg0KDQo8L0JPRFk+DQo8L0hUTUw+ ------_=_NextPart_001_01C6C657.7F79C322-- --===============0647297239== 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 --===============0647297239==-- From lemonade-bounces@ietf.org Tue Aug 22 22:22:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFiO3-0001fA-Os; Tue, 22 Aug 2006 22:22:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFiO3-0001bT-2N for lemonade@ietf.org; Tue, 22 Aug 2006 22:22:35 -0400 Received: from outbound.cantata.com ([208.236.123.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFiO1-0005O0-Nb for lemonade@ietf.org; Tue, 22 Aug 2006 22:22:35 -0400 Received: from ma02exchtmp01.Cantata.com ([10.128.18.41]) by outbound.Cantata.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Aug 2006 22:22:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Aug 2006 22:22:50 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: P-IMAP and lemonade Thread-Index: AcbGWwggrdUVjvscQ7mhLhgBOBM/Aw== From: "Burger, Eric" To: X-OriginalArrivalTime: 23 Aug 2006 02:22:52.0316 (UTC) FILETIME=[09125DC0:01C6C65B] X-Spam-Score: 0.3 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Subject: [lemonade] P-IMAP and lemonade X-BeenThere: lemonade@ietf.org X-Mailman-Version: 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="===============1143238397==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============1143238397== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6C65B.08200882" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6C65B.08200882 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 W0FzIENoYWlyXQ0KDQpJIHdhcyBob3BpbmcgdGhpcyBkaXNjdXNzaW9uIHdhcyBnb2luZyB0byBj bG9zZSBvbiBpdHMgb3duLCBidXQgaXQgaXMgbm90IHN0b3BwaW5nIG9uIGl0cyBvd24uICBIZXJl IGlzIHRoZSB3b3JrIGdyb3VwJ3Mgb2ZmaWNpYWwgcG9zaXRpb24gb24gUC1JTUFQLiAgSSBkbyBu b3QgYmVsaWV2ZSB0aGVyZSBpcyBhbnl0aGluZyBuZXcgaGVyZSB0aGF0IGhhcyBub3QgYmVlbiBz YWlkIG9uIHRoZSBsc2l0LCBidXQgaGVyZSBpdCBpcyBpbiBhIHNpbmdsZSBtZXNzYWdlICBJZiB5 b3UgZG8gbm90IGxpa2UgaXQgb3IgZG8gbm90IHVuZGVyc3RhbmQgaXQsIHBsZWFzZSBlLW1haWwg bWUgb2ZmIGxpc3QuDQoNClAtSU1BUCB3YXMgYW4gaW5kaXZpZHVhbCBzdWJtaXNzaW9uIGZyb20g U3RlcGhhbmUsIFJheSwgZXQgYWwuICBBcyBzdWNoLCBpdCBoYXMgbm8gc3RhbmRpbmcgYXMgYSBz dGFuZGFyZHMtdHJhY2sgZG9jdW1lbnQuICBQbGVhc2UgcmVmZXIgdG8gUkZDMjAyNiBmb3IgcHJl Y2lzZWx5IHdoYXQgdGhhdCBtZWFucy4NCg0KVW5xdWVzdGlvbmFibHksIFAtSU1BUCB3YXMgb25l IG9mIHRoZSBtb3N0IGltcG9ydGFudCBjb250cmlidXRpb25zIHRvIHRoZSBsZW1vbmFkZSBlZmZv cnQuICBJdCBwcm92aWRlZCBhIGNvbXByZWhlbnNpdmUgZnJhbXdvcmsgYW5kLCBhcyBpbXBvcnRh bnQsIHRoZXJlIHdhcyBzb21lIHdvcmtpbmcgY29kZSBhbmQgb3BlcmF0aW9uYWwgZXhwZXJpZW5j ZS4gIE1hbnkgd2lsbCBub3RlIHRoYXQgcXVpdGUgYSBmZXcgbGVtb25hZGUgZXh0ZW5zaW9ucyBh cmUgdGFrZW4gZGlyZWN0bHkgb3IgaW5zcGlyZWQgYnkgUC1JTUFQLiAgTW9yZW92ZXIsIHRoZSBh dXRob3JzIG9mIG1hbnkgb2YgdGhlIGxlbW9uYWRlIGRvY3VtZW50cyBhcmUgdGhlIHNlbGYtc2Ft ZSBhdXRob3JzIG9mIFAtSU1BUC4NCg0KVGhhdCBzYWlkLCB0aGVyZSBhcmUgc29tZSBzdHJ1Y3R1 cmFsIGFuZCBpbXBsZW1lbnRhdGlvbiBpc3N1ZXMgaW4gUC1JTUFQIHRoYXQgbWFrZSBpdCB1bnN1 aXRhYmxlIGFzIGFuIEludGVybmV0IHByb3RvY29sLiAgVG8gYmUgY2xlYXIsIHRoaXMgaXMgbm90 IGFuIGluZGljdG1lbnQgb2YgUC1JTUFQLiAgUmF0aGVyLCBpdCBpcyBhIHJlZmxlY3Rpb24gb2Yg dGhlIHVuaXF1ZSBzY2FsZSwgc2VjdXJpdHksIGFuZCBvcGVyYXRpb25hbCByZXF1aXJlbWVudHMg b2YgdGhlIEludGVybmV0IHRoYXQgbWF5IG5vdCBiZSBwcmVzZW50IGluIGEgY2xvc2VkLCBsb2Nh bCBuZXR3b3JrLg0KDQpCZWNhdXNlIG9mIHRoZXNlIGlzc3VlcywgdGhlIGxlbW9uYWRlIHdvcmsg Z3JvdXAgZGlkIG5vdCB0YWtlIGFsbCBvZiBQLUlNQVAuICBMaWtld2lzZSwgdGhlIFAtSU1BUCBh dXRob3JzIGhhdmUgd29ya2VkIGhhcmQgKGFuZCBzdWNjZXNzZnVsbHksIEkgbWlnaHQgYWRkKSB0 byBwcm9kdWNlIHByb3RvY29scyB0aGF0IHdpbGwgd29yayBpbiB0aGUgSW50ZXJuZXQuICBUaGVz ZSBhcmUgdGhlIHByb3RvY29scyBvZiB0aGUgbGVtb25hZGUgc3VpdGUsLiAgTW9zdCBvZiB0aGVz ZSBwcm90b2NvbHMgYXJlIGluIGxhc3QgY2FsbCBvciB3aWxsIGJlIGluIGxhc3QgY2FsbCBzaG9y dGx5Lg0KDQpJdCBpcyB3b3J0aCBub3RpbmcgdGhhdCBhbnlvbmUgY2FuIHN1Ym1pdCBhbiBJbnRl cm5ldCBEcmFmdCwgYW5kIGFueW9uZSBjYW4gcmVxdWVzdCB0aGUgUkZDIEVkaXRvciB0byBwdWJs aXNoIHRoZSBkcmFmdC4gIEhvd2V2ZXIsIHRoZSBSRkMgRWRpdG9yIHdpbGwgYXNrIHRoZSBJRVNH IGlmIHRoZXJlIGlzIGFueSBzaW1pbGFyIG9yIGNvbmZsaWN0aW5nIHdvcmsgaW4gdGhlIElFVEYu ICBJbiB0aGlzIGNhc2UsIGdpdmVuIHRoZSBoZXJpdGFnZSBvZiBtdWNoIG9mIHRoZSBsZW1vbmFk ZSBzdWl0ZSB3aXRoIHJlc3BlY3QgdG8gUC1JTUFQLCB3ZSB3b3VsZCBoYXZlIHRvIGhvbGQgcHVi bGljYXRpb24gb2YgUC1JTUFQLCBldmVuIGFzIGFuIEluZGl2aWR1YWwgSW5mb3JtYXRpb25hbCAo aS5lLiwgbm8gSUVURiBzdGFiZGFyZHMgc3RhdHVzIHdoYXRzb2V2ZXIpLCB1bnRpbCBhZnRlciB0 aGUgbGVtb25hZGUgd29yayBpcyBjb21wbGV0ZS4NCg0KQWdhaW4sIGlmIHlvdSBoYXZlIGFueSBx dWVzdGlvbnMgYWJvdXQgdGhpcywgcGxlYXNlIGRvIG5vdCBoZXNpdGF0ZSB0byBzZW5kIG1lIGFu IGUtbWFpbCBvZmYtbGlzdC4NCg0KLS0NCi0gRXJpYyBCdXJnZXINCi0gQ2hhaXIsIElFVEYgTGVt b25hZGUgd29yayBncm91cA0KDQotLQ0KU2VudCBmcm9tIG15IGxlc3MtdGhhbi1pZGVhbCwgbm9u LVBhbG0gd2lyZWxlc3MgZGV2aWNlOyBJIGNhbid0IHdhaXQgZm9yIExFTU9OQURFISEhDQo= ------_=_NextPart_001_01C6C65B.08200882 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMg RXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNi41Ljc2MzguMSI+DQo8VElUTEU+UC1JTUFQIGFuZCBs ZW1vbmFkZTwvVElUTEU+DQo8L0hFQUQ+DQo8Qk9EWT4NCjwhLS0gQ29udmVydGVkIGZyb20gdGV4 dC9wbGFpbiBmb3JtYXQgLS0+DQoNCjxQPjxGT05UIFNJWkU9Mj5bQXMgQ2hhaXJdPEJSPg0KPEJS Pg0KSSB3YXMgaG9waW5nIHRoaXMgZGlzY3Vzc2lvbiB3YXMgZ29pbmcgdG8gY2xvc2Ugb24gaXRz IG93biwgYnV0IGl0IGlzIG5vdCBzdG9wcGluZyBvbiBpdHMgb3duLiZuYnNwOyBIZXJlIGlzIHRo ZSB3b3JrIGdyb3VwJ3Mgb2ZmaWNpYWwgcG9zaXRpb24gb24gUC1JTUFQLiZuYnNwOyBJIGRvIG5v dCBiZWxpZXZlIHRoZXJlIGlzIGFueXRoaW5nIG5ldyBoZXJlIHRoYXQgaGFzIG5vdCBiZWVuIHNh aWQgb24gdGhlIGxzaXQsIGJ1dCBoZXJlIGl0IGlzIGluIGEgc2luZ2xlIG1lc3NhZ2UmbmJzcDsg SWYgeW91IGRvIG5vdCBsaWtlIGl0IG9yIGRvIG5vdCB1bmRlcnN0YW5kIGl0LCBwbGVhc2UgZS1t YWlsIG1lIG9mZiBsaXN0LjxCUj4NCjxCUj4NClAtSU1BUCB3YXMgYW4gaW5kaXZpZHVhbCBzdWJt aXNzaW9uIGZyb20gU3RlcGhhbmUsIFJheSwgZXQgYWwuJm5ic3A7IEFzIHN1Y2gsIGl0IGhhcyBu byBzdGFuZGluZyBhcyBhIHN0YW5kYXJkcy10cmFjayBkb2N1bWVudC4mbmJzcDsgUGxlYXNlIHJl ZmVyIHRvIFJGQzIwMjYgZm9yIHByZWNpc2VseSB3aGF0IHRoYXQgbWVhbnMuPEJSPg0KPEJSPg0K VW5xdWVzdGlvbmFibHksIFAtSU1BUCB3YXMgb25lIG9mIHRoZSBtb3N0IGltcG9ydGFudCBjb250 cmlidXRpb25zIHRvIHRoZSBsZW1vbmFkZSBlZmZvcnQuJm5ic3A7IEl0IHByb3ZpZGVkIGEgY29t cHJlaGVuc2l2ZSBmcmFtd29yayBhbmQsIGFzIGltcG9ydGFudCwgdGhlcmUgd2FzIHNvbWUgd29y a2luZyBjb2RlIGFuZCBvcGVyYXRpb25hbCBleHBlcmllbmNlLiZuYnNwOyBNYW55IHdpbGwgbm90 ZSB0aGF0IHF1aXRlIGEgZmV3IGxlbW9uYWRlIGV4dGVuc2lvbnMgYXJlIHRha2VuIGRpcmVjdGx5 IG9yIGluc3BpcmVkIGJ5IFAtSU1BUC4mbmJzcDsgTW9yZW92ZXIsIHRoZSBhdXRob3JzIG9mIG1h bnkgb2YgdGhlIGxlbW9uYWRlIGRvY3VtZW50cyBhcmUgdGhlIHNlbGYtc2FtZSBhdXRob3JzIG9m IFAtSU1BUC48QlI+DQo8QlI+DQpUaGF0IHNhaWQsIHRoZXJlIGFyZSBzb21lIHN0cnVjdHVyYWwg YW5kIGltcGxlbWVudGF0aW9uIGlzc3VlcyBpbiBQLUlNQVAgdGhhdCBtYWtlIGl0IHVuc3VpdGFi bGUgYXMgYW4gSW50ZXJuZXQgcHJvdG9jb2wuJm5ic3A7IFRvIGJlIGNsZWFyLCB0aGlzIGlzIG5v dCBhbiBpbmRpY3RtZW50IG9mIFAtSU1BUC4mbmJzcDsgUmF0aGVyLCBpdCBpcyBhIHJlZmxlY3Rp b24gb2YgdGhlIHVuaXF1ZSBzY2FsZSwgc2VjdXJpdHksIGFuZCBvcGVyYXRpb25hbCByZXF1aXJl bWVudHMgb2YgdGhlIEludGVybmV0IHRoYXQgbWF5IG5vdCBiZSBwcmVzZW50IGluIGEgY2xvc2Vk LCBsb2NhbCBuZXR3b3JrLjxCUj4NCjxCUj4NCkJlY2F1c2Ugb2YgdGhlc2UgaXNzdWVzLCB0aGUg bGVtb25hZGUgd29yayBncm91cCBkaWQgbm90IHRha2UgYWxsIG9mIFAtSU1BUC4mbmJzcDsgTGlr ZXdpc2UsIHRoZSBQLUlNQVAgYXV0aG9ycyBoYXZlIHdvcmtlZCBoYXJkIChhbmQgc3VjY2Vzc2Z1 bGx5LCBJIG1pZ2h0IGFkZCkgdG8gcHJvZHVjZSBwcm90b2NvbHMgdGhhdCB3aWxsIHdvcmsgaW4g dGhlIEludGVybmV0LiZuYnNwOyBUaGVzZSBhcmUgdGhlIHByb3RvY29scyBvZiB0aGUgbGVtb25h ZGUgc3VpdGUsLiZuYnNwOyBNb3N0IG9mIHRoZXNlIHByb3RvY29scyBhcmUgaW4gbGFzdCBjYWxs IG9yIHdpbGwgYmUgaW4gbGFzdCBjYWxsIHNob3J0bHkuPEJSPg0KPEJSPg0KSXQgaXMgd29ydGgg bm90aW5nIHRoYXQgYW55b25lIGNhbiBzdWJtaXQgYW4gSW50ZXJuZXQgRHJhZnQsIGFuZCBhbnlv bmUgY2FuIHJlcXVlc3QgdGhlIFJGQyBFZGl0b3IgdG8gcHVibGlzaCB0aGUgZHJhZnQuJm5ic3A7 IEhvd2V2ZXIsIHRoZSBSRkMgRWRpdG9yIHdpbGwgYXNrIHRoZSBJRVNHIGlmIHRoZXJlIGlzIGFu eSBzaW1pbGFyIG9yIGNvbmZsaWN0aW5nIHdvcmsgaW4gdGhlIElFVEYuJm5ic3A7IEluIHRoaXMg Y2FzZSwgZ2l2ZW4gdGhlIGhlcml0YWdlIG9mIG11Y2ggb2YgdGhlIGxlbW9uYWRlIHN1aXRlIHdp dGggcmVzcGVjdCB0byBQLUlNQVAsIHdlIHdvdWxkIGhhdmUgdG8gaG9sZCBwdWJsaWNhdGlvbiBv ZiBQLUlNQVAsIGV2ZW4gYXMgYW4gSW5kaXZpZHVhbCBJbmZvcm1hdGlvbmFsIChpLmUuLCBubyBJ RVRGIHN0YWJkYXJkcyBzdGF0dXMgd2hhdHNvZXZlciksIHVudGlsIGFmdGVyIHRoZSBsZW1vbmFk ZSB3b3JrIGlzIGNvbXBsZXRlLjxCUj4NCjxCUj4NCkFnYWluLCBpZiB5b3UgaGF2ZSBhbnkgcXVl c3Rpb25zIGFib3V0IHRoaXMsIHBsZWFzZSBkbyBub3QgaGVzaXRhdGUgdG8gc2VuZCBtZSBhbiBl LW1haWwgb2ZmLWxpc3QuPEJSPg0KPEJSPg0KLS08QlI+DQotIEVyaWMgQnVyZ2VyPEJSPg0KLSBD aGFpciwgSUVURiBMZW1vbmFkZSB3b3JrIGdyb3VwPEJSPg0KPEJSPg0KLS08QlI+DQpTZW50IGZy b20gbXkgbGVzcy10aGFuLWlkZWFsLCBub24tUGFsbSB3aXJlbGVzcyBkZXZpY2U7IEkgY2FuJ3Qg d2FpdCBmb3IgTEVNT05BREUhISE8L0ZPTlQ+DQo8L1A+DQoNCjwvQk9EWT4NCjwvSFRNTD4= ------_=_NextPart_001_01C6C65B.08200882-- --===============1143238397== 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 --===============1143238397==-- From lemonade-bounces@ietf.org Tue Aug 22 22:57:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFivH-0006hd-Ot; Tue, 22 Aug 2006 22:56:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFivG-0006gm-93 for lemonade@ietf.org; Tue, 22 Aug 2006 22:56:54 -0400 Received: from mxout7.cac.washington.edu ([140.142.32.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFivE-0001im-Uo for lemonade@ietf.org; Tue, 22 Aug 2006 22:56:54 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7N2uiTs007231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Aug 2006 19:56:45 -0700 X-Auth-Received: from Shimo-Tomobiki.panda.com ([65.122.177.186]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7N2ugcm026235 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 22 Aug 2006 19:56:44 -0700 Date: Tue, 22 Aug 2006 19:56:40 -0700 From: Mark Crispin To: "Burger, Eric" Subject: Re: [lemonade] 'MOVE' (was Notifications for multiple devicesper user) In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.22.194443 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: 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 On Tue, 22 Aug 2006, Burger, Eric wrote: > I have never, EVER, in my experience had a service provider or netowrk > operator mandate that level of protocol operation. Mandating a protocol > suite, yes. Dictating the mechanics of the suite, NEVER. +1 I take claims of "service provider or network operator mandates" with a rock of salt, equivalent to claims that "the protocol will die unless such-and-such feature is added." Either way, it's hyperbole. Sometimes I contact the service providers and/or network operators to verify that the claim is hyperbole without a shred of reality. I have yet to be disappointed. -- 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 Wed Aug 23 01:12:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFl1j-0003xE-TP; Wed, 23 Aug 2006 01:11:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFl1j-0003x6-HY for lemonade@ietf.org; Wed, 23 Aug 2006 01:11:43 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFl1i-0003E5-3t for lemonade@ietf.org; Wed, 23 Aug 2006 01:11:43 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.7) with ESMTP id k7N5BXes028770; Wed, 23 Aug 2006 08:11:41 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 08:11:40 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 08:11:39 +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] 'MOVE' (was Notifications for multiple devicesper user) Date: Wed, 23 Aug 2006 08:11:06 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657D532F4@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] 'MOVE' (was Notifications for multiple devicesper user) Thread-Index: AcbGL0jIRnLUkvFpSua7NPeylJFGxwAQeFYg From: To: X-OriginalArrivalTime: 23 Aug 2006 05:11:39.0655 (UTC) FILETIME=[9D6FA970:01C6C672] X-Spam-Score: 0.2 (/) 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 Hi Randall, >If operators try to mandate a Trash mailbox in OMA, my advise=20 >would be to try and focus the requirement on what is necessary=20 >to permit the desired user experience and on interoperability.=20 > In other words, if operators want to be sure that their users=20 >will see a trash metaphor, it should not matter to them if=20 >this is implemented with a distinct trash mailbox on the=20 >server or on the client, as long as the solution=20 >interoperates. Doing it on the client is actually more=20 >interoperable, since it is reversible by any client. I agree with You. But for interoperabiity You need to know the name of the Trash mailbox - this is where the original arguments started from. We need to identify the name of the trash mailbox - along with other special mailboxes. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Aug 23 07:35:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFr12-0004G3-Mn; Wed, 23 Aug 2006 07:35:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFr11-0004Fx-2l for lemonade@ietf.org; Wed, 23 Aug 2006 07:35:23 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFr0y-0004lq-Kl for lemonade@ietf.org; Wed, 23 Aug 2006 07:35:23 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Wed, 23 Aug 2006 12:35:18 +0100 Message-ID: <44EC2CBB.4070209@isode.com> Date: Wed, 23 Aug 2006 11:23: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 MIME-Version: 1.0 To: Zoltan.Ordogh@nokia.com Subject: Re: [lemonade] 'MOVE' (was Notifications for multiple devicesper user) References: <0FA975F2D8295A448BE3ADC161244657D532F4@esebe199.NOE.Nokia.com> In-Reply-To: <0FA975F2D8295A448BE3ADC161244657D532F4@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: e5ba305d0e64821bf3d8bc5d3bb07228 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 Randall, > > >>If operators try to mandate a Trash mailbox in OMA, my advise >>would be to try and focus the requirement on what is necessary >>to permit the desired user experience and on interoperability. >>In other words, if operators want to be sure that their users >>will see a trash metaphor, it should not matter to them if >>this is implemented with a distinct trash mailbox on the >>server or on the client, as long as the solution >>interoperates. Doing it on the client is actually more >>interoperable, since it is reversible by any client. >> >> >I agree with You. But for interoperabiity You need to know the name of >the Trash mailbox - this is where the original arguments started from. >We need to identify the name of the trash mailbox - along with other >special mailboxes. > > Dave Cridland and I will work on a draft that would describe mailbox tagging and will also define some initial tags for Sent Mail, Drafts, etc. Alexey P.S. Can we please stop discussing this topic now :-), at least until people see the first revision of the draft. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Aug 23 08:25:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFrnA-0002T8-CA; Wed, 23 Aug 2006 08:25:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFrn8-0002RT-Hu for lemonade@ietf.org; Wed, 23 Aug 2006 08:25:06 -0400 Received: from static-71-240-120-213.pitt.east.verizon.net ([71.240.120.213] helo=mulberrymail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFrn5-0001mp-6s for lemonade@ietf.org; Wed, 23 Aug 2006 08:25:06 -0400 Received: from [10.0.1.2] ([10.0.1.2]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id k7NCP285025199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Aug 2006 08:25:02 -0400 Date: Wed, 23 Aug 2006 08:25:01 -0400 From: Cyrus Daboo To: Alexey Melnikov , Zoltan.Ordogh@nokia.com Subject: Re: [lemonade] 'MOVE' (was Notifications for multiple devicesper user) Message-ID: In-Reply-To: <44EC2CBB.4070209@isode.com> References: <0FA975F2D8295A448BE3ADC161244657D532F4@esebe199.NOE.Nokia.com> <44EC2CBB.4070209@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-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on piper.mulberrymail.com X-Spam-Score: 0.1 (/) 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 Hi Alexey, --On August 23, 2006 11:23:55 AM +0100 Alexey Melnikov wrote: >> I agree with You. But for interoperabiity You need to know the name of >> the Trash mailbox - this is where the original arguments started from. >> We need to identify the name of the trash mailbox - along with other >> special mailboxes. >> >> > Dave Cridland and I will work on a draft that would describe mailbox > tagging and will also define some initial tags for Sent Mail, Drafts, etc. I take it this will use the METADATA extension? If so, you will also need to write a LISTEXT/METADATA extension to allow clients to 'search' for mailboxes containing 'tags' (those mailboxes may not always be at the top-level of a hierarchy). BTW Speaking of tagging, it would be handy to have a way to tag individual messages in a mailbox using ANNOTATE, and have the server automatically expose the list of all tags in a mailbox via METADATA. That way searching all my mailboxes for messages with a specific tag can be broken in two - first LISTEXT to find matching mailboxes, then SEARCH within each. That avoids the need to SEARCH every mailbox. -- Cyrus Daboo _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Aug 23 08:28:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFrqp-0003qk-QY; Wed, 23 Aug 2006 08:28:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFrqo-0003qd-8T for lemonade@ietf.org; Wed, 23 Aug 2006 08:28:54 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFrql-0002Iz-Q4 for lemonade@ietf.org; Wed, 23 Aug 2006 08:28:54 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Wed, 23 Aug 2006 13:28:43 +0100 Message-ID: <44EC49C8.30708@isode.com> Date: Wed, 23 Aug 2006 13:27:52 +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: Cyrus Daboo Subject: Re: [lemonade] 'MOVE' (was Notifications for multiple devicesper user) References: <0FA975F2D8295A448BE3ADC161244657D532F4@esebe199.NOE.Nokia.com> <44EC2CBB.4070209@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: 69a74e02bbee44ab4f8eafdbcedd94a1 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 Cyrus Daboo wrote: > Hi Alexey, Hi Cyrus, > --On August 23, 2006 11:23:55 AM +0100 Alexey Melnikov > wrote: > >>> I agree with You. But for interoperabiity You need to know the name of >>> the Trash mailbox - this is where the original arguments started from. >>> We need to identify the name of the trash mailbox - along with other >>> special mailboxes. >> >> Dave Cridland and I will work on a draft that would describe mailbox >> tagging and will also define some initial tags for Sent Mail, Drafts, >> etc. > > I take it this will use the METADATA extension? We are thinking about LISTEXT extension, which can be implemented using METADATA. > If so, you will also need to write a LISTEXT/METADATA extension to > allow clients to 'search' for mailboxes containing 'tags' (those > mailboxes may not always be at the top-level of a hierarchy). Exactly. > BTW Speaking of tagging, it would be handy to have a way to tag > individual messages in a mailbox using ANNOTATE, and have the server > automatically expose the list of all tags in a mailbox via METADATA. > That way searching all my mailboxes for messages with a specific tag > can be broken in two - first LISTEXT to find matching mailboxes, then > SEARCH within each. That avoids the need to SEARCH every mailbox. Good idea (but might be difficult for servers), write a draft :-). _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Aug 23 13:28:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFwWK-0008WS-Vk; Wed, 23 Aug 2006 13:28:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFwWJ-0008WN-H6 for lemonade@ietf.org; Wed, 23 Aug 2006 13:28:03 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFwWH-000370-6h for lemonade@ietf.org; Wed, 23 Aug 2006 13:28:03 -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 k7NHRxg6029914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 23 Aug 2006 10:28:00 -0700 Received: from [[192.168.1.13]] (vpn-10-50-0-67.qualcomm.com [10.50.0.67]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7NHRvU4024738; Wed, 23 Aug 2006 10:27:58 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <0FA975F2D8295A448BE3ADC161244657D532F4@esebe199.NOE.Nokia.com> References: <0FA975F2D8295A448BE3ADC161244657D532F4@esebe199.NOE.Nokia.com> X-Mailer: Eudora for Mac OS X (dev alpha) X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Wed, 23 Aug 2006 10:26:50 -0700 To: From: Randall Gellens Subject: RE: [lemonade] 'MOVE' (was Notifications for multiple devicesper 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: 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 Hi Zoltan, At 8:11 AM +0300 8/23/06, wrote: > >Doing it on the client is actually more >>interoperable, since it is reversible by any client. > > I agree with You. But for interoperabiity You need to know the name of > the Trash mailbox Even if there was a mechanism to identify the Trash mailbox, we still have two problems: (1) existing clients won't use it; and (2) there is no way to know the original mailbox for messages which are in the Trash -- hence there is no way to properly undelete messages. Of course, clients can be updated to start using the mechanism to identify the Trash mailbox. But if clients have to be updated anyway, perhaps they can be updated to use the better Trash mechanism? One which would allow them to (1) show the user a Trash mailbox, (2) successfully undelete messages, and (3) be more efficient in bandwidth and memory. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- The curse of all Art is that the devotee or disciple is always more certain than the Priest. --Rudyard Kipling _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Aug 23 13:29:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFwXt-0000rA-Ih; Wed, 23 Aug 2006 13:29:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFwXs-0000r5-3J for lemonade@ietf.org; Wed, 23 Aug 2006 13:29:40 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFwXp-0003GO-G8 for lemonade@ietf.org; Wed, 23 Aug 2006 13:29:40 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.7) with ESMTP id k7NHTYOB025420 for ; Wed, 23 Aug 2006 20:29:36 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 20:28:48 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 20:28:46 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [lemonade] WGLC reconnect-client-01 Date: Wed, 23 Aug 2006 20:28:11 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657D539B7@esebe199.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] WGLC reconnect-client-01 Thread-Index: AcbG2YIEvpSoGxSlSY+2ncUvl5FrEA== From: To: X-OriginalArrivalTime: 23 Aug 2006 17:28:46.0155 (UTC) FILETIME=[967C01B0:01C6C6D9] X-Spam-Score: 0.2 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 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="===============1872317869==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============1872317869== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6C6D9.960AD122" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6C6D9.960AD122 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, here are my findings - all are editorial. 1. Title: "IMAP4 Extensions for" -> "IMAP4 Extension for" 2. Page 1. "Changes since draft-ietf-lemonade-reconnect-client-01.txt" = Since? It is -01 that I am reading now. Will the change history be kept = or removed? 3. Section 2, par. 1. "since a known moment" Could we be more specific? 4. Section 2, par. 4. "In particular this extension can be useful" = wording change suggestion to: "This extension can be particularly = useful" or "In particular this extension is useful" 5. Section 2, par. 4. "Such clients would need a way to quickly reconnect to the IMAP server, without forcing the user to experience long delay and pay big bills for the amount of traffic generated by resynchronization." Aye, I agree, but this extension is = not about reconnecting but resynch. Hence, I propose to change the = wording to: "Such clients would need a way to quickly resynchronize with the IMAP server, without forcing the = user to experience long delays and pay big bills for the amount of traffic generated by a less efficient resynchronization mechanism." 6. Section 2, par. 5. "By extending the SELECT command to perform the = additional resynchronization, this also allows" wording change suggestion to: = "Extending the SELECT command to perform the additional resynchronization also allows" 7. Section 5. "This document doesn't raise any new security concerns not = already raised by [CONDSTORE]." Suggest adding "or [EXPUNGED]" to the end of = the sentence. Thank You for considering them. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 ------_=_NextPart_001_01C6C6D9.960AD122 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [lemonade] WGLC reconnect-client-01

Hi all,
here are my findings - all = are editorial.

1. Title: "IMAP4 Extensions for" -> "IMAP4 Extension for"
2. Page 1. = "Changes since = draft-ietf-lemonade-reconnect-client-01.txt" Since? It is -01 that I am = reading now. Will the change history be kept or removed?

3. Section 2, par. 1. = "since a known = moment" Could we be = more specific?
4. Section 2, par. 4. = "In particular this = extension can be useful" wording change suggestion to: "This extension can be particularly useful" or = "In particular this = extension is useful"

5. Section 2, par. 4. = "Such clients would need = a way
   to quickly reconnect to the IMAP server, without forcing = the user to
   experience long delay and pay big bills for the amount of = traffic
   generated by resynchronization." Aye, I agree, but this = extension is not about reconnecting but resynch. Hence, I propose to = change the wording to:

"Such clients would need a way
   to quickly resynchronize with = the IMAP server, without forcing the user to
   experience long delays and pay big bills for = the amount of traffic
   generated by a = less efficient resynchronization = mechanism."
6. Section 2, par. 5. = "By extending the SELECT = command to perform the additional
   resynchronization, this also allows" wording change suggestion to: = "Extending the SELECT command to perform the = additional
   resynchronization also allows"
7. Section 5. = "This document doesn't = raise any new security concerns not already
   raised by [CONDSTORE]." Suggest adding "or = [EXPUNGED]" to the = end of the sentence.

Thank You for considering = them.

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


------_=_NextPart_001_01C6C6D9.960AD122-- --===============1872317869== 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 --===============1872317869==-- From lemonade-bounces@ietf.org Wed Aug 23 21:36:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG48r-0003Ls-6A; Wed, 23 Aug 2006 21:36:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG48p-0003Ln-FG for lemonade@ietf.org; Wed, 23 Aug 2006 21:36:19 -0400 Received: from outbound.cantata.com ([208.236.123.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG48m-00063m-7E for lemonade@ietf.org; Wed, 23 Aug 2006 21:36:19 -0400 Received: from ma02exchtmp01.Cantata.com ([10.128.18.41]) by outbound.Cantata.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 21:36:32 -0400 Received: from 10.128.41.41 ([10.128.41.41]) by ma02exchtmp01.Cantata.com ([10.128.18.41]) with Microsoft Exchange Server HTTP-DAV ; Thu, 24 Aug 2006 01:36:31 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Wed, 23 Aug 2006 21:09:02 -0400 From: Eric Burger To: IETF LEMONADE Message-ID: Thread-Topic: COMPRESS=mumble Thread-Index: AcbHGeLPIZE5vDMNEduR3wAWy5cvmw== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 24 Aug 2006 01:36:32.0050 (UTC) FILETIME=[BA513120:01C6C71D] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Eric Rescorla Subject: [lemonade] COMPRESS=mumble X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 private discussion with some security gurus, they were a bit worried about the LEMONADE work group defining security-related IANA registries. Likewise, they are worried that we are going to be mandating requirements on new TLS parameters to fit our world. One quick question: Rather than COMPRESS=DEFLATE or COMPRESS=LZS, why not use COMPRESS=1 and COMPRESS=63? That is, use the values that already exist in the already existing registry? My push back is it is a lot easier to understand "COMPRESS=DEFLATE" than it is to look up that "1" is DEFLATE. We also run the risk of people using 0x01. We could use the DESCRIPTION column from the registry, I suppose. The alternative is to create a new registry, that looks pretty much identical to the existing registry. [1] [1] http://www.iana.org/assignments/comp-meth-ids _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Aug 23 23:44:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG68u-0004BO-P7; Wed, 23 Aug 2006 23:44:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG68t-0004BG-HN for lemonade@ietf.org; Wed, 23 Aug 2006 23:44:31 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GG68m-0005cd-3J for lemonade@ietf.org; Wed, 23 Aug 2006 23:44:31 -0400 X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-6.tower-120.messagelabs.com!1156391062!9876189!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 2135 invoked from network); 24 Aug 2006 03:44:23 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-6.tower-120.messagelabs.com with SMTP; 24 Aug 2006 03:44:23 -0000 Received: from [135.210.73.99] (unknown[135.210.73.99](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20060824034422gw1003jo4ee> (Authid: tony); Thu, 24 Aug 2006 03:44:22 +0000 Message-ID: <44ED2094.4060106@att.com> Date: Wed, 23 Aug 2006 23:44:20 -0400 From: Tony Hansen User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: IETF LEMONADE Subject: Re: [lemonade] COMPRESS=mumble References: In-Reply-To: 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 last time this came up, I hummed to use the description column from the existing comp-meth-ids registry. Tony Hansen tony@att.com Eric Burger wrote: > In private discussion with some security gurus, they were a bit worried > about the LEMONADE work group defining security-related IANA registries. > Likewise, they are worried that we are going to be mandating requirements on > new TLS parameters to fit our world. > > One quick question: Rather than COMPRESS=DEFLATE or COMPRESS=LZS, why not > use COMPRESS=1 and COMPRESS=63? That is, use the values that already exist > in the already existing registry? > > My push back is it is a lot easier to understand "COMPRESS=DEFLATE" than it > is to look up that "1" is DEFLATE. We also run the risk of people using > 0x01. We could use the DESCRIPTION column from the registry, I suppose. > > The alternative is to create a new registry, that looks pretty much > identical to the existing registry. [1] > > > [1] http://www.iana.org/assignments/comp-meth-ids _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Aug 24 04:13:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGAKU-0003Kk-3R; Thu, 24 Aug 2006 04:12:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGAKR-0003Gs-P8 for lemonade@ietf.org; Thu, 24 Aug 2006 04:12: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 1GGAKR-0001dO-NQ for lemonade@ietf.org; Thu, 24 Aug 2006 04:12:43 -0400 Received: from smarthost.yourcomms.net ([195.8.160.124]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGAD4-0003i7-RS for lemonade@ietf.org; Thu, 24 Aug 2006 04:05:11 -0400 Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.12]) by smarthost.yourcomms.net (8.11.7p3+Sun/8.11.6) with ESMTP id k7O7qio01186 for ; Thu, 24 Aug 2006 08:52:48 +0100 (BST) 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=mumble Date: Thu, 24 Aug 2006 09:04:15 +0100 Message-ID: <22C8A0D5D5E095449AB509FE777B5F8002BB8C2E@svr-exchange.avocado.emccsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] COMPRESS=mumble Thread-Index: AcbHGeLPIZE5vDMNEduR3wAWy5cvmwAOcRMA From: "Ben Last" To: "Eric Burger" , "IETF LEMONADE" X-Spam-Score: -2.1 (--) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Eric Rescorla X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 [mailto:eburger@cantata.com] wrote at 24 August 2006 02:09: >One quick question: Rather than COMPRESS=3DDEFLATE or COMPRESS=3DLZS, = why not use COMPRESS=3D1 and COMPRESS=3D63? >That is, use the values that already exist in the already existing registry? I guess one reason is consistency: IMAP is a verbose protocol that tends to use words rather than numbers, so using the algorithm names follows that patterns. Not really a technical rationale, though. Regards Ben EMCC Software Ltd _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Aug 24 05:43:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGBjY-0001se-IB; Thu, 24 Aug 2006 05:42:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGBjX-0001sZ-RX for lemonade@ietf.org; Thu, 24 Aug 2006 05:42:43 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGBjT-00075N-Co for lemonade@ietf.org; Thu, 24 Aug 2006 05:42:43 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Thu, 24 Aug 2006 10:42:33 +0100 Message-ID: <44ED746D.9090509@isode.com> Date: Thu, 24 Aug 2006 10:42: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: Eric Burger Subject: Re: [lemonade] COMPRESS=mumble 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: 7d33c50f3756db14428398e2bdedd581 Cc: IETF LEMONADE , Eric Rescorla X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 wrote: >My push back is it is a lot easier to understand "COMPRESS=DEFLATE" than it >is to look up that "1" is DEFLATE. We also run the risk of people using >0x01. > I agree. >We could use the DESCRIPTION column from the registry, I suppose. > > Make sense to me. >The alternative is to create a new registry, that looks pretty much >identical to the existing registry. [1] > > >[1] http://www.iana.org/assignments/comp-meth-ids > > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Aug 24 08:00:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGDsl-0004nX-Dm; Thu, 24 Aug 2006 08:00:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGDsk-0004n6-DD for lemonade@ietf.org; Thu, 24 Aug 2006 08:00:22 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGDsh-0002OI-Tx for lemonade@ietf.org; Thu, 24 Aug 2006 08:00:22 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Thu, 24 Aug 2006 13:00:17 +0100 Message-ID: <44ED94AD.4070105@isode.com> Date: Thu, 24 Aug 2006 12:59: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 To: Zoltan.Ordogh@nokia.com Subject: Re: [lemonade] WGLC reconnect-client-01 References: <0FA975F2D8295A448BE3ADC161244657D539B7@esebe199.NOE.Nokia.com> In-Reply-To: <0FA975F2D8295A448BE3ADC161244657D539B7@esebe199.NOE.Nokia.com> 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: 769a46790fb42fbb0b0cc700c82f7081 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 Zoltan.Ordogh@nokia.com wrote: > Hi all, > here are my findings - all are editorial. > Thanks for the comments. They all look fine. Some minor comments below. > 1. Title: "IMAP4 Extensions for" -> "IMAP4 Extension for" > 2. Page 1. "Changes since draft-ietf-lemonade-reconnect-client-01.txt" > Since? It is -01 that I am reading now. Will the change history be > kept or removed? > Ah, my mistake. Somehow I've decided that we are at -02. Anyway, this section will be removed. > 3. Section 2, par. 1. "since a known moment" Could we be more specific? > CONDSTORE uses modification sequences, which effectively define moment in time. Do you think this should be spelled out? > 4. Section 2, par. 4. "In particular this extension can be useful" > wording change suggestion to: "This extension can be particularly > useful" or "In particular this extension is useful" > > 5. Section 2, par. 4. "Such clients would need a way > to quickly reconnect to the IMAP server, without forcing the user to > experience long delay and pay big bills for the amount of traffic > generated by resynchronization." Aye, I agree, but this extension > is not about reconnecting but resynch. Hence, I propose to change the > wording to: > > "Such clients would need a way > to quickly resynchronize with the IMAP server, without forcing the > user to > experience long delays and pay big bills for the amount of traffic > generated by a less efficient resynchronization mechanism." > 6. Section 2, par. 5. "By extending the SELECT command to perform the > additional > resynchronization, this also allows" wording change suggestion to: > "Extending the SELECT command to perform the additional > resynchronization also allows" > 7. Section 5. "This document doesn't raise any new security concerns > not already > raised by [CONDSTORE]." Suggest adding "or [EXPUNGED]" to the end > of the sentence. > Sure. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Aug 24 08:47:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGEcD-0008BO-AM; Thu, 24 Aug 2006 08:47:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGEcC-0008BJ-Lj for lemonade@ietf.org; Thu, 24 Aug 2006 08:47:20 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GGEc6-0001Pv-88 for lemonade@ietf.org; Thu, 24 Aug 2006 08:47:20 -0400 X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-14.tower-120.messagelabs.com!1156423632!12034596!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 11513 invoked from network); 24 Aug 2006 12:47:13 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-14.tower-120.messagelabs.com with SMTP; 24 Aug 2006 12:47:13 -0000 Received: from [135.91.110.64] (thansen-n.mt.att.com[135.91.110.64](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20060824124712gw1003jo4se> (Authid: tony); Thu, 24 Aug 2006 12:47:12 +0000 Message-ID: <44ED9FCE.7050802@att.com> Date: Thu, 24 Aug 2006 08:47:10 -0400 From: Tony Hansen User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: IETF LEMONADE Subject: Re: [lemonade] COMPRESS=mumble References: <44ED2094.4060106@att.com> In-Reply-To: <44ED2094.4060106@att.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: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Eric Rescorla X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org One issue with using the description column found in comp-meth-ids is that neither RFC 3749 nor RFC 3943 have placed any constraints on the names to be used in the DESCRIPTION column. While both DEFLATE and LZS fit our needs perfectly, neither of those RFCs have any verbiage, much less ABNF, associated with what those names look like. Tony Hansen tony@att.com Tony Hansen wrote: > The last time this came up, I hummed to use the description column from > the existing comp-meth-ids registry. > > Eric Burger wrote: >> In private discussion with some security gurus, they were a bit worried >> about the LEMONADE work group defining security-related IANA registries. >> Likewise, they are worried that we are going to be mandating requirements on >> new TLS parameters to fit our world. >> >> One quick question: Rather than COMPRESS=DEFLATE or COMPRESS=LZS, why not >> use COMPRESS=1 and COMPRESS=63? That is, use the values that already exist >> in the already existing registry? >> >> My push back is it is a lot easier to understand "COMPRESS=DEFLATE" than it >> is to look up that "1" is DEFLATE. We also run the risk of people using >> 0x01. We could use the DESCRIPTION column from the registry, I suppose. >> >> The alternative is to create a new registry, that looks pretty much >> identical to the existing registry. [1] >> >> >> [1] http://www.iana.org/assignments/comp-meth-ids > > > _______________________________________________ > 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 Aug 24 08:49:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGEdq-00026r-CW; Thu, 24 Aug 2006 08:49:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGEdp-00026m-8h for lemonade@ietf.org; Thu, 24 Aug 2006 08:49:01 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGEdn-0001pb-RY for lemonade@ietf.org; Thu, 24 Aug 2006 08:49:01 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id A41494ADE3; Thu, 24 Aug 2006 14:48:52 +0200 (CEST) Message-Id: <+0f+TF9ExoP+5K/eFIAAoQ.md5@libertango.oryx.com> Date: Thu, 24 Aug 2006 14:48:57 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] COMPRESS=mumble References: <44ED2094.4060106@att.com> <44ED9FCE.7050802@att.com> In-Reply-To: <44ED9FCE.7050802@att.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Tony Hansen , Eric Rescorla X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Tony Hansen writes: > One issue with using the description column found in comp-meth-ids is > that neither RFC 3749 nor RFC 3943 have placed any constraints on the > names to be used in the DESCRIPTION column. While both DEFLATE and > LZS fit our needs perfectly, neither of those RFCs have any verbiage, > much less ABNF, associated with what those names look like. Easily handled. COMPRESS can say that only if the description column meets so-and-so requirements can it be used with IMAP. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Aug 24 08:51:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGEga-0004AB-NA; Thu, 24 Aug 2006 08:51:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGEga-0004A6-0q for lemonade@ietf.org; Thu, 24 Aug 2006 08:51:52 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GGEgY-0002Gc-MI for lemonade@ietf.org; Thu, 24 Aug 2006 08:51:52 -0400 X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-11.tower-120.messagelabs.com!1156423909!12578094!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 14040 invoked from network); 24 Aug 2006 12:51:49 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-11.tower-120.messagelabs.com with SMTP; 24 Aug 2006 12:51:49 -0000 Received: from [135.91.110.64] (thansen-n.mt.att.com[135.91.110.64](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20060824125149gw1003jo4ue> (Authid: tony); Thu, 24 Aug 2006 12:51:49 +0000 Message-ID: <44EDA0E3.9050201@att.com> Date: Thu, 24 Aug 2006 08:51:47 -0400 From: Tony Hansen User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: lemonade@ietf.org Subject: Re: [lemonade] COMPRESS=mumble References: <44ED2094.4060106@att.com> <44ED9FCE.7050802@att.com> <+0f+TF9ExoP+5K/eFIAAoQ.md5@libertango.oryx.com> In-Reply-To: <+0f+TF9ExoP+5K/eFIAAoQ.md5@libertango.oryx.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 Cc: Eric Rescorla X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Another possibility is to add additional IANA considerations to the table, such that there *IS* a description (either verbiage or ABNF) associated with the DESCRIPTION column. Tony Hansen tony@att.com Arnt Gulbrandsen wrote: > Tony Hansen writes: >> One issue with using the description column found in comp-meth-ids is >> that neither RFC 3749 nor RFC 3943 have placed any constraints on the >> names to be used in the DESCRIPTION column. While both DEFLATE and LZS >> fit our needs perfectly, neither of those RFCs have any verbiage, much >> less ABNF, associated with what those names look like. > > Easily handled. COMPRESS can say that only if the description column > meets so-and-so requirements can it be used with IMAP. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Aug 24 13:02:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGIaY-0007Qs-U4; Thu, 24 Aug 2006 13:01:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGIaW-0007QT-VI for lemonade@ietf.org; Thu, 24 Aug 2006 13:01:52 -0400 Received: from mail146.messagelabs.com ([216.82.245.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GGIaR-0001fS-MW for lemonade@ietf.org; Thu, 24 Aug 2006 13:01:52 -0400 X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-5.tower-146.messagelabs.com!1156438906!1309625!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 6794 invoked from network); 24 Aug 2006 17:01:46 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-5.tower-146.messagelabs.com with SMTP; 24 Aug 2006 17:01:46 -0000 Received: from [135.91.110.64] (thansen-n.mt.att.com[135.91.110.64](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20060824170146gw1003jo84e> (Authid: tony); Thu, 24 Aug 2006 17:01:46 +0000 Message-ID: <44EDDB78.9000301@att.com> Date: Thu, 24 Aug 2006 13:01:44 -0400 From: Tony Hansen User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Eric Rescorla Subject: Re: [lemonade] COMPRESS=mumble References: <20060824143554.227E7222425@laser.networkresonance.com> In-Reply-To: <20060824143554.227E7222425@laser.networkresonance.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 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 it sounds like Arnt's proposal would be the best compromise: Names from the DESCRIPTION column can be used for IMAP if and only if they satisfy these requirements.... Tony Hansen tony@att.com Eric Rescorla wrote: > Tony Hansen wrote: >> Another possibility is to add additional IANA considerations to the >> table, such that there *IS* a description (either verbiage or ABNF) >> associated with the DESCRIPTION column. > > But this has exactly the property that I was concerned about: > LEMONADE is placing requirements on TLS documents... > > -Ekr _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Aug 24 15:49:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGLC5-0005N7-HE; Thu, 24 Aug 2006 15:48:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGLC4-0005Mu-Qe for lemonade@ietf.org; Thu, 24 Aug 2006 15:48: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 1GGLC4-0003sI-PA for lemonade@ietf.org; Thu, 24 Aug 2006 15:48:48 -0400 Received: from orthanc.ca ([209.89.70.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGL4A-0004m9-5v for lemonade@ietf.org; Thu, 24 Aug 2006 15:40:39 -0400 Received: from localhost (localhost [127.0.0.1]) (authenticated bits=0) by orthanc.ca (8.13.4/8.13.4) with ESMTP id k7OJePZG095244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Aug 2006 13:40:30 -0600 (MDT) (envelope-from lyndon@orthanc.ca) Date: Thu, 24 Aug 2006 12:40:25 -0700 (PDT) From: Lyndon Nerenberg To: Tony Hansen Subject: Re: [lemonade] COMPRESS=mumble In-Reply-To: <44EDDB78.9000301@att.com> Message-ID: <20060824123423.Y94886@orthanc.ca> References: <20060824143554.227E7222425@laser.networkresonance.com> <44EDDB78.9000301@att.com> Organization: The Frobozz Magic Homing Pigeon Company MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,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.6 (--) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: lemonade@ietf.org, Eric Rescorla X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 it sounds like Arnt's proposal would be the best compromise: > > Names from the DESCRIPTION column can be used for IMAP if and only if > they satisfy these requirements.... What do we use if the description isn't valid for IMAP? We would have to fall back to the numeric value. Now what if an update comes along that adds a name to an existing entry? Now you have to support the text version as well as the numeric value. Or not. What a mess. The protocol is intended to be read by computers, not humans. While it's nice to have readable strings for debugging, it can't be done at the cost of adding protocol ambiguity. I object to the use of text descriptions for this reason; we should instead use the numeric value. --lyndon _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Aug 24 16:12:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGLZ5-0000gx-L6; Thu, 24 Aug 2006 16:12:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGLZ3-0000at-Pv for lemonade@ietf.org; Thu, 24 Aug 2006 16:12:33 -0400 Received: from smtp.andrew.cmu.edu ([128.2.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGLZ2-0007GI-JK for lemonade@ietf.org; Thu, 24 Aug 2006 16:12:33 -0400 Received: from [192.168.137.22] (69-171-17-197.kntnny.adelphia.net [69.171.17.197]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.6/8.13.6) with ESMTP id k7OKBp6H031636 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 24 Aug 2006 16:11:52 -0400 Message-ID: <44EE0805.60708@andrew.cmu.edu> Date: Thu, 24 Aug 2006 16:11:49 -0400 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Thunderbird 1.5 (X11/20060313) MIME-Version: 1.0 To: Lyndon Nerenberg Subject: Re: [lemonade] COMPRESS=mumble References: <20060824143554.227E7222425@laser.networkresonance.com> <44EDDB78.9000301@att.com> <20060824123423.Y94886@orthanc.ca> In-Reply-To: <20060824123423.Y94886@orthanc.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: lemonade@ietf.org, Tony Hansen , Eric Rescorla X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Lyndon Nerenberg wrote: >> So it sounds like Arnt's proposal would be the best compromise: >> >> Names from the DESCRIPTION column can be used for IMAP if and only if >> they satisfy these requirements.... > > What do we use if the description isn't valid for IMAP? We would have > to fall back to the numeric value. Now what if an update comes along > that adds a name to an existing entry? Now you have to support the text > version as well as the numeric value. Or not. What a mess. > > The protocol is intended to be read by computers, not humans. While > it's nice to have readable strings for debugging, it can't be done at > the cost of adding protocol ambiguity. > > I object to the use of text descriptions for this reason; we should > instead use the numeric value. +1 -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Aug 24 16:23:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGLjj-0008AX-8M; Thu, 24 Aug 2006 16:23:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGLji-0008AN-Jq for lemonade@ietf.org; Thu, 24 Aug 2006 16:23:34 -0400 Received: from brooklyn.mumbo.ca ([209.89.70.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGLjf-0000Lf-9l for lemonade@ietf.org; Thu, 24 Aug 2006 16:23:34 -0400 Received: from [209.89.70.52] (tribeca.mumbo.ca [209.89.70.52]) by brooklyn.mumbo.ca (Postfix) with ESMTP id 98BDB48EAD; Thu, 24 Aug 2006 14:23:24 -0600 (MDT) In-Reply-To: <20060824123423.Y94886@orthanc.ca> References: <20060824143554.227E7222425@laser.networkresonance.com> <44EDDB78.9000301@att.com> <20060824123423.Y94886@orthanc.ca> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <633D13EC-AEC6-44A9-B5B0-A0C721BFC807@mumbo.ca> Content-Transfer-Encoding: 7bit From: Curtis King Subject: Re: [lemonade] COMPRESS=mumble Date: Thu, 24 Aug 2006 14:23:24 -0600 To: Lyndon Nerenberg X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: lemonade@ietf.org, Tony Hansen , Eric Rescorla X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 24-Aug-06, at 1:40 PM, Lyndon Nerenberg wrote: >> So it sounds like Arnt's proposal would be the best compromise: >> >> Names from the DESCRIPTION column can be used for IMAP if and only if >> they satisfy these requirements.... > > What do we use if the description isn't valid for IMAP? We would > have to fall back to the numeric value. Now what if an update > comes along that adds a name to an existing entry? Now you have to > support the text version as well as the numeric value. Or not. > What a mess. > > The protocol is intended to be read by computers, not humans. > While it's nice to have readable strings for debugging, it can't be > done at the cost of adding protocol ambiguity. > > I object to the use of text descriptions for this reason; we should > instead use the numeric value. +1 ck _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Aug 24 16:25:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGLlq-0000tt-L4; Thu, 24 Aug 2006 16:25:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGLlp-0000ri-B2 for lemonade@ietf.org; Thu, 24 Aug 2006 16:25:45 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGLln-0000dR-Um for lemonade@ietf.org; Thu, 24 Aug 2006 16:25:45 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id E5BCE4ADDE for ; Thu, 24 Aug 2006 22:25:42 +0200 (CEST) Message-Id: Date: Thu, 24 Aug 2006 22:25:43 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] COMPRESS=mumble References: <20060824143554.227E7222425@laser.networkresonance.com> <44EDDB78.9000301@att.com> <20060824123423.Y94886@orthanc.ca> <633D13EC-AEC6-44A9-B5B0-A0C721BFC807@mumbo.ca> In-Reply-To: <633D13EC-AEC6-44A9-B5B0-A0C721BFC807@mumbo.ca> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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: > +1 Do you guys also think it's unreasonable to add another IANA consideration, to force the description column to be suitable? Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Aug 24 16:40:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGLzh-0007HF-3Q; Thu, 24 Aug 2006 16:40:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGLzf-0007H9-Ux for lemonade@ietf.org; Thu, 24 Aug 2006 16:40:03 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGLzd-0002Ww-Gy for lemonade@ietf.org; Thu, 24 Aug 2006 16:40:03 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id C16A84ADF6; Thu, 24 Aug 2006 22:39:51 +0200 (CEST) Message-Id: Date: Thu, 24 Aug 2006 22:39:53 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] COMPRESS=mumble References: <20060824143554.227E7222425@laser.networkresonance.com> <44EDDB78.9000301@att.com> <20060824123423.Y94886@orthanc.ca> <633D13EC-AEC6-44A9-B5B0-A0C721BFC807@mumbo.ca> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Eric Rescorla X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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: > Do you guys also think it's unreasonable to add another IANA > consideration, to force the description column to be suitable? Oh, crap. I deleted too many ccs. Eric/Glenn: Please permit cc. Armt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Aug 24 17:56:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGNBg-0004Mg-N9; Thu, 24 Aug 2006 17:56:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGNBe-0004IJ-Vy for lemonade@ietf.org; Thu, 24 Aug 2006 17:56:30 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGNBc-0008MU-Kk for lemonade@ietf.org; Thu, 24 Aug 2006 17:56:30 -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 k7OLuMtl015765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 24 Aug 2006 14:56:23 -0700 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.172.15]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7OLuIre007964; Thu, 24 Aug 2006 14:56:22 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <44EDA0E3.9050201@att.com> References: <44ED2094.4060106@att.com> <44ED9FCE.7050802@att.com> <+0f+TF9ExoP+5K/eFIAAoQ.md5@libertango.oryx.com> <44EDA0E3.9050201@att.com> X-Mailer: Eudora for Mac OS X (dev alpha) X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Thu, 24 Aug 2006 14:56:04 -0700 To: lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] COMPRESS=mumble 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: Eric Rescorla X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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:51 AM -0400 8/24/06, Tony Hansen wrote: > Another possibility is to add additional IANA considerations to the > table, such that there *IS* a description (either verbiage or ABNF) > associated with the DESCRIPTION column. I'd be happy with this approach, or with not using an IANA registry at all. There was debate over the need for an IANA registry to begin with, so now that there are new problems with doing so, let's revisit the issue. Since the intent, as I understand it, is that IMAP (and message submission) level compression is to be used as an interim solution until TLS compression is widely deployed, and since we don't anticipate needing to standardize new compression mechanisms for IMAP (or message submission), I suggest we go back to only allowing DEFLATE. We can say that new mechanisms, if needed, can be established via standards-track or experimental RFCs that extend the COMPRESS command. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Programs that crash have been proven to be less useful than those that don't. --Apple Technical Note OV04 (formerly Technote #117) developer.apple.com/technotes/ov/ov_04.html _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Aug 24 19:10:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGOKZ-0007mq-2F; Thu, 24 Aug 2006 19:09:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGOKX-0007mk-5n for lemonade@ietf.org; Thu, 24 Aug 2006 19:09:45 -0400 Received: from static-71-240-120-213.pitt.east.verizon.net ([71.240.120.213] helo=mulberrymail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGOKU-0007Hl-TW for lemonade@ietf.org; Thu, 24 Aug 2006 19:09:45 -0400 Received: from [10.0.1.2] ([10.0.1.2]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id k7ON9ZJb010457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Aug 2006 19:09:37 -0400 Date: Thu, 24 Aug 2006 09:30:22 -0400 From: Cyrus Daboo To: Tony Hansen , lemonade@ietf.org Subject: Re: [lemonade] COMPRESS=mumble Message-ID: <7AD2D9337499C6BE346F3110@ninevah.local> In-Reply-To: <44EDA0E3.9050201@att.com> References: <44ED2094.4060106@att.com> <44ED9FCE.7050802@att.com> <+0f+TF9ExoP+5K/eFIAAoQ.md5@libertango.oryx.com> <44EDA0E3.9050201@att.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-Status: No, score=-0.7 required=5.0 tests=ALL_TRUSTED, DATE_IN_PAST_06_12 autolearn=disabled version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on piper.mulberrymail.com X-Spam-Score: 0.3 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Eric Rescorla X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 Tony, --On August 24, 2006 8:51:47 AM -0400 Tony Hansen wrote: > Another possibility is to add additional IANA considerations to the > table, such that there *IS* a description (either verbiage or ABNF) > associated with the DESCRIPTION column. Why not just add a new column to the IANA registry for a new 'ID' attribute that follows IMAP Atom syntax requirements. Another alternative is to use the numeric value followed by some descriptive text, e.g.: COMPRESS=1.DEFLATE COMPRESS=64.LZS COMPRESS=227.MYHYPERCOMPRESSOR The numeric value would be the actual algorithm identifier - the text is only their as a 'friendly name' descriptor and MUST NOT be used to identify any algorithm. -- Cyrus Daboo _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Aug 24 19:23:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGOXs-0001Hm-5I; Thu, 24 Aug 2006 19:23:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGOXp-0001Hh-Re for lemonade@ietf.org; Thu, 24 Aug 2006 19:23:30 -0400 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGOXo-0001Vc-H2 for lemonade@ietf.org; Thu, 24 Aug 2006 19:23:29 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M6DKIIYCVK00LMTU@mauve.mrochek.com> for lemonade@ietf.org; Thu, 24 Aug 2006 16:23:26 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1156461805; h=Date: From:Subject:MIME-version:Content-type; b=S4PihXY0fvy3uqamNSlLcCd4K 685WH9tnEHIIqda0J0RmmStR9+jZidNaY0PpmR/qTccJXe4nFE4VCeKox/IiA== Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M6DI7HFK1C0008CX@mauve.mrochek.com>; Thu, 24 Aug 2006 16:23:23 -0700 (PDT) To: Cyrus Daboo Message-id: <01M6DKIHTKJW0008CX@mauve.mrochek.com> Date: Thu, 24 Aug 2006 16:21:10 -0700 (PDT) From: Ned Freed Subject: Re: [lemonade] COMPRESS=mumble In-reply-to: "Your message dated Thu, 24 Aug 2006 09:30:22 -0400" <7AD2D9337499C6BE346F3110@ninevah.local> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <44ED2094.4060106@att.com> <44ED9FCE.7050802@att.com> <+0f+TF9ExoP+5K/eFIAAoQ.md5@libertango.oryx.com> <44EDA0E3.9050201@att.com> <7AD2D9337499C6BE346F3110@ninevah.local> X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: lemonade@ietf.org, Tony Hansen , Eric Rescorla X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 August 24, 2006 8:51:47 AM -0400 Tony Hansen wrote: > > Another possibility is to add additional IANA considerations to the > > table, such that there *IS* a description (either verbiage or ABNF) > > associated with the DESCRIPTION column. > Why not just add a new column to the IANA registry for a new 'ID' attribute > that follows IMAP Atom syntax requirements. +1 If my own IANA experiences are any indication, this sort of tweak is not more difficult than creating a new registry, and may in fact be slightly easier. > Another alternative is to use the numeric value followed by some > descriptive text, e.g.: > COMPRESS=1.DEFLATE > COMPRESS=64.LZS > COMPRESS=227.MYHYPERCOMPRESSOR I'd really rather not do this. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Aug 24 23:29:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGSNe-0004eL-DV; Thu, 24 Aug 2006 23:29:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGSNd-0004eD-IQ for lemonade@ietf.org; Thu, 24 Aug 2006 23:29:13 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGSNb-0008GE-5x for lemonade@ietf.org; Thu, 24 Aug 2006 23:29:13 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4J009T7B3SM2@szxga01-in.huawei.com> for lemonade@ietf.org; Fri, 25 Aug 2006 11:31:04 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4J00BTLB3RVC@szxga01-in.huawei.com> for lemonade@ietf.org; Fri, 25 Aug 2006 11:31:04 +0800 (CST) Received: from w48795 ([10.164.120.52]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4J00KCTBIRSA@szxml04-in.huawei.com> for lemonade@ietf.org; Fri, 25 Aug 2006 11:40:04 +0800 (CST) Date: Fri, 25 Aug 2006 11:27:50 +0800 From: Lingyan Wu Subject: [lemonade]About "Avoiding Duplicates" To: lemonade@ietf.org Message-id: <007501c6c7f6$71bfdf40$3478a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.5 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Lingyan Wu List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0394988369==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============0394988369== Content-type: multipart/alternative; boundary="Boundary_(ID_akQ1g7jzfLyYTXEPgmjHNw)" This is a multi-part message in MIME format. --Boundary_(ID_akQ1g7jzfLyYTXEPgmjHNw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi All, I have some questions as follows: Questions 1: A message appearing in more than one vfolders may lead to duplicate retrieval of such a message. Why will "appearing in more than one vfolders" lead to "duplicate retrieval"? What's the direct reason? I have seen all of the emails talking about the question but I still think it's very strange. If more than one notifications (corresponding to the message appearing in different vfolders) for the same message lead to "duplicate retrieval", server can solve the problem by only sending one notification for the same message. If client downloads the message from one vfolder (actually it exists in the backing mailbox), it will be tagged "SEEN" or some other tag indicating that the message has been downloaded in all the folders that the message appears in, so the problem can be resolved. Some other reasons could be listed here. Questions 2: That a message appears, disappears and reappears in a VFOLDER may result in unnecessary duplication of message on a client and may interfere with notification mechanisms. Why will it lead to such results? The server should know the message in the backing mailbox has been downloaded or notified. Maybe the server itself can resolve "Avoiding Duplicates" . Best Regards, Lingyan Huawei Technologies Co., Ltd. --Boundary_(ID_akQ1g7jzfLyYTXEPgmjHNw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT

Hi All,

 

I have some questions as follows:

Questions 1:

A message appearing in more than one vfolders may lead to duplicate retrieval of such a message.

Why will "appearing in more than one vfolders" lead to "duplicate retrieval"? What's the direct reason?

I have seen all of the emails talking about the question but I still think it's very strange.

If more than one notifications (corresponding to the message appearing in different vfolders) for the same message lead to "duplicate retrieval", server can solve the problem by only sending one notification for the same message.

If client downloads the message from one vfolder (actually it exists in the backing mailbox), it will be tagged "SEEN" or some other tag indicating that the message has been downloaded in all the folders that the message appears in, so the problem can be resolved.

Some other reasons could be listed here.

 

Questions 2:

That a message appears, disappears and reappears in a VFOLDER may result in unnecessary duplication of message on a client and may interfere with notification mechanisms.

Why will it lead to such results?

The server should know the message in the backing mailbox has been downloaded or notified.

 

Maybe the server itself can resolve "Avoiding Duplicates" .

 

Best Regards,
Lingyan
Huawei Technologies Co., Ltd.

--Boundary_(ID_akQ1g7jzfLyYTXEPgmjHNw)-- --===============0394988369== 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 --===============0394988369==-- From lemonade-bounces@ietf.org Thu Aug 24 23:49:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGSgp-0006NA-0S; Thu, 24 Aug 2006 23:49:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGSgo-0006Ld-Bl for lemonade@ietf.org; Thu, 24 Aug 2006 23:49:02 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGSgm-0004Lx-Ue for lemonade@ietf.org; Thu, 24 Aug 2006 23:49:02 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.7) with ESMTP id k7P3mx0W006527; Fri, 25 Aug 2006 06:48:59 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 06:48:59 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 06:48: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="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] WGLC reconnect-client-01 Date: Fri, 25 Aug 2006 06:48:24 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657DB7455@esebe199.NOE.Nokia.com> In-Reply-To: <44ED94AD.4070105@isode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] WGLC reconnect-client-01 Thread-Index: AcbHdPDSa0e/fzdQT2uQfonhW5K3bwAg30mA From: To: X-OriginalArrivalTime: 25 Aug 2006 03:48:58.0934 (UTC) FILETIME=[65713560:01C6C7F9] X-Spam-Score: 0.2 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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, >> 3. Section 2, par. 1. "since a known moment" Could we be=20 >more specific? >> >CONDSTORE uses modification sequences, which effectively=20 >define moment in time. Do you think this should be spelled out? No, I mean the "known moment". It does not sound very good. "since a known moment" -> "using timestamps"? Since it is in the introduction section, I do not have strong feelings about this. Thank You. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Aug 24 23:54:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGSls-00080w-LG; Thu, 24 Aug 2006 23:54:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGSlq-00080r-SH for lemonade@ietf.org; Thu, 24 Aug 2006 23:54:14 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGSln-0006ML-Bi for lemonade@ietf.org; Thu, 24 Aug 2006 23:54:14 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.7) with ESMTP id k7P3s1t9015273; Fri, 25 Aug 2006 06:54:03 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 06:53:15 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 06:53: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] COMPRESS=mumble Date: Fri, 25 Aug 2006 06:52:41 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657DB7456@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] COMPRESS=mumble Thread-Index: AcbHGeLPIZE5vDMNEduR3wAWy5cvmwA36eug From: To: , X-OriginalArrivalTime: 25 Aug 2006 03:53:15.0682 (UTC) FILETIME=[FE79D820:01C6C7F9] X-Spam-Score: 0.2 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ekr@networkresonance.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 think that there are two things to this. One is registration, the other is whether we use the numberic or alpha = representation. My suggestion would be to leave the registry for them (avoid creating = yet another registry), and instead of numberic representation use the = alpha representation. Would this work? Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 =20 >-----Original Message----- >From: ext Eric Burger [mailto:eburger@cantata.com]=20 >Sent: 24 August, 2006 04:09 >To: IETF LEMONADE >Cc: Eric Rescorla >Subject: [lemonade] COMPRESS=3Dmumble > >In private discussion with some security gurus, they were a=20 >bit worried about the LEMONADE work group defining=20 >security-related IANA registries. >Likewise, they are worried that we are going to be mandating=20 >requirements on new TLS parameters to fit our world. > >One quick question: Rather than COMPRESS=3DDEFLATE or=20 >COMPRESS=3DLZS, why not use COMPRESS=3D1 and COMPRESS=3D63? That=20 >is, use the values that already exist in the already existing registry? > >My push back is it is a lot easier to understand=20 >"COMPRESS=3DDEFLATE" than it is to look up that "1" is DEFLATE. =20 >We also run the risk of people using 0x01. We could use the=20 >DESCRIPTION column from the registry, I suppose. > >The alternative is to create a new registry, that looks pretty=20 >much identical to the existing registry. [1] > > >[1] http://www.iana.org/assignments/comp-meth-ids > > >_______________________________________________ >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 Aug 24 23:58:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGSpS-0008Vt-DN; Thu, 24 Aug 2006 23:57:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGSpQ-0008Vm-VS for lemonade@ietf.org; Thu, 24 Aug 2006 23:57:56 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGSpP-0006oP-H4 for lemonade@ietf.org; Thu, 24 Aug 2006 23:57:56 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.7) with ESMTP id k7P3vqbN007179; Fri, 25 Aug 2006 06:57:53 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 06:57:52 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 06:57:52 +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=mumble Date: Fri, 25 Aug 2006 06:57:17 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657DB7457@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] COMPRESS=mumble Thread-Index: AcbHu514CHsS0A95RKut0aj2sO344QAPnGIg From: To: , X-OriginalArrivalTime: 25 Aug 2006 03:57:52.0079 (UTC) FILETIME=[A338ADF0:01C6C7FA] X-Spam-Score: 0.2 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 would go for forcing such column. People will refer to each algorithm = using their names anyway. The short name could be the RFC number as well. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 =20 >-----Original Message----- >From: ext Arnt Gulbrandsen [mailto:arnt@gulbrandsen.priv.no]=20 >Sent: 24 August, 2006 23:26 >To: lemonade@ietf.org >Subject: Re: [lemonade] COMPRESS=3Dmumble > >Curtis King writes: >> +1 > >Do you guys also think it's unreasonable to add another IANA=20 >consideration, to force the description column to be suitable? > >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 Fri Aug 25 02:58:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGVdn-0003Vi-69; Fri, 25 Aug 2006 02:58:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGVdm-0003Vd-Bg for lemonade@ietf.org; Fri, 25 Aug 2006 02:58:06 -0400 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGVdj-0001g7-RG for lemonade@ietf.org; Fri, 25 Aug 2006 02:58:06 -0400 Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.12]) by smarthost.yourcomms.net (8.11.7p3+Sun/8.11.6) with ESMTP id k7P6jko20855 for ; Fri, 25 Aug 2006 07:45:47 +0100 (BST) 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]About "Avoiding Duplicates" Date: Fri, 25 Aug 2006 07:57:20 +0100 Message-ID: <22C8A0D5D5E095449AB509FE777B5F8002BFB214@svr-exchange.avocado.emccsoft.com> In-Reply-To: <007501c6c7f6$71bfdf40$3478a40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade]About "Avoiding Duplicates" Thread-Index: AcbH9ukC7bgvSgiIT4OJAcJupGYSHwAGzRrA From: "Ben Last" To: "Lingyan Wu" , 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 >From: Lingyan Wu [mailto:wulingyan_48795@huawei.com]=20 >Sent: 25 August 2006 04:28 >A message appearing in more than one vfolders may lead to duplicate retrieval of such a message. >Why will "appearing in more than one vfolders" lead to "duplicate retrieval"? What's the direct reason? >I have seen all of the emails talking about the question but I still think it's very strange. >If more than one notifications (corresponding to the message appearing in different vfolders) for the same message >lead to "duplicate retrieval", server can solve the problem by only sending one notification for the same message. Notifications are only one way in which a client is advised of the existence of a message. The EXISTS count also implies it, and certainly our client will use both the EXISTS responses to SELECT commands as well as notifications to keep the list of messsages per mailbox up to date. >If client downloads the message from one vfolder (actually it exists in the backing mailbox), it >will be tagged "SEEN" or some other tag indicating that the message has been downloaded in all >the folders that the message appears in, so the problem can be resolved. That assumes only one client. A Lemonade server is very likely to have multiple clients accessing the same account (set of mailboxes), so the "tag" would need to be client-specific. Also, adding a tag means that clients need to be extended to handle that tag, and the tag needs to be standardized, etc. Also, this may not solve the problem; tagging a message as "seen" doesn't allow the client to spot the same message in all other mailboxes/vfolders in which it appears. The problem is in spotting the fact that message A in vfolder X is a duplicate of message B in vfolder Y. >That a message appears, disappears and reappears in a VFOLDER may result in unnecessary duplication >of message on a client and may interfere with notification mechanisms. >Why will it lead to such results? Because when a message appears in a vfolder it is given a UID; if it then disappears and reappears it would be given a new UID. The UIDs would be allocated within the VFOLDER and not be the UIDs from the underlying mailboxes, because otherwise the semantics of UIDs would be broken (that's my understanding; I welcome corrections on this or any other point!). I think the key point here (and this applies to your comments about question 2 also) is that vfolders appears as if they are standard mailboxes. Thus the client treats them as such, and must also make the assumption that a message in one mailbox is distinct from all other messages in other mailboxes. The proposed VFOLDER extension includes no way to allow a client to see that one message is in fact a duplicate of another. Regards Ben EMCC Software Ltd _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Aug 25 03:48:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGWPl-0003JQ-DS; Fri, 25 Aug 2006 03:47:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGGBd-0005uk-6I for lemonade@ietf.org; Thu, 24 Aug 2006 10:28:01 -0400 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGGBb-0008Mx-Tl for lemonade@ietf.org; Thu, 24 Aug 2006 10:28:01 -0400 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id 227E7222425; Thu, 24 Aug 2006 07:35:54 -0700 (PDT) To: Tony Hansen Subject: Re: [lemonade] COMPRESS=mumble In-reply-to: Your message of "Thu, 24 Aug 2006 08:51:47 EDT." <44EDA0E3.9050201@att.com> X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 19) Date: Thu, 24 Aug 2006 07:27:57 -0700 From: Eric Rescorla Message-Id: <20060824143554.227E7222425@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-Mailman-Approved-At: Fri, 25 Aug 2006 03:47:39 -0400 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 Tony Hansen wrote: > Another possibility is to add additional IANA considerations to the > table, such that there *IS* a description (either verbiage or ABNF) > associated with the DESCRIPTION column. But this has exactly the property that I was concerned about: LEMONADE is placing requirements on TLS documents... -Ekr _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Aug 25 04:04:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGWfc-000131-L1; Fri, 25 Aug 2006 04:04:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGWfb-00011Q-6S for lemonade@ietf.org; Fri, 25 Aug 2006 04:04:03 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGWfX-0008K9-BN for lemonade@ietf.org; Fri, 25 Aug 2006 04:04:03 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1GGWfT-0002Au-D4; Fri, 25 Aug 2006 08:03:56 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 983F6498003; Fri, 25 Aug 2006 09:05: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 10113-05; Fri, 25 Aug 2006 09:04: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 680CA498002; Fri, 25 Aug 2006 09:04:59 +0100 (BST) Date: Fri, 25 Aug 2006 09:03:39 +0100 Subject: Re: [lemonade]About "Avoiding Duplicates" References: <007501c6c7f6$71bfdf40$3478a40a@china.huawei.com> In-Reply-To: <007501c6c7f6$71bfdf40$3478a40a@china.huawei.com> MIME-Version: 1.0 Message-Id: <601.1156493030.076873@peirce.dave.cridland.net> From: Dave Cridland To: Lingyan Wu 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: 34d35111647d654d033d58d318c0d21a 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 Aug 25 04:27:50 2006, Lingyan Wu wrote: > Why will "appearing in more than one vfolders" lead to "duplicate > retrieval"? What's the direct reason? > > I have seen all of the emails talking about the question but I > still think it's very strange. > > In IMAP, a message can be uniquely identified by a triplet of (mailbox path, UIDVALIDITY, UID). Whenever a message is copied by a third party - including the implicit copy by a virtual mailbox implementation - it appears, to the client, as an entirely new mailbox - there is no reliable mechansim by which the client can identify the message as being previously known - or also known - by any other triplet than the one the client sees. Unfortunately, the Message-Id field doesn't quite identify the message - you may get two copies of this message, for instance - the one sent to the list, and the one sent directly to you. The one sent to the list will have additional metadata present in the List-* fields, and also it'll have the "lemonade mailing list" information appended to the bottom. Of course, the triplet only identifies a message on a single server - really, there's more information than that, like the server's name, it's port number, etc. This is essentially encompassed into an IMAP URL. Copying a message gives it a new URL, but there's no method to find the original, nor is there any method to find out if there even was one. > If more than one notifications (corresponding to the message > appearing in different vfolders) for the same message lead to > "duplicate retrieval", server can solve the problem by only sending > one notification for the same message. > > Yes, but the notification would then only point to one message - conceptually, within IMAP, there is no such thing as a message in two mailboxes. > If client downloads the message from one vfolder (actually it > exists in the backing mailbox), it will be tagged "SEEN" or some > other tag indicating that the message has been downloaded in all > the folders that the message appears in, so the problem can be > resolved. > > Not quite - for resynchronization operations (as opposed to online reading), flags are left unchanged by downloading the message. Even if this were not the case, there is no way to tell what data relates to the message you've apparently already read. FWIW, I do have a bit of a plan here: 1) Assign a unique identifier to all mailboxes on a server. This unqiue identifier is essentially a shorthand for (mailbox path, UIDVALIDITY), except that should a folder be renamed, it will be preserved. This allows clients to shorten the triplet to a 2-tuple (mailbox id, UID). 2) All messages acquire this 2-tuple when they first enter the IMAP server, whether via delivery or via APPEND. This 2-tuple is preserved across COPY. 3) The 2-tuple can be read via a FETCH operation that will only return the 2-tuple when the mailbox id differs from the current mailbox id - that is, it'll only be shown for messages which have been copied or otherwise duplicated with the knowledge of the IMAP server. This last is a bit of a hack, I admit, but it's one that eliminates the overhead of retrieving the data when it's mostly redundant. It's never redundant for virtual mailboxes, of course. I was hoping to re-use the UIDVALIDITY as a mailbox id, but Philip Guenther pointed out this won't work in all cases. > Questions 2: > That a message appears, disappears and reappears in a VFOLDER may > result in unnecessary duplication of message on a client and may > interfere with notification mechanisms. > > Why will it lead to such results? > > I think Ben Last answered this sufficiently well that I've nothing to add. 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 Aug 25 04:25:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGX0J-0005Ak-LD; Fri, 25 Aug 2006 04:25:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGX0I-0005Ac-IE for lemonade@ietf.org; Fri, 25 Aug 2006 04:25:26 -0400 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGX0H-0004cL-57 for lemonade@ietf.org; Fri, 25 Aug 2006 04:25:26 -0400 Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.12]) by smarthost.yourcomms.net (8.11.7p3+Sun/8.11.6) with ESMTP id k7P8D2o25826 for ; Fri, 25 Aug 2006 09:13:02 +0100 (BST) 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]About "Avoiding Duplicates" Date: Fri, 25 Aug 2006 09:24:35 +0100 Message-ID: <22C8A0D5D5E095449AB509FE777B5F8002BFB5AD@svr-exchange.avocado.emccsoft.com> In-Reply-To: <601.1156493030.076873@peirce.dave.cridland.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade]About "Avoiding Duplicates" Thread-Index: AcbIHRopc+N4U/L2Sh6ihsNMhiVd1QAAOoPw From: "Ben Last" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org From: Dave Cridland [mailto:dave@cridland.net]=20 Sent: 25 August 2006 09:04 >FWIW, I do have a bit of a plan here: >1) Assign a unique identifier to all mailboxes on a server. This=20 >unqiue identifier is essentially a shorthand for (mailbox path,=20 >UIDVALIDITY), except that should a folder be renamed, it will be=20 >preserved. This allows clients to shorten the triplet to a 2-tuple=20 >(mailbox id, UID). This I like very much; it also helps to solve the potentially very expensive resynchronization/download currently incurred by renaming of a mailbox. It could also help to identify "special" mailboxes, if there were some agreement on reserved identifiers for certain special mailboxes. >2) All messages acquire this 2-tuple when they first enter the IMAP=20 >server, whether via delivery or via APPEND. This 2-tuple is preserved=20 >across COPY. Hang on; doesn't that imply that a message can be copied to another mailbox, but keep the id of the mailbox in which it first appeared? If so, that means that nearly all messages would end up with the mailbox id of the INBOX, surely? >3) The 2-tuple can be read via a FETCH operation that will only=20 >return the 2-tuple when the mailbox id differs from the current=20 >mailbox id - that is, it'll only be shown for messages which have=20 >been copied or otherwise duplicated with the knowledge of the IMAP=20 >server. Interesting: presumably a SEARCH could also do this? I guess this has already been considered, but if we're adding new attributes (like this 2-tuple) to messages, why not just allocate a unique id to each message on arrival, and preserve that over COPY? Then that id can serve to allow identification of individual messages as duplicates between vfolders or mailboxes? Effectively this is what you're doing, but with a 2-tuple. >This last is a bit of a hack, I admit, but it's one that eliminates=20 >the overhead of retrieving the data when it's mostly redundant. It's=20 >never redundant for virtual mailboxes, of course. I was hoping to=20 >re-use the UIDVALIDITY as a mailbox id, but Philip Guenther pointed=20 >out this won't work in all cases. There's at least one server I'm aware of that can change the UIDVALIDITY of mailboxes in response to (what I consider) quite common/low-level operations, incurring a severe re-synchronization/download penalty for our client. Plus, as far as I can tell from a quick re-reading of RFC3501, there's no reason that UIDVALIDITY values currently need to be unique across mailboxes. Regards Ben EMCC Software Ltd _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Aug 25 04:58:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGXVX-0002kn-Ol; Fri, 25 Aug 2006 04:57:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGXVV-0002kc-Uz for lemonade@ietf.org; Fri, 25 Aug 2006 04:57:41 -0400 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGXVU-0001r7-Fp for lemonade@ietf.org; Fri, 25 Aug 2006 04:57:41 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.50) id 1GGXVT-0007Jc-IO; Fri, 25 Aug 2006 08:57:39 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 5B5F0498003; Fri, 25 Aug 2006 09:58:46 +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 10370-07; Fri, 25 Aug 2006 09:58: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 EFB55498002; Fri, 25 Aug 2006 09:58:42 +0100 (BST) Date: Fri, 25 Aug 2006 09:57:32 +0100 Subject: Re: [lemonade] COMPRESS=mumble References: <20060824143554.227E7222425@laser.networkresonance.com> In-Reply-To: <20060824143554.227E7222425@laser.networkresonance.com> MIME-Version: 1.0 Message-Id: <601.1156496253.302925@peirce.dave.cridland.net> From: Dave Cridland To: Eric Rescorla 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: 02ec665d00de228c50c93ed6b5e4fc1a 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 Aug 24 15:27:57 2006, Eric Rescorla wrote: > Tony Hansen wrote: > > Another possibility is to add additional IANA considerations to > the > > table, such that there *IS* a description (either verbiage or > ABNF) > > associated with the DESCRIPTION column. > > But this has exactly the property that I was concerned about: > LEMONADE is placing requirements on TLS documents... I hear what you're saying, but I seem to be missing why this is a problem. Personally, I agree with the idea that if we were trying to place a requirement on a security related registry which affected security, that would rightfully raise a few eyebrows. But we're not talking about a security related registry. We're talking about a compression related registry, which is almost a good fit for what we're after - indeed, all the current registrations are perfectly formed for us. It happens to be defined relating to TLS, but that's really the only "security" issue. We're just after either another column, or a retrofitted syntactic requirement on the "DESCRIPTION" column which maintains the status quo. This was certainly the consensus of the group as I understood it. And we're absolutely not talking about anything which affects security - you say "requirements on TLS documents", but really, this would only place requirements on TLS *COMPRESSION* documents. That's a requirement on *TWO* documents in the history of TLS, so far. Of course, I'm possibly unaware of some enormous activity within the security area on compression which'll be defining new compression methods for TLS by the dozen, but I don't understand why mandating that such documents include a short alphanumeric string uniquely identifying the algorithm is such a problem. It's not as if compression algorithms don't have names, and even if they didn't, this is not a security-related requirement. The only relation compression has to TLS is that TLS happens to provide the facility - it's really nothing to do with security at all. Arguably, TLS compression documents shouldn't come from the Security Area at all. Personally, I feel that a single registry covering all compression algorithms would benefit the general architecture of the IETF enormously over a series of disconnected registries. If you can come up with a technical reason why we can't make a minor adjustment to the registry, or if the IAB makes a formal statement on the issue, then for the record, I'll have to say we ditch the registry entirely (ie, follow Randy's suggestion). But my strong preference is to leverage the existing registry (ie, follow Ned Freed's suggestion). 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 Aug 25 06:18:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGYlN-0000hi-Dl; Fri, 25 Aug 2006 06:18:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGYlM-0000hb-1C for lemonade@ietf.org; Fri, 25 Aug 2006 06:18:08 -0400 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGYlK-0006nd-J1 for lemonade@ietf.org; Fri, 25 Aug 2006 06:18:08 -0400 Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.12]) by smarthost.yourcomms.net (8.11.7p3+Sun/8.11.6) with ESMTP id k7PA5nH08939 for ; Fri, 25 Aug 2006 11:05:49 +0100 (BST) 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, 25 Aug 2006 11:17:23 +0100 Message-ID: <22C8A0D5D5E095449AB509FE777B5F8002BFBB48@svr-exchange.avocado.emccsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Message priority Thread-Index: AcbIL6gauRfnLcShQ62+PteM629tTg== From: "Ben Last" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [lemonade] Message priority X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dear Lemonaders As far as I can tell, the subject of messge priority (as expressed via the non-RFC2822 X-Priority message header) hasn't been discussed in the context of Lemonade, except in Stephane Maes's drafts in which he mentions vfolders filtering on priority. Also, as far as I know, there is no IMAP way in which the message priority is exposed to the client, unless the client retrieves the raw RFC2822 message text (or the header part) and parses it. We have a need to show message priority in our client, but we don't want to have to download the raw message body (we tend to just download the text/plain message part to minimize data transfer) or the header just to extract one field which will be either missing or set to normal priority for 95% (or more) of messages (based on a test data set). So: is anyone aware of proposals to provide access to this field? If not, is anyone interesting in working on a proposal for it? Best regards ben Ben Last EMCC Software Ltd _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Aug 25 06:27:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGYuU-0006Uu-3P; Fri, 25 Aug 2006 06:27:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGYuS-0006Uk-UJ for lemonade@ietf.org; Fri, 25 Aug 2006 06:27:32 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGYuR-00015Q-Gg for lemonade@ietf.org; Fri, 25 Aug 2006 06:27:32 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 818894AD44 for ; Fri, 25 Aug 2006 12:27:30 +0200 (CEST) Message-Id: Date: Fri, 25 Aug 2006 12:27:21 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Message priority References: <22C8A0D5D5E095449AB509FE777B5F8002BFBB48@svr-exchange.avocado.emccsoft.com> In-Reply-To: <22C8A0D5D5E095449AB509FE777B5F8002BFBB48@svr-exchange.avocado.emccsoft.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Ben Last writes: > Also, as far as I know, there is no IMAP way in which the message > priority is exposed to the client, unless the client retrieves the > raw RFC2822 message text (or the header part) and parses it. That's not quite true. Optional first step: Find the messages with such a field a uid search header priority "" Then fetch just that field: b uid fetch 123 body.peek[header.fields (priority)]". (for 123, read 1:* or the UIDs returned by the search.) Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Aug 25 06:31:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGYyK-0007x0-5k; Fri, 25 Aug 2006 06:31:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGYyI-0007wv-J1 for lemonade@ietf.org; Fri, 25 Aug 2006 06:31:30 -0400 Received: from smtp-out.sendmail.com ([209.246.26.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGYyH-0002MJ-7D for lemonade@ietf.org; Fri, 25 Aug 2006 06:31:30 -0400 Received: from [10.201.0.58] (adsl-64-58-1-252.mho.net [64.58.1.252] (may be forged)) (authenticated bits=0) by foon.sendmail.com (Switch-3.2.4/Switch-3.2.0) with ESMTP id k7PAV34w004060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Aug 2006 03:31:06 -0700 X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com k7PAV34w004060 DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1156501867; bh=K9Ow4+iBNSVc3SFgWzO82dcoU2c=; h=X-DomainKeys: DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:In-Reply-To: Message-ID:References:MIME-Version:Content-Type; b=CudAuuzoQ7o1BTs5 p3Yjgg8by5ZVANtqYKh8d+/yX55zWI0GHtMLpYo8CRHa4VCx+viCv7Nu6fmAn4foe+i IQFzxqbK/2exzlqsaQgId6P0fEuw6CEx9Aw+hMhIZk/M9sA/tJRivUtT6cWUKhqmjyu bPCk1I0bMLHhAeIRNSDmA= X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com k7PAV34w004060 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type; b=GVHj9nXLeC1MVaK83uGs99PCLooFIiJGeVEOGteChfrcGb5+IQJX1FDrjJHZB+m2e YResDEtv2HM6VZkAPHEjMSiCZQWY1f1wFCpn9DjrScap1THxcuD6ICoe58isu5e+Uxg 6vWZJC79QKk4tonIErCTQEcvo1Y27g0nwwigzaM= Date: Fri, 25 Aug 2006 04:31:03 -0600 From: Philip Guenther X-X-Sender: guenther@vanye.mho.net To: Ben Last Subject: Re: [lemonade] Message priority In-Reply-To: <22C8A0D5D5E095449AB509FE777B5F8002BFBB48@svr-exchange.avocado.emccsoft.com> Message-ID: References: <22C8A0D5D5E095449AB509FE777B5F8002BFBB48@svr-exchange.avocado.emccsoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 On Fri, 25 Aug 2006, Ben Last wrote: ... > Also, as far as I know, there is no IMAP way in which the message > priority is exposed to the client, unless the client retrieves the raw > RFC2822 message text (or the header part) and parses it. While the X-Priority header field has no special handling in IMAP, clients can do substring searches against the field using the HEADER SEARCH critierion and can retrieve the value of the field using the BODY[HEADER.FIELDS (...)] FETCH item...just like any other random header field. > We have a need to show message priority in our client, but we don't want > to have to download the raw message body (we tend to just download the > text/plain message part to minimize data transfer) or the header just to > extract one field which will be either missing or set to normal priority > for 95% (or more) of messages (based on a test data set). Then use BODY[HEADER.FIELDS (x-priority)] with FETCH/UID FETCH and let the server do the extraction for you. > So: is anyone aware of proposals to provide access to this field? If > not, is anyone interesting in working on a proposal for it? What precise need is not met by the existing functionality in IMAP4rev1? Philip Guenther _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Aug 25 07:01:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGZRL-0006KT-Nw; Fri, 25 Aug 2006 07:01:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGZRL-0006KN-02 for lemonade@ietf.org; Fri, 25 Aug 2006 07:01: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 1GGZB1-0005kt-Nl for lemonade@ietf.org; Fri, 25 Aug 2006 06:44:39 -0400 Received: from smarthost.yourcomms.net ([195.8.160.124]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGYw5-0008RQ-S1 for lemonade@ietf.org; Fri, 25 Aug 2006 06:29:14 -0400 Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.12]) by smarthost.yourcomms.net (8.11.7p3+Sun/8.11.6) with ESMTP id k7PAGxH10492 for ; Fri, 25 Aug 2006 11:16:59 +0100 (BST) 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: FW: [lemonade] Message priority Date: Fri, 25 Aug 2006 11:28:33 +0100 Message-ID: <22C8A0D5D5E095449AB509FE777B5F8002BFBB80@svr-exchange.avocado.emccsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Message priority Thread-Index: AcbIMEZmoje/Xz+UR4WqWQFW9S2eEAAAHELg From: "Ben Last" To: X-Spam-Score: -2.2 (--) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org >From: Abhijit Menon-Sen [mailto:ams@oryx.com]=20 >Sent: 25 August 2006 11:22 >FETCH n BODY[header.fields (X-Priority)]? Many thanks to Abhijit Menon-Sen for pointing this out, and my abject humiliation may be seen by all. But that's what a learning curve looks like :) And Arnt's solution is even nicer. Regards Ben _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Aug 25 08:08:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGaTj-0005wv-RG; Fri, 25 Aug 2006 08:08:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGaTi-0005wp-MG for lemonade@ietf.org; Fri, 25 Aug 2006 08:08:02 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGaTh-0000lf-9G for lemonade@ietf.org; Fri, 25 Aug 2006 08:08:02 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 25 Aug 2006 13:08:00 +0100 Message-ID: <44EEE27B.1000006@isode.com> Date: Fri, 25 Aug 2006 12:43: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 MIME-Version: 1.0 To: Zoltan.Ordogh@nokia.com Subject: Re: [lemonade] WGLC reconnect-client-01 References: <0FA975F2D8295A448BE3ADC161244657DB7455@esebe199.NOE.Nokia.com> In-Reply-To: <0FA975F2D8295A448BE3ADC161244657DB7455@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: 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 Zoltan.Ordogh@nokia.com wrote: >Hi Alexey, > > >>>3. Section 2, par. 1. "since a known moment" Could we be >>> >>> >>more specific? >> >> >>CONDSTORE uses modification sequences, which effectively >>define moment in time. Do you think this should be spelled out? >> >> > >No, I mean the "known moment". It does not sound very good. "since a >known moment" -> "using timestamps"? > > Modsequences are not timestamps, they are counters. Thus the current wording. >Since it is in the introduction section, I do not have strong feelings >about this. > > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Aug 25 08:37:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGavo-00034c-7D; Fri, 25 Aug 2006 08:37:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGavn-00033v-CD for lemonade@ietf.org; Fri, 25 Aug 2006 08:37:03 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGavm-00049J-1h for lemonade@ietf.org; Fri, 25 Aug 2006 08:37:03 -0400 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail2.lucent.com (8.13.6/IER-o) with ESMTP id k7PCapWN009636; Fri, 25 Aug 2006 07:36:51 -0500 (CDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 25 Aug 2006 07:36:51 -0500 Message-ID: <54E40201497DF142B06B27255953F797204B1163@il0015exch007u.ih.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: Ben Last , lemonade@ietf.org Subject: RE: [lemonade] Message priority Date: Fri, 25 Aug 2006 07:36:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) 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 I had written a proposal to the Lemonade group on a closely related topic. draft-ietf-lemonade-msg-context-00.txt. The draft made it easy to view (show icon), sort, and retrieve based on message context by defining flag conventions. Also status-counters addressed a related issue in terms of counting messages with a given context, priority, or seen status: draft-neystadt-imap-status-counters-01.txt The disposition was that the extensions were unnecessary since the IMAP client could view, search and fetch on the Importance (and/or X-priority) headers without downloading the full header block. Can anyone re-itterate the details? The discussion was "live" rather than on the list. Greg V. -----Original Message----- From: Ben Last [mailto:Ben.Last@emccsoft.com] Sent: Friday, August 25, 2006 6:17 AM To: lemonade@ietf.org Subject: [lemonade] Message priority Dear Lemonaders As far as I can tell, the subject of messge priority (as expressed via the non-RFC2822 X-Priority message header) hasn't been discussed in the context of Lemonade, except in Stephane Maes's drafts in which he mentions vfolders filtering on priority. Also, as far as I know, there is no IMAP way in which the message priority is exposed to the client, unless the client retrieves the raw RFC2822 message text (or the header part) and parses it. We have a need to show message priority in our client, but we don't want to have to download the raw message body (we tend to just download the text/plain message part to minimize data transfer) or the header just to extract one field which will be either missing or set to normal priority for 95% (or more) of messages (based on a test data set). So: is anyone aware of proposals to provide access to this field? If not, is anyone interesting in working on a proposal for it? Best regards ben Ben Last EMCC Software Ltd _______________________________________________ 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 Aug 25 09:00:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGbIe-0006q1-BS; Fri, 25 Aug 2006 09:00:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGbIc-0006pw-Sy for lemonade@ietf.org; Fri, 25 Aug 2006 09:00:38 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGbIb-0008IW-C4 for lemonade@ietf.org; Fri, 25 Aug 2006 09:00:38 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Fri, 25 Aug 2006 13:57:36 +0100 Message-ID: <44EEF3A0.8010502@isode.com> Date: Fri, 25 Aug 2006 13:57:04 +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: Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] COMPRESS=mumble References: <20060824143554.227E7222425@laser.networkresonance.com> <601.1156496253.302925@peirce.dave.cridland.net> In-Reply-To: <601.1156496253.302925@peirce.dave.cridland.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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've replied directly to Dave and Eric. Dave asked me to reply to the mailing list. Dave Cridland wrote: > On Thu Aug 24 15:27:57 2006, Eric Rescorla wrote: > >> Tony Hansen wrote: >> > Another possibility is to add additional IANA considerations to the >> > table, such that there *IS* a description (either verbiage or ABNF) >> > associated with the DESCRIPTION column. >> >> But this has exactly the property that I was concerned about: >> LEMONADE is placing requirements on TLS documents... > > I hear what you're saying, but I seem to be missing why this is a > problem. > > Personally, I agree with the idea that if we were trying to place a > requirement on a security related registry which affected security, > that would rightfully raise a few eyebrows. > > But we're not talking about a security related registry. We're talking > about a compression related registry, which is almost a good fit for > what we're after - indeed, all the current registrations are perfectly > formed for us. It happens to be defined relating to TLS, but that's > really the only "security" issue. We're just after either another > column, or a retrofitted syntactic requirement on the "DESCRIPTION" > column which maintains the status quo. This was certainly the > consensus of the group as I understood it. > > And we're absolutely not talking about anything which affects security > - you say "requirements on TLS documents", but really, this would only > place requirements on TLS *COMPRESSION* documents. That's a > requirement on *TWO* documents in the history of TLS, so far. Of > course, I'm possibly unaware of some enormous activity within the > security area on compression which'll be defining new compression > methods for TLS by the dozen, but I don't understand why mandating > that such documents include a short alphanumeric string uniquely > identifying the algorithm is such a problem. +1 > It's not as if compression algorithms don't have names, and even if > they didn't, this is not a security-related requirement. The only > relation compression has to TLS is that TLS happens to provide the > facility - it's really nothing to do with security at all. Arguably, > TLS compression documents shouldn't come from the Security Area at all. > > Personally, I feel that a single registry covering all compression > algorithms would benefit the general architecture of the IETF > enormously over a series of disconnected registries. +1 > If you can come up with a technical reason why we can't make a minor > adjustment to the registry, or if the IAB makes a formal statement on > the issue, then for the record, I'll have to say we ditch the registry > entirely (ie, follow Randy's suggestion). But my strong preference is > to leverage the existing registry (ie, follow Ned Freed's suggestion). _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Aug 25 09:08:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGbQ3-0001sF-Ul; Fri, 25 Aug 2006 09:08:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGbQ3-0001sA-5l for lemonade@ietf.org; Fri, 25 Aug 2006 09:08:19 -0400 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGbQ0-0000nc-Le for lemonade@ietf.org; Fri, 25 Aug 2006 09:08:19 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.50) id 1GGbPv-00060e-Mn for lemonade@ietf.org; Fri, 25 Aug 2006 13:08:11 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 85E61498003 for ; Fri, 25 Aug 2006 14:09: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 11471-10 for ; Fri, 25 Aug 2006 14:09:14 +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 638AD498002 for ; Fri, 25 Aug 2006 14:09:14 +0100 (BST) Date: Fri, 25 Aug 2006 14:08:02 +0100 Subject: RE: [lemonade] About "Avoiding Duplicates" References: =?US-ASCII?Q?<22C8A0D5D5E095449AB509FE777B5F800?= =?US-ASCII?Q?BFB5AD@svr-exchange.avocado.emccsoft.com>?= In-Reply-To: =?US-ASCII?Q?<22C8A0D5D5E095449AB509FE777B5F80?= =?US-ASCII?Q?2BFB5AD@svr-exchange.avocado.emccsoft.com>?= MIME-Version: 1.0 Message-Id: <601.1156511282.919826@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-Pythagoras-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 Aug 25 09:24:35 2006, Ben Last wrote: > From: Dave Cridland [mailto:dave@cridland.net] Sent: 25 August 2006 > 09:04 > >FWIW, I do have a bit of a plan here: > >1) Assign a unique identifier to all mailboxes on a server. This > >unqiue identifier is essentially a shorthand for (mailbox path, > >UIDVALIDITY), except that should a folder be renamed, it will be > >preserved. This allows clients to shorten the triplet to a 2-tuple > >(mailbox id, UID). > > This I like very much; it also helps to solve the potentially very > expensive resynchronization/download currently incurred by renaming > of a > mailbox. ... which I don't think is a big problem, but it's a nice side-effect to take advantage of. > It could also help to identify "special" mailboxes, if there > were some agreement on reserved identifiers for certain special > mailboxes. > > No, sorry, I don't like magic numbers, only mystic names. :-) > >2) All messages acquire this 2-tuple when they first enter the > IMAP >server, whether via delivery or via APPEND. This 2-tuple is > preserved >across COPY. > Hang on; doesn't that imply that a message can be copied to another > mailbox, but keep the id of the mailbox in which it first appeared? Yes - I didn't intend to merely imply it, but state it categorically. It's kept as a distinct bit of information, though - ie, it still gets a new UID. > If > so, that means that nearly all messages would end up with the > mailbox id > of the INBOX, surely? > > That might happen, yes. It depends on what server-side delivery filtering is happening, for instance. I can't see a way of avoiding that, right now. > >3) The 2-tuple can be read via a FETCH operation that will only > >return the 2-tuple when the mailbox id differs from the current > >mailbox id - that is, it'll only be shown for messages which have > >been copied or otherwise duplicated with the knowledge of the IMAP > >server. > Interesting: presumably a SEARCH could also do this? > > I have to admit, I hadn't really considered that. > I guess this has already been considered, but if we're adding new > attributes (like this 2-tuple) to messages, why not just allocate a > unique id to each message on arrival, and preserve that over COPY? > Then > that id can serve to allow identification of individual messages as > duplicates between vfolders or mailboxes? Effectively this is what > you're doing, but with a 2-tuple. > > Yes. The first advantage of the 2-tuple is that if I do the currently mythical: A01 UID FETCH 1:* (PROPOSED2TUPLE) Then the server can omit the PROPOSED2TUPLE if it's the "default". As you point out, for many messages, this will only occur when they're seen in the INBOX, but maybe we can work out some refinement to deal with that. The second advantage is that it's lower impact on existing client code, or at least, I think it probably is. > Plus, as far as I can tell from a quick re-reading of > RFC3501, there's no reason that UIDVALIDITY values currently need > to be > unique across mailboxes. > > True - it's not the lack of uniqueness that stopped me making UIDVALIDITY serve double duty, since that additional constraint could have been retrospectively imposed by the extension, it was Phil pointing out that UIDVALIDITY MUST always increase for a mailbox, and therefore tends to get "bumped" by a RENAME. That I couldn't work around. 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 Aug 25 09:21:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGbco-0007zd-I5; Fri, 25 Aug 2006 09:21:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGbcm-0007xG-Gs for lemonade@ietf.org; Fri, 25 Aug 2006 09:21:28 -0400 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGbcl-0003gq-2K for lemonade@ietf.org; Fri, 25 Aug 2006 09:21:28 -0400 Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.12]) by smarthost.yourcomms.net (8.11.7p3+Sun/8.11.6) with ESMTP id k7PD8eH02610 for ; Fri, 25 Aug 2006 14:08:55 +0100 (BST) 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] About "Avoiding Duplicates" Date: Fri, 25 Aug 2006 14:18:29 +0100 Message-ID: <22C8A0D5D5E095449AB509FE777B5F8002BFBCDC@svr-exchange.avocado.emccsoft.com> In-Reply-To: <601.1156511282.919826@peirce.dave.cridland.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] About "Avoiding Duplicates" Thread-Index: AcbIR6L3NVJrPgeBT7GZNn0X8soXeAAAOfBA From: "Ben Last" To: "Enhancements to Internet email to support diverse service enivronments" X-Spam-Score: 0.0 (/) 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 >From: Dave Cridland [mailto:dave@cridland.net]=20 >Sent: 25 August 2006 14:08 >>On Fri Aug 25 09:24:35 2006, Ben Last wrote: >> This I like very much; it also helps to solve the potentially very=20 >> expensive resynchronization/download currently incurred by renaming of=20 >> a mailbox. >... which I don't think is a big problem, but it's a nice side-effect to take advantage of. Well, it doesn't happen very often, but there's a very large cost when it does. >> It could also help to identify "special" mailboxes, if there were=20 >> some agreement on reserved identifiers for certain special mailboxes. >No, sorry, I don't like magic numbers, only mystic names. :-) "Mystic identifiers", then :) Regards ben EMCC Software Ltd _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Aug 25 10:14:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGcRp-0002R9-N9; Fri, 25 Aug 2006 10:14:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGcRo-0002Qr-Sw for lemonade@ietf.org; Fri, 25 Aug 2006 10:14:12 -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 1GGcRo-00025m-RO for lemonade@ietf.org; Fri, 25 Aug 2006 10:14:12 -0400 Received: from laser.networkresonance.com ([198.144.196.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGc7E-000524-Mg for lemonade@ietf.org; Fri, 25 Aug 2006 09:52:57 -0400 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id 89CA6222425; Fri, 25 Aug 2006 07:00:48 -0700 (PDT) To: Dave Cridland Subject: Re: [lemonade] COMPRESS=mumble In-reply-to: Your message of "Fri, 25 Aug 2006 09:57:32 BST." <601.1156496253.302925@peirce.dave.cridland.net> X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 19) Date: Fri, 25 Aug 2006 06:52:51 -0700 From: Eric Rescorla Message-Id: <20060825140048.89CA6222425@laser.networkresonance.com> X-Spam-Score: -2.4 (--) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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: > On Thu Aug 24 15:27:57 2006, Eric Rescorla wrote: > > Tony Hansen wrote: > > > Another possibility is to add additional IANA considerations to the > > > table, such that there *IS* a description (either verbiage or ABNF) > > > associated with the DESCRIPTION column. > > But this has exactly the property that I was concerned about: > > LEMONADE is placing requirements on TLS documents... > > I hear what you're saying, but I seem to be missing why this is a > problem. Obviously. > And we're absolutely not talking about anything which affects security > - you say "requirements on TLS documents", but really, this would only > place requirements on TLS *COMPRESSION* documents. That's a > requirement on *TWO* documents in the history of TLS, so far. Of > course, I'm possibly unaware of some enormous activity within the > security area on compression which'll be defining new compression > methods for TLS by the dozen, but I don't understand why mandating > that such documents include a short alphanumeric string uniquely > identifying the algorithm is such a problem. You're assuming that's the only set of requirements, but that's not clear. I haven't studied the problem extensively, but it may or may not be the case that the technical requirements for TLS compression algorithms match the ones for LEMONADE compression algorithms. I know, for instance, that TLS compression algorithms have different requirements than DTLS compression algorithms, despite the fact that those two protocols are very closely related. So, the situation I'm trying to avoid is one in which someone wants to define a new compression algorithm for TLS and people find it's inappropriate for LEMONADE or vice versa. > It's not as if compression algorithms don't have names, and even if > they didn't, this is not a security-related requirement. The only > relation compression has to TLS is that TLS happens to provide the > facility - it's really nothing to do with security at all. Arguably, > TLS compression documents shouldn't come from the Security Area at all. Arguably so, but this doesn't amount to an argument that they should be defined in LEMONADE. > Personally, I feel that a single registry covering all compression > algorithms would benefit the general architecture of the IETF > enormously over a series of disconnected registries. Sure, but the first thing that would require would be an explicit statement of the protocol architectural interface that those algorithms were expected to provide, rather than the implicit one that happens to derive from TLS's characteristics. I fail to see what the "enormous" benefit of having one registry with three columns in it is over having two registries with two columns each. -Ekr _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Aug 25 14:39:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGgaW-0001Dt-3y; Fri, 25 Aug 2006 14:39:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGgaV-0001Do-FS for lemonade@ietf.org; Fri, 25 Aug 2006 14:39:27 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGgaU-0001sO-52 for lemonade@ietf.org; Fri, 25 Aug 2006 14:39: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 k7PIdI7s023574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 25 Aug 2006 11:39:19 -0700 Received: from [10.0.1.2] (dhcp-campbell-50.qualcomm.com [129.46.225.24]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7PIdF7N000318; Fri, 25 Aug 2006 11:39:17 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <20060825140048.89CA6222425@laser.networkresonance.com> References: <20060825140048.89CA6222425@laser.networkresonance.com> Date: Fri, 25 Aug 2006 11:39:12 -0700 To: Eric Rescorla , Dave Cridland From: Ted Hardie Subject: Re: [lemonade] COMPRESS=mumble Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 2.3 (++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 6:52 AM -0700 8/25/06, Eric Rescorla wrote: >You're assuming that's the only set of requirements, but that's not >clear. I haven't studied the problem extensively, but it may or may not >be the case that the technical requirements for TLS compression >algorithms match the ones for LEMONADE compression algorithms. Perhaps I misunderstood this, but I believe the working group previously discussed using these explicit compression algorithms until TLS compression is more widely deployed. So there are two points of connection here--these existing compression algorithms do match and there is an intent to transition toward using TLS compression more generally. (If I misunderstood the state of play here, sorry; please let me know). There might be, of course, conditions later where no TLS is present and compression is desired using some later non-TLS-friendly compression algorithm. But if I understand things correctly, that would be a change in design goals, which seem to be at the moment "compression should be tls-friendly" trending into "should be done in TLS" in the future. Revisiting the registry question at that point would make sense. In the short term, though, I suspect that skipping the registry is reasonable. The document will provide the names, and if there is a later need to expand them to include more algorithms, we'll have more data points to use in deciding whether the TLS-friendly aspect is a design constraint or not. regards, Ted _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Aug 25 18:09:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGjrc-0000dB-P6; Fri, 25 Aug 2006 18:09:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGjrb-0000d5-As for lemonade@ietf.org; Fri, 25 Aug 2006 18:09:19 -0400 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGjrZ-0002hg-RZ for lemonade@ietf.org; Fri, 25 Aug 2006 18:09:19 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.50) id 1GGjrZ-0002ct-0N; Fri, 25 Aug 2006 22:09:17 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 3570B498003; Fri, 25 Aug 2006 23:10:31 +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 15803-07; Fri, 25 Aug 2006 23:10:22 +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 5DF4D498002; Fri, 25 Aug 2006 23:10:22 +0100 (BST) Date: Fri, 25 Aug 2006 23:09:00 +0100 Subject: Re: [lemonade] COMPRESS=mumble References: <20060825140048.89CA6222425@laser.networkresonance.com> In-Reply-To: <20060825140048.89CA6222425@laser.networkresonance.com> MIME-Version: 1.0 Message-Id: <1754.1156543747.106946@peirce.dave.cridland.net> From: Dave Cridland To: Eric Rescorla 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: 73734d43604d52d23b3eba644a169745 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 Aug 25 14:52:51 2006, Eric Rescorla wrote: > Dave Cridland wrote: > > On Thu Aug 24 15:27:57 2006, Eric Rescorla wrote: > > > Tony Hansen wrote: > > > > Another possibility is to add additional IANA considerations > to the > > > > table, such that there *IS* a description (either verbiage or > ABNF) > > > > associated with the DESCRIPTION column. > > > But this has exactly the property that I was concerned about: > > > LEMONADE is placing requirements on TLS documents... > > > I hear what you're saying, but I seem to be missing why this is > a > > problem. > > Obviously. > > I should hope it was obvious, given that I said so. > You're assuming that's the only set of requirements, but that's not > clear. I haven't studied the problem extensively, but it may or may > not > be the case that the technical requirements for TLS compression > algorithms match the ones for LEMONADE compression algorithms. I > know, > for instance, that TLS compression algorithms have different > requirements than DTLS compression algorithms, despite the fact that > those two protocols are very closely related. > > Well, DTLS being datagram based, this would make sense. But both TLS and TCP provide an essentially streamed interface, albeit TLS has the framing information provided by an octet count. > So, the situation I'm trying to avoid is one in which someone > wants to define a new compression algorithm for TLS and people > find it's inappropriate for LEMONADE or vice versa. > I'm not convinced that's at all likely. You're basically saying that someone would need to find a compression algorithm such that it would need octet counting in its encoded state. That is to say, that the algorithm would fail if there were more compressed data after the compressed data it was operating on. I cannot conceive of such an algorithm, nor can I find any criteria at all which would prevent a COMPRESS=x algorithm from working as a TLS compression method. So I'll go for impossible in one direction, and highly improbable in the other. > > Personally, I feel that a single registry covering all compression > > algorithms would benefit the general architecture of the IETF > > enormously over a series of disconnected registries. > > Sure, but the first thing that would require would be an explicit > statement of the protocol architectural interface that those > algorithms were expected to provide, rather than the implicit > one that happens to derive from TLS's characteristics. > > Yes, absolutely. I'd consider that valuable work. Then a compression algorithm document could simply tick a handful of boxes and be available to a much wider range of protocols. > I fail to see what the "enormous" benefit of having one registry > with three columns in it is over having two registries with > two columns each. Obviously. :-) I used the word enormous concerning a single registry for compression algorithms, rather than the merely avoiding a single additional one. I still don't think that there's any real technical issue here at all, but this is going nowhere, so I'll assume we'll simply ditch the registry concept entirely for the sake of a quiet life. 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 Aug 25 20:04:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGle7-0004KB-Jx; Fri, 25 Aug 2006 20:03:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGle6-0004Jo-5P for lemonade@ietf.org; Fri, 25 Aug 2006 20:03:30 -0400 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGlQi-0001mj-Uo for lemonade@ietf.org; Fri, 25 Aug 2006 19:49:42 -0400 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id EDD19222425; Fri, 25 Aug 2006 16:57:36 -0700 (PDT) To: Dave Cridland Subject: Re: [lemonade] COMPRESS=mumble In-reply-to: Your message of "Fri, 25 Aug 2006 23:09:00 BST." <1754.1156543747.106946@peirce.dave.cridland.net> X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 19) Date: Fri, 25 Aug 2006 16:49:40 -0700 From: Eric Rescorla Message-Id: <20060825235736.EDD19222425@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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: > > So, the situation I'm trying to avoid is one in which someone > > wants to define a new compression algorithm for TLS and people > > find it's inappropriate for LEMONADE or vice versa. > I'm not convinced that's at all likely. You're basically saying that > someone would need to find a compression algorithm such that it would > need octet counting in its encoded state. That is to say, that the > algorithm would fail if there were more compressed data after the > compressed data it was operating on. > > I cannot conceive of such an algorithm, nor can I find any criteria at > all which would prevent a COMPRESS=x algorithm from working as a TLS > compression method. Well, it's not particularly difficult: one that potentially expands the data more than 1024-bytes, which is forbidden by RFC 3749. > I still don't think that there's any real technical issue here at all, > but this is going nowhere, so I'll assume we'll simply ditch the > registry concept entirely for the sake of a quiet life. Fine by me. -Ekr _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Aug 25 20:43:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGmGn-0001wO-UU; Fri, 25 Aug 2006 20:43:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGmGn-0001wJ-1r for lemonade@ietf.org; Fri, 25 Aug 2006 20:43:29 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGmGj-0007u6-Ml for lemonade@ietf.org; Fri, 25 Aug 2006 20:43:29 -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 k7Q0hIfc002390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 25 Aug 2006 17:43:18 -0700 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.172.15]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7Q0hGi8025567; Fri, 25 Aug 2006 17:43:17 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <0FA975F2D8295A448BE3ADC161244657D539B7@esebe199.NOE.Nokia.com> References: <0FA975F2D8295A448BE3ADC161244657D539B7@esebe199.NOE.Nokia.com> X-Mailer: Eudora for Mac OS X (dev alpha) X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Fri, 25 Aug 2006 17:40:52 -0700 To: , From: Randall Gellens Subject: Re: [lemonade] WGLC reconnect-client-01 Mime-Version: 1.0 X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 1.3 (+) 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: , Content-Type: multipart/mixed; boundary="===============0370772898==" Errors-To: lemonade-bounces@ietf.org --===============0370772898== Content-Type: text/html; charset="us-ascii" Re: [lemonade] WGLC reconnect-client-01
At 8:28 PM +0300 8/23/06, <Zoltan.Ordogh@nokia.com> wrote:

Hence, I propose to change the wording to:
"Such clients would need a way
   to quickly resynchronize with the IMAP server, without forcing the user to
   experience long delays and pay big bills for the amount of traffic
   generated by a less efficient resynchronization mechanism."

I'd suggest making it:

"Such clients need a way to quickly resynchronize without exposing the user to long delays or charges for data traffic caused by less efficient mechanisms."
--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
It is a general popular error to imagine the loudest
complainers for the public to be the most anxious for
its welfare.                     --Edmund Burke, 1769
--===============0370772898== 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 --===============0370772898==-- From lemonade-bounces@ietf.org Fri Aug 25 20:47:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGmKd-0003tg-Tp; Fri, 25 Aug 2006 20:47:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGmKd-0003tb-Eu for lemonade@ietf.org; Fri, 25 Aug 2006 20:47:27 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGmKc-0008Pa-4k for lemonade@ietf.org; Fri, 25 Aug 2006 20:47:27 -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 k7Q0lODN013343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 25 Aug 2006 17:47:25 -0700 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.172.15]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7Q0lMtO024382; Fri, 25 Aug 2006 17:47:23 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <0FA975F2D8295A448BE3ADC161244657DB7455@esebe199.NOE.Nokia.com> References: <0FA975F2D8295A448BE3ADC161244657DB7455@esebe199.NOE.Nokia.com> X-Mailer: Eudora for Mac OS X (dev alpha) X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Fri, 25 Aug 2006 17:43:26 -0700 To: , From: Randall Gellens Subject: RE: [lemonade] WGLC reconnect-client-01 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 6:48 AM +0300 8/25/06, wrote: > No, I mean the "known moment". It does not sound very good. "since a > known moment" -> "using timestamps"? > Since it is in the introduction section, I do not have strong feelings > about this. Personally, I think "known moment" is OK here, since it is a deterministic point in the mailbox history that is known to both client and server (the modseq). -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Invention is the mother of necessity. --Thorstein Veblen _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Aug 25 21:01:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGmYY-0002ri-1g; Fri, 25 Aug 2006 21:01:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGmYW-0002rd-Dd for lemonade@ietf.org; Fri, 25 Aug 2006 21:01:48 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGmYT-0001yy-2e for lemonade@ietf.org; Fri, 25 Aug 2006 21:01:48 -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 k7Q11OCB004301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 25 Aug 2006 18:01:25 -0700 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.172.15]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7Q11KCx007077; Fri, 25 Aug 2006 18:01:23 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <007501c6c7f6$71bfdf40$3478a40a@china.huawei.com> References: <007501c6c7f6$71bfdf40$3478a40a@china.huawei.com> X-Mailer: Eudora for Mac OS X (dev alpha) X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Fri, 25 Aug 2006 17:56:18 -0700 To: Lingyan Wu , lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade]About "Avoiding Duplicates" 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: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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:27 AM +0800 8/25/06, Lingyan Wu wrote: > Why will "appearing in more than one vfolders" lead to "duplicate > retrieval"? What's the direct reason? A client is likely to download message in all mailboxes that is synchronizes. It can't tell that message A in mailbox 1 is the same as message B in mailbox 2. > If more than one notifications (corresponding to the message > appearing in different vfolders) for the same message lead to > "duplicate retrieval", server can solve the problem by only sending > one notification for the same message. How would the server decide for which mailbox to send the notification? Also, clients download messages when they SELECT mailboxes. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- The ignorance of how to use new knowledge stockpiles exponentially. --Marshall McLuhan _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Aug 25 21:01:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGmYh-0002t2-7C; Fri, 25 Aug 2006 21:01:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGmYg-0002sx-3M for lemonade@ietf.org; Fri, 25 Aug 2006 21:01:58 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGmYd-00020v-PO for lemonade@ietf.org; Fri, 25 Aug 2006 21:01:58 -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 k7Q11M1J004296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 25 Aug 2006 18:01:23 -0700 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.172.15]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7Q11KCv007077; Fri, 25 Aug 2006 18:01:21 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <22C8A0D5D5E095449AB509FE777B5F8002BFB214@svr-exchange.avocado.emccsof t.com> References: <22C8A0D5D5E095449AB509FE777B5F8002BFB214@svr-exchange.avocado.emccsof t.com> X-Mailer: Eudora for Mac OS X (dev alpha) X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Fri, 25 Aug 2006 17:56:30 -0700 To: "Ben Last" , "Lingyan Wu" , From: Randall Gellens Subject: RE: [lemonade]About "Avoiding Duplicates" 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: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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:57 AM +0100 8/25/06, Ben Last wrote: > I think the key point here (and this applies to your comments about > question 2 also) is that vfolders appears as if they are standard > mailboxes. Thus the client treats them as such, and must also make the > assumption that a message in one mailbox is distinct from all other > messages in other mailboxes. The proposed VFOLDER extension includes no > way to allow a client to see that one message is in fact a duplicate of > another. Yes, this is the key point. It was a topic of some discussion at our last meeting. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- If God lived on Earth, people would knock out all His windows. --Yiddish saying _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Aug 25 21:02:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGmYi-0002uF-F4; Fri, 25 Aug 2006 21:02:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGmYh-0002uA-C6 for lemonade@ietf.org; Fri, 25 Aug 2006 21:01:59 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGmYe-00020w-0r for lemonade@ietf.org; Fri, 25 Aug 2006 21:01:59 -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 k7Q11Phd004306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 25 Aug 2006 18:01:26 -0700 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.172.15]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7Q11KD1007077; Fri, 25 Aug 2006 18:01:25 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <22C8A0D5D5E095449AB509FE777B5F8002BFB5AD@svr-exchange.avocado.emccsof t.com> References: <22C8A0D5D5E095449AB509FE777B5F8002BFB5AD@svr-exchange.avocado.emccsof t.com> X-Mailer: Eudora for Mac OS X (dev alpha) X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Fri, 25 Aug 2006 17:56:38 -0700 To: "Ben Last" , From: Randall Gellens Subject: RE: [lemonade]About "Avoiding Duplicates" 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 9:24 AM +0100 8/25/06, Ben Last wrote: > There's at least one server I'm aware of that can change the UIDVALIDITY > of mailboxes in response to (what I consider) quite common/low-level > operations, incurring a severe re-synchronization/download penalty for > our client. Such a server would impose penalties on most clients, I think. It's quite rude of the server, really. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Eight out of every five people are math illiterate. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Aug 25 21:02:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGmYl-000303-LF; Fri, 25 Aug 2006 21:02:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGmYk-0002wD-7u for lemonade@ietf.org; Fri, 25 Aug 2006 21:02:02 -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 1GGmYk-000249-6I for lemonade@ietf.org; Fri, 25 Aug 2006 21:02:02 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGmYg-00026l-9N for lemonade@ietf.org; Fri, 25 Aug 2006 21:02:01 -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 k7Q11RC8004310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 25 Aug 2006 18:01:28 -0700 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.172.15]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7Q11KD3007077; Fri, 25 Aug 2006 18:01:26 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <22C8A0D5D5E095449AB509FE777B5F8002BFBB48@svr-exchange.avocado.emccsof t.com> References: <22C8A0D5D5E095449AB509FE777B5F8002BFBB48@svr-exchange.avocado.emccsof t.com> X-Mailer: Eudora for Mac OS X (dev alpha) X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Fri, 25 Aug 2006 17:59:18 -0700 To: "Ben Last" , From: Randall Gellens Subject: Re: [lemonade] Message priority 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: 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 As an aside, note that 'Importance' is the politically-correct version of 'x-priority'. Many clients today recognize both; some generate one, some both. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Frankly, facts have nothing to do with what people's opinions are and will be. --Jon Bond, president Bond + Partners (an ad agency), talking about political commercials _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Aug 25 21:24:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGmuC-0006Sy-NW; Fri, 25 Aug 2006 21:24:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGmuA-0006St-Sn for lemonade@ietf.org; Fri, 25 Aug 2006 21:24:10 -0400 Received: from smtp-out.sendmail.com ([209.246.26.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGmu9-0003Zi-HQ for lemonade@ietf.org; Fri, 25 Aug 2006 21:24:10 -0400 Received: from [10.201.0.58] (adsl-64-58-1-252.mho.net [64.58.1.252] (may be forged)) (authenticated bits=0) by foon.sendmail.com (Switch-3.2.4/Switch-3.2.0) with ESMTP id k7Q1NKMK020245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Aug 2006 18:23:22 -0700 X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com k7Q1NKMK020245 DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1156555405; bh=pVvxZeTRGIpjpSnqgzADkDSH/xc=; h=X-DomainKeys: DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:In-Reply-To: Message-ID:References:MIME-Version:Content-Type; b=iD8fiFm53hlWO0nX oHMe+rkOpWiZSc1rfG7z+Erz6hy39bnSu3Rbhbp689P1Rt0aptPCDeNi2qwDH9B1x4w 8TteugLea378GaiKCBOyBDdWGcswtrsp3b0SokaactpCqh1fpza5PPenAbdahfvGvfH 0NwoLwl/s+yHbC3OjdsCc= X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com k7Q1NKMK020245 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type; b=muQeDItyfeBbMF1jYzbNLBdMD67e4kqedVayR7BTvvRp3ihBdrVYvgGbZrgPMjimT j5lyzRITp4hrjpz6rAfUrN27y2qu/JaZKvp4q1qHaTorSnX4t0IagSVPlq4UnKO8pXs d/UCooYley8Kb+xTyqW+Sg1giUA/oxXylKbW9eI= Date: Fri, 25 Aug 2006 19:23:17 -0600 From: Philip Guenther X-X-Sender: guenther@vanye.mho.net To: Ben Last Subject: RE: [lemonade]About "Avoiding Duplicates" In-Reply-To: Message-ID: References: <22C8A0D5D5E095449AB509FE777B5F8002BFB5AD@svr-exchange.avocado.emccsof t.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 9:24 AM +0100 8/25/06, Ben Last wrote: > There's at least one server I'm aware of that can change the UIDVALIDITY > of mailboxes in response to (what I consider) quite common/low-level > operations, incurring a severe re-synchronization/download penalty for > our client. Could you describe the operations that cause the UIDVALIDITY changes? RENAME _has_ to do that in some cases, but that's the only pure-IMAP operation I can think of that does so. Philip Guenther _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Aug 25 23:21:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGojV-0001GX-9D; Fri, 25 Aug 2006 23:21:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGojU-0001GP-CO for lemonade@ietf.org; Fri, 25 Aug 2006 23:21:16 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGojS-0004YV-SW for lemonade@ietf.org; Fri, 25 Aug 2006 23:21:16 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.7) with ESMTP id k7Q2LDZf014305; Sat, 26 Aug 2006 05:21:15 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 26 Aug 2006 06:21:06 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 26 Aug 2006 06:21:08 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [lemonade] WGLC reconnect-client-01 Date: Sat, 26 Aug 2006 06:20:31 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657DB7B1F@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] WGLC reconnect-client-01 Thread-Index: AcbIqLVGgmJ34rRAQ3O42eqHG5DEugAFcx5Q From: To: , X-OriginalArrivalTime: 26 Aug 2006 03:21:08.0078 (UTC) FILETIME=[ABF290E0:01C6C8BE] X-Spam-Score: 0.2 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 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: , Content-Type: multipart/mixed; boundary="===============1632794344==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============1632794344== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6C8BE.AB60EFFA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6C8BE.AB60EFFA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Randall, yes, even better. =20 Best regards: Zolt=E1n =D6rd=F6gh=20 E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566=20 =20 ________________________________ From: ext Randall Gellens [mailto:randy@qualcomm.com]=20 Sent: 26 August, 2006 03:41 To: Ordogh Zoltan (Nokia-TP-MSW/Tampere); lemonade@ietf.org Subject: Re: [lemonade] WGLC reconnect-client-01 =09 =09 At 8:28 PM +0300 8/23/06, wrote: Hence, I propose to change the wording to: =09 "Such clients would need a way to quickly resynchronize with the IMAP server, without forcing the = user to experience long delays and pay big bills for the amount of traffic generated by a less efficient resynchronization mechanism." I'd suggest making it: "Such clients need a way to quickly resynchronize without exposing the = user to long delays or charges for data traffic caused by less efficient = mechanisms." --=20 Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- It is a general popular error to imagine the loudest complainers for the public to be the most anxious for its welfare. --Edmund Burke, 1769 =09 ------_=_NextPart_001_01C6C8BE.AB60EFFA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [lemonade] WGLC reconnect-client-01
Hi Randall,
yes, even better.
 

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

 

From: ext Randall Gellens=20 [mailto:randy@qualcomm.com]
Sent: 26 August, 2006=20 03:41
To: Ordogh Zoltan (Nokia-TP-MSW/Tampere);=20 lemonade@ietf.org
Subject: Re: [lemonade] WGLC=20 reconnect-client-01

At 8:28 PM +0300 8/23/06, <Zoltan.Ordogh@nokia.com> = wrote:

Hence, I=20 propose to change the wording to:
"Such clients = would need a=20 way
   to quickly resynchronize with the IMAP server, = without=20 forcing the user to
   experience long delays and pay = big bills=20 for the amount of traffic
  =20 generated by a less efficient resynchronization = mechanism."

I'd suggest making it:

"Such clients need a way to quickly resynchronize without = exposing the=20 user to long delays or charges for data traffic caused by less = efficient=20 mechanisms."
--=20
Randall Gellens
Opinions are=20 personal;    facts are suspect;    I = speak for=20 myself only
-------------- Randomly-selected tag: = ---------------
It is=20 a general popular error to imagine the loudest
complainers for the = public=20 to be the most anxious for
its welfare.=20 =             &= nbsp;       --Edmund=20 Burke, 1769
------_=_NextPart_001_01C6C8BE.AB60EFFA-- --===============1632794344== 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 --===============1632794344==-- From lemonade-bounces@ietf.org Fri Aug 25 23:21:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGojr-0001Ij-GR; Fri, 25 Aug 2006 23:21:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGojq-0001IY-2o for lemonade@ietf.org; Fri, 25 Aug 2006 23:21:38 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGojm-0004al-Ka for lemonade@ietf.org; Fri, 25 Aug 2006 23:21:38 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.7) with ESMTP id k7Q3LXuo011572; Sat, 26 Aug 2006 06:21:33 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 26 Aug 2006 06:21:33 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 26 Aug 2006 06:21:33 +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] WGLC reconnect-client-01 Date: Sat, 26 Aug 2006 06:20:58 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657DB7B20@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] WGLC reconnect-client-01 Thread-Index: AcbIqa15vA8ozCViS0WltDHLohKT9wAFPAew From: To: , X-OriginalArrivalTime: 26 Aug 2006 03:21:33.0088 (UTC) FILETIME=[BADACA00:01C6C8BE] X-Spam-Score: 0.2 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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, let's keep the existing one then. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 =20 >-----Original Message----- >From: ext Randall Gellens [mailto:randy@qualcomm.com]=20 >Sent: 26 August, 2006 03:43 >To: Ordogh Zoltan (Nokia-TP-MSW/Tampere); alexey.melnikov@isode.com >Cc: lemonade@ietf.org >Subject: RE: [lemonade] WGLC reconnect-client-01 > >At 6:48 AM +0300 8/25/06, wrote: > >> No, I mean the "known moment". It does not sound very good.=20 >"since a =20 >> known moment" -> "using timestamps"? >> Since it is in the introduction section, I do not have strong=20 >> feelings about this. > >Personally, I think "known moment" is OK here, since it is a=20 >deterministic point in the mailbox history that is known to=20 >both client and server (the modseq). >-- >Randall Gellens >Opinions are personal; facts are suspect; I speak for myself only >-------------- Randomly-selected tag: --------------- >Invention is the mother of necessity. --Thorstein Veblen > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Aug 25 23:42:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGp4J-0003vQ-5w; Fri, 25 Aug 2006 23:42:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGp4H-0003vE-30 for lemonade@ietf.org; Fri, 25 Aug 2006 23:42:45 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGp4F-00081B-9J for lemonade@ietf.org; Fri, 25 Aug 2006 23:42:45 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4L00NRW6F738@szxga01-in.huawei.com> for lemonade@ietf.org; Sat, 26 Aug 2006 11:45:07 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4L00HWA6F6YU@szxga01-in.huawei.com> for lemonade@ietf.org; Sat, 26 Aug 2006 11:45:07 +0800 (CST) Received: from w48795 ([10.164.120.52]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4L00MVV6GK2A@szxml03-in.huawei.com> for lemonade@ietf.org; Sat, 26 Aug 2006 11:45:57 +0800 (CST) Date: Sat, 26 Aug 2006 11:41:51 +0800 From: Lingyan Wu Subject: Re: [lemonade]About "Avoiding Duplicates" To: lemonade@ietf.org Message-id: <006401c6c8c1$9180ab90$3478a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <22C8A0D5D5E095449AB509FE777B5F8002BFB214@svr-exchange.avocado.emccsoft.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Lingyan Wu List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org ----- Original Message ----- From: "Ben Last" To: "Lingyan Wu" ; Sent: Friday, August 25, 2006 2:57 PM Subject: RE: [lemonade]About "Avoiding Duplicates" >>From: Lingyan Wu [mailto:wulingyan_48795@huawei.com] >>Sent: 25 August 2006 04:28 >>A message appearing in more than one vfolders may lead to duplicate >>retrieval of such a message. >>Why will "appearing in more than one vfolders" lead to "duplicate >>retrieval"? What's the direct reason? >>I have seen all of the emails talking about the question but I still >>think it's very strange. >>If more than one notifications (corresponding to the message appearing >>in different vfolders) for the same message >>lead to "duplicate retrieval", server can solve the problem by only >>sending one notification for the same message. >> >Notifications are only one way in which a client is advised of the >existence of a message. The EXISTS count also implies it, and certainly >our client will use both the EXISTS responses to SELECT commands as well >as notifications to keep the list of messsages per mailbox up to date. >>If client downloads the message from one vfolder (actually it exists in >>the backing mailbox), it >>will be tagged "SEEN" or some other tag indicating that the message has >>been downloaded in all >>the folders that the message appears in, so the problem can be >>resolved. >That assumes only one client. A Lemonade server is very likely to have >multiple clients accessing the same account (set of mailboxes), so the >"tag" would need to be client-specific. Also, adding a tag means that >clients need to be extended to handle that tag, and the tag needs to be >standardized, etc. >Also, this may not solve the problem; tagging a message as "seen" >doesn't allow the client to spot the same message in all other >mailboxes/vfolders in which it appears. The problem is in spotting the >fact that message A in vfolder X is a duplicate of message B in vfolder >Y. [Lingyan]-------------------------------------------------- I didn't assumes only one client but just one user with one or more clients (devices). If I download one message through one client, I also want the message appears "having to be downloaded" to other clients. If I download one message from one vfolder, I also want the same message in another vfolder appears "having to be downloaded" . After all, all the messages in vfolders are just "link" of the actual messages in the backing mailbox, right? Could the statuses (or flags) of a message in different vfolders be different or not? Maybe it's the key question. >>That a message appears, disappears and reappears in a VFOLDER may >>result in unnecessary duplication >>of message on a client and may interfere with notification mechanisms. >>Why will it lead to such results? >Because when a message appears in a vfolder it is given a UID; if it >then disappears and reappears it would be given a new UID. The UIDs >would be allocated within the VFOLDER and not be the UIDs from the >underlying mailboxes, because otherwise the semantics of UIDs would be >broken (that's my understanding; I welcome corrections on this or any >other point!). > >I think the key point here (and this applies to your comments about >question 2 also) is that vfolders appears as if they are standard >mailboxes. Thus the client treats them as such, and must also make the >assumption that a message in one mailbox is distinct from all other >messages in other mailboxes. The proposed VFOLDER extension includes no >way to allow a client to see that one message is in fact a duplicate of >another. > [Lingyan]---------------------------------------------------------------- Does it mean that the message appearing in different vfolders (actually only "message link" and some related information, right? ) should be dealt with independently and never impact each other including flags? If the flags of the same message keep the same in all of the vfolders where it appears... what will happen? Regards Lingyan _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Aug 25 23:46:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGp7S-0005sp-Li; Fri, 25 Aug 2006 23:46:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGp7S-0005sh-3u for lemonade@ietf.org; Fri, 25 Aug 2006 23:46:02 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGp7Q-0008US-NJ for lemonade@ietf.org; Fri, 25 Aug 2006 23:46:02 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4L008V3795AY@szxga02-in.huawei.com> for lemonade@ietf.org; Sat, 26 Aug 2006 12:03:05 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4L008I3794O0@szxga02-in.huawei.com> for lemonade@ietf.org; Sat, 26 Aug 2006 12:03:05 +0800 (CST) Received: from w48795 ([10.164.120.52]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4L00M0J6M22A@szxml03-in.huawei.com> for lemonade@ietf.org; Sat, 26 Aug 2006 11:49:15 +0800 (CST) Date: Sat, 26 Aug 2006 11:45:10 +0800 From: Lingyan Wu Subject: Re: [lemonade]About "Avoiding Duplicates" To: lemonade@ietf.org Message-id: <006701c6c8c2$07a8c730$3478a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <007501c6c7f6$71bfdf40$3478a40a@china.huawei.com> <601.1156493030.076873@peirce.dave.cridland.net> X-Spam-Score: 0.5 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Lingyan Wu List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org ----- Original Message ----- From: "Dave Cridland" To: "Lingyan Wu" Cc: "Enhancements to Internet email to support diverse service enivronments" Sent: Friday, August 25, 2006 4:03 PM Subject: Re: [lemonade]About "Avoiding Duplicates" > On Fri Aug 25 04:27:50 2006, Lingyan Wu wrote: >> Why will "appearing in more than one vfolders" lead to "duplicate >> retrieval"? What's the direct reason? >> >> I have seen all of the emails talking about the question but I still >> think it's very strange. >> >> > In IMAP, a message can be uniquely identified by a triplet of (mailbox > path, UIDVALIDITY, UID). Whenever a message is copied by a third party - > including the implicit copy by a virtual mailbox implementation - it > appears, to the client, as an entirely new mailbox - there is no reliable > mechansim by which the client can identify the message as being previously > known - or also known - by any other triplet than the one the client sees. [Lingyan]------------------------------------ The same point just as in the last reply email i sent: if the flags of the same message keep the same all of the time in all vfolders where it appears, the user will know he has seen or downloaded or been notified the message in another vfolder (or through another client). The server should know what has happened to the message. > > Unfortunately, the Message-Id field doesn't quite identify the message - > you may get two copies of this message, for instance - the one sent to the > list, and the one sent directly to you. The one sent to the list will have > additional metadata present in the List-* fields, and also it'll have the > "lemonade mailing list" information appended to the bottom. [Lingyan]---------------------- I agree. > > Of course, the triplet only identifies a message on a single server - > really, there's more information than that, like the server's name, it's > port number, etc. This is essentially encompassed into an IMAP URL. > Copying a message gives it a new URL, but there's no method to find the > original, nor is there any method to find out if there even was one. > [Lingyan]--------------------------------- Messages appearing in different vfolders are just "Links" of the actual messages in the backing mailbox, right? The server could get the original mailbox and UID of the message from "mapping record". Maybe it is not like COPY. If i misunderstand you, please correct me. > >> If more than one notifications (corresponding to the message appearing in >> different vfolders) for the same message lead to "duplicate retrieval", >> server can solve the problem by only sending one notification for the >> same message. >> >> > Yes, but the notification would then only point to one message - > conceptually, within IMAP, there is no such thing as a message in two > mailboxes. [Lingyan]-------------------------------------------- What you means is that one notification points to one actual message even if the message appears in different vfolders, right? E.g. If a message arrives and appears in two vfolders (e.g. Lemonade & CompanyX) (and the user has set that all the messages appearing in the two vfolders should be notified ), the server only sends one notification for a "lemonade mailing list" message coming from xyz@companyX.com . > > >> If client downloads the message from one vfolder (actually it exists in >> the backing mailbox), it will be tagged "SEEN" or some other tag >> indicating that the message has been downloaded in all the folders that >> the message appears in, so the problem can be resolved. >> >> > Not quite - for resynchronization operations (as opposed to online > reading), flags are left unchanged by downloading the message. [Lingyan]--------------------------------- Unchanged? Is it possible to set a flag meaning that the message has been downloaded or not? I think it's useful. >Even if this were not the case, there is no way to tell what data relates >to the message you've apparently already read. > > FWIW, I do have a bit of a plan here: > > 1) Assign a unique identifier to all mailboxes on a server. This unqiue > identifier is essentially a shorthand for (mailbox path, UIDVALIDITY), > except that should a folder be renamed, it will be preserved. This allows > clients to shorten the triplet to a 2-tuple (mailbox id, UID). > > 2) All messages acquire this 2-tuple when they first enter the IMAP > server, whether via delivery or via APPEND. This 2-tuple is preserved > across COPY. > > 3) The 2-tuple can be read via a FETCH operation that will only return the > 2-tuple when the mailbox id differs from the current mailbox id - that is, > it'll only be shown for messages which have been copied or otherwise > duplicated with the knowledge of the IMAP server. > > This last is a bit of a hack, I admit, but it's one that eliminates the > overhead of retrieving the data when it's mostly redundant. It's never > redundant for virtual mailboxes, of course. I was hoping to re-use the > UIDVALIDITY as a mailbox id, but Philip Guenther pointed out this won't > work in all cases. > >> Questions 2: That a message appears, disappears and reappears in a >> VFOLDER may result in unnecessary duplication of message on a client and >> may interfere with notification mechanisms. >> >> Why will it lead to such results? >> >> > I think Ben Last answered this sufficiently well that I've nothing to add. > > 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 Aug 25 23:49:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGpAn-0007xq-G9; Fri, 25 Aug 2006 23:49:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGpAm-0007xi-0r for lemonade@ietf.org; Fri, 25 Aug 2006 23:49:28 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGpAk-0000WS-8l for lemonade@ietf.org; Fri, 25 Aug 2006 23:49:28 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4L00N5S6QH38@szxga01-in.huawei.com> for lemonade@ietf.org; Sat, 26 Aug 2006 11:51:54 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4L00HA86QHXE@szxga01-in.huawei.com> for lemonade@ietf.org; Sat, 26 Aug 2006 11:51:53 +0800 (CST) Received: from w48795 ([10.164.120.52]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4L008C175G71@szxml04-in.huawei.com> for lemonade@ietf.org; Sat, 26 Aug 2006 12:00:53 +0800 (CST) Date: Sat, 26 Aug 2006 11:48:38 +0800 From: Lingyan Wu Subject: Re: [lemonade]About "Avoiding Duplicates" To: lemonade@ietf.org Message-id: <006a01c6c8c2$8423d7f0$3478a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <007501c6c7f6$71bfdf40$3478a40a@china.huawei.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Lingyan Wu List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org ----- Original Message ----- From: "Randall Gellens" To: "Lingyan Wu" ; Sent: Saturday, August 26, 2006 8:56 AM Subject: Re: [lemonade]About "Avoiding Duplicates" > At 11:27 AM +0800 8/25/06, Lingyan Wu wrote: > >> Why will "appearing in more than one vfolders" lead to "duplicate >> retrieval"? What's the direct reason? > > A client is likely to download message in all mailboxes that is > synchronizes. It can't tell that message A in mailbox 1 is the same as > message B in mailbox 2. [Lingyan]----------------------------------------------------------------- I'll give the same answer and question with my other reply emails. Assume that the flags of the same message keep the same in all of the vfolder where it appears and there is such a flag meaning that the message has been downloaded or not. If a client has downloaded the message from a vfolder ,the flag of the message in all of the vfolder where it appears as well as the backing mailbox will be changed , and the server/client/user will know what has happend to the message so "duplicate retrieval" could be avoided. > >> If more than one notifications (corresponding to the message appearing >> in different vfolders) for the same message lead to "duplicate >> retrieval", server can solve the problem by only sending one notification >> for the same message. > > How would the server decide for which mailbox to send the notification? > Also, clients download messages when they SELECT mailboxes. [Lingyan]------------------------------------------------------------------------- I think user could set that all the messages appearing in certain vfolders should be notified. > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly-selected tag: --------------- > The ignorance of how to use new knowledge stockpiles exponentially. > --Marshall McLuhan > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Aug 26 00:03:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGpO1-0006f1-Qs; Sat, 26 Aug 2006 00:03:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGpO0-0006ew-UT for lemonade@ietf.org; Sat, 26 Aug 2006 00:03:08 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGpNz-0002mb-Dx for lemonade@ietf.org; Sat, 26 Aug 2006 00:03:08 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4L00LKK7LQD9@szxga03-in.huawei.com> for lemonade@ietf.org; Sat, 26 Aug 2006 12:10:38 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4L009057LQ49@szxga03-in.huawei.com> for lemonade@ietf.org; Sat, 26 Aug 2006 12:10:38 +0800 (CST) Received: from w48795 ([10.164.120.52]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4L00MMP7B02A@szxml03-in.huawei.com> for lemonade@ietf.org; Sat, 26 Aug 2006 12:04:13 +0800 (CST) Date: Sat, 26 Aug 2006 12:00:08 +0800 From: Lingyan Wu Subject: The last three emails are different, not repeated email. Thanks. //Re: [lemonade]About "Avoiding Duplicates" To: lemonade@ietf.org Message-id: <007b01c6c8c4$1f11e710$3478a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.5 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Lingyan Wu List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Aug 28 17:13:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHoPb-0000rR-LS; Mon, 28 Aug 2006 17:12:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHoPa-0000qL-LO for lemonade@ietf.org; Mon, 28 Aug 2006 17:12:50 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHoPY-0004Yq-5l for lemonade@ietf.org; Mon, 28 Aug 2006 17:12: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 k7SLCYFB028953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 28 Aug 2006 14:12:35 -0700 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.172.15]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7SLCXZu021210; Mon, 28 Aug 2006 14:12:34 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <006701c6c8c2$07a8c730$3478a40a@china.huawei.com> <006a01c6c8c2$8423d7f0$3478a40a@china.huawei.com> References: <007501c6c7f6$71bfdf40$3478a40a@china.huawei.com> <601.1156493030.076873@peirce.dave.cridland.net> <006701c6c8c2$07a8c730$3478a40a@china.huawei.com> <007501c6c7f6$71bfdf40$3478a40a@china.huawei.com> <006a01c6c8c2$8423d7f0$3478a40a@china.huawei.com> X-Mailer: Eudora for Mac OS X (dev alpha) X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Mon, 28 Aug 2006 14:12:26 -0700 To: Lingyan Wu , lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade]About "Avoiding Duplicates" 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: 0fa76816851382eb71b0a882ccdc29ac 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 11:41 AM +0800 8/26/06, Lingyan Wu wrote: > If I download one message through one client, I also want the message > appears "having to be downloaded" to other clients. > If I download one message from one vfolder, I also want the same > message in another vfolder appears "having to be downloaded" . > After all, all the messages in vfolders are just "link" of the > actual messages in the backing mailbox, right? > Could the statuses (or flags) of a message in different vfolders > be different or not? Maybe it's the key question. I think there are two issues here: There is no standard way in IMAP for a message to be marked as 'downloaded'. A client can use a custom flag for this if the server supports custom flags. However, other clients won't know what the flag means. IMAP does have a standard \Seen flag, which might provide what you're looking for. Many clients use this flag to know how to present the message in the UI's listing of messages within a mailbox. If the flag is not set, the client presents the message as being 'new' or 'unseen'. If the flag is present, the client shows the message's status as 'read'. For example, in Eudora there is a big dot in the 'status' column of the message listing for messages that have not been seen. IMAP also has a \Recent flag, but this is probably not what you want. At 11:45 AM +0800 8/26/06, Lingyan Wu wrote: > The same point just as in the last reply email i sent: if the flags > of the same message keep the same all of the time in all vfolders > where it appears, the user will know he has seen or downloaded or > been notified the message in another vfolder (or through another > client). The server should know what has happened to the message. I think this goes to the central issue regarding vmailbox, views, contexts, and similar facilities that are now being discussed or have been proposed in the past: At 7:57 AM +0100 8/25/06, Ben Last wrote: > I think the key point here (and this applies to your comments about > question 2 also) is that vfolders appears as if they are standard > mailboxes. If the facility uses virtual mailboxes that appear as regular mailboxes, then a message which exists in a physical mailbox and also in one or more virtual mailboxes will appear to the client as multiple messages. However, if the facility is a form of searching or sub-mailbox, then the client can know that the message exists elsewhere. I don't think the group has picked one approach over the other as yet. >> Not quite - for resynchronization operations (as opposed to online >> reading), flags are left unchanged by downloading the message. > > [Lingyan]--------------------------------- > Unchanged? Is it possible to set a flag meaning that the message > has been downloaded or not? I think it's useful. There is not currently a standard IMAP flag that means the message has been downloaded, but there is a flag that indicates the message has been seen. Do you really want a client that will only download messages that no other client has yet downloaded? That seems strange, since if you see a message on your desktop you will not see it on your phone. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Cabbage: A familiar kitchen-garden vegetable about as large and wise as a man's head. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Aug 29 01:07:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHvo4-00046d-Sl; Tue, 29 Aug 2006 01:06:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHvo3-00046U-6J for lemonade@ietf.org; Tue, 29 Aug 2006 01:06:35 -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 1GHu38-0006Wd-SJ for lemonade@ietf.org; Mon, 28 Aug 2006 23:14:02 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GHtvc-0002yE-6Q for lemonade@ietf.org; Mon, 28 Aug 2006 23:06:19 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4Q00HKYOPTG6@szxga01-in.huawei.com> for lemonade@ietf.org; Tue, 29 Aug 2006 11:08:17 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4Q00MABOPS5V@szxga01-in.huawei.com> for lemonade@ietf.org; Tue, 29 Aug 2006 11:08:17 +0800 (CST) Received: from w48795 ([10.164.120.52]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4Q00CSYP4S9O@szxml04-in.huawei.com> for lemonade@ietf.org; Tue, 29 Aug 2006 11:17:17 +0800 (CST) Date: Tue, 29 Aug 2006 11:04:57 +0800 From: Lingyan Wu Subject: Re: [lemonade]About "Avoiding Duplicates" To: Randall Gellens , lemonade@ietf.org Message-id: <004401c6cb17$e9379c60$3478a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <007501c6c7f6$71bfdf40$3478a40a@china.huawei.com> <601.1156493030.076873@peirce.dave.cridland.net> <006701c6c8c2$07a8c730$3478a40a@china.huawei.com> <007501c6c7f6$71bfdf40$3478a40a@china.huawei.com> <006a01c6c8c2$8423d7f0$3478a40a@china.huawei.com> X-Spam-Score: -2.6 (--) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Lingyan Wu List-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 for your reply! Inline. ----- Original Message ----- From: "Randall Gellens" To: "Lingyan Wu" ; Sent: Tuesday, August 29, 2006 5:12 AM Subject: Re: [lemonade]About "Avoiding Duplicates" > At 11:41 AM +0800 8/26/06, Lingyan Wu wrote: >> If I download one message through one client, I also want the message >> appears "having to be downloaded" to other clients. >> If I download one message from one vfolder, I also want the same message >> in another vfolder appears "having to be downloaded" . >> After all, all the messages in vfolders are just "link" of the actual >> messages in the backing mailbox, right? >> Could the statuses (or flags) of a message in different vfolders be >> different or not? Maybe it's the key question. > > I think there are two issues here: > > There is no standard way in IMAP for a message to be marked as > 'downloaded'. A client can use a custom flag for this if the server > supports custom flags. However, other clients won't know what the flag > means. > > IMAP does have a standard \Seen flag, which might provide what you're > looking for. Many clients use this flag to know how to present the > message in the UI's listing of messages within a mailbox. If the flag is > not set, the client presents the message as being 'new' or 'unseen'. If > the flag is present, the client shows the message's status as 'read'. For > example, in Eudora there is a big dot in the 'status' column of the > message listing for messages that have not been seen. > [Lingyan]--------------------------- Does downloading a message or sending a notification for the arrival of the messge not affect any flag of the message? Another simple question: What data (corresponding a certain message) are there in a vfolder? (UID, flags, link of the actual message)? Maybe the flags of the same message (e.g. \Seen,\Answered etc) could keep the same in different vfolders where it appears, so that the server/user could find what had happened to the message to determin what to do. > IMAP also has a \Recent flag, but this is probably not what you want. > > > At 11:45 AM +0800 8/26/06, Lingyan Wu wrote: > >> The same point just as in the last reply email i sent: if the flags of >> the same message keep the same all of the time in all vfolders where it >> appears, the user will know he has seen or downloaded or been notified >> the message in another vfolder (or through another client). The server >> should know what has happened to the message. > > I think this goes to the central issue regarding vmailbox, views, > contexts, and similar facilities that are now being discussed or have been > proposed in the past: > > At 7:57 AM +0100 8/25/06, Ben Last wrote: >> I think the key point here (and this applies to your comments about >> question 2 also) is that vfolders appears as if they are standard >> mailboxes. > > If the facility uses virtual mailboxes that appear as regular mailboxes, > then a message which exists in a physical mailbox and also in one or more > virtual mailboxes will appear to the client as multiple messages. > > However, if the facility is a form of searching or sub-mailbox, then the > client can know that the message exists elsewhere. > > I don't think the group has picked one approach over the other as yet. > >>> Not quite - for resynchronization operations (as opposed to online >>> reading), flags are left unchanged by downloading the message. >> >> [Lingyan]--------------------------------- >> Unchanged? Is it possible to set a flag meaning that the message has >> been downloaded or not? I think it's useful. > > There is not currently a standard IMAP flag that means the message has > been downloaded, but there is a flag that indicates the message has been > seen. Do you really want a client that will only download messages that > no other client has yet downloaded? That seems strange, since if you see > a message on your desktop you will not see it on your phone. > [Lingyan]------------------------------------------- I want such a flag for the following reason: A message appearing in more than one vfolders: If a client downloads the message from one vfolder, the message will appears "downloaded" in all of the vfolders where it appears as well as the backing mailbox, so that the user could find that the same message has been downloaded and could determine to download the message or not. Another simple question: Is there a flag or record showing that the arrival of a message has been notified to the client? If not, maybe there will be multi-notifications for one message appearing in more than one important vfolders. Multi-notifications may lead to duplicate retrieval of such a message if the client retrive messages without user interaction. > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly-selected tag: --------------- > Cabbage: A familiar kitchen-garden vegetable about as large and wise > as a man's head. > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Aug 29 01:22:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHw3d-0003VQ-Qc; Tue, 29 Aug 2006 01:22:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHw3b-0003VD-Sa for lemonade@ietf.org; Tue, 29 Aug 2006 01:22:39 -0400 Received: from fugue.toroid.org ([85.10.196.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHw3a-0003Rb-KI for lemonade@ietf.org; Tue, 29 Aug 2006 01:22:39 -0400 Received: from penne.toroid.org (localhost [127.0.0.1]) by fugue.toroid.org (Postfix) with ESMTP id 669BBF3F1; Tue, 29 Aug 2006 07:22:12 +0200 (CEST) Received: by penne.toroid.org (Postfix, from userid 1000) id B11BF3E239E; Tue, 29 Aug 2006 10:52:13 +0530 (IST) Date: Tue, 29 Aug 2006 10:52:13 +0530 From: Abhijit Menon-Sen To: Lingyan Wu Message-ID: <20060829052213.GB507@penne.toroid.org> References: <007501c6c7f6$71bfdf40$3478a40a@china.huawei.com> <601.1156493030.076873@peirce.dave.cridland.net> <006701c6c8c2$07a8c730$3478a40a@china.huawei.com> <007501c6c7f6$71bfdf40$3478a40a@china.huawei.com> <006a01c6c8c2$8423d7f0$3478a40a@china.huawei.com> <004401c6cb17$e9379c60$3478a40a@china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004401c6cb17$e9379c60$3478a40a@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Randall Gellens , lemonade@ietf.org Subject: [lemonade] Re: About "Avoiding Duplicates" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 2006-08-29 11:04:57 +0800, wulingyan_48795@huawei.com wrote: > > What data (corresponding a certain message) are there in a vfolder? > (UID, flags, link of the actual message)? IMAP has no way to express a "link to the actual message". As far as the client is concerned, the message in the vfolder *is* the actual message, and there's no direct way to differentiate between instances of the same message appearing in different vfolders. (So, to answer your question, a vfolder contains exactly the same data for one message as any other mailbox would.) -- ams _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Aug 29 01:51:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHwVL-0000iJ-O4; Tue, 29 Aug 2006 01:51:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHwVJ-0000ag-S1 for lemonade@ietf.org; Tue, 29 Aug 2006 01:51:17 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHwVI-0000gy-D7 for lemonade@ietf.org; Tue, 29 Aug 2006 01:51:17 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4Q009A7WDJ8L@szxga01-in.huawei.com> for lemonade@ietf.org; Tue, 29 Aug 2006 13:53:43 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4Q00M73WDJ68@szxga01-in.huawei.com> for lemonade@ietf.org; Tue, 29 Aug 2006 13:53:43 +0800 (CST) Received: from w48795 ([10.164.120.52]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4Q00A1AWEYR8@szxml03-in.huawei.com> for lemonade@ietf.org; Tue, 29 Aug 2006 13:54:35 +0800 (CST) Date: Tue, 29 Aug 2006 13:50:23 +0800 From: Lingyan Wu To: Abhijit Menon-Sen Message-id: <007701c6cb2f$05622f60$3478a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <007501c6c7f6$71bfdf40$3478a40a@china.huawei.com> <601.1156493030.076873@peirce.dave.cridland.net> <006701c6c8c2$07a8c730$3478a40a@china.huawei.com> <007501c6c7f6$71bfdf40$3478a40a@china.huawei.com> <006a01c6c8c2$8423d7f0$3478a40a@china.huawei.com> <004401c6cb17$e9379c60$3478a40a@china.huawei.com> <20060829052213.GB507@penne.toroid.org> X-Spam-Score: 0.5 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: lemonade@ietf.org Subject: [lemonade] Re: About "Avoiding Duplicates" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Lingyan Wu List-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. Just as what you said, as far as the client is concerned, vfolder looks and behaves like a real IMAP4 folder, but it does not contain any messages itself. ----- Original Message ----- From: "Abhijit Menon-Sen" To: "Lingyan Wu" Cc: "Randall Gellens" ; Sent: Tuesday, August 29, 2006 1:22 PM Subject: Re: About "Avoiding Duplicates" > At 2006-08-29 11:04:57 +0800, wulingyan_48795@huawei.com wrote: >> >> What data (corresponding a certain message) are there in a vfolder? >> (UID, flags, link of the actual message)? > > IMAP has no way to express a "link to the actual message". As far as the > client is concerned, the message in the vfolder *is* the actual message, > and there's no direct way to differentiate between instances of the same > message appearing in different vfolders. > > (So, to answer your question, a vfolder contains exactly the same data > for one message as any other mailbox would.) > > -- ams > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Aug 29 02:23:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHwzi-0008B1-V8; Tue, 29 Aug 2006 02:22:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHwzh-0008At-O4 for lemonade@ietf.org; Tue, 29 Aug 2006 02:22:41 -0400 Received: from smtp-out.sendmail.com ([209.246.26.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHwzf-00008W-Ao for lemonade@ietf.org; Tue, 29 Aug 2006 02:22:41 -0400 Received: from [10.201.0.58] (adsl-64-58-1-252.mho.net [64.58.1.252] (may be forged)) (authenticated bits=0) by foon.sendmail.com (Switch-3.2.4/Switch-3.2.0) with ESMTP id k7T6M9hE031561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Aug 2006 23:22:11 -0700 X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com k7T6M9hE031561 DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1156832533; bh=r6wh8HH4vGiuwRDPpyBYx/A4M9U=; h=X-DomainKeys: DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:In-Reply-To: Message-ID:References:MIME-Version:Content-Type; b=SZq9blIRUd9HROIo byTitrp5oP6EDLViZxPYXyUfZ30+hWlXuz8M1rBAag/ckzpt8wQxcotYg59F5yogrti /kzhJ8lI61xETHqucrdN+xJyo6g14MwD66nTpuD0pz4u9rx2OUN8XY5+e1miHlwf0ox z/3C0FtOkjQWHNlB141Xs= X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com k7T6M9hE031561 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type; b=kPA9Dyr5yFzCGlwA+ggktwCamiqjcha/m+KbLfdLHE8oqrGfPX9pcZV9Ip+sVxcZD V1Vf59avN/zDHPf5nxVhyilhfaqn5RAe5aBs4bpQYCwaLFv6vSKeYXsS5i5VG+aRR/S a1oHm7Q+PXHxSSs07CuCpeP8UT8ndE+W6glZ7ew= Date: Tue, 29 Aug 2006 00:22:06 -0600 From: Philip Guenther X-X-Sender: guenther@vanye.mho.net To: Lingyan Wu Subject: Re: [lemonade]About "Avoiding Duplicates" In-Reply-To: <004401c6cb17$e9379c60$3478a40a@china.huawei.com> Message-ID: References: <007501c6c7f6$71bfdf40$3478a40a@china.huawei.com> <601.1156493030.076873@peirce.dave.cridland.net> <006701c6c8c2$07a8c730$3478a40a@china.huawei.com> <007501c6c7f6$71bfdf40$3478a40a@china.huawei.com> <006a01c6c8c2$8423d7f0$3478a40a@china.huawei.com> <004401c6cb17$e9379c60$3478a40a@china.huawei.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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, 29 Aug 2006, Lingyan Wu wrote: >"Randall Gellens" wrote: ... >> There is not currently a standard IMAP flag that means the message has been >> downloaded, <...> > > I want such a flag for the following reason: A message appearing in more > than one vfolders: If a client downloads the message from one vfolder, > the message will appears "downloaded" in all of the vfolders where it > appears as well as the backing mailbox, so that the user could find that > the same message has been downloaded and could determine to download the > message or not. So, the flag by itself would *not* solve the problem. Telling the client that it had already downloaded the message doesn't help unless the client can figure out where that data is. That is, the client would need some way to know that the message with UID N in mailbox A is the message as the one with UID M in mailbox B. BUT, that once you tell the client that, _it_ can figure out whether it has already downloaded the message and the flag is completely pointless. Indeed, the flag would be misleading: the server has no way of knowing whether the client decided to flush the previously downloaded instance of the message from its cache. (Requiring the client to tell the server that it dropped something from its cache would be utterly ridiculous: cost with no benefit!) > Another simple question: > Is there a flag or record showing that the arrival of a message has been > notified to the client? "the client"? _Which_ client? My INBOX is often concurrently selected by two distinct clients, one of which changes IP fairly often. I occasionally select it in another program running on the same machine as one of the above. This flag or record will have to some how be "per-client" in some way, so that each client have its own view of which messages have been downloaded, no? How is the server supposed to do that? So, the answer to your question is "no, no such flag or record exists on the server". > If not, maybe there will be multi-notifications for one message > appearing in more than one important vfolders. That's a completely separate issue from the above. Even if there was _no_ way in IMAP itself to tell a client that two messages were "the same", we could still have a notification protocol that coalesced notification for distinct folders. Philip Guenther _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Aug 29 07:25:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI1iJ-0006Ck-PM; Tue, 29 Aug 2006 07:25:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI1iH-0006Cc-Qe for lemonade@ietf.org; Tue, 29 Aug 2006 07:25:01 -0400 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI1iC-0007hT-Es for lemonade@ietf.org; Tue, 29 Aug 2006 07:25:01 -0400 Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.12]) by smarthost.yourcomms.net (8.11.7p3+Sun/8.11.6) with ESMTP id k7TBCPQ26176 for ; Tue, 29 Aug 2006 12:12:26 +0100 (BST) Content-class: urn:content-classes:message Subject: RE: [lemonade]About "Avoiding Duplicates" MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 29 Aug 2006 12:23:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <22C8A0D5D5E095449AB509FE777B5F8002C41ADB@svr-exchange.avocado.emccsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade]About "Avoiding Duplicates" Thread-Index: AcbIrjSGd2ZffiehSiuNTzVwIsF5GgCrvEzA From: "Ben Last" To: "Philip Guenther" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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's not a pure IMAP operation, it happens in response to changing some parameters for mobile clients, via a webmail interface. A number of our users were doing this quite often and that's what clued us in to why we were seeing frequent complete resynchronizations. Regards Ben Ben Last EMCC Software ben.last@emccsoft.com direct: +44 161 919 0178 mobile: +44 7966 136572 skype: bjlast MSN Messenger: ben@benlast.com -----Original Message----- From: Philip Guenther [mailto:guenther+lemonade@sendmail.com]=20 Sent: 26 August 2006 02:23 To: Ben Last Cc: lemonade@ietf.org Subject: RE: [lemonade]About "Avoiding Duplicates" At 9:24 AM +0100 8/25/06, Ben Last wrote: > There's at least one server I'm aware of that can change the=20 > UIDVALIDITY of mailboxes in response to (what I consider) quite=20 > common/low-level operations, incurring a severe=20 > re-synchronization/download penalty for our client. Could you describe the operations that cause the UIDVALIDITY changes?=20 RENAME _has_ to do that in some cases, but that's the only pure-IMAP operation I can think of that does so. Philip Guenther _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Aug 29 13:51:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI7jk-0003wE-Jn; Tue, 29 Aug 2006 13:50:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI7ji-0003rO-Up for lemonade@ietf.org; Tue, 29 Aug 2006 13:50:54 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI7cn-0007HD-2C for lemonade@ietf.org; Tue, 29 Aug 2006 13:43:47 -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 k7THhSnM030899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 29 Aug 2006 10:43:29 -0700 Received: from [[192.168.1.13]] (vpn-10-50-0-3.qualcomm.com [10.50.0.3]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7THhQeK021912; Tue, 29 Aug 2006 10:43:27 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <004401c6cb17$e9379c60$3478a40a@china.huawei.com> References: <007501c6c7f6$71bfdf40$3478a40a@china.huawei.com> <601.1156493030.076873@peirce.dave.cridland.net> <006701c6c8c2$07a8c730$3478a40a@china.huawei.com> <007501c6c7f6$71bfdf40$3478a40a@china.huawei.com> <006a01c6c8c2$8423d7f0$3478a40a@china.huawei.com> <004401c6cb17$e9379c60$3478a40a@china.huawei.com> X-Mailer: Eudora for Mac OS X (dev alpha) X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Tue, 29 Aug 2006 10:40:09 -0700 To: Lingyan Wu , lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade]About "Avoiding Duplicates" 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: 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 At 11:04 AM +0800 8/29/06, Lingyan Wu wrote: > Does downloading a message or sending a notification for the > arrival of the messge not affect any flag of the message? Downloading all or part of a message may or may not set the \Seen flag, but this is under control of the client. Probably most clients today are designed to be used off-line. So the client maintains a cache of messages in mailboxes. When the client fetches all or part of a message, it usually does so without setting the \Seen flag. The client displays the status of the message in the message listing for the mailbox. If the \Seen flag was already set, the client shows the message as having been seen or read. Otherwise it shows the message as being unread. If the user opens the message, the client sets the \Seen flag when it next connects to the server. Note that this way of operating is a design decision for the client, it is not a requirement of IMAP. > Maybe the flags of the same message (e.g. \Seen,\Answered etc) > could keep the same in different vfolders where it appears, so that > the server/user could find what had happened to the message to > determin what to do. Since a vmailbox doesn't physically exist, flags may or may not be kept in synch. That's a design decision for the vmailbox facility. >> >> There is not currently a standard IMAP flag that means the message >> has been downloaded, but there is a flag that indicates the >> message has been seen. Do you really want a client that will only >> download messages that no other client has yet downloaded? That >> seems strange, since if you see a message on your desktop you will >> not see it on your phone. >> > I want such a flag for the following reason: > A message appearing in more than one vfolders: > If a client downloads the message from one vfolder, the message > will appears "downloaded" in all of the vfolders where it appears > as well as the backing mailbox, so that the user could find that > the same message has been downloaded and could determine to > download the message or not. Two points: (1) It sounds to me that you want a flag that means the message has been seen, not a flag that means the message has been downloaded. I say this because I assume that a user will be interested in a message based on if he or she has already read it or not, instead of based on if some client has downloaded it or not. (2) It is a client design issue when to download the message and how much of it to download at any point. Often this is settable by the user. Sometimes the client will download basic information about the message in order to populate the message listing for a mailbox. This may include the To, From, Subject, and Date headers plus the body structure. That allows the client to fill in the most common columns of the message listing, including if the message has attachments. Sometimes clients will also fetch other headers and maybe also one or more body parts. So, in some cases the message body will not be downloaded by the client until the users specifically asks for it. In other cases the client will download it in advance, so the user can see it at any point, even when not connected. -- 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 Tue Aug 29 14:52:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI8gh-00019U-24; Tue, 29 Aug 2006 14:51:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI8gf-00019P-VP for lemonade@ietf.org; Tue, 29 Aug 2006 14:51:49 -0400 Received: from ppsw-1.csi.cam.ac.uk ([131.111.8.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI8gd-0004b6-MO for lemonade@ietf.org; Tue, 29 Aug 2006 14:51:49 -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-2.csi.cam.ac.uk ([131.111.8.54]:40261) by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25) with esmtpa (EXTERNAL:fanf2) id 1GI8gR-000705-41 (Exim 4.54) (return-path ); Tue, 29 Aug 2006 19:51:36 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1GI8gQ-0007GL-SR (Exim 4.54) (return-path ); Tue, 29 Aug 2006 19:51:34 +0100 Date: Tue, 29 Aug 2006 19:51:34 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Ted Hardie Subject: Re: [lemonade] COMPRESS=mumble In-Reply-To: Message-ID: References: <20060825140048.89CA6222425@laser.networkresonance.com> MIME-Version: 1.0 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 , Eric Rescorla X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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, 25 Aug 2006, Ted Hardie wrote: > > There might be, of course, conditions later where no TLS is present and > compression is desired using some later non-TLS-friendly compression > algorithm. But if I understand things correctly, that would be a change > in design goals, which seem to be at the moment "compression should > be tls-friendly" trending into "should be done in TLS" in the future. "Later"? What about security layers negotiated with SASL? Are we expecting them to provide their own compression, or should they leave it to application level compression? Tony. -- f.a.n.finch http://dotat.at/ FISHER: WEST OR NORTHWEST 4 OR 5 BECOMING VARIABLE 3 OR 4. FAIR. MODERATE OR GOOD. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Aug 29 21:07:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIEX0-0003nG-Dd; Tue, 29 Aug 2006 21:06:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIEWz-0003mA-9Y for lemonade@ietf.org; Tue, 29 Aug 2006 21:06:13 -0400 Received: from mxout5.cac.washington.edu ([140.142.32.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIEPt-0004Dm-F5 for lemonade@ietf.org; Tue, 29 Aug 2006 20:58:54 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout5.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7U0wqTn019143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Aug 2006 17:58:52 -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.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7U0wqLf026962 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 29 Aug 2006 17:58:52 -0700 Date: Tue, 29 Aug 2006 17:56:50 -0700 (Pacific Daylight Time) From: Mark Crispin To: Randall Gellens Subject: Re: [lemonade]About "Avoiding Duplicates" In-Reply-To: Message-ID: References: <007501c6c7f6$71bfdf40$3478a40a@china.huawei.com> <601.1156493030.076873@peirce.dave.cridland.net> <006701c6c8c2$07a8c730$3478a40a@china.huawei.com> <007501c6c7f6$71bfdf40$3478a40a@china.huawei.com> <006a01c6c8c2$8423d7f0$3478a40a@china.huawei.com> <004401c6cb17$e9379c60$3478a40a@china.huawei.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.29.164942 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: 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 On Tue, 29 Aug 2006, Randall Gellens wrote: > Probably most clients today are > designed to be used off-line. So the client maintains a cache of messages in > mailboxes. I agree that this is the case today. I hope that it is not always the case. In particular, as connectivity continues to be increasingly faster, more ubiquitous, and less costly, I hope to see more online IMAP clients (which do not keep state on the client). This includes mobile clients. Most mobile client web browsers these days are online. I hope to see this trend occur with message browsers. Of course, some further advances are necessary, but I think (hope!) that they're coming. -- 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 Aug 29 22:06:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIFTT-000483-5L; Tue, 29 Aug 2006 22:06:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIFTR-00042N-LT for lemonade@ietf.org; Tue, 29 Aug 2006 22:06:37 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIFTQ-0004lP-Ab for lemonade@ietf.org; Tue, 29 Aug 2006 22:06:37 -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 k7U26P6K018425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 29 Aug 2006 19:06:26 -0700 Received: from [[192.168.1.13]] (vpn-10-50-0-3.qualcomm.com [10.50.0.3]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7U26N7e007201; Tue, 29 Aug 2006 19:06:25 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <007501c6c7f6$71bfdf40$3478a40a@china.huawei.com> <601.1156493030.076873@peirce.dave.cridland.net> <006701c6c8c2$07a8c730$3478a40a@china.huawei.com> <007501c6c7f6$71bfdf40$3478a40a@china.huawei.com> <006a01c6c8c2$8423d7f0$3478a40a@china.huawei.com> <004401c6cb17$e9379c60$3478a40a@china.huawei.com> X-Mailer: Eudora for Mac OS X (dev alpha) X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Tue, 29 Aug 2006 19:06:20 -0700 To: Mark Crispin From: Randall Gellens Subject: Re: [lemonade]About "Avoiding Duplicates" 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 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:56 PM -0700 8/29/06, Mark Crispin wrote: > On Tue, 29 Aug 2006, Randall Gellens wrote: >> Probably most clients today are designed to be used off-line. So >> the client maintains a cache of messages in mailboxes. > > I agree that this is the case today. I hope that it is not always the case. > > In particular, as connectivity continues to be increasingly faster, > more ubiquitous, and less costly, I hope to see more online IMAP > clients (which do not keep state on the client). I think it is likely that for the near future there will continue ti be situations where Internet access is not available, even if in general Internet access becomes faster, cheaper, and more widely available. It is frustrating to be unable to use email just because network access isn't immediately available. > This includes mobile clients. Most mobile client web browsers > these days re online. I have a hard time imagining how an off-line web browser would be useful. I suppose it would cache popular sites or personal favorites, but still, web browsing is based on being able to immediately follow links wherever they may lead. It seems to me to be very different from email, where messages are directed to you. > I hope to see this trend occur with message browsers. Of course, > some further advances are necessary, but I think (hope!) that > they're coming. Of course, in the old days all mail readers were online only. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- A successful tool is used to do something undreamed of by its author. --Johnson _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Aug 30 10:54:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIRRs-0004YC-9i; Wed, 30 Aug 2006 10:53:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIRRr-0004Y6-EP for lemonade@ietf.org; Wed, 30 Aug 2006 10:53:47 -0400 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIRRo-0004Qh-SW for lemonade@ietf.org; Wed, 30 Aug 2006 10:53:47 -0400 Received: from ocsemcc.emccsoft.com ([212.248.196.12]) by smarthost.yourcomms.net (8.11.7p3+Sun/8.11.6) with ESMTP id k7UEemQ13133; Wed, 30 Aug 2006 15:40:54 +0100 (BST) Received: from ocsemcc.emccsoft.com by ocsemcc.emccsoft.com with ESMTP id 3678891156949895; Wed, 30 Aug 2006 15:58:15 +0100 MIME-Version: 1.0 Message-ID: <13603622.1156949895725.JavaMail.oracle@ocsemcc.emccsoft.com> Date: Wed, 30 Aug 2006 14:36:20 GMT From: Ben.Last@emccsoft.com To: "Randall Gellens" To: "Mark Crispin" Subject: RE: Re: [lemonade]About "Avoiding Duplicates" X-Message-Flag: Sent from my mobile phone via m-Sync Content-Type: TEXT/PLAIN; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 Perhaps in cities, connectivity will eventually be ubiquitous and continuously reliable. However, I think it'll be a long time before software for mobile devices can rely on that. We see plenty of clients who try a mobile online solution and then come and talk to us about a thicker client. As long as Lemonade profiles allow either mode of operations, that'll suit me :) Incidentally, this email composed and sent from a mobile phone via a client that's close to Lemonade compliant... regards ben --- Original message --- From: "Mark Crispin" To: "Randall Gellens" Sent on: 00:56 Wed 30th Aug 2006 On Tue, 29 Aug 2006, Randall Gellens wrote: > Probably most clients today are > designed to be used off-line. So the client maintains a cache of messages in > mailboxes. I agree that this is the case today. I hope that it is not always the case. In particular, as connectivity continues to be increasingly faster, more ubiquitous, and less costly, I hope to see more online IMAP clients (which do not keep state on the client). This includes mobile clients. Most mobile client web browsers these days are online. I hope to see this trend occur with message browsers. Of course, some further advances are necessary, but I think (hope!) that they're coming. -- 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 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Aug 31 05:53:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIjDy-0003iO-JZ; Thu, 31 Aug 2006 05:52:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIjDw-0003iG-Hz for lemonade@ietf.org; Thu, 31 Aug 2006 05:52: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 1GIhtK-0002W5-5k for lemonade@ietf.org; Thu, 31 Aug 2006 04:27:14 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GIhl3-0006cH-B8 for lemonade@ietf.org; Thu, 31 Aug 2006 04:18:45 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 3273E4AD19; Thu, 31 Aug 2006 10:18:33 +0200 (CEST) Message-Id: Date: Thu, 31 Aug 2006 10:18:36 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade]About "Avoiding Duplicates" References: <13603622.1156949895725.JavaMail.oracle@ocsemcc.emccsoft.com> In-Reply-To: <13603622.1156949895725.JavaMail.oracle@ocsemcc.emccsoft.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: -1.4 (-) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Randall Gellens , Mark Crispin X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Seconded! I live in Munich, where city power is available 99.99931% of the time, there's 253 .de domains per 1000 inhabitants and BMW is the biggest-selling car brand. If connectivity will be ubiquitous anywhere, then here. But today, if I take the elevator down to the servers, my mobile phone won't work in the elevator and it won't work in the server room. I suppose I should be grateful that it works in my office, because it didn't in my previous office. I won't even hope for ubiquitous IP until GSM is. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade