From lemonade-bounces@ietf.org Tue May 01 11:38:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiuQq-0002Cr-1B; Tue, 01 May 2007 11:38:24 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HiuQm-00026U-Us for lemonade-confirm+ok@megatron.ietf.org; Tue, 01 May 2007 11:38:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiuQm-000264-J3; Tue, 01 May 2007 11:38:20 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HiuQm-0008UB-8T; Tue, 01 May 2007 11:38:20 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 31D341761D; Tue, 1 May 2007 15:37:50 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HiuQH-00089e-VQ; Tue, 01 May 2007 11:37:49 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Tue, 01 May 2007 11:37:49 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: lemonade mailing list , lemonade chair , Internet Architecture Board , RFC Editor Subject: [lemonade] Protocol Action: 'The IMAP COMPRESS Extension' to Proposed Standard X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 IESG has approved the following document: - 'The IMAP COMPRESS Extension ' as a Proposed Standard This document is the product of the Enhancements to Internet email to Support Diverse Service Environments Working Group. The IESG contact persons are Chris Newman and Lisa Dusseault. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-compress-08.txt Technical Summary This document specifies an IMAP extension to compress IMAP commands and responses and gives some advice on how to implement that to the best possible effect. It does not create any IANA registry or define several compression mechanisms: The WG believes that in the long term, TLS compression availability will make this extension obsolete. However, if that should be wrong, the document leaves an option to define more mechanisms and a registry later. Working Group Summary There is consensus in the WG to publish this document. Document Quality Many members of the Lemonade WG, including Dave Criland, Ned Freed, Philip Guenther, Randy Gellens and Tony Hansen, have reviewed the document. Eric Rescorla (non-work group) has provided a security review and also gave valuable feed back. The protocol has been implemented by three servers and two clients and was shown to interoperate. The document has been checked manually and using idnits 1.118, and passed both checks. The IANA Considerations section is sensible and consistent. The (four-line) ABNF has been manually checked. Eric Burger shepherds this document. He has reviewed this document and believes the -06 version is ready for publication. The responsible AD is Chris Newman Note to RFC Editor Section 2, penultimate paragraph: OLD: IMAP clients MAY use either COMPRESS or TLS compression. NEW: IMAP clients MAY use either COMPRESS or TLS compression, however, if client and server support both, it is RECOMMENDED that the client chooses TLS compression. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue May 01 11:45:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiuXI-0007Ng-UZ; Tue, 01 May 2007 11:45:04 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HiuXH-0007L7-Iq for lemonade-confirm+ok@megatron.ietf.org; Tue, 01 May 2007 11:45:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiuXH-0007Kx-8t for lemonade@ietf.org; Tue, 01 May 2007 11:45:03 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiuXC-0002uk-Rn for lemonade@ietf.org; Tue, 01 May 2007 11:45:01 -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 ; Tue, 1 May 2007 16:44:57 +0100 Message-ID: <4637603E.6050801@isode.com> Date: Tue, 01 May 2007 16:43:58 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: lemonade mailing list , Arnt Gulbrandsen , Chris Newman 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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [lemonade] Re: Protocol Action: 'The IMAP COMPRESS Extension' to Proposed Standard X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 IESG wrote: >The IESG has approved the following document: > >- 'The IMAP COMPRESS Extension ' > as a Proposed Standard > >This document is the product of the Enhancements to Internet email to >Support Diverse Service Environments Working Group. > > Well done! _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue May 01 12:08:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hiutz-0002EB-8z; Tue, 01 May 2007 12:08:31 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hiutx-0002E0-3v for lemonade-confirm+ok@megatron.ietf.org; Tue, 01 May 2007 12:08:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hiutw-0002Ds-Qf for lemonade@ietf.org; Tue, 01 May 2007 12:08:28 -0400 Received: from dsl-217-155-137-60.zen.co.uk ([217.155.137.60] helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hiutv-0000nP-E1 for lemonade@ietf.org; Tue, 01 May 2007 12:08:28 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id D8AC2498005; Tue, 1 May 2007 17:08:26 +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 16787-04; Tue, 1 May 2007 17:08:25 +0100 (BST) Received: from invsysm1 (shiny.isode.com [62.3.217.250]) by turner.dave.cridland.net (Postfix) with ESMTP id 86009498001; Tue, 1 May 2007 17:08:25 +0100 (BST) MIME-Version: 1.0 Message-Id: <4494.1178035704.265196@invsysm1> Date: Tue, 01 May 2007 17:08:24 +0100 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: Debian amavisd-new at turner.dave.cridland.net X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: [lemonade] Message ORGanization list formed X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 those who are interested, a mailing list called morg@ietf.org has been formed to discuss the general issues surrounding message organization and search. The intent is to examine what existing clients are actually doing, and see what servers might do to support this functionality such that it can be done efficiently (possibly including over limited bandwidth). If it seems to be heading in a fruitful direction with a reasonable amount of support, I'll see what I can do about getting a BOF together with a much more concrete charter proposal. To subscribe, it's the usual morg-request@ietf.org thing. 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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed May 02 02:33:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hj8Oy-000196-C0; Wed, 02 May 2007 02:33:24 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hj8Ow-00014L-Q8 for lemonade-confirm+ok@megatron.ietf.org; Wed, 02 May 2007 02:33:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hj8Ov-000147-VM for lemonade@ietf.org; Wed, 02 May 2007 02:33:21 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hj8Ou-0005GT-KG for lemonade@ietf.org; Wed, 02 May 2007 02:33:21 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 1D0094AC2B for ; Wed, 2 May 2007 08:33:20 +0200 (CEST) Message-Id: Date: Wed, 2 May 2007 08:35:01 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Re: Protocol Action: 'The IMAP COMPRESS Extension' to Proposed Standard References: <4637603E.6050801@isode.com> In-Reply-To: <4637603E.6050801@isode.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Alexey Melnikov writes: > Well done! This feels strange. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed May 02 16:18:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjLH3-0004sv-D4; Wed, 02 May 2007 16:18:05 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HjLH2-0004sq-Se for lemonade-confirm+ok@megatron.ietf.org; Wed, 02 May 2007 16:18:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjLH2-0004sh-JC for lemonade@ietf.org; Wed, 02 May 2007 16:18:04 -0400 Received: from noware.co.uk ([82.153.134.193] helo=mail.noware.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjLH1-00033N-7u for lemonade@ietf.org; Wed, 02 May 2007 16:18:04 -0400 Received: by mail.noware.co.uk (Postfix, from userid 1008) id 4A0EF37B3; Wed, 2 May 2007 21:11:50 +0100 (BST) X-CMAE-Analysis: v=1.0 c=1 a=RW3O_llhDo-y6fbbRrcA:9 a=8LEMaLpbI9xEFu9RvpIA:7 a=ylzZQ2cuHBGpZ9Fb6zDHQPpvW_IA:4 Received: from [192.168.0.111] (anagu.york.openwave.com [192.168.0.111]) by mail.noware.co.uk (Postfix) with ESMTP id 8041036EC for ; Wed, 2 May 2007 21:11:49 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <6030D885-5442-471E-95AB-7FCA3DC10128@noware.co.uk> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Enhancements to Internet email to support diverse service enivronments From: Neil Cook Date: Wed, 2 May 2007 21:17:48 +0100 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [lemonade] Lemonade Streaming and Media-Server Discovery X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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'm just finishing off updating the lemonade streaming draft, and as part of that I've been looking at how best to provide media server discovery features to clients. In draft-ietf-lemonade-streaming-01.txt I had the media server information represented by a simple host/port tuple. However, Dave Cridland suggested using URIs instead, and I agree - I propose to use URIs to represent the media servers. For example: ABNF (this is not formal, just indicative) media-servers = ms-tuple *("separator1" ms-tuple) ms-tuple = uri [ "separator2" authuser ] This would have the following benefits: - SIP URIs contain a "service indicator" that contains the protocol supported by the media server, thus reducing the amount of "fishing" that client have to do. For example "sip:ivr@ms2.example.com" and "sip:netannc@ms2.example.com" are valid SIP uris that tell the client which protocol to use. - Extensibility is built in, since new URI forms in the future would allow for completely different streaming mechanisms Issues might be: - A single media server would potentially have multiple entries: one for each service that would be supported. - When configuring media server information on the IMAP server, the adminsitrator has to know more than just host/port information, they also have to know the service type(s) supported by that media server. This could potentially go out of date, or be subject to incorrect configuration due to lack of knowledge. Any comments? Neil. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu May 03 03:18:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjVZu-0003ye-Vs; Thu, 03 May 2007 03:18:14 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HjVZt-0003yW-5r for lemonade-confirm+ok@megatron.ietf.org; Thu, 03 May 2007 03:18:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjVZp-0003yI-IV for lemonade@ietf.org; Thu, 03 May 2007 03:18:09 -0400 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjVZo-0006sn-3T for lemonade@ietf.org; Thu, 03 May 2007 03:18:09 -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 l4373ix09742 for ; Thu, 3 May 2007 08:03:44 +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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Lemonade Streaming and Media-Server Discovery Date: Thu, 3 May 2007 08:16:50 +0100 Message-ID: <22C8A0D5D5E095449AB509FE777B5F80040D675A@svr-exchange.avocado.emccsoft.com> In-Reply-To: <6030D885-5442-471E-95AB-7FCA3DC10128@noware.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Lemonade Streaming and Media-Server Discovery Thread-Index: AceM9uEe3skyfsM5TjGsmApaDbC/1gAWu7iQ References: <6030D885-5442-471E-95AB-7FCA3DC10128@noware.co.uk> From: "Ben Last" To: "Neil Cook" , "Enhancements to Internet email to support diverse service enivronments" X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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: Neil Cook [mailto:neil.cook@noware.co.uk]=20 >Subject: [lemonade] Lemonade Streaming and Media-Server Discovery >I propose to use URIs to represent the media servers. >This would have the following benefits: One big benefit is that it's usually possible (i.e.: possible on all the = mobile OS's I'm aware of) to hand URIs off to the OS to deal with. Thus = the email client has no need to wire in complex rules on URI handling. >Issues might be: >- A single media server would potentially have multiple entries: one = for each service that would be supported. Not sure that's a big deal - is there really any concept of a single = media server, given that an FQDN in a URI would very probably map to a = cluster of actual servers (or an Akamai-style cloud) anyway? You may also have a single service represented by multiple entries, if = the same stream is accessible via different service types. >- When configuring media server information on the IMAP server, the = adminsitrator has to know more than just >host/port information, they also have to know the service type(s) = supported by that media server. Agreed, but surely the client must have to know that anyway, otherwise = it doesn't know what protocol to use to talk to the server? Regards Ben Ben Last R&D Manager EMCC Software _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu May 03 10:54:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjchq-0000NO-Hk; Thu, 03 May 2007 10:54:54 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hjchl-000064-0H for lemonade-confirm+ok@megatron.ietf.org; Thu, 03 May 2007 10:54:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjchj-0008OU-Dl for lemonade@ietf.org; Thu, 03 May 2007 10:54:47 -0400 Received: from mtarwc.openwave.com ([12.25.200.46] helo=rwc-isa.openwave.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjcZk-0002TU-VT for lemonade@ietf.org; Thu, 03 May 2007 10:46:33 -0400 Received: from rwc-exch-prd1.myopwv.com ([10.16.249.141]) by rwc-isa.openwave.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 May 2007 07:46:27 -0700 Received: from rwc-smtp-prd1.myopwv.com ([10.16.249.26]) by rwc-exch-prd1.myopwv.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 May 2007 07:46:27 -0700 Received: from rwc-fe-prd1.myopwv.com ([10.16.249.143]) by rwc-smtp-prd1.myopwv.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 May 2007 07:46:27 -0700 Received: from [10.68.15.5] ([10.68.15.5]) by rwc-fe-prd1.myopwv.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 May 2007 07:46:27 -0700 Message-ID: <4639F5B9.9090806@openwave.com> Date: Thu, 03 May 2007 10:46:17 -0400 From: Mike Zraly User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: lemonade@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 May 2007 14:46:27.0292 (UTC) FILETIME=[D42E31C0:01C78D91] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [lemonade] Comments on draft-ietf-lemonade-reconnect-client-04.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org When processing a SELECT ... (QRESYNC ...) command, what is the correct behavior of the IMAP server if the server DOES support persistent storage of mod-sequence values, but only retains a limited number of records of EXPUNGEd messages? For example, let's say the server retains at most some maximum number of expunged records, each containing a mod-sequence value and an associated uid value. Let's also say that for each mailbox the server retains the highest mod-sequence number of all the expunged messages for which the server does not retain an expunged record. Call this value MAXUNAVAILABLE. If a client issues a SELECT/QRESYNC command with a cached mod-seq value less than or equal to MAXUNAVAILABLE, then the server will know that it cannot provide a list of all the EXPUNGEd messages. (It would be able to provide a list of changed messages however, by scanning through all the messages in a mailbox and selecting messages with a large enough MODSEQ field.) However, in this case the client would be incorrect in assuming that the server does not maintain MODSEQ values for each message or a HIGHESTMODSEQ value for each mailbox. In particular, the client should still be able to issue conditional STORE commands using the UNCHANGEDSINCE modifier. So returning a NOMODSEQ response would be the wrong thing to do here (see section 3.1.2 in RFC 4551). I suppose in this case the server could increment the mailbox's UIDVALIDITY to force the client to resynchronize some other way without implying that MODSEQ values are not being maintained for messages in the mailbox, but that would force OTHER clients to resynchronize too. It seems to me that there should be an alternate response for this case, perhaps called MISSINGEXPUNGED or something like that, to indicate that there may be messages in the client's cache whose EXPUNGE operations are no longer recorded by the server, but that the mailbox DOES support MODSEQ in general and conditional STORE operations in particular. It is not clear to me if, given a MISSINGEXPUNGED response, the server should still return untagged FETCH responses for new and modified messages and an untagged VANISHED response for the EXPUNGEd messages it knows about. - Mike Zraly _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri May 04 03:10:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjrvZ-0003Xn-LL; Fri, 04 May 2007 03:10:05 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HjrvX-0003RQ-Km for lemonade-confirm+ok@megatron.ietf.org; Fri, 04 May 2007 03:10:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjrvW-0003QY-W6 for lemonade@ietf.org; Fri, 04 May 2007 03:10:03 -0400 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjrvV-0005DM-Ki for lemonade@ietf.org; Fri, 04 May 2007 03:10:02 -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 l446tax05862 for ; Fri, 4 May 2007 07:55:37 +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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Comments on draft-ietf-lemonade-reconnect-client-04.txt Date: Fri, 4 May 2007 08:08:42 +0100 Message-ID: <22C8A0D5D5E095449AB509FE777B5F8004128DF9@svr-exchange.avocado.emccsoft.com> In-Reply-To: <4639F5B9.9090806@openwave.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Comments on draft-ietf-lemonade-reconnect-client-04.txt Thread-Index: AceNktrPb/qHFwspQpqohgfweeflSAAh1N0w References: <4639F5B9.9090806@openwave.com> From: "Ben Last" To: "Mike Zraly" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org >From: Mike Zraly [mailto:Michael.Zraly@openwave.com]=20 >It seems to me that there should be an alternate response for this = case, perhaps called MISSINGEXPUNGED or something like that... But what could a client do when it receives such a response (other than = a state-comparison resync)? Isn't this pretty much equivalent (in terms = of what it means to the client) to the untagged RESYNC login response = that was in the P-IMAP spec? That is, a response that means "hello = client, the only sensible way for you to remain in sync is to do a = state-comparison resync". I guess I'm arguing for explicit being better than implicit: if the = server knows that it has insufficient stored history to replay = modification events to the client, perhaps an explicit "let's start = over" is better. Regards Ben Ben Last R&D Manager EMCC Software _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri May 04 03:39:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjsO3-0003Qa-Az; Fri, 04 May 2007 03:39:31 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HjsO2-0003QP-3G for lemonade-confirm+ok@megatron.ietf.org; Fri, 04 May 2007 03:39:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjsO1-0003QF-MM for lemonade@ietf.org; Fri, 04 May 2007 03:39:29 -0400 Received: from mta02.zimbra.com ([4.78.240.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjsO0-0002Hx-DQ for lemonade@ietf.org; Fri, 04 May 2007 03:39:29 -0400 Received: from dogfood.zimbra.com (dogfood.liquidsys.com [66.92.25.198]) by mta02.zimbra.com (Postfix) with ESMTP id BA3DD810510; Fri, 4 May 2007 00:32:51 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 11F5137AC3; Fri, 4 May 2007 00:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRo6ZPLxvcGZ; Fri, 4 May 2007 00:39:15 -0700 (PDT) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 5AFFF37AC2; Fri, 4 May 2007 00:39:15 -0700 (PDT) Date: Fri, 4 May 2007 00:39:15 -0700 (PDT) From: Dan Karp To: Ben Last Message-ID: <775158338.18781178264355201.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <22C8A0D5D5E095449AB509FE777B5F8004128DF9@svr-exchange.avocado.emccsoft.com> Subject: Re: [lemonade] Comments on draft-ietf-lemonade-reconnect-client-04.txt MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [67.112.120.184] X-Spam-Score: 0.1 (/) 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 > >It seems to me that there should be an alternate response for this > > case, perhaps called MISSINGEXPUNGED or something like that... > > But what could a client do when it receives such a response (other > than a state-comparison resync)? Isn't this pretty much equivalent > (in terms of what it means to the client) to the untagged RESYNC login > response that was in the P-IMAP spec? That is, a response that means > "hello client, the only sensible way for you to remain in sync is to > do a state-comparison resync". If the server doesn't have enough persisted state to answer "what's VANISHED since last sync", it can just downgrade from the functionality described in section 4.3 to the functionality described in section 4.1. The situations requiring such a downgrade should be rare, but the server will still be fully compliant: Strictly speaking, a server implementation that doesn't remember modsequences associated with expunged messages can be considered compliant with this specification. Such implementations return all expunged messages specified in the UID set of the UID FETCH (VANISHED) command every time, without paying attention to the specified CHANGEDSINCE modsequence. Such implementations are discouraged, as they can end up returning VANISHED responses bigger than the result of a UID SEARCH command for the same UID set. There shouldn't be a need for a resync. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri May 04 03:49:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjsXz-0004bo-TE; Fri, 04 May 2007 03:49:47 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HjsXy-0004bj-GE for lemonade-confirm+ok@megatron.ietf.org; Fri, 04 May 2007 03:49:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjsXy-0004ba-5R for lemonade@ietf.org; Fri, 04 May 2007 03:49:46 -0400 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjsXw-00031W-IV for lemonade@ietf.org; Fri, 04 May 2007 03:49:46 -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 l447ZKx08374 for ; Fri, 4 May 2007 08:35:20 +0100 (BST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [lemonade] Comments on draft-ietf-lemonade-reconnect-client-04.txt Date: Fri, 4 May 2007 08:48:27 +0100 Message-ID: <22C8A0D5D5E095449AB509FE777B5F8004128E1C@svr-exchange.avocado.emccsoft.com> In-Reply-To: <775158338.18781178264355201.JavaMail.root@dogfood.zimbra.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Comments on draft-ietf-lemonade-reconnect-client-04.txt Thread-Index: AceOH0f7LIrcFxfgSz+y8kd7mz+0qgAALx4Q References: <22C8A0D5D5E095449AB509FE777B5F8004128DF9@svr-exchange.avocado.emccsoft.com> <775158338.18781178264355201.JavaMail.root@dogfood.zimbra.com> From: "Ben Last" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1940134912==" Errors-To: lemonade-bounces@ietf.org --===============1940134912== Content-class: urn:content-classes:message Content-Type: text/plain; charset="Utf-8" Content-Transfer-Encoding: base64 PkZyb206IERhbiBLYXJwIFttYWlsdG86ZGthcnBAemltYnJhLmNvbV0gDQoNCj5JZiB0aGUgc2Vy dmVyIGRvZXNuJ3QgaGF2ZSBlbm91Z2ggcGVyc2lzdGVkIHN0YXRlIHRvIGFuc3dlciAid2hhdCdz IFZBTklTSEVEIHNpbmNlIGxhc3Qgc3luYyIsIGl0IGNhbiBqdXN0IGRvd25ncmFkZSBmcm9tIHRo ZQ0KPmZ1bmN0aW9uYWxpdHkgZGVzY3JpYmVkIGluIHNlY3Rpb24gNC4zIHRvIHRoZSBmdW5jdGlv bmFsaXR5IGRlc2NyaWJlZCBpbiBzZWN0aW9uIDQuMS4NClRoYW5rcywgRGFuLiAgSSBndWVzcyB0 aGF0J3MgYSBwYXJ0aWFsLXN0YXRlLWNvbXBhcmlzb24gc3luYyBieSBkZWZhdWx0LCBpbiB0aGF0 IEkgYXNzdW1lIGEgc2VydmVyIHdpdGhvdXQgZXhwdW5nZSBoaXN0b3J5IHdpbGwgcmVwb3J0IGFz IFZBTklTSEVEIGFueSBVSURzIGZvciB3aGljaCB0aGVyZSBhcmUgbm8gbWVzc2FnZXMgaW4gdGhl IFVJRCBzZXQuICBIb3dldmVyLCBmcm9tIGEgY2xpZW50IHBvaW50IG9mIHZpZXcsIGl0J3MgInJl bW92ZSBhbGwgVUlEcyB0aGF0IGFyZW4ndCBjb25maXJtZWQgaW4gdGhpcyBsaXN0IiByYXRoZXIg dGhhbiAicmVtb3ZlIGFsbCBtZXNzYWdlcyB0aGF0IGFyZSByZXBvcnRlZCBhcyBFWFBVTkdFZCBp biB0aGlzIGxpc3QiLCB3aGljaCBoYXMgc29tZSBpbXBsaWNhdGlvbnMgZm9yIGRlc2lnbiAoaWUs IG9uZSByZW1vdmVzIG9uIHN1Y2Nlc3NmdWwgY29tcGxldGlvbiBvZiBhIGNvbW1hbmQgcmF0aGVy IHRoYW4gYXMgcmVzcG9uc2VzIGFyZSBwcm9jZXNzZWQpLg0KDQpSZWdhcmRzDQpCZW4NCg0KQmVu IExhc3QNClImRCBNYW5hZ2VyDQpFTUNDIFNvZnR3YXJlDQo= --===============1940134912== 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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============1940134912==-- From lemonade-bounces@ietf.org Fri May 04 05:53:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjuU6-00028u-Fj; Fri, 04 May 2007 05:53:54 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HjuU3-0001x6-6k for lemonade-confirm+ok@megatron.ietf.org; Fri, 04 May 2007 05:53:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjuU2-0001sa-SR for lemonade@ietf.org; Fri, 04 May 2007 05:53:50 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjuTA-0007NR-R3 for lemonade@ietf.org; Fri, 04 May 2007 05:52:57 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l449qauG001515 for ; Fri, 4 May 2007 12:52:55 +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 May 2007 12:52:42 +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 May 2007 12:52: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] I-D ACTION:draft-ietf-lemonade-profile-bis-05.txt Date: Fri, 4 May 2007 12:50:50 +0300 Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA157717B33@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-05.txt Thread-Index: Acd28s3jXDL63iV0TaiEyO2iLHMRcAXLXZDQ References: From: To: X-OriginalArrivalTime: 04 May 2007 09:52:42.0256 (UTC) FILETIME=[F540E100:01C78E31] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 for the late reply, been busy with OMA business. Here are my comments: Section 2. 1. Lemonade Profile =3D Lemonade? I thought the first was the specs, the = latter a group in IETF. 2. I am missing some sort of description of Profile vs. Profile bis. Or = it does not matter because Profile bis will obsolete Profile? Section 3. 3. In the previous version there was a statement saying that the = extensions need to be declared using CAPABILITY. Was the removal of this = statement accidental, or is that intention to save sending some data and = just declare Profile bis support? BTW: how is Profile bis support = declared? It seems that it is not declared at all - so how does one know = that the Lemonade-specific things (like the $Forwarded keyword) can be = used? Section 4.1 4. A reference to section 7 would be nice here. Section 5.5. 5. "Lemonade Message Stores therefore MUST implement the CONTEXT = extension defined in [IMAP-CONTEXT]." CONTEXT is already said to be = mandatory in section 3. I would prefere describing CONTEXT itself a = little more instead. Section 6. 6. In the previous draft the FLOWED was a MUST - now it's only a SHOULD. = Mistake or intentional? Section 7.1 7. "..., or whatever else may be designed in the future" Is this part = really needed? We can't really be sure about the future... Figure 16, 17, 18, 19 in section 8. 8. There is no ME-2a and ME-2b interface in OMA MEM anymore. (The MEM AD = has been updated). General: 9. There are some places where the word "folder" is used. Should we = consistently use "mailbox" instead of "folder"? Or provide some sort of = clarification (a reference?) to what the difference is? 10. References - do we want to provide some sort of update here? Pipelining; RFC2197 is obsoleted by RFC2920 DSN; RFC3461 is updated by RFC3798 and RFC3885 BINARY; RFC3516 is updated by RFC4466 LITERAL+; RFC2088 is updated by RFC4466 NAMESPACE; RFC2342 is updated by RFC4466 Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri May 04 07:54:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjwMx-0001LU-UD; Fri, 04 May 2007 07:54:39 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HjwMw-0001Ft-O5 for lemonade-confirm+ok@megatron.ietf.org; Fri, 04 May 2007 07:54:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjwMw-0001ET-DY for lemonade@ietf.org; Fri, 04 May 2007 07:54:38 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjwMv-0006V6-Tz for lemonade@ietf.org; Fri, 04 May 2007 07:54:38 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l44Bs8cb022305 for ; Fri, 4 May 2007 14:54:36 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 May 2007 14:54:07 +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 May 2007 14:54: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-notifications-04.txt Date: Fri, 4 May 2007 14:52:15 +0300 Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA1577527B2@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] I-D ACTION:draft-ietf-lemonade-notifications-04.txt Thread-Index: Acd3vAwNyJiBkFZ4STWphBf/VjkBFQWhfuxA References: From: To: X-OriginalArrivalTime: 04 May 2007 11:54:07.0657 (UTC) FILETIME=[EBB0D990:01C78E42] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi all, Thanks for the update. I have onlt one comment related to Figure 1: There is no ME-2a and ME-2b = interface in OMA MEM anymore. (The MEM AD has been updated). 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 lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org]=20 >Sent: 05 April, 2007 22:50 >To: i-d-announce@ietf.org >Cc: lemonade@ietf.org >Subject: [lemonade] I-D=20 >ACTION:draft-ietf-lemonade-notifications-04.txt=20 > >A New Internet-Draft is available from the on-line=20 >Internet-Drafts directories. >This draft is a work item of the Enhancements to Internet=20 >email to Support Diverse Service Environments Working Group of=20 >the IETF. > > Title : Lemonade Notifications and Filters > Author(s) : S. Maes, et al. > Filename : draft-ietf-lemonade-notifications-04.txt > Pages : 28 > Date : 2007-4-5 >=09 >This document discusses how to provide notification and filtering > mechanisms to IMAP as part the Lemonade profile. > =20 > This document also discusses the use of Lemonade notifications to > implement server to server notifications. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-lemonade-notific >ations-04.txt > >To remove yourself from the I-D Announcement list, send a=20 >message to i-d-announce-request@ietf.org with the word=20 >unsubscribe in the body of the message.=20 >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > >Internet-Drafts are also available by anonymous FTP. Login=20 >with the username "anonymous" and a password of your e-mail=20 >address. After logging in, type "cd internet-drafts" and then=20 >"get draft-ietf-lemonade-notifications-04.txt". > >A list of Internet-Drafts directories can be found in=20 >http://www.ietf.org/shadow.html or=20 >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=20 >/internet-drafts/draft-ietf-lemonade-notifications-04.txt". >=09 >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant=20 >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=20 >reader implementation to automatically retrieve the ASCII=20 >version of the Internet-Draft. > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri May 04 08:21:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjwmY-0007E7-Op; Fri, 04 May 2007 08:21:06 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HjwmX-00077l-K6 for lemonade-confirm+ok@megatron.ietf.org; Fri, 04 May 2007 08:21:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjwmX-00075o-9r for lemonade@ietf.org; Fri, 04 May 2007 08:21:05 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjwmU-0002ce-PV for lemonade@ietf.org; Fri, 04 May 2007 08:21:05 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l44CKkAp018839; Fri, 4 May 2007 15:20:58 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 May 2007 15:20:51 +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 May 2007 15:20:51 +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] Inclusion of QUICKSTART in Lemonade Profile-bis Date: Fri, 4 May 2007 15:18:58 +0300 Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA1577527F6@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Inclusion of QUICKSTART in Lemonade Profile-bis Thread-Index: AceA/zfO9tOjezmcQEOB3Q2MiWMoxAE2pW4gAhrwNcA= References: <4624D46A.1090408@isode.com> From: To: , X-OriginalArrivalTime: 04 May 2007 12:20:51.0231 (UTC) FILETIME=[A77ED2F0:01C78E46] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) 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 As a client vendor, this definiately got my attention since reducing the = number of roundtrips is always a good thing. However, reading the comments from other participants, it seems that = there is no real benefit. Is it really so? Cutting the roundtrips to half does not have real = benefits? I do not have a client that implements this, so I cannot check this = myself. If the claims regarding no benefit are true, then obviously there is no = point complicating the implementations. Anyone with actual measurements? 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 Eric Burger [mailto:eburger@bea.com]=20 >Sent: 24 April, 2007 02:39 >To: Lemonade WG >Subject: RE: [lemonade] Inclusion of QUICKSTART in Lemonade Profile-bis > >Joking aside, anyone think this MUST be in Profile-bis? =20 >Alternately, anyone think it MUST NOT be in Profile-bis?=20 > >-----Original Message----- >From: Tony Finch [mailto:dot@dotat.at] >Sent: Tuesday, April 17, 2007 10:45 AM >To: Alexey Melnikov >Cc: Lemonade WG >Subject: Re: [lemonade] Inclusion of QUICKSTART in Lemonade Profile-bis > >On Tue, 17 Apr 2007, Alexey Melnikov wrote: >> >> I actually disagree that this is insignificant. Not very=20 >many clients=20 >> keep persistent SMTP connections. > >It occurred to me this morning that a good slogan for=20 >QUICKSTART is "makes SMTP as fast as HTTP POST". > >Tony. >-- >f.a.n.finch http://dotat.at/ FAIR ISLE: WEST=20 >OR NORTHWEST 5 TO 7, DECREASING 4 OR 5, BACKING SOUTHWEST=20 >LATER. MODERATE OR ROUGH, OCCASIONALLY VERY ROUGH IN WEST.=20 >SQUALLY SHOWERS. >MODERATE OR GOOD. > > >_______________________________________________ >lemonade mailing list >lemonade@ietf.org >https://www1.ietf.org/mailman/listinfo/lemonade >Supplemental Web Site: >http://www.standardstrack.com/ietf/lemonade > >Notice: This email message, together with any attachments,=20 >may contain information of BEA Systems, Inc., its=20 >subsidiaries and affiliated entities, that may be=20 >confidential, proprietary, copyrighted and/or legally=20 >privileged, and is intended solely for the use of the=20 >individual or entity named in this message. If you are not the=20 >intended recipient, and have received this message in error,=20 >please immediately return this by email and then delete it. > > >_______________________________________________ >lemonade mailing list >lemonade@ietf.org >https://www1.ietf.org/mailman/listinfo/lemonade >Supplemental Web Site: >http://www.standardstrack.com/ietf/lemonade > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri May 04 08:41:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjx6Q-0006h7-95; Fri, 04 May 2007 08:41:38 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hjx6O-0006gm-D7 for lemonade-confirm+ok@megatron.ietf.org; Fri, 04 May 2007 08:41:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjx6O-0006ge-3f for lemonade@ietf.org; Fri, 04 May 2007 08:41:36 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hjx6M-0005UH-LD for lemonade@ietf.org; Fri, 04 May 2007 08:41:36 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l44CfSNL032298; Fri, 4 May 2007 15:41:32 +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 May 2007 15:41:32 +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 May 2007 15:41:32 +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 IMAP URL - update; comments (2192bis) Date: Fri, 4 May 2007 15:39:40 +0300 Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA157752823@esebe199.NOE.Nokia.com> In-Reply-To: <4625580F.40902@isode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] WGLC IMAP URL - update; comments (2192bis) Thread-Index: AceBtJLJR07rUMT4SOGv2qPWQSExCQMlHovQ References: <4C38DC11F6B4FF4FAEA73E30DB5AA1573FDF7B@esebe199.NOE.Nokia.com> <4625580F.40902@isode.com> From: To: X-OriginalArrivalTime: 04 May 2007 12:41:32.0318 (UTC) FILETIME=[8B3DABE0:01C78E49] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) 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 >>16. Wording chage suggestion in section 3.2 paragraph 9: >>"An authentication mechanism is used which will not reveal=20 >information to the server which could be used to compromise=20 >future connections." >>-> >>"Use an authentication mechanism with the server that does=20 >not reveal any information that could be used to compromise=20 >future connections." > >"Reveal to the server" part is important. The replacement=20 >sentence doesn't have it. I understand that the sentence might=20 >be difficult to understand, but it is correct. What is the=20 >exact problem with the existing sentence? There is no problem, just an attempt to improve readability. I accept Your justification, so leave it as it is. >>24. Re-location proposal for section 6.1.2 last paragraph:=20 >shouldn't this be in section 6.1.1.5? > >I would rather not do that. Section 6.1.1.5 provides=20 >definition. The last paragraph of section 6.1.2 mostly talks=20 >about encoding. If You insist :-) Thanks for the replies. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri May 04 09:07:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjxVn-0002Uk-O2; Fri, 04 May 2007 09:07:51 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HjxVm-0002Uf-J5 for lemonade-confirm+ok@megatron.ietf.org; Fri, 04 May 2007 09:07:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjxVm-0002US-9R for lemonade@ietf.org; Fri, 04 May 2007 09:07:50 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjxVk-0002Dh-S3 for lemonade@ietf.org; Fri, 04 May 2007 09:07:50 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l44D7YRu001819; Fri, 4 May 2007 16:07:47 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 May 2007 16:07:45 +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 May 2007 16:07:45 +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 IMAP URL - update; comments (2192bis) Date: Fri, 4 May 2007 16:05:52 +0300 Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA1577528AB@esebe199.NOE.Nokia.com> In-Reply-To: <46255B15.60603@isode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] WGLC IMAP URL - update; comments (2192bis) Thread-Index: AceBtJP6NaiR84YCR4O7lZe8rsJwLQMmEvfw References: <4C38DC11F6B4FF4FAEA73E30DB5AA1573FDF7B@esebe199.NOE.Nokia.com> <46255B15.60603@isode.com> From: To: X-OriginalArrivalTime: 04 May 2007 13:07:45.0169 (UTC) FILETIME=[34BBB010:01C78E4D] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) 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 >-----Original Message----- >From: ext Alexey Melnikov [mailto:alexey.melnikov@isode.com]=20 >Sent: 18 April, 2007 02:41 >To: Ordogh Zoltan (Nokia-TP-MSW/Tampere) >Cc: lemonade@ietf.org >Subject: Re: [lemonade] WGLC IMAP URL - update; comments (2192bis) > >Zoltan.Ordogh@nokia.com wrote: > >>23. Clarification needed in section 6.1.2 paragraph 4. What=20 >is "submit+", what is a "access identifier prefix" and what is=20 >a "userid" - these have not been mentioned before, and these=20 >are not in the ABNF either. >>Same question for "user+", "authuser" in the following paragraphs. >> =20 >> >The previous paragraph starts with: > The URLAUTH takes the form ";URLAUTH=3D::", and > MUST be at the end of the URL. > >So the sentence like the following: > The "submit+" access identifier prefix, followed by a userid, > indicates that only a userid authorized as a message submission > entity on behalf of the specified userid is permitted to use this > URL. >really means: > > The "submit+" identifier prefix, followed by a userid, > indicates that only a userid authorized as a message submission > entity on behalf of the specified userid is permitted to use this > URL. > >Would it be clearer if I include <> around "access"? > > Yes, what would help, thank You. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri May 04 09:14:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjxc3-0006UP-UY; Fri, 04 May 2007 09:14:19 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hjxc2-0006UE-4b for lemonade-confirm+ok@megatron.ietf.org; Fri, 04 May 2007 09:14:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjxc1-0006U2-HS for lemonade@ietf.org; Fri, 04 May 2007 09:14:17 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hjxc0-0003yH-3W for lemonade@ietf.org; Fri, 04 May 2007 09:14:17 -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, 4 May 2007 14:14:13 +0100 Message-ID: <463B08C3.8020106@isode.com> Date: Fri, 04 May 2007 11:19:47 +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: Neil Cook Subject: Re: [lemonade] Lemonade Streaming and Media-Server Discovery References: <6030D885-5442-471E-95AB-7FCA3DC10128@noware.co.uk> In-Reply-To: <6030D885-5442-471E-95AB-7FCA3DC10128@noware.co.uk> 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: 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 Neil Cook wrote: > I'm just finishing off updating the lemonade streaming draft, and as > part of that I've been looking at how best to provide media server > discovery features to clients. > > In draft-ietf-lemonade-streaming-01.txt I had the media server > information represented by a simple host/port tuple. However, Dave > Cridland suggested using URIs instead, and I agree - I propose to use > URIs to represent the media servers. > > For example: > > ABNF (this is not formal, just indicative) > > media-servers = ms-tuple *("separator1" ms-tuple) > ms-tuple = uri [ "separator2" authuser ] This seems fine, as long as syntax is unambiguous (e.g. the optional authuser can't be confused with subsequent URI). > This would have the following benefits: > > - SIP URIs contain a "service indicator" that contains the protocol > supported by the media server, thus reducing the amount of "fishing" > that client have to do. For example "sip:ivr@ms2.example.com" and > "sip:netannc@ms2.example.com" are valid SIP uris that tell the client > which protocol to use. > - Extensibility is built in, since new URI forms in the future would > allow for completely different streaming mechanisms > > Issues might be: > > - A single media server would potentially have multiple entries: one > for each service that would be supported. I surely hope that the number of services would be relatively limited, otherwise interoperability can be a pain. > - When configuring media server information on the IMAP server, the > adminsitrator has to know more than just host/port information, they > also have to know the service type(s) supported by that media server. > This could potentially go out of date, or be subject to incorrect > configuration due to lack of knowledge. I agree with Ben that somebody has to keep this information up-to-date. > Any comments? I think the benefits outweigh the disadvantages. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri May 04 09:14:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjxcI-0006fB-Eq; Fri, 04 May 2007 09:14:34 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HjxcG-0006aS-Kb for lemonade-confirm+ok@megatron.ietf.org; Fri, 04 May 2007 09:14:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjxcG-0006a7-Ak for lemonade@ietf.org; Fri, 04 May 2007 09:14:32 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjxcF-00042Y-SA for lemonade@ietf.org; Fri, 04 May 2007 09:14:32 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l44DETHv029332; Fri, 4 May 2007 16:14:30 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 May 2007 16:14:25 +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 May 2007 16:14: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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] WGLC IMAP URL - update; comments (2192bis) Date: Fri, 4 May 2007 16:12:33 +0300 Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA1577528B5@esebe199.NOE.Nokia.com> In-Reply-To: <463380EB.4030204@isode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] WGLC IMAP URL - update; comments (2192bis) Thread-Index: AceLCm7YN7W1STntSL27SnhcSdwNaQDQpPxw References: <4C38DC11F6B4FF4FAEA73E30DB5AA1573FDF7B@esebe199.NOE.Nokia.com> <463380EB.4030204@isode.com> From: To: X-OriginalArrivalTime: 04 May 2007 13:14:25.0727 (UTC) FILETIME=[237BFCF0:01C78E4E] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) 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 >-----Original Message----- >From: ext Alexey Melnikov [mailto:alexey.melnikov@isode.com]=20 >Sent: 28 April, 2007 20:14 >To: Ordogh Zoltan (Nokia-TP-MSW/Tampere) >Cc: lemonade@ietf.org >Subject: Re: [lemonade] WGLC IMAP URL - update; comments (2192bis) > >Zoltan.Ordogh@nokia.com wrote: > >>9. Clarification needed in section 3.2 paragraph 3: Shouldn't=20 >this be moved in from the previous paragraph? That talks about=20 >what happens when there no user name, so it would seem logical=20 >to use the user name first, and then if there no user name,=20 >use anonymous instead. >> >The 3rd paragraph used to be a part of the 2nd paragraph in RFC 2192. >As it summarizes what is described in subsequent paragraphs, I=20 >think the best thing is just to delete it. Otherwise it might=20 >be interpreted as conflicting with some of them. Anyone having a problem with deleting it? >>14. Clarification needed in section 3.2 paragraph 9: "Note=20 >that user entry of the URL may or may not count as a trusted=20 >source, depending on the experience level of the user and site policy." >>How can the "experience level of the user" govern whether the=20 >source is trusted? Sounds awfully wrong - things should be=20 >secure in any case. >>How does one calculate the "experience level of the user" and=20 >what counts as a "safe" level? >> >This might be impossible to code, but the text is correct. >I would not trust my mother to understand the difference=20 >between "user@pay-pal.com" and "user@paypal.com". > >>I thought bullet (3) would cover the user's mistakes. >> =20 >> >People automatically hit Ok button way too often, so explicit=20 >confirmation might help, but might not completely address the issue. > > [...] Well, I still don't like it, but I guess I am going to have to accept this fact. >>17. Section 3.2 paragraph 10. >> >>I do not think that such authentication should be allowed.=20 >Why not force anonymous instead? >> >This is explained in the following text describing ;AUTH=3D*: > > If no user name is specified and no appropriate=20 >authentication mechanisms > are available, the client SHOULD fall back to anonymous=20 >login as described > above. This allows a URL which grants read-write access=20 >to authorized > users, and read-only anonymous access to other users. > >>Well, at least this is hinted in the next paragraph with=20 >saying: "If a URL does not contain a user name or=20 >authentication mechanism, then only an anonymous connection=20 >may be re-used.", so which one is it? Allow omitting user name=20 >or force anonymous? I would prefer the latter. >> >Unless there is strong consensus from the WG to change the=20 >behavior described in RFC 2192, I would leave this text as is. It seems noone in the WG raised the issue, so I guess we can leave it as it is. Thanks for the fixes and replies. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri May 04 09:16:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjxdg-000793-3L; Fri, 04 May 2007 09:16:00 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hjxdf-00078x-66 for lemonade-confirm+ok@megatron.ietf.org; Fri, 04 May 2007 09:15:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjxde-00078p-Sf for lemonade@ietf.org; Fri, 04 May 2007 09:15:58 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hjxdd-0004Au-E6 for lemonade@ietf.org; Fri, 04 May 2007 09:15:58 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l44DFqQV002689; Fri, 4 May 2007 16:15:55 +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 May 2007 16:15:54 +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 May 2007 16:15: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] WGLC IMAP URL - update; comments (2192bis) Date: Fri, 4 May 2007 16:14:02 +0300 Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA1577528B8@esebe199.NOE.Nokia.com> In-Reply-To: <46337280.3030503@isode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] WGLC IMAP URL - update; comments (2192bis) Thread-Index: AceLCm9WjVGg1rtwRR+kynv24ORO9wDQ4zaQ References: <4C38DC11F6B4FF4FAEA73E30DB5AA1573FDF7B@esebe199.NOE.Nokia.com> <46337280.3030503@isode.com> From: To: X-OriginalArrivalTime: 04 May 2007 13:15:54.0537 (UTC) FILETIME=[586B5190:01C78E4E] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) 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 >-----Original Message----- >From: ext Alexey Melnikov [mailto:alexey.melnikov@isode.com]=20 >Sent: 28 April, 2007 19:13 >To: Ordogh Zoltan (Nokia-TP-MSW/Tampere) >Cc: lemonade@ietf.org >Subject: Re: [lemonade] WGLC IMAP URL - update; comments (2192bis) > >Zoltan.Ordogh@nokia.com wrote: > >>23. Clarification needed in section 6.1.2 paragraph 4. What=20 >is "submit+", what is a "access identifier prefix" and what is=20 >a "userid" - these have not been mentioned before, and these=20 >are not in the ABNF either. >> =20 >> >Actually they are: > access =3D ("submit+" enc-user) / ("user+" enc-user) / > "authuser" / "anonymous" > >>Same question for "user+", "authuser" in the following paragraphs. >> =20 >> >I've changed "access" to "" in several places to make=20 >this clearer. > > [...] Adding the <> was definiately needed. It's OK now. Thanks. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri May 04 09:51:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjyCT-0004oH-Uc; Fri, 04 May 2007 09:51:57 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HjyCS-0004oB-CV for lemonade-confirm+ok@megatron.ietf.org; Fri, 04 May 2007 09:51:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjyCS-0004o3-31 for lemonade@ietf.org; Fri, 04 May 2007 09:51:56 -0400 Received: from mtarwc.openwave.com ([12.25.200.46] helo=rwc-isa.openwave.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjyCR-0008GX-Lk for lemonade@ietf.org; Fri, 04 May 2007 09:51:56 -0400 Received: from rwc-exch-prd1.myopwv.com ([10.16.249.141]) by rwc-isa.openwave.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 May 2007 06:51:46 -0700 Received: from rwc-smtp-prd1.myopwv.com ([10.16.249.26]) by rwc-exch-prd1.myopwv.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 May 2007 06:51:46 -0700 Received: from rwc-fe-prd1.myopwv.com ([10.16.249.143]) by rwc-smtp-prd1.myopwv.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 May 2007 06:51:45 -0700 Received: from [127.0.0.1] ([10.16.72.73]) by rwc-fe-prd1.myopwv.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 May 2007 06:51:45 -0700 Message-ID: <463B3AD6.3030904@openwave.com> Date: Fri, 04 May 2007 09:53:26 -0400 From: Mike Zraly User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Karp Subject: Re: [lemonade] Comments on draft-ietf-lemonade-reconnect-client-04.txt References: <775158338.18781178264355201.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <775158338.18781178264355201.JavaMail.root@dogfood.zimbra.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 May 2007 13:51:45.0545 (UTC) FILETIME=[5A851790:01C78E53] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 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 Dan Karp wrote: >>>It seems to me that there should be an alternate response for this >>>case, perhaps called MISSINGEXPUNGED or something like that... >> >>But what could a client do when it receives such a response (other >>than a state-comparison resync)? Isn't this pretty much equivalent >>(in terms of what it means to the client) to the untagged RESYNC login >>response that was in the P-IMAP spec? That is, a response that means >>"hello client, the only sensible way for you to remain in sync is to >>do a state-comparison resync". > > If the server doesn't have enough persisted state to answer > "what's VANISHED since last sync", it can just downgrade from > the functionality described in section 4.3 to the functionality > described in section 4.1. The situations requiring such a > downgrade should be rare, but the server will still be fully > compliant: > > Strictly speaking, a server implementation that doesn't remember > modsequences associated with expunged messages can be considered > compliant with this specification. Such implementations return all > expunged messages specified in the UID set of the UID FETCH > (VANISHED) command every time, without paying attention to the > specified CHANGEDSINCE modsequence. Such implementations are > discouraged, as they can end up returning VANISHED responses bigger > than the result of a UID SEARCH command for the same UID set. > > There shouldn't be a need for a resync. True. What I am trying to work my head around is how the server should handle the case where the expunged message queue described in section 4.3 has been truncated, i.e. there are expired expunged messages. In this case, I think there is value in having the server return BOTH the set of known changed messages (via FETCH and VANISHED responses) AND an indication that the VANISHED response is known to be incomplete. Given this information, plus the number of messages in the mailbox on the server as reported by the EXISTS response, a client could decide the most efficient way to resynchronize the messages not affected by the reported changes. If the number of messages reported by the EXISTS response is less than the number of messages in the client's cache not affected by the FETCH and VANISHED responses, then it would make sense for the client to ignore the changes, discard its cache, and repopulate it directly from the server (via FETCH 1:* ...). OTOH if the number of messages reported by the EXISTS response is greater than the number of messages in the client's cache not affected by the FETCH and VANISHED responses, then it would make sense for the client to apply the changes, then ask the server only about the messages in its cache unaffected by the FETCH and VANISHED responses. To save the client for applying changes to its cache that it will immediately discard, the server could send untagged VANISHEDINCOMPLETE (what I called MISSINGEXPUNGED in my first email) and TOTALCHANGES responses before sending the FETCH and VANISHED responses. The VANISHEDINCOMPLETE response would tell the client that there is at least one message in its cache that was expunged but that the server no longer has a record of it. The TOTALCHANGES response would tell the client how many messages in its cache will be affected by the forthcoming FETCH and VANISHED responses. When a client receives both VANISHEDINCOMPLETE and TOTALCHANGES responses, it can subtract the number of changes from the size of its cache to determine the number of messages in the cache not affected by the FETCH and VANISHED responses. The client can then compare this number with the value returned by the EXISTS response to decide how to detect expunges of messages in that set, as described above. The interaction might look like this: C: A02 SELECT INBOX (QRESYNC (67890007 90060115194045000)) S: * 314 EXISTS S: * 15 RECENT S: * OK [UIDVALIDITY 67890007] UIDVALIDITY S: * OK [UIDNEXT 567] Predicted next UID S: * OK [HIGHESTMODSEQ 90060115205545359] S: * OK [UNSEEN 7] There are some unseen messages in the mailbox S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \*)] Permanent flags S: * OK [VANISHEDINCOMPLETE] some expunged message data has expired S: * OK [TOTALCHANGES 547] changed messages plus S: * 49 FETCH (UID 117 FLAGS (\Seen \Answered)) S: * 50 FETCH (UID 119 FLAGS (\Draft $MDNSent)) S: ... S: * 100 FETCH (UID 541 FLAGS (\Seen $Forwarded)) S: * VANISHED 41,43:116,118,120:211,214:540 S: A02 OK [READ-WRITE] mailbox selected Note that it would be best for the client if the TOTALCHANGES response were to precede the FETCH and VANISHED responses. However, some servers may not want to collect all the changes and count them before emitting the FETCH and VANISHED responses, so it probably makes more sense to say that servers SHOULD emit TOTALCHANGES before the FETCH and VANISHED responses rather than that they MUST do so. Of course, if the TOTALCHANGES response is only emitted after the FETCH and VANISHED responses, then it doesn't really add any extra information. If the TOTALCHANGES response is emitted prior to the FETCH and VANISHED responses, then I would say VANISHEDINCOMPLETE MUST also be emitted prior to the FETCH and VANISHED responses. If the TOTALCHANGES response is not emitted until after the FETCH and VANISHED responses, then I would say VANISHEDINCOMPLETE MAY be emitted after the FETCH and VANISHED responses. Reasonable? - Mike _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri May 04 10:20:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjydr-00039E-F9; Fri, 04 May 2007 10:20:15 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hjydq-000399-8q for lemonade-confirm+ok@megatron.ietf.org; Fri, 04 May 2007 10:20:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjydp-000391-Vb for lemonade@ietf.org; Fri, 04 May 2007 10:20:13 -0400 Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hjydm-0000BC-M2 for lemonade@ietf.org; Fri, 04 May 2007 10:20:13 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:51031) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:fanf2) id 1Hjyat-0005pT-1H (Exim 4.63) (return-path ); Fri, 04 May 2007 15:17:11 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Hjyas-00045B-Ff (Exim 4.54) (return-path ); Fri, 04 May 2007 15:17:10 +0100 Date: Fri, 4 May 2007 15:17:10 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Zoltan.Ordogh@nokia.com Subject: RE: [lemonade] Inclusion of QUICKSTART in Lemonade Profile-bis In-Reply-To: <4C38DC11F6B4FF4FAEA73E30DB5AA1577527F6@esebe199.NOE.Nokia.com> Message-ID: References: <4624D46A.1090408@isode.com> <4C38DC11F6B4FF4FAEA73E30DB5AA1577527F6@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Fri, 4 May 2007, Zoltan.Ordogh@nokia.com wrote: > However, reading the comments from other participants, it seems that > there is no real benefit. Is it really so? Cutting the roundtrips to > half does not have real benefits? There's a benefit of up to a couple of seconds less delay (assuming 300ms RTT) if the client sends in the foreground. There's no benefit if your client can send in the background. So it's probably interesting and useful for some but not all people. Tony. -- f.a.n.finch http://dotat.at/ NORTH UTSIRE SOUTH UTSIRE: NORTH 5 OR 6, OCCASIONALLY 7. MODERATE. MAINLY FAIR. MODERATE OR GOOD. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri May 04 13:27:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hk1YZ-0005wj-Ib; Fri, 04 May 2007 13:26:59 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hk1YY-0005wd-7r for lemonade-confirm+ok@megatron.ietf.org; Fri, 04 May 2007 13:26:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hk1YX-0005wV-Ud for lemonade@ietf.org; Fri, 04 May 2007 13:26:57 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hk1YV-0000xj-HQ for lemonade@ietf.org; Fri, 04 May 2007 13:26:57 -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, 4 May 2007 18:26:54 +0100 Message-ID: <463B6CA1.3060308@isode.com> Date: Fri, 04 May 2007 18:25:53 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Larry Masinter Subject: Re: [lemonade] RE: Review request for draft-ietf-lemonade-convert-06.txt References: <001d01c78938$55e9fb80$01bdf280$@org> In-Reply-To: <001d01c78938$55e9fb80$01bdf280$@org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: 'Ted Hardie' , 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 Larry, Thank you for your feedback! Larry Masinter wrote: >On the specific question of whether it is reasonable >to re-use existing IETF registered values, well, I >don't see any reason not to, if they're being used >with the same meaning. > >But my broader concern is that the sets of values chosen >don't really seem to match what's necessary to be effective. >From a content creation point of view, it seems like >you need to know a lot more, and I'm not sure why content >conversion would be different. > >At least, that seems to be the tone of W3C work in this >area, e.g., http://www.w3.org/TR/DDR-requirements >http://www.w3.org/2005/MWI/DDWG/ which is ongoing, > > I've glanced over the two URLs and didn't see any registry for conversion attributes. Do you know if there is a registry that I can reference in the draft I am editing? >and even of commercial products in this area >(http://www.adobe.com/products/creativesuite/devicecentral/). > >In general, I think coordinating IMAP with web access >mechanisms is a good idea, even if the web work isn't >happening in the IETF. > > Agreed. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri May 04 15:50:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hk3nj-0008Bu-Lc; Fri, 04 May 2007 15:50:47 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hk3nV-0007a4-8W for lemonade-confirm+ok@megatron.ietf.org; Fri, 04 May 2007 15:50:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hk3nU-0007Zn-T8; Fri, 04 May 2007 15:50:32 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hk3nU-00030R-HM; Fri, 04 May 2007 15:50:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 73CAF2AC8B; Fri, 4 May 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hk3n0-0006BF-7d; Fri, 04 May 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 04 May 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-streaming-02.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to Support Diverse Service Environments Working Group of the IETF. Title : Streaming Internet Messaging Attachments Author(s) : N. Cook Filename : draft-ietf-lemonade-streaming-02.txt Pages : 31 Date : 2007-5-4 This document describes a method for streaming multimedia attachments received by a resource constrained and/or mobile device from an IMAP server. It allows such clients, which often have limits in storage space and bandwidth, to play video and audio e-mail content. The document describes a profile for making use of the IMAP URLAUTH extension (RFC 4467), the Network Announcement SIP Media Service (RFC 4240), and the Media Server Control Markup Language (RFC 4722). The document also defines a new IMAP METADATA entry. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-streaming-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-streaming-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-streaming-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-5-4141856.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-streaming-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-streaming-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-4141856.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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --NextPart-- From lemonade-bounces@ietf.org Fri May 04 15:50:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hk3no-0008L0-TS; Fri, 04 May 2007 15:50:52 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hk3nV-0007aW-TO for lemonade-confirm+ok@megatron.ietf.org; Fri, 04 May 2007 15:50:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hk3nV-0007a5-9W; Fri, 04 May 2007 15:50:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hk3nU-00030a-Vl; Fri, 04 May 2007 15:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id D0ECF17658; Fri, 4 May 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hk3n0-0006Bj-HT; Fri, 04 May 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 04 May 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-rfc2192bis-05.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 : IMAP URL Scheme Author(s) : A. Melnikov, et al. Filename : draft-ietf-lemonade-rfc2192bis-05.txt Pages : 30 Date : 2007-5-4 IMAP (RFC 3501) is a rich protocol for accessing remote message stores. It provides an ideal mechanism for accessing public mail- ing list archives as well as private and shared message stores. This document defines a URL scheme for referencing objects on an IMAP server. This document obsoletes RFC 2192. It also updates RFC 4467. Together with update to RFC 4467 they will obsolete RFC 4467. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-rfc2192bis-05.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-rfc2192bis-05.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-rfc2192bis-05.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: <2007-5-4145512.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-rfc2192bis-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-rfc2192bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-4145512.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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --NextPart-- From lemonade-bounces@ietf.org Fri May 04 21:45:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hk9LC-0003yY-Tr; Fri, 04 May 2007 21:45:42 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hk9LB-0003yO-Sp for lemonade-confirm+ok@megatron.ietf.org; Fri, 04 May 2007 21:45:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hk9LB-0003yG-67 for lemonade@ietf.org; Fri, 04 May 2007 21:45:41 -0400 Received: from exprod6og50.obsmtp.com ([64.18.1.181]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hk9L9-0005jI-An for lemonade@ietf.org; Fri, 04 May 2007 21:45:41 -0400 Received: from source ([192.150.20.142]) by exprod6ob50.postini.com ([64.18.5.12]) with SMTP; Fri, 04 May 2007 18:45:31 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l451jHSd009067; Fri, 4 May 2007 18:45:21 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l451iK0o018920; Fri, 4 May 2007 18:45:06 -0700 (PDT) Received: from namail1.corp.adobe.com ([10.8.192.62]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 May 2007 18:44:52 -0700 Received: from masinterlap06 ([153.32.47.39]) by namail1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 May 2007 18:44:52 -0700 From: "Larry Masinter" To: "'Alexey Melnikov'" References: <001d01c78938$55e9fb80$01bdf280$@org> <463B6CA1.3060308@isode.com> In-Reply-To: <463B6CA1.3060308@isode.com> Subject: RE: [lemonade] RE: Review request for draft-ietf-lemonade-convert-06.txt Date: Fri, 4 May 2007 18:44:53 -0700 Message-ID: <000e01c78eb6$f9f60330$ede20990$@org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AceOcWpYi5C3oCcyQQib2CZoEkY2MgAPZukQ Content-Language: en-us X-OriginalArrivalTime: 05 May 2007 01:44:52.0737 (UTC) FILETIME=[F9AC7710:01C78EB6] X-Spam-Score: 0.6 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: 'Ted Hardie' , lemonade@ietf.org, 'Graham Klyne' X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org You might consider looking more closely at RFC 3297: "Content Negotiation for Messaging Services based on Email" http://tools.ietf.org/html/rfc3297 even though IMAP is different than SMTP, most of the concepts about message adaptation should apply; perhaps it should be more transparent whether the adaptation is done by the IMAP server or somewhere upstream? You might also consider the proposed (Experimental) transparent content negotiation framework: http://www.ietf.org/rfc/rfc2295.txt I don't think there is a clear distinction between renditions that are previously made available and those that are converted on demand. >> At least, that seems to be the tone of W3C work in this >> area, e.g., http://www.w3.org/TR/DDR-requirements >> http://www.w3.org/2005/MWI/DDWG/ which is ongoing, >> and even of commercial products in this area >> (http://www.adobe.com/products/creativesuite/devicecentral/). >> I've glanced over the two URLs and didn't see any registry for >> conversion attributes. >> Do you know if there is a registry that I can reference in the draft I >> am editing? The registries are more about either content attributes, device capabilities or preference parameters, but their purpose is for selection or conversion -- each content attribute is either an attribute of the source or an attribute of the destination. I know there are conversion parameters that don't easily fit into that framework (e.g., 'scale down 50%') but I'm not sure of their appropriateness for the context you're considering. Under what circumstances is it preferable for the client to supply conversion parameters rather than output constraints based on client capabilities? Larry _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon May 07 04:34:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hkyfp-0005Kl-DS; Mon, 07 May 2007 04:34:25 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hkyfo-0005KU-2K for lemonade-confirm+ok@megatron.ietf.org; Mon, 07 May 2007 04:34:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hkyfn-0005KG-Ii for lemonade@ietf.org; Mon, 07 May 2007 04:34:23 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hkyfm-0002xB-3N for lemonade@ietf.org; Mon, 07 May 2007 04:34:23 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l478Xnv7004913; Mon, 7 May 2007 11:34:09 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 May 2007 11:33:47 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 May 2007 11:33: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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Inclusion of QUICKSTART in Lemonade Profile-bis Date: Mon, 7 May 2007 11:31:54 +0300 Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA157752D68@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Inclusion of QUICKSTART in Lemonade Profile-bis Thread-Index: AceOV1XtZbeAdsD7SxqZFN6An/RKCgCKpY+A References: <4624D46A.1090408@isode.com> <4C38DC11F6B4FF4FAEA73E30DB5AA1577527F6@esebe199.NOE.Nokia.com> From: To: X-OriginalArrivalTime: 07 May 2007 08:33:47.0495 (UTC) FILETIME=[6E5AEF70:01C79082] X-Nokia-AV: Clean 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 Hello Tony, >> However, reading the comments from other participants, it seems that=20 >> there is no real benefit. Is it really so? Cutting the roundtrips to=20 >> half does not have real benefits? > >There's a benefit of up to a couple of seconds less delay=20 >(assuming 300ms >RTT) if the client sends in the foreground. There's no benefit=20 >if your client can send in the background. So it's probably=20 >interesting and useful for some but not all people. Using fixed network, right? Not a GPRS or other wireless connection, right? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon May 07 06:20:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl0KR-0002Wy-Iy; Mon, 07 May 2007 06:20:27 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hl0KQ-0002Wp-7g for lemonade-confirm+ok@megatron.ietf.org; Mon, 07 May 2007 06:20:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl0KP-0002Wg-UN for lemonade@ietf.org; Mon, 07 May 2007 06:20:25 -0400 Received: from ppsw-7.csi.cam.ac.uk ([131.111.8.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hl0KK-0006oq-Ku for lemonade@ietf.org; Mon, 07 May 2007 06:20:25 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:45579) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1Hl0In-00062J-N3 (Exim 4.63) (return-path ); Mon, 07 May 2007 11:18:45 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Hl0In-0002NX-3w (Exim 4.54) (return-path ); Mon, 07 May 2007 11:18:45 +0100 Date: Mon, 7 May 2007 11:18:45 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Zoltan.Ordogh@nokia.com Subject: RE: [lemonade] Inclusion of QUICKSTART in Lemonade Profile-bis In-Reply-To: <4C38DC11F6B4FF4FAEA73E30DB5AA157752D68@esebe199.NOE.Nokia.com> Message-ID: References: <4624D46A.1090408@isode.com> <4C38DC11F6B4FF4FAEA73E30DB5AA1577527F6@esebe199.NOE.Nokia.com> <4C38DC11F6B4FF4FAEA73E30DB5AA157752D68@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Mon, 7 May 2007, Zoltan.Ordogh@nokia.com wrote: > > Using fixed network, right? Not a GPRS or other wireless connection, > right? I'm not making any assumptions about the network layer, because this is a purely application-layer optimization. I'm only counting time from the sending of the first TCP SYN, so I'm not counting setup delays that occur before that point, e.g. DNS lookups. Tony. -- f.a.n.finch http://dotat.at/ SOLE: SOUTHWESTERLY 6 OR 7. ROUGH OR VERY ROUGH. RAIN OR DRIZZLE. MODERATE OR POOR. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon May 07 08:34:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl2Q9-0000J8-7W; Mon, 07 May 2007 08:34:29 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hl2Q8-0000J3-Jl for lemonade-confirm+ok@megatron.ietf.org; Mon, 07 May 2007 08:34:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl2Q8-0000Iv-AL for lemonade@ietf.org; Mon, 07 May 2007 08:34:28 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hl2Q6-0005au-Sn for lemonade@ietf.org; Mon, 07 May 2007 08:34:28 -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 ; Mon, 7 May 2007 13:34:21 +0100 Message-ID: <463C68AC.1020503@isode.com> Date: Sat, 05 May 2007 12:21:16 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Randall Gellens References: <463078CD.9030002@isode.com> In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: lemonade@ietf.org Subject: [lemonade] CONVERT: conversion from text/html to text/plain as a SHOULD X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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: >> 3). Mandatory to implement conversion: >> >>> ---------- >>> Section 6.1.1: >>> >>> Do we really want to say SHOULD for text/html to text/plain? >> >> I think we had this discussion before and I thought that consensus >> was declared. >> However I feel that many people are unhappy with the choice, so >> maybe we don't actually have a consensus. >> >> Do you think charset conversion (ISO-8859-* to UTF-8) is better? > > Better and more useful, perhaps. > >>> Is this actually useful for any mobile device that can support IMAP? >> >> It is useful for a desktop client that doesn't support HTML. > > But are there any clients that don't support HTML? The most simple ones might not. >>> I wonder if text/plain to text/html wouldn't be just as useful? (it >>> is easier to implement). >> >> It is easier, but I think it is pointless. > > Perhaps not. If a client has an HTML display engine, it is easier to > use it than to reformat plain text to fit a small screen. As an > example, Eudora for Palm makes use of the Qpopper x-mangle option to > have plain text (both format=flowed and format=fixed) converted to > HTML to make rendering easier. Interesting. But I still don't think this is generally useful to warrant a SHOULD. ----------------------------------------- Trying to summarize opinions on this issue: People against text/html -> text/plain conversion: Randy, Arnt, Dave. I personally can be counted as +0.5 for dropping it as well. The major problem for me is that this conversion is underspecified and specifying it would take a lot of time. So at this point I think we have a rough consensus for not having this as a SHOULD. I will delete the relevant text. If you object, please speak up now. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon May 07 08:34:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl2QD-0000KS-DC; Mon, 07 May 2007 08:34:33 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hl2QB-0000JZ-TN for lemonade-confirm+ok@megatron.ietf.org; Mon, 07 May 2007 08:34:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl2QB-0000JP-Jm for lemonade@ietf.org; Mon, 07 May 2007 08:34:31 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hl2QA-0005bF-BG for lemonade@ietf.org; Mon, 07 May 2007 08:34:31 -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 ; Mon, 7 May 2007 13:34:23 +0100 Message-ID: <463C69CD.90309@isode.com> Date: Sat, 05 May 2007 12:26:06 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: lemonade@ietf.org References: <463078CD.9030002@isode.com> <463C68AC.1020503@isode.com> In-Reply-To: <463C68AC.1020503@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [lemonade] Re: CONVERT: conversion from text/html to text/plain as a SHOULD X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 wrote: > So at this point I think we have a rough consensus for not having this > as a SHOULD. I will delete the relevant text. If you object, please > speak up now. Correction: I will change the text to make informative, instead of deleting it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon May 07 08:34:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl2QE-0000LS-Jn; Mon, 07 May 2007 08:34:34 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hl2QD-0000KN-9y for lemonade-confirm+ok@megatron.ietf.org; Mon, 07 May 2007 08:34:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl2QD-0000KF-0H for lemonade@ietf.org; Mon, 07 May 2007 08:34:33 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hl2QB-0005bF-MT for lemonade@ietf.org; Mon, 07 May 2007 08:34:32 -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 ; Mon, 7 May 2007 13:34:24 +0100 Message-ID: <463C851A.5060502@isode.com> Date: Sat, 05 May 2007 14:22:34 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Ben Last Subject: Re: [lemonade] WGCL Convert-05 References: <22C8A0D5D5E095449AB509FE777B5F80036DC473@svr-exchange.avocado.emccsoft.com> In-Reply-To: <22C8A0D5D5E095449AB509FE777B5F80036DC473@svr-exchange.avocado.emccsoft.com> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.3 (/) 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 Ben Last wrote: >Second issue: size of the converted data. Our client makes use of the >size of a body section that's to be downloaded for two reasons: first, >we can check to see whether there is enough space to store it (and >invoke smart storage management if required). On a storage-limited >device, that's important: we've seen users who are used to PCs and >ignore the size of attachments when starting a download. Secondly, we >download any section in chunks (for networking and command-interleaving >reasons) and that requires us to keep track of the current amount >downloaded and the final amount to download. At best, the client should >have a way to request that size *before* requesting conversion. Since >the sizes resulting from different conversions may vary consierably, the >client may want to request a set of sizes in order to determine the best >format to download. > Ok, I've added CONVERT.SIZE. This will look like this: C: c000 FETCH 2 CONVERT.SIZE[4.STRICT ("TEXT/PLAIN" ("CHARSET" "us-ascii"))] S: * 2 FETCH (CONVERT.SIZE[4.STRICT ("TEXT/PLAIN" ("CHARSET" "us-ascii"))] 2135) S: c000 OK FETCH COMPLETED _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon May 07 08:34:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl2QH-0000O7-R5; Mon, 07 May 2007 08:34:37 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hl2QG-0000Nj-Kf for lemonade-confirm+ok@megatron.ietf.org; Mon, 07 May 2007 08:34:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl2QG-0000Nb-Ac for lemonade@ietf.org; Mon, 07 May 2007 08:34:36 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hl2QE-0005bV-15 for lemonade@ietf.org; Mon, 07 May 2007 08:34:36 -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 ; Mon, 7 May 2007 13:34:24 +0100 Message-ID: <463C8B56.8030901@isode.com> Date: Sat, 05 May 2007 14:49:10 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Zoltan.Ordogh@nokia.com Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-05.txt References: <4C38DC11F6B4FF4FAEA73E30DB5AA157717B33@esebe199.NOE.Nokia.com> In-Reply-To: <4C38DC11F6B4FF4FAEA73E30DB5AA157717B33@esebe199.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Zoltan, Zoltan.Ordogh@nokia.com wrote: >General: > > [I will let Dave reply to the rest of your comments.] >9. There are some places where the word "folder" is used. Should we consistently use "mailbox" instead of "folder"? > Yes, we should use "mailbox" everywhere. > Or provide some sort of clarification (a reference?) to what the difference is? >10. References - do we want to provide some sort of update here? >Pipelining; RFC2197 is obsoleted by RFC2920 > > Yes. >DSN; RFC3461 is updated by RFC3798 and RFC3885 >BINARY; RFC3516 is updated by RFC4466 >LITERAL+; RFC2088 is updated by RFC4466 >NAMESPACE; RFC2342 is updated by RFC4466 > > We don't need to list all RFCs that update the ones we are referencing. "Updated" status is more like "see also". _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon May 07 08:34:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl2QJ-0000PQ-02; Mon, 07 May 2007 08:34:39 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hl2QH-0000O2-6w for lemonade-confirm+ok@megatron.ietf.org; Mon, 07 May 2007 08:34:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl2QG-0000Np-SU for lemonade@ietf.org; Mon, 07 May 2007 08:34:36 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hl2QG-0005bV-DF for lemonade@ietf.org; Mon, 07 May 2007 08:34:36 -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 ; Mon, 7 May 2007 13:34:26 +0100 Message-ID: <463C8D79.30602@isode.com> Date: Sat, 05 May 2007 14:58:17 +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: Mike Zraly Subject: Re: [lemonade] Comments on draft-ietf-lemonade-reconnect-client-04.txt References: <775158338.18781178264355201.JavaMail.root@dogfood.zimbra.com> <463B3AD6.3030904@openwave.com> In-Reply-To: <463B3AD6.3030904@openwave.com> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Mike Zraly wrote: > Dan Karp wrote: > >>>> It seems to me that there should be an alternate response for this >>>> case, perhaps called MISSINGEXPUNGED or something like that... >>> >>> But what could a client do when it receives such a response (other >>> than a state-comparison resync)? Isn't this pretty much equivalent >>> (in terms of what it means to the client) to the untagged RESYNC login >>> response that was in the P-IMAP spec? That is, a response that means >>> "hello client, the only sensible way for you to remain in sync is to >>> do a state-comparison resync". >> >> If the server doesn't have enough persisted state to answer >> "what's VANISHED since last sync", it can just downgrade from >> the functionality described in section 4.3 to the functionality >> described in section 4.1. The situations requiring such a >> downgrade should be rare, but the server will still be fully >> compliant: >> >> Strictly speaking, a server implementation that doesn't remember >> modsequences associated with expunged messages can be considered >> compliant with this specification. Such implementations return all >> expunged messages specified in the UID set of the UID FETCH >> (VANISHED) command every time, without paying attention to the >> specified CHANGEDSINCE modsequence. Such implementations are >> discouraged, as they can end up returning VANISHED responses bigger >> than the result of a UID SEARCH command for the same UID set. >> >> There shouldn't be a need for a resync. > > True. Hi Mike, > What I am trying to work my head around is how the server should > handle the case where the expunged message queue described in > section 4.3 has been truncated, i.e. there are expired expunged > messages. > > In this case, I think there is value in having the server return > BOTH the set of known changed messages (via FETCH and VANISHED > responses) Correct so far. > AND an indication that the VANISHED response is known > to be incomplete. This part is wrong. If the server knows that it doesn't have information about some expunged messages, the server should always return them as expunged (after checking that they are in the UID list specified by the client). After all, there is no harm in reporting a message expunged long time ago as a "recently expunged message". This might cause some extra traffic, but the client must be able to handle it anyway. [...] _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon May 07 08:34:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl2QZ-00017H-B1; Mon, 07 May 2007 08:34:55 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hl2QX-000175-Nc for lemonade-confirm+ok@megatron.ietf.org; Mon, 07 May 2007 08:34:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl2QX-00016r-DC for lemonade@ietf.org; Mon, 07 May 2007 08:34:53 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hl2QW-0005cy-3U for lemonade@ietf.org; Mon, 07 May 2007 08:34:53 -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 ; Mon, 7 May 2007 13:34:37 +0100 Message-ID: <463DEA3A.3010507@isode.com> Date: Sun, 06 May 2007 15:46:18 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Zoltan.Ordogh@nokia.com Subject: Re: [lemonade] WGLC IMAP URL - update; comments (2192bis) References: <4C38DC11F6B4FF4FAEA73E30DB5AA1573FDF7B@esebe199.NOE.Nokia.com> In-Reply-To: <4C38DC11F6B4FF4FAEA73E30DB5AA1573FDF7B@esebe199.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Zoltan, >2. Clarification needed for section 3.1: in medias res. Assuming a top-down reading order, the terms "enc-user" and "iuserinfo" have not been mentioned yet so the reader will have no clue what these terms mean. I scrolled back up to section 2, but there are no such things either. It might also be that there is something missing under "3. IMAP userinfo component" because that section seems to be empty (only a heading without text). Reading the ABNF clears this up, but ABNF is at the end of the document. >Perphaps moving the first paragraph of section 3.2 to section 3? > I've added syntax of various components to sections that mention them for the first time. This will appear in version -06 of the draft. Let me know if -06 is sufficiently clear. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon May 07 09:16:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl35E-0001ER-K2; Mon, 07 May 2007 09:16:56 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hl35D-0001EH-Mp for lemonade-confirm+ok@megatron.ietf.org; Mon, 07 May 2007 09:16:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl35D-0001E9-DJ for lemonade@ietf.org; Mon, 07 May 2007 09:16:55 -0400 Received: from mtarwc.openwave.com ([12.25.200.46] helo=rwc-isa.openwave.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hl35B-0007SS-0S for lemonade@ietf.org; Mon, 07 May 2007 09:16:55 -0400 Received: from rwc-exch-prd1.myopwv.com ([10.16.249.141]) by rwc-isa.openwave.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 May 2007 06:16:46 -0700 Received: from rwc-smtp-prd1.myopwv.com ([10.16.249.26]) by rwc-exch-prd1.myopwv.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 May 2007 06:16:46 -0700 Received: from rwc-fe-prd1.myopwv.com ([10.16.249.143]) by rwc-smtp-prd1.myopwv.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 May 2007 06:16:45 -0700 Received: from [10.68.15.5] ([10.68.15.5]) by rwc-fe-prd1.myopwv.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 May 2007 06:16:45 -0700 Message-ID: <463F26A5.6000504@openwave.com> Date: Mon, 07 May 2007 09:16:21 -0400 From: Mike Zraly User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Alexey Melnikov Subject: Re: [lemonade] Comments on draft-ietf-lemonade-reconnect-client-04.txt References: <775158338.18781178264355201.JavaMail.root@dogfood.zimbra.com> <463B3AD6.3030904@openwave.com> <463C8D79.30602@isode.com> In-Reply-To: <463C8D79.30602@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 May 2007 13:16:45.0484 (UTC) FILETIME=[F60676C0:01C790A9] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Alexey Melnikov wrote: > Mike Zraly wrote: > >> Dan Karp wrote: >> >>>>> It seems to me that there should be an alternate response for this >>>>> case, perhaps called MISSINGEXPUNGED or something like that... >>>> >>>> But what could a client do when it receives such a response (other >>>> than a state-comparison resync)? Isn't this pretty much equivalent >>>> (in terms of what it means to the client) to the untagged RESYNC login >>>> response that was in the P-IMAP spec? That is, a response that means >>>> "hello client, the only sensible way for you to remain in sync is to >>>> do a state-comparison resync". >>> >>> If the server doesn't have enough persisted state to answer >>> "what's VANISHED since last sync", it can just downgrade from >>> the functionality described in section 4.3 to the functionality >>> described in section 4.1. The situations requiring such a >>> downgrade should be rare, but the server will still be fully >>> compliant: >>> >>> Strictly speaking, a server implementation that doesn't remember >>> modsequences associated with expunged messages can be considered >>> compliant with this specification. Such implementations return all >>> expunged messages specified in the UID set of the UID FETCH >>> (VANISHED) command every time, without paying attention to the >>> specified CHANGEDSINCE modsequence. Such implementations are >>> discouraged, as they can end up returning VANISHED responses bigger >>> than the result of a UID SEARCH command for the same UID set. >>> >>> There shouldn't be a need for a resync. >> >> True. > > Hi Mike, > >> What I am trying to work my head around is how the server should >> handle the case where the expunged message queue described in >> section 4.3 has been truncated, i.e. there are expired expunged >> messages. >> >> In this case, I think there is value in having the server return >> BOTH the set of known changed messages (via FETCH and VANISHED >> responses) > > Correct so far. > >> AND an indication that the VANISHED response is known >> to be incomplete. > > This part is wrong. If the server knows that it doesn't have information > about some expunged messages, the server should always return them as > expunged (after checking that they are in the UID list specified by the > client). After all, there is no harm in reporting a message expunged > long time ago as a "recently expunged message". This might cause some > extra traffic, but the client must be able to handle it anyway. Agreed that if the client *does* specify the UID list then it is easy and correct for a server to declare that any UID in the list which the server does not know about is expunged. But what if the client doesn't specify the UID list? The set of known UIDs is an optional parameter, per section 3.1. Hmm, later on in section 3.1 the draft says that the server should treat an unspecified known UID list as "1:*". I suppose this could work, depending on how "*" is interpreted. If "*" is interpreted the same ways as it is for the UID command (RFC 3501 section 6.4.8), i.e. to mean the highest numbered UID in the mailbox, then this will not work in the case where there are expunged messages with higher IMAP UIDs (and there are enough of them that the server does not have a record of each one). If on the other hand the "*" in this context is interpreted as meaning the largest UID value that was ever assigned to a message in the mailbox, then this would work. Generally I suppose this value would be one less than a mailbox's UIDNEXT value. - Mike _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon May 07 19:35:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlCjQ-0004Gu-JM; Mon, 07 May 2007 19:35:04 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HlCjO-0004GU-Li for lemonade-confirm+ok@megatron.ietf.org; Mon, 07 May 2007 19:35:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlCjO-0004GD-Ax for lemonade@ietf.org; Mon, 07 May 2007 19:35:02 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlCjM-0006Rr-Iw for lemonade@ietf.org; Mon, 07 May 2007 19:35:01 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l47NYwbm032040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 7 May 2007 16:34:59 -0700 Received: from [[192.168.1.13]] (vpn-10-50-16-67.qualcomm.com [10.50.16.67]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l47NYvv6015630 for ; Mon, 7 May 2007 16:34:58 -0700 (PDT) Mime-Version: 1.0 Message-Id: X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Mon, 7 May 2007 16:31:08 -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: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [lemonade] Updated msgevents Draft X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 updated the msgevents draft. I've posted it at to provide immediate access. I'll be sending it in to be published tomorrow (Tuesday), so if you are able to read it and find anything that needs to be corrected, please let me know right away. Changes from -01 to -02 o Add editor's note regarding deprecation of IDLE o Add text indicating that mailboxes may contain Internet messages and/or child mailboxes o Remove word "folder" from definition of "mailbox" o Add editor's note regarding optionality in this document o Add editor's note regarding optional vs. mandatory events o Add editor's note regarding event names o Remove U.S.-centric wording regarding laws o Review uses of "will" and change as appropriate o Clarification of server address in login event o Addition of MailboxCreate, MailboxDelete, MailboxRename, and MailboxSubscribe events o Added mailboxName parameter o Moved RFC2822 from normative to informative o Added IANA Considerations and reference to RFC 2434 o Minor grammatical improvements -- 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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue May 08 06:41:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlN82-0002J7-Be; Tue, 08 May 2007 06:41:10 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HlN81-0002J2-CE for lemonade-confirm+ok@megatron.ietf.org; Tue, 08 May 2007 06:41:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlN81-0002Iq-28 for lemonade@ietf.org; Tue, 08 May 2007 06:41:09 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlN7y-0006iq-4y for lemonade@ietf.org; Tue, 08 May 2007 06:41:09 -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 ; Tue, 8 May 2007 11:41:05 +0100 Message-ID: <463F8DA6.1090501@isode.com> Date: Mon, 07 May 2007 21:35:50 +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: Mike Zraly Subject: Re: [lemonade] Comments on draft-ietf-lemonade-reconnect-client-04.txt References: <775158338.18781178264355201.JavaMail.root@dogfood.zimbra.com> <463B3AD6.3030904@openwave.com> <463C8D79.30602@isode.com> <463F26A5.6000504@openwave.com> In-Reply-To: <463F26A5.6000504@openwave.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: 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 Mike Zraly wrote: > Agreed that if the client *does* specify the UID list then it is > easy and correct for a server to declare that any UID in the list > which the server does not know about is expunged. > > But what if the client doesn't specify the UID list? The set of > known UIDs is an optional parameter, per section 3.1. > > Hmm, later on in section 3.1 the draft says that the server should > treat an unspecified known UID list as "1:*". I suppose this could > work, depending on how "*" is interpreted. If "*" is interpreted > the same ways as it is for the UID command (RFC 3501 section 6.4.8), > i.e. to mean the highest numbered UID in the mailbox, then this will > not work in the case where there are expunged messages with higher > IMAP UIDs (and there are enough of them that the server does not > have a record of each one). > > If on the other hand the "*" in this context is interpreted as > meaning the largest UID value that was ever assigned to a message > in the mailbox, then this would work. Generally I suppose this > value would be one less than a mailbox's UIDNEXT value. I will clarify that "*" references the latter in this case. Thanks, Alexey _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue May 08 06:41:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlN8C-0002Kr-HR; Tue, 08 May 2007 06:41:20 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HlN8B-0002Ki-73 for lemonade-confirm+ok@megatron.ietf.org; Tue, 08 May 2007 06:41:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlN8A-0002KX-TL for lemonade@ietf.org; Tue, 08 May 2007 06:41:18 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlN8A-0006jo-BG for lemonade@ietf.org; Tue, 08 May 2007 06:41:18 -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 ; Tue, 8 May 2007 11:41:17 +0100 Message-ID: <463FACDD.8020300@isode.com> Date: Mon, 07 May 2007 23:49:01 +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: Larry Masinter Subject: Re: [lemonade] RE: Review request for draft-ietf-lemonade-convert-06.txt References: <001d01c78938$55e9fb80$01bdf280$@org> <463B6CA1.3060308@isode.com> <000e01c78eb6$f9f60330$ede20990$@org> In-Reply-To: <000e01c78eb6$f9f60330$ede20990$@org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: 'Ted Hardie' , lemonade@ietf.org, 'Graham Klyne' X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 Larry, Larry Masinter wrote: >You might consider looking more closely at RFC 3297: >"Content Negotiation for Messaging Services based on Email" >http://tools.ietf.org/html/rfc3297 > >even though IMAP is different than SMTP, most of the concepts >about message adaptation should apply; > Yes, this seems close enough to what we are doing. >perhaps it should be more transparent whether the adaptation is done by the IMAP >server or somewhere upstream? > > IMAP CONVERT only deals with adaptations that happen once the message is delivered to a mailstore. But IMAP CONVERT can be implemented in a proxy server that performs conversion after retrieving data from a vanilla IMAP server. >You might also consider the proposed (Experimental) transparent >content negotiation framework: > >http://www.ietf.org/rfc/rfc2295.txt > >I don't think there is a clear distinction between renditions >that are previously made available and those that are converted >on demand. > > >>>At least, that seems to be the tone of W3C work in this >>>area, e.g., http://www.w3.org/TR/DDR-requirements >>>http://www.w3.org/2005/MWI/DDWG/ which is ongoing, >>>and even of commercial products in this area >>>(http://www.adobe.com/products/creativesuite/devicecentral/). >>> >>> >>>I've glanced over the two URLs and didn't see any registry for >>>conversion attributes. >>> >>> >>>Do you know if there is a registry that I can reference in the draft I >>>am editing? >>> >>> >The registries are more about either content attributes, >device capabilities or preference parameters, but their >purpose is for selection or conversion -- each content >attribute is either an attribute of the source >or an attribute of the destination. > > Yes, this is how they are used in IMAP CONVERT. (Does this mean that IMAP CONVERT can reuse RFC 2506's registry :-) ?) >I know there are conversion parameters that don't easily >fit into that framework (e.g., 'scale down 50%') but I'm >not sure of their appropriateness for the context you're >considering. > Taking your specific example: if you mean that the "scale down 50%" can be replaced by "I want resolution X by Y", then I agree. > Under what circumstances is it preferable >for the client to supply conversion parameters rather than >output constraints based on client capabilities? > > I can't think of any at the moment. Regards, Alexey _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue May 08 07:44:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlO7D-0000D0-M7; Tue, 08 May 2007 07:44:23 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HlO7C-0000Cv-PQ for lemonade-confirm+ok@megatron.ietf.org; Tue, 08 May 2007 07:44:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlO7C-0000Cn-Fv for lemonade@ietf.org; Tue, 08 May 2007 07:44:22 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlO79-0002Oe-2Z for lemonade@ietf.org; Tue, 08 May 2007 07:44:22 -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 ; Tue, 8 May 2007 12:44:18 +0100 Message-ID: <46406252.8050507@isode.com> Date: Tue, 08 May 2007 12:43:14 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randall Gellens Subject: Re: [lemonade] Updated msgevents Draft 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: de4f315c9369b71d7dd5909b42224370 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 4.4. Mailbox Management This section lists events related to the management of mailboxes. MailboxCreate A mailbox has been created. If the mailbox creation caused the creation of new mailboxes earlier in the hierarchy, separate MailboxCreate events are not sent for those as their creation is implied. The parameters include the deleted mailbox name, its ^^^^^^^ Should be "the created mailbox name". UIDVALIDITY for IMAP-accessible message stores, and may also indicate which access protocol triggered the event. Access/ permissions information (such as ACL settings) MAY be included. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue May 08 15:50:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlVhi-0003Pb-MA; Tue, 08 May 2007 15:50:34 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HlVhh-0003PQ-4c for lemonade-confirm+ok@megatron.ietf.org; Tue, 08 May 2007 15:50:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlVhg-0003Op-Q1; Tue, 08 May 2007 15:50:32 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HlVhg-0001oS-GD; Tue, 08 May 2007 15:50:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 6C5032ACC9; Tue, 8 May 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HlVhC-0003Jp-6p; Tue, 08 May 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 08 May 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-rfc2192bis-06.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 : IMAP URL Scheme Author(s) : A. Melnikov, et al. Filename : draft-ietf-lemonade-rfc2192bis-06.txt Pages : 31 Date : 2007-5-8 IMAP (RFC 3501) is a rich protocol for accessing remote message stores. It provides an ideal mechanism for accessing public mail- ing list archives as well as private and shared message stores. This document defines a URL scheme for referencing objects on an IMAP server. This document obsoletes RFC 2192. It also updates RFC 4467. Together with update to RFC 4467 they will obsolete RFC 4467. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-rfc2192bis-06.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-rfc2192bis-06.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-rfc2192bis-06.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: <2007-5-8145939.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-rfc2192bis-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-rfc2192bis-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-8145939.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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --NextPart-- From lemonade-bounces@ietf.org Tue May 08 18:07:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlXpu-0005GK-6q; Tue, 08 May 2007 18:07:10 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HlXpt-0005GE-Me for lemonade-confirm+ok@megatron.ietf.org; Tue, 08 May 2007 18:07:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlXpt-0005G6-D8 for lemonade@ietf.org; Tue, 08 May 2007 18:07:09 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlXpr-0007Vk-Fm for lemonade@ietf.org; Tue, 08 May 2007 18:07: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 l48M76Og025928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 May 2007 15:07:06 -0700 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.72.21]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l48M75xu026778; Tue, 8 May 2007 15:07:05 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Tue, 8 May 2007 15:04:34 -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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Alexey Melnikov Subject: [lemonade] Updated msgevents Draft to -02 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 updated the msgevents draft to -02. I've posted it at to provide immediate access. Thanks very much to Alexey for the quick review and helpful comments! I also found a bunch other stuff to fix, so -02 is different from -02-a. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- There are two kinds of light--the glow that illuminates, and the glare that obscures. --James Thurber _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed May 09 04:13:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlhIW-000706-Fr; Wed, 09 May 2007 04:13:20 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HlhIU-0006zy-GN for lemonade-confirm+ok@megatron.ietf.org; Wed, 09 May 2007 04:13:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlhIU-0006zq-4V for lemonade@ietf.org; Wed, 09 May 2007 04:13:18 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlhIS-0006ZS-Iv for lemonade@ietf.org; Wed, 09 May 2007 04:13:18 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l498CvxZ008016; Wed, 9 May 2007 11:13:14 +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 May 2007 11:13:14 +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 May 2007 11:13:14 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] CONVERT: .STRICT specifier (again) Date: Wed, 9 May 2007 11:11:20 +0300 Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA1577972B9@esebe199.NOE.Nokia.com> In-Reply-To: <4634A134.6030508@isode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] CONVERT: .STRICT specifier (again) Thread-Index: AceLE1Wr9FGotzYDRrK2xdOXreo2egG/h8oA References: <4634A134.6030508@isode.com> From: To: , X-OriginalArrivalTime: 09 May 2007 08:13:14.0072 (UTC) FILETIME=[E4010580:01C79211] X-Nokia-AV: Clean 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 We removed SERVEROVERRIDE. I think removing .STRICT is pretty much the = same argument. 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 Alexey Melnikov [mailto:alexey.melnikov@isode.com]=20 >Sent: 29 April, 2007 16:44 >To: Lemonade WG >Subject: [lemonade] CONVERT: .STRICT specifier (again) > >I am somewhat hesitating to remove .STRICT specifier. Are=20 >there any cases when the client would like to specify a=20 >transcoding parameter that can be ignored by the server? > > > > >_______________________________________________ >lemonade mailing list >lemonade@ietf.org >https://www1.ietf.org/mailman/listinfo/lemonade >Supplemental Web Site: >http://www.standardstrack.com/ietf/lemonade > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed May 09 09:35:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlmJx-0001ef-V8; Wed, 09 May 2007 09:35:09 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HlmJw-0001dL-EF for lemonade-confirm+ok@megatron.ietf.org; Wed, 09 May 2007 09:35:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlmJw-0001cn-1z for lemonade@ietf.org; Wed, 09 May 2007 09:35:08 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlmIP-0007I9-JR for lemonade@ietf.org; Wed, 09 May 2007 09:33:34 -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 ; Wed, 9 May 2007 14:33:29 +0100 Message-ID: <4641CD6B.7080601@isode.com> Date: Wed, 09 May 2007 14:32:27 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randall Gellens 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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: lemonade@ietf.org Subject: [lemonade] Re: Updated msgevents Draft to -02 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 Randy, I have one more comment: >3. Event Model > >[[anchor9: Should event names follow a pattern of ? >For example, should "AppendMessage" be "MessageAppend"?]] I slightly prefer consistent naming, but frankly I don't care much one way or another. If we are going to rename events, we need to make this very soon, so that other documents can be brought in sync (in particular IMAP NOTIFY) before being last called. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed May 09 15:50:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlsAr-0003Od-Hl; Wed, 09 May 2007 15:50:09 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HlsAl-0003NX-3N for lemonade-confirm+ok@megatron.ietf.org; Wed, 09 May 2007 15:50:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlsAk-0003NC-NQ; Wed, 09 May 2007 15:50:02 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlsAk-0005lY-EG; Wed, 09 May 2007 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 64CA3329DF; Wed, 9 May 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HlsAk-0002Hs-8S; Wed, 09 May 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 09 May 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-msgevent-02.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to Support Diverse Service Environments Working Group of the IETF. Title : Internet Message Store Events Author(s) : R. Gellens, C. Newman Filename : draft-ietf-lemonade-msgevent-02.txt Pages : 19 Date : 2007-5-9 One of the missing features in the existing Internet mail and messaging standards is a facility for server-to-server and server-to- client event notifications related to message store events. As the scope of Internet mail expands to support more diverse media (such as voice mail), devices (such as cell phones) and to provide rich interactions with other services (such as web portals and legal compliance systems), the need for an interoperable notification system increases. This document attempts to enumerate the types of events which interest real-world consumers of such a system. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-msgevent-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-msgevent-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-msgevent-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-5-9133307.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-msgevent-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-msgevent-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-9133307.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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --NextPart-- From lemonade-bounces@ietf.org Wed May 09 15:50:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlsBR-0004j9-ET; Wed, 09 May 2007 15:50:45 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HlsBF-0004Zh-B0 for lemonade-confirm+ok@megatron.ietf.org; Wed, 09 May 2007 15:50:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlsBE-0004ZQ-UG; Wed, 09 May 2007 15:50:32 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HlsBE-0000H1-IE; Wed, 09 May 2007 15:50:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 7C5472ACF5; Wed, 9 May 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HlsAk-0002Hp-7n; Wed, 09 May 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 09 May 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-deployments-07.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to Support Diverse Service Environments Working Group of the IETF. Title : Deployment Considerations for lemonade-compliant Mobile Email Author(s) : R. Gellens Filename : draft-ietf-lemonade-deployments-07.txt Pages : 13 Date : 2007-5-9 This document discusses deployment issues and describes requirements for successful deployment of mobile email which are implicit in the IETF lemonade documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-deployments-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-deployments-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-deployments-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-5-9133010.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-deployments-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-deployments-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-9133010.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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --NextPart-- From lemonade-bounces@ietf.org Thu May 10 04:33:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm457-0000KZ-UK; Thu, 10 May 2007 04:33:01 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hm456-0000KT-Rk for lemonade-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 04:33:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm456-0000K8-FQ for lemonade@ietf.org; Thu, 10 May 2007 04:33:00 -0400 Received: from noware.co.uk ([82.153.134.193] helo=mail.noware.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm455-0005f7-4B for lemonade@ietf.org; Thu, 10 May 2007 04:33:00 -0400 Received: by mail.noware.co.uk (Postfix, from userid 1008) id 7126936EC; Thu, 10 May 2007 09:26:24 +0100 (BST) X-CMAE-Analysis: v=1.0 c=1 a=k3vNDPZ0RJrcPCaCAAMA:9 a=fZHJ85j8vEiDqebX94UA:7 a=cPHKHY6NZEevTcbOopKn7-lhEqYA:4 Received: from [192.168.0.111] (noware.co.uk [82.153.134.193]) by mail.noware.co.uk (Postfix) with ESMTP id EBDC936EC; Thu, 10 May 2007 09:26:18 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Neil Cook Date: Thu, 10 May 2007 09:32:51 +0100 To: Enhancements to Internet email to support diverse service enivronments X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Mark Crispin , Alexey Melnikov Subject: [lemonade] Extend URLAUTH to fetch MIME data for bodyparts? X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org All, the current version of the streaming draft has got a problem, in that, given a piece of MIME content stored in a message, and an IMAP URL to that bodypart that must be retrieved using URLFETCH, the client given the URL does not know: 1) The Content-Type of the bodypart to be fetched 2) The Content-Transfer-Encoding of the bodypart to be fetched To fix this entails the streaming draft recommending updates to two other RFCs (4240 and 4722) which specify the ability to pass Content- Type and Content-Transfer-Encoding data to media servers supporting these protocols. Now there has been a small amount of discussion in this group on how to achieve that without updating those protocols. I've been thinking about it, and it seems to me that the best (and most generic) fix would be to update the URLAUTH RFC to include an option that specifies that the MIME data associated with the bodypart should be returned. This could be an option to the existing URLFETCH command, e.g. a1 MIME URLFETCH "imap://joe@example.com/INBOX/;uid=20/ ;section=1.2;urlauth=submit+fred:internal :91354a473744909de610943775f92038" That would return the MIME headers associated with that bodypart along with the bodypart itself. or, perhaps better, to create a new command that retrieve only the MIME data associated with the bodypart, e.g. a2 URLFETCHMIME "imap://joe@example.com/INBOX/;uid=20/ ;section=1.2;urlauth=submit+fred:internal :91354a473744909de610943775f92038" I think this would be generally useful in the future to other applications that make use of URLAUTH, as it cannot be presumed that they know in advance the content-type or c-t-e when they have just been passed an IMAP URL. Comments? Neil. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu May 10 04:52:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm4NW-0003ft-8L; Thu, 10 May 2007 04:52:02 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hm4NV-0003fo-Ug for lemonade-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 04:52:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm4NV-0003fg-Kg for lemonade@ietf.org; Thu, 10 May 2007 04:52:01 -0400 Received: from [2001:838:378:0:2a0:d2ff:fe1b:110f] (helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm4NT-0008DQ-Oz for lemonade@ietf.org; Thu, 10 May 2007 04:52:01 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id B0CC8498006 for ; Thu, 10 May 2007 09:51: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 15513-09 for ; Thu, 10 May 2007 09:51:56 +0100 (BST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:838:378:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 80D7B498005 for ; Thu, 10 May 2007 09:51:56 +0100 (BST) Subject: Re: [lemonade] Extend URLAUTH to fetch MIME data for bodyparts? References: In-Reply-To: MIME-Version: 1.0 Message-Id: <14903.1178787116.488136@peirce.dave.cridland.net> Date: Thu, 10 May 2007 09:51:56 +0100 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: Debian amavisd-new at turner.dave.cridland.net X-Spam-Score: -2.8 (--) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 May 10 09:32:51 2007, Neil Cook wrote: > Now there has been a small amount of discussion in this group on > how to achieve that without updating those protocols. I've been > thinking about it, and it seems to me that the best (and most > generic) fix would be to update the URLAUTH RFC to include an > option that specifies that the MIME data associated with the > bodypart should be returned. > > You can, of course, pass a URL to the MIME header of the part. That's doable, but it means passing two URLs to the consumer. Otherwise, I'd personally be more interested in decoding the CTE at source (like BINARY does), and then appending a BODYSTRUCTURE fragment (or similar) describing MIME headers. For example: url-full = url-simple / url-extended ; Changed from RFC4467 url-simple = astring ; Containing authimapurlfull url-extended = "(" url-simple *(SP url-additional) ")" url-additional = "STRUCTURE" / "BINARY" / iana-token urlfetch-data = "*" SP "URLFETCH" 1*(SP url-simple [SP "(" url-additional SP stuff ")"] SP nstring) Now we have the syntactic glue, we can do: C: D01 URLFETCH ("imap://[...]" STRUCTURE BINARY) S: * URLFETCH "imap://[...]" (STRUCTURE ("audio" "mp3" [...])) {~1234} S: [1234 octets of binary data, containing NUL octets] S: D01 OK Completed Does this seem reasonable? I think it gets the streaming servers what they need (and at lower impact, since presumably they never had to deal with CTE before). 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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu May 10 07:05:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm6Sg-0005Jv-IV; Thu, 10 May 2007 07:05:30 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hm6Sf-0005Jq-CQ for lemonade-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 07:05:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm6Sf-0005Ji-2o for lemonade@ietf.org; Thu, 10 May 2007 07:05:29 -0400 Received: from noware.co.uk ([82.153.134.193] helo=mail.noware.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm6Sd-0001Re-Gl for lemonade@ietf.org; Thu, 10 May 2007 07:05:29 -0400 Received: by mail.noware.co.uk (Postfix, from userid 1008) id CE28337B3; Thu, 10 May 2007 11:58:52 +0100 (BST) X-CMAE-Analysis: v=1.0 c=1 a=KWikpAkKAAAA:8 a=48vgC7mUAAAA:8 a=bfLuiRfvAAAA:8 a=mjAbWKXCTECz1lwAGbQA:9 a=Y1mpE3KigAs72KIzbKMA:7 a=xE8zCyERFSmN8Mt7AZRoiFQ4qroA:4 Received: from [192.168.0.111] (noware.co.uk [82.153.134.193]) by mail.noware.co.uk (Postfix) with ESMTP id CF26036EC; Thu, 10 May 2007 11:58:51 +0100 (BST) In-Reply-To: <14903.1178787116.488136@peirce.dave.cridland.net> References: <14903.1178787116.488136@peirce.dave.cridland.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <25AE0E2A-D0FD-42F3-869F-CF0B9B6C4659@noware.co.uk> Content-Transfer-Encoding: 7bit From: Neil Cook Subject: Re: [lemonade] Extend URLAUTH to fetch MIME data for bodyparts? Date: Thu, 10 May 2007 12:05:24 +0100 To: Dave Cridland X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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, that seems reasonable to me. Presumably if you did the fetch without specifying binary, you'd get the CTE in the BODYSTRUCTURE,and could thus decode it manually? BTW, I think media servers are probably already used to dealing with CTE, as they can already handle HTTP URLs, which may or may not refer to c-t-e content. However, being able to download the content without CTE is definitely a big plus imo. Neil. On 10 May 2007, at 09:51, Dave Cridland wrote: > On Thu May 10 09:32:51 2007, Neil Cook wrote: >> Now there has been a small amount of discussion in this group on >> how to achieve that without updating those protocols. I've been >> thinking about it, and it seems to me that the best (and most >> generic) fix would be to update the URLAUTH RFC to include an >> option that specifies that the MIME data associated with the >> bodypart should be returned. > You can, of course, pass a URL to the MIME header of the part. > That's doable, but it means passing two URLs to the consumer. > > Otherwise, I'd personally be more interested in decoding the CTE at > source (like BINARY does), and then appending a BODYSTRUCTURE > fragment (or similar) describing MIME headers. > > For example: > > url-full = url-simple / url-extended > ; Changed from RFC4467 > url-simple = astring > ; Containing authimapurlfull > url-extended = "(" url-simple *(SP url-additional) ")" > url-additional = "STRUCTURE" / "BINARY" / iana-token > urlfetch-data = "*" SP "URLFETCH" 1*(SP url-simple [SP "(" url- > additional SP stuff ")"] > SP nstring) > > Now we have the syntactic glue, we can do: > > C: D01 URLFETCH ("imap://[...]" STRUCTURE BINARY) > S: * URLFETCH "imap://[...]" (STRUCTURE ("audio" "mp3" [...])) {~1234} > S: [1234 octets of binary data, containing NUL octets] > S: D01 OK Completed > > Does this seem reasonable? I think it gets the streaming servers > what they need (and at lower impact, since presumably they never > had to deal with CTE before). > > 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 > Supplemental Web Site: > http://www.standardstrack.com/ietf/lemonade > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu May 10 07:25:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm6m3-0007gp-7k; Thu, 10 May 2007 07:25:31 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hm6m1-0007bO-EO for lemonade-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 07:25:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm6m1-0007ap-3p for lemonade@ietf.org; Thu, 10 May 2007 07:25:29 -0400 Received: from [2001:838:378:0:2a0:d2ff:fe1b:110f] (helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm6lz-0005DN-Fz for lemonade@ietf.org; Thu, 10 May 2007 07:25:29 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 8809A498005; Thu, 10 May 2007 12:25:26 +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 16709-07; Thu, 10 May 2007 12:25:25 +0100 (BST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:838:378:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 073DA498003; Thu, 10 May 2007 12:25:25 +0100 (BST) Subject: Re: [lemonade] Extend URLAUTH to fetch MIME data for bodyparts? References: <14903.1178787116.488136@peirce.dave.cridland.net> <25AE0E2A-D0FD-42F3-869F-CF0B9B6C4659@noware.co.uk> In-Reply-To: <25AE0E2A-D0FD-42F3-869F-CF0B9B6C4659@noware.co.uk> MIME-Version: 1.0 Message-Id: <14903.1178796325.024009@peirce.dave.cridland.net> Date: Thu, 10 May 2007 12:25:25 +0100 From: Dave Cridland To: Neil Cook Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: Debian amavisd-new at turner.dave.cridland.net X-Spam-Score: -2.8 (--) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 May 10 12:05:24 2007, Neil Cook wrote: > Presumably if you did the fetch without specifying binary, you'd > get the CTE in the BODYSTRUCTURE,and could thus decode it manually? > > Probably we could define that, yes. To be honest, I'd be inclined to aim for just type information, and tell people to use BINARY. The alternative would be to wrap up the binary into the URI, but I don't see the need - I think it's quite complex enough to parse IMAP URIs without making life even harder for us. Something that might be worthwhile would be allowing CATENATE and BURL to handle additional directives. That and a CONVERT-like directive would allow clients to construct multipart/alternative messages quite easily. > BTW, I think media servers are probably already used to dealing > with CTE, as they can already handle HTTP URLs, which may or may > not refer to c-t-e content. However, being able to download the > content without CTE is definitely a big plus imo. > > I was under the impression that HTTP doesn't have CTE, technically - it has TE, which is different. Transfer-Encoding is usually payload compression, whereas Content-Transfer-Encoding is solely to make things fit into a (possibly 7-bit) text domain. 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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu May 10 10:31:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm9gI-0003k3-CK; Thu, 10 May 2007 10:31:46 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hm9gH-0003jX-76 for lemonade-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 10:31:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm9gG-0003jJ-TW for lemonade@ietf.org; Thu, 10 May 2007 10:31:44 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm9gF-0001xB-Fm for lemonade@ietf.org; Thu, 10 May 2007 10:31:44 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4AEVfvA004094 for ; Thu, 10 May 2007 07:31:41 -0700 Received: from rcpbex01.amer.bea.com (repbex01.bea.com [10.168.26.17] (may be forged)) by repmmr01.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4AEVdwr027159 for ; Thu, 10 May 2007 07:31:40 -0700 Received: from 10.40.8.35 ([10.40.8.35]) by rcpbex01.amer.bea.com ([10.168.26.17]) with Microsoft Exchange Server HTTP-DAV ; Thu, 10 May 2007 14:32:28 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 10 May 2007 10:31:38 -0400 From: Eric Burger To: Message-ID: Thread-Topic: Interim Next Week Thread-Index: AceTD+sDKXlBvf8DEduvWwAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [lemonade] Interim Next Week X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 have updated the supplemental web site, http://www.standardstrack.com/ietf/lemonade/ with updated information on the hotel and Thursday start time. Glenn and I are staying at the Hilton Toronto Airport. The upside is it is a Hilton and very close to the airport. The downside is that it is NOT walking distance to the venue, but it is a short taxi ride. For CDN 12 extra per night you can stay at the Courtyard, which is walking distance. Do note the Nortel (Hilton) and BEA (Courtyard) rates are significantly lower than the web rates. Nortel is host for dinner; that will most likely be a taxi ride, but we can share. The start time on Thursday is 9am. Although that is still 6am for the North American West-Coasters, we do not want the session to eat in to Europe's dinner too much [sic]. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri May 11 07:05:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmSvo-0003x0-C0; Fri, 11 May 2007 07:05:04 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HmSvn-0003wv-Ee for lemonade-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 07:05:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmSvk-0003wg-4x for lemonade@ietf.org; Fri, 11 May 2007 07:05:00 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmSvi-00077Q-O7 for lemonade@ietf.org; Fri, 11 May 2007 07:05:00 -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, 11 May 2007 12:04:49 +0100 Message-ID: <4642F601.2070808@isode.com> Date: Thu, 10 May 2007 11:37:53 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Zoltan.Ordogh@nokia.com Subject: Re: [lemonade] CONVERT: .STRICT specifier (again) References: <4634A134.6030508@isode.com> <4C38DC11F6B4FF4FAEA73E30DB5AA1577972B9@esebe199.NOE.Nokia.com> In-Reply-To: <4C38DC11F6B4FF4FAEA73E30DB5AA1577972B9@esebe199.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) 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 Zoltan.Ordogh@nokia.com wrote: >We removed SERVEROVERRIDE. > >I think removing .STRICT is pretty much the same argument. > > I think the draft used .STRICT to mean different things in different cases. One was to prevent SERVEROVERRIDE, especially substitution of MIME type. The MIME type substitution is disallowed in the latest version, unless the client explicitly requests the default conversion. Another use of .STRICT is to specify that conversion parameters are not optional. Imagine a client that would prefer that the target image has width X, but can cope with the case when the server ignores the width parameter, but otherwise perform the request. Do we want to be able to optimize for this case? Without .STRICT (i.e. it is always implied) the client will have to issue the first conversion request with WIDTH. This conversion request will fail because the server can't comply. Then the client will have to reissue the request without WIDTH. So the absence of .STRICT will allow for this optimization. Another way of doing optional conversion parameters would be to remove .STRICT, but to allow for "optional." prefix in parameter names. I.e. "optional.width" would mean that the width parameter is option. This would actually be more flexible than "all or nothing" approach required by .STRICT. >>-----Original Message----- >>From: ext Alexey Melnikov [mailto:alexey.melnikov@isode.com] >>Sent: 29 April, 2007 16:44 >>To: Lemonade WG >>Subject: [lemonade] CONVERT: .STRICT specifier (again) >> >>I am somewhat hesitating to remove .STRICT specifier. Are >>there any cases when the client would like to specify a >>transcoding parameter that can be ignored by the server? >> >> _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri May 11 09:33:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmVF4-0000b0-Lk; Fri, 11 May 2007 09:33:06 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HmVF2-0000ai-SR for lemonade-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 09:33:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmVF2-0000aa-Ir for lemonade@ietf.org; Fri, 11 May 2007 09:33:04 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmVF1-00025F-NC for lemonade@ietf.org; Fri, 11 May 2007 09:33:04 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4BDWrre023443; Fri, 11 May 2007 16:33:01 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 May 2007 16:32:56 +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 May 2007 16:32:56 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] CONVERT: .STRICT specifier (again) Date: Fri, 11 May 2007 16:32:58 +0300 Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA1577D20B3@esebe199.NOE.Nokia.com> In-Reply-To: <4642F601.2070808@isode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] CONVERT: .STRICT specifier (again) Thread-Index: AceTvDYPlEgaeg61TdKOJB2HETaVAAAEnXsA References: <4634A134.6030508@isode.com> <4C38DC11F6B4FF4FAEA73E30DB5AA1577972B9@esebe199.NOE.Nokia.com> <4642F601.2070808@isode.com> From: To: X-OriginalArrivalTime: 11 May 2007 13:32:56.0664 (UTC) FILETIME=[E28BC580:01C793D0] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 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 Alexey, my preference would be to always assume "STRICT": I am the client and I = know what I want because I know what I am capable of. Either give it to = me, or let's forget the whole thing (get error). The only time I would leave the choice up the the server is when the = client wants "default" conversion - leaving all conversion parameters to = the server - however this is a different story. For example: I am a simple client, I show what I get (no scrolling or zooming). The = display is 400*300, so I request conversion to 400*300. Now, if the = server gave me anything else than this, I can't show the image properly = since I do not have scrolling, or zooming facilities. There is one useful option for keeping .STRICT. For example, I get an = 1600*1000 picture, and I want to show it on a 400*300 display. So I = request the server to convert this to 400*300 and do not specify = .STRICT. The server is allowed to change a parameter, so it will give me = a 400*250 picture (keeping the original aspect ratio). Question is: will this be used in the future? I mean clients are getting = better and better, so they should be able to handle such exceptions. = Also, which parameters are the servers allowed to override? (I meam if I = want MP3, I would not want a WAV instead). Assuming always strict and indicating "optional" would be better. Any thoughts? 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 Alexey Melnikov [mailto:alexey.melnikov@isode.com]=20 >Sent: 10 May, 2007 13:38 >To: Ordogh Zoltan (Nokia-TP-MSW/Tampere) >Cc: lemonade@ietf.org >Subject: Re: [lemonade] CONVERT: .STRICT specifier (again) > >Zoltan.Ordogh@nokia.com wrote: > >>We removed SERVEROVERRIDE. >> >>I think removing .STRICT is pretty much the same argument. >> =20 >> >I think the draft used .STRICT to mean different things in=20 >different cases. > >One was to prevent SERVEROVERRIDE, especially substitution of=20 >MIME type.=20 >The MIME type substitution is disallowed in the latest=20 >version, unless the client explicitly requests the default conversion. > >Another use of .STRICT is to specify that conversion=20 >parameters are not optional. Imagine a client that would=20 >prefer that the target image has width X, but can cope with=20 >the case when the server ignores the width parameter, but=20 >otherwise perform the request. Do we want to be able to=20 >optimize for this case? > >Without .STRICT (i.e. it is always implied) the client will=20 >have to issue the first conversion request with WIDTH. This=20 >conversion request will fail because the server can't comply.=20 >Then the client will have to reissue the request without WIDTH. >So the absence of .STRICT will allow for this optimization. > >Another way of doing optional conversion parameters would be=20 >to remove .STRICT, but to allow for "optional." prefix in=20 >parameter names. I.e.=20 >"optional.width" would mean that the width parameter is=20 >option. This would actually be more flexible than "all or=20 >nothing" approach required by .STRICT. > >>>-----Original Message----- >>>From: ext Alexey Melnikov [mailto:alexey.melnikov@isode.com] >>>Sent: 29 April, 2007 16:44 >>>To: Lemonade WG >>>Subject: [lemonade] CONVERT: .STRICT specifier (again) >>> >>>I am somewhat hesitating to remove .STRICT specifier. Are there any=20 >>>cases when the client would like to specify a transcoding parameter=20 >>>that can be ignored by the server? >>> =20 >>> > > > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri May 11 14:30:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmZsv-0001n8-4Y; Fri, 11 May 2007 14:30:33 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HmZst-0001kr-N0 for lemonade-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 14:30:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmZst-0001j1-D0 for lemonade@ietf.org; Fri, 11 May 2007 14:30:31 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmZss-0008Jk-0n for lemonade@ietf.org; Fri, 11 May 2007 14:30:31 -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, 11 May 2007 19:30:27 +0100 Message-ID: <4644B603.4070305@isode.com> Date: Fri, 11 May 2007 19:29:23 +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: Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] Treat as WGLC: draft-cridland-imap-context-01.txt References: <13829.1177506908.404308@peirce.dave.cridland.net> <462F56A3.3000006@isode.com> In-Reply-To: <462F56A3.3000006@isode.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: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 wrote: > Dave Cridland wrote: > >> Network Working Group D. Cridland >> Internet-Draft C. King >> Expires: October 27, 2007 Isode Limited >> April 25, 2007 >> >> >> Contexts for IMAP4 >> draft-cridland-imap-context > > Work Group Last Call closes on 11 May 2007. > > If you chose to send private comments, please don't forget to CC them > to me, so that I can keep track of issues in the document. The WGLC is ending today. If you've reviewed the document and found no issues, please let me know. So far it seems that everybody who reviewed the document is happy with this. If this continue to be the case, I will request publication of the document. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri May 11 15:13:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmaY4-0001lV-72; Fri, 11 May 2007 15:13:04 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HmaY2-0001lQ-N2 for lemonade-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 15:13:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmaY2-0001lI-Db for lemonade@ietf.org; Fri, 11 May 2007 15:13:02 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmaY1-0004yG-1u for lemonade@ietf.org; Fri, 11 May 2007 15:13: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, 11 May 2007 20:12:59 +0100 Message-ID: <4644BFFB.4020807@isode.com> Date: Fri, 11 May 2007 20:11:55 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] Treat as WGLC: draft-cridland-imap-context-01.txt References: <13829.1177506908.404308@peirce.dave.cridland.net> <462F56A3.3000006@isode.com> <4644B603.4070305@isode.com> In-Reply-To: <4644B603.4070305@isode.com> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Some minor comments on -01: 3.3.2. REMOVEFROM Return Data Item C: B03 SEARCH RETURN () 1:* ALL I think "UPDATE ALL" is missing from the (). Also, the command should be UID SEARCH, as the second ESEARCH response below includes the UID tag: S: * ESEARCH (TAG "B03") ALL 1:49152 S: * ESEARCH (TAG "B01") UID REMOVEFROM 32768 S: B03 OK Search completed. In section 4: ret-data-removefrom = "REMOVEFROM" sequence-set ;; from [IMAP] SP is missing before the sequence-set _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon May 14 05:48:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnXAK-0006Nd-Q5; Mon, 14 May 2007 05:48:28 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HnXAJ-0006NU-T8 for lemonade-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 05:48:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnXAJ-0006NM-JS for lemonade@ietf.org; Mon, 14 May 2007 05:48:27 -0400 Received: from noware.co.uk ([82.153.134.193] helo=mail.noware.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnXAI-0000Gm-4q for lemonade@ietf.org; Mon, 14 May 2007 05:48:27 -0400 Received: by mail.noware.co.uk (Postfix, from userid 1008) id 7CBE437B3; Mon, 14 May 2007 10:41:37 +0100 (BST) X-CMAE-Analysis: v=1.0 c=1 a=KWikpAkKAAAA:8 a=WzEyV7uBzynE8g8x_NYA:9 a=Fgyh9rCTiDWp7TIynhcA:7 a=dg-wNVeiuSo24qB5UnB3YRWoCxUA:4 Received: from [192.168.0.111] (noware.co.uk [82.153.134.193]) by mail.noware.co.uk (Postfix) with ESMTP id 96B8D36EC; Mon, 14 May 2007 10:41:36 +0100 (BST) In-Reply-To: <14903.1178796325.024009@peirce.dave.cridland.net> References: <14903.1178787116.488136@peirce.dave.cridland.net> <25AE0E2A-D0FD-42F3-869F-CF0B9B6C4659@noware.co.uk> <14903.1178796325.024009@peirce.dave.cridland.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <68837EB4-8FCD-401E-B685-C54D6509CEF8@noware.co.uk> Content-Transfer-Encoding: 7bit From: Neil Cook Subject: Re: [lemonade] Extend URLAUTH to fetch MIME data for bodyparts? Date: Mon, 14 May 2007 10:48:15 +0100 To: Dave Cridland X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 Thanks Dave, You're right about HTTP TE, but of course HTTP may contain MIME parts, however I think practice there isn't that much CTE in HTTP. Anyway, do you know what the next step is? How do I formally propose that we update URLAUTH with this new functionality? Neil. On 10 May 2007, at 12:25, Dave Cridland wrote: > On Thu May 10 12:05:24 2007, Neil Cook wrote: >> Presumably if you did the fetch without specifying binary, you'd >> get the CTE in the BODYSTRUCTURE,and could thus decode it manually? > Probably we could define that, yes. To be honest, I'd be inclined > to aim for just type information, and tell people to use BINARY. > > The alternative would be to wrap up the binary into the URI, but I > don't see the need - I think it's quite complex enough to parse > IMAP URIs without making life even harder for us. > > Something that might be worthwhile would be allowing CATENATE and > BURL to handle additional directives. That and a CONVERT-like > directive would allow clients to construct multipart/alternative > messages quite easily. > > >> BTW, I think media servers are probably already used to dealing >> with CTE, as they can already handle HTTP URLs, which may or may >> not refer to c-t-e content. However, being able to download the >> content without CTE is definitely a big plus imo. > I was under the impression that HTTP doesn't have CTE, technically > - it has TE, which is different. Transfer-Encoding is usually > payload compression, whereas Content-Transfer-Encoding is solely to > make things fit into a (possibly 7-bit) text domain. > > 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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon May 14 06:13:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnXYg-0004Bo-No; Mon, 14 May 2007 06:13:38 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HnXYf-0004Bj-Oo for lemonade-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 06:13:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnXYf-0004Bb-F8 for lemonade@ietf.org; Mon, 14 May 2007 06:13:37 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnXYe-0006NV-Q6 for lemonade@ietf.org; Mon, 14 May 2007 06:13:37 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4EADRhJ017081; Mon, 14 May 2007 13:13:32 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 May 2007 13:13:24 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 May 2007 13:13:18 +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] Updated Draft: draft-cridland-imap-context Date: Mon, 14 May 2007 13:13:19 +0300 Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA157812F7D@esebe199.NOE.Nokia.com> In-Reply-To: <13829.1177506908.404308@peirce.dave.cridland.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Updated Draft: draft-cridland-imap-context Thread-Index: AceHO8u0SXjzF0F0S76DDuT8tTFKpwK1vDhA References: <13829.1177506908.404308@peirce.dave.cridland.net> From: To: X-OriginalArrivalTime: 14 May 2007 10:13:18.0545 (UTC) FILETIME=[7E451C10:01C79610] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c 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, here are my comments: Section 2. " Although the basic SEARCH command defined in [IMAP], as enhanced by [ESEARCH], is relatively compact in its representation, this reduction only saves a certain amount of data, and huge mailboxes can overwhelm the storage available for results on even relatively high- end desktop machines." 1. "as enhanced by" -> "and enhanced by" ? 2. "this reduction only saves" -> "the reduction saves only" ? 3. "and huge mailboxes can" -> "therefore huge mailboxes might" ? 4. "for results on even relatively high-end desktop machines." -> "for = results. This extension reduces the amount of data to be sent by = providing a windowing facility for the search results." ? Section 3.3 5. So far the extension is not clear about the notification used (IDLE = is shown in the examples). Does this extension require IDLE or NOTIFY? = If so, which? I would suggest updating all examples showing IDLE to = NOTIFY instead and require NOTIFY as mandatory. 6. "The search return option UPDATE, if used by a client, causes the = server to ..." Should we make it mandatory? At least I would not want to see a client = that supports notifications (IDLE/NOTIFY will be in all LEMONADE clients = anyway) but cannot coop with search result updates. Server and client = will get seriously out of sync without notifications, so when the client = requests a next window, some results might be displayed again (when new = results have been inserted before the current window) and some might be = missed as well (when obsolete results have been removed before the = current window). Section 3.3.1 7. What exactly does the ADDTO Return Data Item contain? It seems to me = that the client will only get position and UID. Does it mean that the = client will have to fetch all data (sender, subject, - well, the header) = for each email "inserted"? Also, I did not find description, about how the addition works. Here is = my assumption, please consider adding something like this: The new = result is to be inserted at the given position; meaning that the new = result will occupy the indicated position and all results starting from = that position are shifted to the next position. The client MUST updated = the position numbers of the shifted results. The ADDTO Return Data Item = MAY include several new results to be insterted - therefore it is = imporant to note that the positions included in a single ADDTO Return = Data Item contain positions before the shifting due to other new results = take place. (If the recieved ADDTO new results were sorted descending, = by position, it would be very easy). Also, something similar to = REMOVEFROM (3.3.2) should be added. 8. "The results are specified as UIDs or message numbers, ..." What does 'results' mean here? My guess would be the search results on = the client (and not the new results to be added). Would it be possible = to use another term for the new/obsolete (see 3.3.2 as well) results? Section 3.3.2 (3.3.1 is relevant as well). 9. "Servers SHOULD sort the results in order to use the sequence-set = syntax as efficiently as possible." Sort by ... (what? UID, date, sender, subject, priority, etc)? (Sorry, I = am not familiar with SORT). Should we make this mandatory (that the list = MUST be sorted)? 10. Are the ADDTO/REMOVEFROM Return Data Items to be sorted as well? = (There was nothing about this in 3.3.1 or 3.3.2.) 11. "There is no requirement on servers to avoid issuing REMOVEFROM = return data at any particular moment, in particular this is distinct = from EXPUNGE responses." What does it mean in practice? Would it be better to state the server = must (should?) send update on EXPUNGE (or on new email arrival -> = section 3.3.1), should (may) on any other event (of course only when an = email is involved in our current search)? 12. Looking at the questions above I think these should be a general = description (that is valid for both ADDTO and REMOVEFROM) about the = updates in section 3.3. I mean some things that are described in 3.3.2 = are not described in 3.3.1. Section 3.4 13. "The subset of results are returned in sequence-set syntax, and = servers SHOULD order results from a SEARCH for maximum efficiency." This is is an amost identical duplicate of the sentence in 3.3.2 = paragraph 1. Should one be removed (I understand UPDATE and PARTIAL are = both optional, but still...) Same questions regarding this question - see comment #9. Section A.1. 14. CONTEXT is a replacement for VFOLDER. VFOLDER had the advantage of = re-using virtual folders: I could easily create new virtual folders from = virtual folders, and altering one virtual folder in the "path" would = alter all "child" virtual folders. It appears (or, I missed something) = that it is no longer possible using this extension. Section A.2. 15. This is useful, but it would be nice to tell that it is also = possible to "leave out" trashed messaged from the inbox - by using an = inverted search for \Deleted. Section A.3. 16. "It is entirely possible to simultaneously have two or more UPDATE = searches in operation." No PARTIAL? Additonal question that I did not find an answer for: What happens when I search without sorting, get a list of results, start = windowing, cannot find what I am looking for so I decide to sort the = results (or, change the basis for sorting)? I get REMOVEFROM removing = everything from my view and I get an ADDTO to re-fill my view? Will I = see blinking (most likely all positions and UIDs will be messed up). = What happens in the same case if I do not support UPDATE (I proposed to = make it mandatory above, but it is not yet mandatory). Thank You - and sorry about the delay with the review. Hopefully still = in time for the interim... 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: 25 April, 2007 16:15 >To: Internet-Drafts@ietf.org >Cc: Enhancements to Internet email to support diverse service=20 >enivronments >Subject: [lemonade] Updated Draft: draft-cridland-imap-context > >This is draft-cridland-imap-context-01.txt > >Thanks. >-- >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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon May 14 08:15:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnZSL-0001bU-5H; Mon, 14 May 2007 08:15:13 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HnZSJ-0001bM-Pd for lemonade-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 08:15:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnZSJ-0001bE-Fu for lemonade@ietf.org; Mon, 14 May 2007 08:15:11 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnZSG-0002fx-62 for lemonade@ietf.org; Mon, 14 May 2007 08:15:11 -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 ; Mon, 14 May 2007 13:15:07 +0100 Message-ID: <46485289.6000607@isode.com> Date: Mon, 14 May 2007 13:14:01 +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: Neil Cook Subject: Re: [lemonade] Extend URLAUTH to fetch MIME data for bodyparts? References: <14903.1178787116.488136@peirce.dave.cridland.net> <25AE0E2A-D0FD-42F3-869F-CF0B9B6C4659@noware.co.uk> <14903.1178796325.024009@peirce.dave.cridland.net> <68837EB4-8FCD-401E-B685-C54D6509CEF8@noware.co.uk> In-Reply-To: <68837EB4-8FCD-401E-B685-C54D6509CEF8@noware.co.uk> 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: 08e48e05374109708c00c6208b534009 Cc: support diverse service enivronments , Enhancements X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Neil Cook wrote: > Anyway, do you know what the next step is? How do I formally propose > that we update URLAUTH with this new functionality? Somebody needs to write a new (short) draft extending URLAUTH. Any volunteers? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon May 14 12:23:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HndL1-0006bC-E8; Mon, 14 May 2007 12:23:55 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HndKz-0006aa-Nf for lemonade-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 12:23:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HndKz-0006aN-Dj for lemonade@ietf.org; Mon, 14 May 2007 12:23:53 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HndKx-00041y-Ti for lemonade@ietf.org; Mon, 14 May 2007 12:23:53 -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 ; Mon, 14 May 2007 17:23:46 +0100 Message-ID: <46488CD1.2020308@isode.com> Date: Mon, 14 May 2007 17:22: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] Updated Draft: draft-cridland-imap-context References: <13829.1177506908.404308@peirce.dave.cridland.net> <4C38DC11F6B4FF4FAEA73E30DB5AA157812F7D@esebe199.NOE.Nokia.com> In-Reply-To: <4C38DC11F6B4FF4FAEA73E30DB5AA157812F7D@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: 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 Zoltan, Thanks for the detailed comments. Some comments below. Zoltan.Ordogh@nokia.com wrote: >6. "The search return option UPDATE, if used by a client, causes the server to ..." >Should we make it mandatory? > Mandatory for clients to use? > At least I would not want to see a client that supports notifications (IDLE/NOTIFY will be in all LEMONADE clients anyway) but cannot coop with search result updates. Server and client will get seriously out of sync without notifications, so when the client requests a next window, some results might be displayed again (when new results have been inserted before the current window) and some might be missed as well (when obsolete results have been removed before the current window). > >Section 3.3.1 >7. What exactly does the ADDTO Return Data Item contain? It seems to me that the client will only get position and UID. Does it mean that the client will have to fetch all data (sender, subject, - well, the header) for each email "inserted"? > Yes. >Also, I did not find description, about how the addition works. Here is my assumption, please consider adding something like this: The new result is to be inserted at the given position; meaning that the new result will occupy the indicated position and all results starting from that position are shifted to the next position. The client MUST updated the position numbers of the shifted results. The ADDTO Return Data Item MAY include several new results to be insterted - therefore it is imporant to note that the positions included in a single ADDTO Return Data Item contain positions before the shifting due to other new results take place. > You observation is important, this needs to be described in the document. [...] >Section A.1. >14. CONTEXT is a replacement for VFOLDER. VFOLDER had the advantage of re-using virtual folders: I could easily create new virtual folders from virtual folders, and altering one virtual folder in the "path" would alter all "child" virtual folders. It appears (or, I missed something) that it is no longer possible using this extension. > This is still possible by constructing a SEARCH criterion which logically ANDs two or more SEARCH criteria. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon May 14 14:38:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnfRf-0000Wq-LH; Mon, 14 May 2007 14:38:55 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HnfRe-0000Wa-CV for lemonade-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 14:38:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnfRe-0000WR-2f for lemonade@ietf.org; Mon, 14 May 2007 14:38:54 -0400 Received: from [2001:838:378:0:2a0:d2ff:fe1b:110f] (helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnfRW-0004GD-Er for lemonade@ietf.org; Mon, 14 May 2007 14:38:54 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 34A5B498006; Mon, 14 May 2007 19:38: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 17726-06; Mon, 14 May 2007 19:38:37 +0100 (BST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:838:378:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 59218498002; Mon, 14 May 2007 19:38:37 +0100 (BST) Subject: RE: [lemonade] Updated Draft: draft-cridland-imap-context References: <13829.1177506908.404308@peirce.dave.cridland.net> <4C38DC11F6B4FF4FAEA73E30DB5AA157812F7D@esebe199.NOE.Nokia.com> In-Reply-To: <4C38DC11F6B4FF4FAEA73E30DB5AA157812F7D@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Message-Id: <30512.1179167917.106478@peirce.dave.cridland.net> Date: Mon, 14 May 2007 19:38:37 +0100 From: Dave Cridland To: "Zoltan.Ordogh@nokia.com" Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: Debian amavisd-new at turner.dave.cridland.net X-Spam-Score: -2.4 (--) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Mon May 14 11:13:19 2007, Zoltan.Ordogh@nokia.com wrote: > Hi Dave, > here are my comments: > > Thanks for the review. > Section 2. > " Although the basic SEARCH command defined in [IMAP], as > enhanced by > [ESEARCH], is relatively compact in its representation, this > reduction only saves a certain amount of data, and huge > mailboxes can > overwhelm the storage available for results on even relatively > high- > end desktop machines." > 1. "as enhanced by" -> "and enhanced by" ? > 2. "this reduction only saves" -> "the reduction saves only" ? > 3. "and huge mailboxes can" -> "therefore huge mailboxes might" ? > 4. "for results on even relatively high-end desktop machines." -> > "for results. This extension reduces the amount of data to be sent > by providing a windowing facility for the search results." ? > > I've used some of this. > Section 3.3 > 5. So far the extension is not clear about the notification used > (IDLE is shown in the examples). Does this extension require IDLE > or NOTIFY? If so, which? I would suggest updating all examples > showing IDLE to NOTIFY instead and require NOTIFY as mandatory. I've stripped IDLE from the examples, and made it clear that neither IDLE nor NOTIFY is required. (Although in practise, I'm expecting servers to send updates when they'd usually send unsolicited data, and therefore take into account IDLE, NOTIFY, etc). > 6. "The search return option UPDATE, if used by a client, causes > the server to ..." > Should we make it mandatory? At least I would not want to see a > client that supports notifications (IDLE/NOTIFY will be in all > LEMONADE clients anyway) but cannot coop with search result > updates. Server and client will get seriously out of sync without > notifications, so when the client requests a next window, some > results might be displayed again (when new results have been > inserted before the current window) and some might be missed as > well (when obsolete results have been removed before the current > window). > > Yes, clients which don't use UPDATE, but do use PARTIAL, may well get confused, depending on what they're trying to do. > Section 3.3.1 > 7. What exactly does the ADDTO Return Data Item contain? It seems > to me that the client will only get position and UID. Does it mean > that the client will have to fetch all data (sender, subject, - > well, the header) for each email "inserted"? Yes. > Also, I did not find description, about how the addition works. > Here is my assumption, please consider adding something like this: > The new result is to be inserted at the given position; meaning > that the new result will occupy the indicated position and all > results starting from that position are shifted to the next > position. The client MUST updated the position numbers of the > shifted results. The ADDTO Return Data Item MAY include several new > results to be insterted - therefore it is imporant to note that the > positions included in a single ADDTO Return Data Item contain > positions before the shifting due to other new results take place. > (If the recieved ADDTO new results were sorted descending, by > position, it would be very easy). Also, something similar to > REMOVEFROM (3.3.2) should be added. Used more or less verbatim, thanks. > 8. "The results are specified as UIDs or message numbers, ..." > What does 'results' mean here? My guess would be the search results > on the client (and not the new results to be added). Would it be > possible to use another term for the new/obsolete (see 3.3.2 as > well) results? > > I've tried to make this clearer. > Section 3.3.2 (3.3.1 is relevant as well). > 9. "Servers SHOULD sort the results in order to use the > sequence-set syntax as efficiently as possible." > Sort by ... (what? UID, date, sender, subject, priority, etc)? > (Sorry, I am not familiar with SORT). Should we make this mandatory > (that the list MUST be sorted)? The protocol is unaffected by sorting the results, but the representation is smaller if servers do. Typically, the server will issue SEARCH results in the natural order of the mailbox, which will then be easy to collapse into a compact set-syntax representation. > 10. Are the ADDTO/REMOVEFROM Return Data Items to be sorted as > well? (There was nothing about this in 3.3.1 or 3.3.2.) REMOVEFROM should be, ADDTO shouldn't - but for SEARCHes, you might as well. (It doesn't stipulate that ADDTO result updates should be sorted because it'd break SORT results). > 11. "There is no requirement on servers to avoid issuing REMOVEFROM > return data at any particular moment, in particular this is > distinct from EXPUNGE responses." > What does it mean in practice? Would it be better to state the > server must (should?) send update on EXPUNGE (or on new email > arrival -> section 3.3.1), should (may) on any other event (of > course only when an email is involved in our current search)? I added a huge great paragraph on this. Basically, servers can send a REMOVEFROM whenever they like, as with any response - with the exception of EXPUNGE, which is special. I also added an appendix noting that it's possible to use the extension to gain immediate EXPUNGE notifications whilst not losing message sequence numbering. > 12. Looking at the questions above I think these should be a > general description (that is valid for both ADDTO and REMOVEFROM) > about the updates in section 3.3. I mean some things that are > described in 3.3.2 are not described in 3.3.1. > > Added. > Section 3.4 > 13. "The subset of results are returned in sequence-set syntax, and > servers SHOULD order results from a SEARCH for maximum efficiency." > This is is an amost identical duplicate of the sentence in 3.3.2 > paragraph 1. Should one be removed (I understand UPDATE and PARTIAL > are both optional, but still...) > Same questions regarding this question - see comment #9. > > Yes, it's partly for the same reason as above, but also because SEARCH results need to be ordered consistently for PARTIAL to be useful for virtual scrollbar techniques. I've seperated these requirements into a MUST and a SHOULD. > Section A.1. > 14. CONTEXT is a replacement for VFOLDER. No, it isn't. It's an alternate mechanism for achieving similar results. Arnt (and others) will tell you, quite rightly, that VFOLDER is optimized for different cases, and covers different requirements. > VFOLDER had the advantage of re-using virtual folders: I could > easily create new virtual folders from virtual folders, and > altering one virtual folder in the "path" would alter all "child" > virtual folders. It appears (or, I missed something) that it is no > longer possible using this extension. > > Not directly. The mechanism one might use for doing this is Alexey's named filter draft, which would allow you to build composite user-defined search keys. I have no idea what the desired result of changing one used by an update context would be. However, the simplest method would be to drop the context (now possible with a FREECONTEXT command) and recreate it with the new desired search program. > Section A.2. > 15. This is useful, but it would be nice to tell that it is also > possible to "leave out" trashed messaged from the inbox - by using > an inverted search for \Deleted. > > I think it does - if you've a suggestion for how to make this clearer, I'd welcome it. > Section A.3. > 16. "It is entirely possible to simultaneously have two or more > UPDATE searches in operation." > No PARTIAL? > > That too, but the emphasis here is that there's no upper limit on update contexts. (Servers can, in -02, enforce them if they wish). > Additonal question that I did not find an answer for: > What happens when I search without sorting, get a list of results, > start windowing, cannot find what I am looking for so I decide to > sort the results (or, change the basis for sorting)? I get > REMOVEFROM removing everything from my view and I get an ADDTO to > re-fill my view? Will I see blinking (most likely all positions and > UIDs will be messed up). What happens in the same case if I do not > support UPDATE (I proposed to make it mandatory above, but it is > not yet mandatory). > > No changes to the definition of a context are possible, you'd have to drop and recreate. > Thank You - and sorry about the delay with the review. Hopefully > still in time for the interim... > > Shouldn't be a problem, I'll post the update to the list as well, shortly. (Just finishing it off now). Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon May 14 15:00:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnfmQ-0004f0-SA; Mon, 14 May 2007 15:00:22 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HnfmP-0004en-Lq for lemonade-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 15:00:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnfmP-0004ef-C6; Mon, 14 May 2007 15:00:21 -0400 Received: from [2001:838:378:0:2a0:d2ff:fe1b:110f] (helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnfmM-0006p2-FX; Mon, 14 May 2007 15:00:21 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 69737498006; Mon, 14 May 2007 20:00:15 +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 18017-02; Mon, 14 May 2007 20:00:11 +0100 (BST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:838:378:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 0FB6E498002; Mon, 14 May 2007 20:00:11 +0100 (BST) MIME-Version: 1.0 Message-Id: <30512.1179169211.052893@peirce.dave.cridland.net> Date: Mon, 14 May 2007 20:00:11 +0100 From: Dave Cridland To: Enhancements to Internet email to support diverse service enivronments , Messaging Organization Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: Debian amavisd-new at turner.dave.cridland.net X-Spam-Score: -2.8 (--) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [lemonade] Context update X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 just submitted update to my IMAP CONTEXT draft. I've put it up at http://dave.cridland.net/draft-cridland-imap-context-02.txt until it's announced. The major change is that update contexts can now be explicitly freed, and there's a response code to allow servers to refuse to honour them. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon May 14 16:19:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnh0a-0006Cl-5G; Mon, 14 May 2007 16:19:04 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hnh0X-00066D-Mb for lemonade-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 16:19:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnh0W-00065D-RI for lemonade@ietf.org; Mon, 14 May 2007 16:19:00 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hnh0W-00070Q-E2 for lemonade@ietf.org; Mon, 14 May 2007 16:19:00 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4EKIwZT026934 for ; Mon, 14 May 2007 13:18:58 -0700 Received: from rcpbex01.amer.bea.com (repbex01.bea.com [10.168.26.17] (may be forged)) by repmmr01.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4EKIq4Q015971 for ; Mon, 14 May 2007 13:18:57 -0700 Received: from 10.60.24.161 ([10.60.24.161]) by rcpbex01.amer.bea.com ([10.168.26.17]) with Microsoft Exchange Server HTTP-DAV ; Mon, 14 May 2007 20:19:48 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Mon, 14 May 2007 14:44:15 -0400 From: Eric Burger To: Message-ID: Thread-Topic: Going way out on a limb on search-within Thread-Index: AceWV97wHWPnMQJLEdyl3wAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [lemonade] Going way out on a limb on search-within X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org OK, so the #1 complaint has been that on the one hand, we do not want to allow clients to specify an arbitrarily small search interval, as that can lock-up the server. On the other hand, if the client picks an interval that is too small, the server mysteriously happens to send updates at a longer interval. Base Proposal: In the capabilities exchange, instead of saying "WITHIN", the server responds with "WITHIN=min", where min is the minimum number of seconds the server is willing to offer updates. With that information, I have two proposals for how the protocol can work. Proposal #1: If the client requests an OLDER or YOUNGER interval that is not evenly divided by the WITHIN=min specification, the server returns NO. The client knows what the server can do, so if the client asks for something else, shame on it. Proposal #2: If the client requests an OLDER or YOUNGER interval that is not evenly divided by the WITHIN=min specification, the server processes the request as if the client requested the closest interval, rounding up if the interval would fall exactly in the mid-range of the interval. If the result is zero, then we round down for YOUNGER and up for OLDER, to have the more restrictive result set. The benefit of proposal #1 is that it is exact. There is no ambiguity. The client has sufficient information to construct a user interface that presents the possible options. For example, if the server responds WITHIN=2, the client knows to only offer even intervals. Likewise, if the server responds WITHIN=30, and the user asks for OLDER 25, the client can tell the user that 25 equals 30, and the client can make the request for 30. The benefit of proposal #2 is that it is way easier on clients. In proposal #1, the user interface has to be dynamic. Either the user interface only offers intervals that are multiples of WITHIN=min or the user interface has to check the user's request is a multiple of WITHIN=min. In proposal #2, one can construct a client that does not really understand the interval, and the server will do something close to what the user requested. My personal preference is for #1, but I do not build clients. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue May 15 03:45:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnriX-0005yz-AD; Tue, 15 May 2007 03:45:09 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HnriW-0005yj-Ax for lemonade-confirm+ok@megatron.ietf.org; Tue, 15 May 2007 03:45:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnriV-0005yZ-G6 for lemonade@ietf.org; Tue, 15 May 2007 03:45:07 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnriV-0006xP-2G for lemonade@ietf.org; Tue, 15 May 2007 03:45:07 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4F7iuni008304; Tue, 15 May 2007 10:45:04 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 May 2007 10:44:56 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 May 2007 10:44:56 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Updated Draft: draft-cridland-imap-context Date: Tue, 15 May 2007 10:44:57 +0300 Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA1578135E3@esebe199.NOE.Nokia.com> In-Reply-To: <46488CD1.2020308@isode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Updated Draft: draft-cridland-imap-context Thread-Index: AceWREFFfrNSDoNlSsu2KuBescJsTAAf/SMw References: <13829.1177506908.404308@peirce.dave.cridland.net> <4C38DC11F6B4FF4FAEA73E30DB5AA157812F7D@esebe199.NOE.Nokia.com> <46488CD1.2020308@isode.com> From: To: X-OriginalArrivalTime: 15 May 2007 07:44:56.0897 (UTC) FILETIME=[EEE32B10:01C796C4] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Alexey, further comments below. (I removed the comments that I am OK with.) Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 =20 >>6. "The search return option UPDATE, if used by a client,=20 >causes the server to ..." >>Should we make it mandatory? >> >Mandatory for clients to use? For all LEMONADE clients and servers. Reasoning below. I know that the = draft is independent of LEMONADE, therefore it is not very convenient to = enforce it in this draft. >> At least I would not want to see a client that supports=20 >notifications (IDLE/NOTIFY will be in all LEMONADE clients=20 >anyway) but cannot coop with search result updates. Server and=20 >client will get seriously out of sync without notifications,=20 >so when the client requests a next window, some results might=20 >be displayed again (when new results have been inserted before=20 >the current window) and some might be missed as well (when=20 >obsolete results have been removed before the current window). >>Section A.1. >>14. CONTEXT is a replacement for VFOLDER. VFOLDER had the=20 >advantage of re-using virtual folders: I could easily create=20 >new virtual folders from virtual folders, and altering one=20 >virtual folder in the "path" would alter all "child" virtual=20 >folders. It appears (or, I missed something) that it is no=20 >longer possible using this extension. >> >This is still possible by constructing a SEARCH criterion=20 >which logically ANDs two or more SEARCH criteria. Yes, but the entire path would not exist, would it? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue May 15 03:54:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnrrH-00041Q-Bc; Tue, 15 May 2007 03:54:11 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HnrrF-00041I-Qk for lemonade-confirm+ok@megatron.ietf.org; Tue, 15 May 2007 03:54:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnrrF-000416-E9 for lemonade@ietf.org; Tue, 15 May 2007 03:54:09 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnrrE-0002Yr-0D for lemonade@ietf.org; Tue, 15 May 2007 03:54:09 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4F7rfTf008217; Tue, 15 May 2007 10:54:05 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 May 2007 10:53:28 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 May 2007 10:53:27 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Updated Draft: draft-cridland-imap-context Date: Tue, 15 May 2007 10:53:28 +0300 Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA157813606@esebe199.NOE.Nokia.com> In-Reply-To: <30512.1179167917.106478@peirce.dave.cridland.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Updated Draft: draft-cridland-imap-context Thread-Index: AceWVx/BSSb2htlnT16giFMkauR3ZAAbd/5g References: <13829.1177506908.404308@peirce.dave.cridland.net> <4C38DC11F6B4FF4FAEA73E30DB5AA157812F7D@esebe199.NOE.Nokia.com> <30512.1179167917.106478@peirce.dave.cridland.net> From: To: X-OriginalArrivalTime: 15 May 2007 07:53:27.0727 (UTC) FILETIME=[1F5DA3F0:01C796C6] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Dave, thanks for the fixes. I will check the new draft later on today hopefully. *rushing to a meeting* Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 =20 >> 6. "The search return option UPDATE, if used by a client, causes the=20 >> server to ..." >> Should we make it mandatory? At least I would not want to=20 >see a client=20 >> that supports notifications (IDLE/NOTIFY will be in all LEMONADE=20 >> clients anyway) but cannot coop with search result updates.=20 >Server and=20 >> client will get seriously out of sync without notifications, so when=20 >> the client requests a next window, some results might be displayed=20 >> again (when new results have been inserted before the=20 >current window)=20 >> and some might be missed as well (when obsolete results have been=20 >> removed before the current window). >>=20 >>=20 >Yes, clients which don't use UPDATE, but do use PARTIAL, may well get=20 >confused, depending on what they're trying to do. Could we add a requiement at least (PARTIAL requires UPDATE)? Alexey = sent His response on this (well, the response was a question), please = consult with Him. >> Section 3.3.2 (3.3.1 is relevant as well). >> 9. "Servers SHOULD sort the results in order to use the=20 >> sequence-set syntax as efficiently as possible." >> Sort by ... (what? UID, date, sender, subject, priority, etc)?=20 >> (Sorry, I am not familiar with SORT). Should we make this mandatory=20 >> (that the list MUST be sorted)? > >The protocol is unaffected by sorting the results, but the=20 >representation is smaller if servers do. Typically, the server will=20 >issue SEARCH results in the natural order of the mailbox, which will=20 >then be easy to collapse into a compact set-syntax representation. Ah, I thought that server would sort the results the way the client = wants it. I guess I should familiarize myself with SORT. -cut- I will sent another mail starting from comment#11 - gotta go. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue May 15 04:48:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnsi3-0000xA-8n; Tue, 15 May 2007 04:48:43 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hnsi2-0000wz-Gx for lemonade-confirm+ok@megatron.ietf.org; Tue, 15 May 2007 04:48:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnsi1-0000wg-OA for lemonade@ietf.org; Tue, 15 May 2007 04:48:41 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hnsi1-0000jn-Ac for lemonade@ietf.org; Tue, 15 May 2007 04:48:41 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4F8mFl4004768; Tue, 15 May 2007 11:48:38 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 May 2007 11:48:32 +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 May 2007 11:48:32 +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] Updated Draft: draft-cridland-imap-context Date: Tue, 15 May 2007 11:48:32 +0300 Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA1578136E9@esebe199.NOE.Nokia.com> In-Reply-To: <30512.1179167917.106478@peirce.dave.cridland.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Updated Draft: draft-cridland-imap-context Thread-Index: AceWVx/BSSb2htlnT16giFMkauR3ZAAdMTwA References: <13829.1177506908.404308@peirce.dave.cridland.net> <4C38DC11F6B4FF4FAEA73E30DB5AA157812F7D@esebe199.NOE.Nokia.com> <30512.1179167917.106478@peirce.dave.cridland.net> From: To: X-OriginalArrivalTime: 15 May 2007 08:48:32.0174 (UTC) FILETIME=[D0F83CE0:01C796CD] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Dave, Here are my repsonses to Your comments starting from #11 (which is OK, = so it's missing from the mail below). Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 >> Section A.1. >> 14. CONTEXT is a replacement for VFOLDER. > >No, it isn't. It's an alternate mechanism for achieving similar=20 >results. Arnt (and others) will tell you, quite rightly, that VFOLDER=20 >is optimized for different cases, and covers different requirements. > >> VFOLDER had the advantage of re-using virtual folders: I could=20 >> easily create new virtual folders from virtual folders, and=20 >> altering one virtual folder in the "path" would alter all "child"=20 >> virtual folders. It appears (or, I missed something) that it is no=20 >> longer possible using this extension. >>=20 >>=20 >Not directly. The mechanism one might use for doing this is Alexey's=20 >named filter draft, which would allow you to build composite=20 >user-defined search keys. I have no idea what the desired result of=20 >changing one used by an update context would be. This draft You are referring to is not part of LEMONADE, is it? Is this = draft published somewhere? >However, the simplest method would be to drop the context (now=20 >possible with a FREECONTEXT command) and recreate it with the new=20 >desired search program. Erm, is this in the new draft? If so, then there is no need to repond; I = will see it when I get there. >> Section A.2. >> 15. This is useful, but it would be nice to tell that it is also=20 >> possible to "leave out" trashed messaged from the inbox - by using=20 >> an inverted search for \Deleted. >>=20 >>=20 >I think it does - if you've a suggestion for how to make this=20 >clearer, I'd welcome it. I will check the new draft first. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue May 15 05:53:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HntiU-0003AX-VI; Tue, 15 May 2007 05:53:14 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HntiT-0003AS-KW for lemonade-confirm+ok@megatron.ietf.org; Tue, 15 May 2007 05:53:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HntiT-0003AK-As for lemonade@ietf.org; Tue, 15 May 2007 05:53:13 -0400 Received: from [2001:838:378:0:2a0:d2ff:fe1b:110f] (helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HntiS-0008J0-Bk for lemonade@ietf.org; Tue, 15 May 2007 05:53:13 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 4611E498006; Tue, 15 May 2007 10:53:09 +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 25048-05; Tue, 15 May 2007 10:53:07 +0100 (BST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:838:378:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 20A92498002; Tue, 15 May 2007 10:53:07 +0100 (BST) Subject: RE: [lemonade] Updated Draft: draft-cridland-imap-context References: <13829.1177506908.404308@peirce.dave.cridland.net> <4C38DC11F6B4FF4FAEA73E30DB5AA157812F7D@esebe199.NOE.Nokia.com> <30512.1179167917.106478@peirce.dave.cridland.net> <4C38DC11F6B4FF4FAEA73E30DB5AA1578136E9@esebe199.NOE.Nokia.com> In-Reply-To: <4C38DC11F6B4FF4FAEA73E30DB5AA1578136E9@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Message-Id: <6426.1179222788.050501@peirce.dave.cridland.net> Date: Tue, 15 May 2007 10:53:08 +0100 From: Dave Cridland To: "Zoltan.Ordogh@nokia.com" Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: Debian amavisd-new at turner.dave.cridland.net X-Spam-Score: -2.4 (--) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue May 15 09:48:32 2007, Zoltan.Ordogh@nokia.com wrote: > >However, the simplest method would be to drop the context (now > >possible with a FREECONTEXT command) and recreate it with the new > >desired search program. > > Erm, is this in the new draft? If so, then there is no need to > repond; I will see it when I get there. > > Not explicitly - do you think it needs an explicit mention? Currently, there's simply no other way of changing the search program used for a context. Only Alexey's draft would provide a mechanism for this. 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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue May 15 05:53:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HntiY-0003BY-3r; Tue, 15 May 2007 05:53:18 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HntiW-0003Ar-ID for lemonade-confirm+ok@megatron.ietf.org; Tue, 15 May 2007 05:53:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HntiW-0003Aj-8X for lemonade@ietf.org; Tue, 15 May 2007 05:53:16 -0400 Received: from [2001:838:378:0:2a0:d2ff:fe1b:110f] (helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HntiV-0008LZ-9H for lemonade@ietf.org; Tue, 15 May 2007 05:53:16 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 68007498002; Tue, 15 May 2007 10:53: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 25283-01; Tue, 15 May 2007 10:53:06 +0100 (BST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:838:378:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 47BF4498001; Tue, 15 May 2007 10:53:06 +0100 (BST) Subject: RE: [lemonade] Updated Draft: draft-cridland-imap-context References: <13829.1177506908.404308@peirce.dave.cridland.net> <4C38DC11F6B4FF4FAEA73E30DB5AA157812F7D@esebe199.NOE.Nokia.com> <30512.1179167917.106478@peirce.dave.cridland.net> <4C38DC11F6B4FF4FAEA73E30DB5AA157813606@esebe199.NOE.Nokia.com> In-Reply-To: <4C38DC11F6B4FF4FAEA73E30DB5AA157813606@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Message-Id: <6426.1179222787.187587@peirce.dave.cridland.net> Date: Tue, 15 May 2007 10:53:07 +0100 From: Dave Cridland To: "Zoltan.Ordogh@nokia.com" Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: Debian amavisd-new at turner.dave.cridland.net X-Spam-Score: -2.4 (--) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue May 15 08:53:28 2007, Zoltan.Ordogh@nokia.com wrote: > >> 6. "The search return option UPDATE, if used by a client, causes > the >> server to ..." > >> Should we make it mandatory? At least I would not want to >see a > client >> that supports notifications (IDLE/NOTIFY will be in all > LEMONADE >> clients anyway) but cannot coop with search result > updates. >Server and >> client will get seriously out of sync > without notifications, so when >> the client requests a next > window, some results might be displayed >> again (when new results > have been inserted before the >current window) >> and some might be > missed as well (when obsolete results have been >> removed before > the current window). > >> >> >Yes, clients which don't use UPDATE, but do use PARTIAL, may > well get >confused, depending on what they're trying to do. > > Could we add a requiement at least (PARTIAL requires UPDATE)? > Alexey sent His response on this (well, the response was a > question), please consult with Him. > > It's a requirement for servers - if a server has "CONTEXT" or "CONTEXTS=", it has to do UPDATE. (Although in principle it could refuse to honour the requests, or something, but it's possible to mangle any specification into uselessness if one tries hard enough.) > >> Section 3.3.2 (3.3.1 is relevant as well). > >> 9. "Servers SHOULD sort the results in order to use the >> > sequence-set syntax as efficiently as possible." > >> Sort by ... (what? UID, date, sender, subject, priority, etc)? > >> (Sorry, I am not familiar with SORT). Should we make this > mandatory >> (that the list MUST be sorted)? > > > >The protocol is unaffected by sorting the results, but the > >representation is smaller if servers do. Typically, the server > will >issue SEARCH results in the natural order of the mailbox, > which will >then be easy to collapse into a compact set-syntax > representation. > > Ah, I thought that server would sort the results the way the client > wants it. I guess I should familiarize myself with SORT. > > SORT isn't addressed by CONTEXT. The design is intended to handle it, and this specification was originally written to include it - now I've merely tried to make it work with a future CONTEXT=SORT extension. 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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue May 15 08:21:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnw2F-00016D-Bd; Tue, 15 May 2007 08:21:47 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hnw2D-000168-Gm for lemonade-confirm+ok@megatron.ietf.org; Tue, 15 May 2007 08:21:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnw2D-000160-79 for lemonade@ietf.org; Tue, 15 May 2007 08:21:45 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hnw2B-0001bE-QG for lemonade@ietf.org; Tue, 15 May 2007 08:21:45 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4FCLSp4032416; Tue, 15 May 2007 15:21:41 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 May 2007 15:21: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, 15 May 2007 15:21: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] Updated Draft: draft-cridland-imap-context Date: Tue, 15 May 2007 15:21:28 +0300 Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA1578139F0@esebe199.NOE.Nokia.com> In-Reply-To: <6426.1179222788.050501@peirce.dave.cridland.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Updated Draft: draft-cridland-imap-context Thread-Index: AceW1tzikP4ipF5WTDOv9aiirsqG3gAFHzYQ References: <13829.1177506908.404308@peirce.dave.cridland.net> <4C38DC11F6B4FF4FAEA73E30DB5AA157812F7D@esebe199.NOE.Nokia.com> <30512.1179167917.106478@peirce.dave.cridland.net> <4C38DC11F6B4FF4FAEA73E30DB5AA1578136E9@esebe199.NOE.Nokia.com> <6426.1179222788.050501@peirce.dave.cridland.net> From: To: X-OriginalArrivalTime: 15 May 2007 12:21:28.0435 (UTC) FILETIME=[9036F430:01C796EB] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) 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 >-----Original Message----- >From: ext Dave Cridland [mailto:dave@cridland.net]=20 >Sent: 15 May, 2007 12:53 >To: Ordogh Zoltan (Nokia-TP-MSW/Tampere) >Cc: Enhancements to Internet email to support diverse service=20 >enivronments >Subject: RE: [lemonade] Updated Draft: draft-cridland-imap-context > >On Tue May 15 09:48:32 2007, Zoltan.Ordogh@nokia.com wrote: >> >However, the simplest method would be to drop the context (now=20 >> >possible with a FREECONTEXT command) and recreate it with the new=20 >> >desired search program. >>=20 >> Erm, is this in the new draft? If so, then there is no need=20 >to repond;=20 >> I will see it when I get there. >>=20 >>=20 >Not explicitly - do you think it needs an explicit mention?=20 >Currently, there's simply no other way of changing the search=20 >program used for a context. Only Alexey's draft would provide=20 >a mechanism for this. I do not have a strong opinion on this one. It would avoid questions like mine ;-) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue May 15 08:24:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnw4Y-0003Jt-Oh; Tue, 15 May 2007 08:24:10 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hnw4W-0003Jc-Ly for lemonade-confirm+ok@megatron.ietf.org; Tue, 15 May 2007 08:24:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnw4W-0003JS-Ay for lemonade@ietf.org; Tue, 15 May 2007 08:24:08 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hnw4U-0002D6-TO for lemonade@ietf.org; Tue, 15 May 2007 08:24:08 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4FCNogm004760; Tue, 15 May 2007 15:24:03 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 May 2007 15:23:51 +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 May 2007 15:23:51 +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] Updated Draft: draft-cridland-imap-context Date: Tue, 15 May 2007 15:23:52 +0300 Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA1578139F8@esebe199.NOE.Nokia.com> In-Reply-To: <6426.1179222787.187587@peirce.dave.cridland.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Updated Draft: draft-cridland-imap-context Thread-Index: AceW1t0bMUDoPIpNTVetxsORw75dSwAFMqqw References: <13829.1177506908.404308@peirce.dave.cridland.net> <4C38DC11F6B4FF4FAEA73E30DB5AA157812F7D@esebe199.NOE.Nokia.com> <30512.1179167917.106478@peirce.dave.cridland.net> <4C38DC11F6B4FF4FAEA73E30DB5AA157813606@esebe199.NOE.Nokia.com> <6426.1179222787.187587@peirce.dave.cridland.net> From: To: X-OriginalArrivalTime: 15 May 2007 12:23:51.0682 (UTC) FILETIME=[E598B620:01C796EB] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 >-----Original Message----- >From: ext Dave Cridland [mailto:dave@cridland.net]=20 >Sent: 15 May, 2007 12:53 >To: Ordogh Zoltan (Nokia-TP-MSW/Tampere) >Cc: Enhancements to Internet email to support diverse service=20 >enivronments >Subject: RE: [lemonade] Updated Draft: draft-cridland-imap-context > >On Tue May 15 08:53:28 2007, Zoltan.Ordogh@nokia.com wrote: >> >> 6. "The search return option UPDATE, if used by a client, causes >> the >> server to ..." >> >> Should we make it mandatory? At least I would not want to >see a >> client >> that supports notifications (IDLE/NOTIFY will be in all=20 >> LEMONADE >> clients anyway) but cannot coop with search result=20 >> updates. >Server and >> client will get seriously out of=20 >sync without=20 >> notifications, so when >> the client requests a next window, some=20 >> results might be displayed >> again (when new results have been=20 >> inserted before the >current window) >> and some might be missed as=20 >> well (when obsolete results have been >> removed before the current=20 >> window). >> >> >> >Yes, clients which don't use UPDATE, but do use PARTIAL, may >> well get >confused, depending on what they're trying to do. >>=20 >> Could we add a requiement at least (PARTIAL requires UPDATE)?=20 >> Alexey sent His response on this (well, the response was a=20 >question),=20 >> please consult with Him. >>=20 >>=20 >It's a requirement for servers - if a server has "CONTEXT" or=20 >"CONTEXTS=3D", it has to do UPDATE. (Although in principle it=20 >could refuse to honour the requests, or something, but it's=20 >possible to mangle any specification into uselessness if one=20 >tries hard enough.) Ok, then I guess I can answer Alexey's question here and say: yes, for the clients supporting this extension, too. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue May 15 08:24:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnw4i-0003NN-6o; Tue, 15 May 2007 08:24:20 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hnw4h-0003NI-6z for lemonade-confirm+ok@megatron.ietf.org; Tue, 15 May 2007 08:24:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnw4g-0003N8-TN for lemonade@ietf.org; Tue, 15 May 2007 08:24:18 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hnw4f-0002EF-Cl for lemonade@ietf.org; Tue, 15 May 2007 08:24:18 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4FCNwA3004822; Tue, 15 May 2007 15:24:15 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 May 2007 15:24:00 +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 May 2007 15:24:00 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Context update Date: Tue, 15 May 2007 15:24:00 +0300 Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA1578139FB@esebe199.NOE.Nokia.com> In-Reply-To: <30512.1179169211.052893@peirce.dave.cridland.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Context update Thread-Index: AceWWiRYNHrenxSrQ0e3IYthMmdpOAAeXlyw References: <30512.1179169211.052893@peirce.dave.cridland.net> From: To: , X-OriginalArrivalTime: 15 May 2007 12:24:00.0213 (UTC) FILETIME=[EAAE7050:01C796EB] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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 Dave, Comments on -02: Section 2. 1. "might overwhelm the storage available for results on even relatively = high-end desktop machines." In a comment vs. -01 I proposed to get rid of "relatively high-end = desktop machines". It's still there, but what You call today realtively = high-end might be the extreme low-end tomorrow... If You insist, keep it = - but I do not think it adds much value to the draft. Section 3.3.1 2. "In some cases, the server MAY refuse to provide updates, such as if = an internal limit on the number of update contexts is reached." I do not like the "MAY". It suggests that a server can refuse updates = whenever it feels like it. A "SHOULD NOT" would be better. Could we change this something like: "The server SHOULD NOT refuse to provide updates unless it is running = out of resources, or, some other internal limiting factor has been = reached." Addition of something like this might be beneficial: "In order to receive updates in the future, the client MAY issue the = FREECONTEXT command and perform the search." Section 3.3.5 3. "The server MAY free any resource associated with a context so = disabled." Fuzzy/incomplete(?) sentence. Also, if all associated resources are = dropped, how can I use PARTIAL after FREECONTEXT? According to paragraph = one it is possible: "When a client no longer wishes to receive updates, = it may issue the FREECONTEXT command, which will prevent all updates to = the contexts named in the arguments from being transmitted by the = server." <- this says only updates will cease, so the client could still = request PARTIAL. I suggest the sentence to be completed with something like this: "The server MAY free any resource associated with a context and the = client MUST NOT use the freed context any further during the current = IMAP session." Other than that, it look Ok to me, thank You for the update. 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: 14 May, 2007 22:00 >To: Enhancements to Internet email to support diverse service=20 >enivronments; Messaging Organization >Subject: [lemonade] Context update > >I've just submitted update to my IMAP CONTEXT draft. > >I've put it up at >http://dave.cridland.net/draft-cridland-imap-context-02.txt=20 >until it's announced. > >The major change is that update contexts can now be explicitly=20 >freed, and there's a response code to allow servers to refuse=20 >to honour them. > >Dave. >-- >Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org > - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ > - http://dave.cridland.net/ >Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade > > >_______________________________________________ >lemonade mailing list >lemonade@ietf.org >https://www1.ietf.org/mailman/listinfo/lemonade >Supplemental Web Site: >http://www.standardstrack.com/ietf/lemonade > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue May 15 11:14:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnyjn-0007mH-Fl; Tue, 15 May 2007 11:14:55 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hnyjm-0007m8-2Z for lemonade-confirm+ok@megatron.ietf.org; Tue, 15 May 2007 11:14:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnyjl-0007m0-P7 for lemonade@ietf.org; Tue, 15 May 2007 11:14:53 -0400 Received: from [2001:838:378:0:2a0:d2ff:fe1b:110f] (helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hnyjj-0006QS-JU for lemonade@ietf.org; Tue, 15 May 2007 11:14:53 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 40F05498002; Tue, 15 May 2007 16:14:47 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28360-05; Tue, 15 May 2007 16:14:41 +0100 (BST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:838:378:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 7F3FB498001; Tue, 15 May 2007 16:14:41 +0100 (BST) Subject: Re: [lemonade] Going way out on a limb on search-within References: In-Reply-To: MIME-Version: 1.0 Message-Id: <6426.1179242081.442212@peirce.dave.cridland.net> Date: Tue, 15 May 2007 16:14:41 +0100 From: Dave Cridland To: Eric Burger Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: Debian amavisd-new at turner.dave.cridland.net X-Spam-Score: -2.8 (--) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Mon May 14 19:44:15 2007, Eric Burger wrote: > OK, so the #1 complaint has been that on the one hand, we do not > want to > allow clients to specify an arbitrarily small search interval, as > that can > lock-up the server. No, it can't. :-) The size of the value given as argument to OLDER or YOUNGER has no effect whatsoever on server load. What affects it is how often the server has to re-evaluate it. Rather than mess about with granularity of the OLDER/YOUNGER, why not replace paragraph 2/3 of section 2 with: In those cases where the search criteria are used to provide dynamically updated results, the strict definition of YOUNGER and OLDER above means that the target date and time requires recalculating every second, leading to new comparisons every second in turn. Servers may be unable, or unwilling, to do this, and in these cases, the target date and time MAY be recalculated less frequently. Servers MUST recalculate the target date and time at least once every X seconds, or as frequently as required by the dynamic search mechanism. For example, if a SEARCH command with YOUNGER 1 is executed at any time against a mailbox containing a message which arrived one second ago, that message will match. However, if used with a dynamic search, it may be up to X seconds until that message is removed from the result set. You get to pick X, I don't care too much. 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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue May 15 12:22:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnzn9-0007gw-Q4; Tue, 15 May 2007 12:22:27 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hnzn7-0007aM-Nq for lemonade-confirm+ok@megatron.ietf.org; Tue, 15 May 2007 12:22:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnzn5-0007ZH-AZ for lemonade@ietf.org; Tue, 15 May 2007 12:22:23 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hnzn3-0003sJ-TY for lemonade@ietf.org; Tue, 15 May 2007 12:22:23 -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 ; Tue, 15 May 2007 17:22:20 +0100 Message-ID: <4649DDFA.1000908@isode.com> Date: Tue, 15 May 2007 17:21:14 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave Cridland Subject: Re: [lemonade] Going way out on a limb on search-within References: <6426.1179242081.442212@peirce.dave.cridland.net> In-Reply-To: <6426.1179242081.442212@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: a7d6aff76b15f3f56fcb94490e1052e4 Cc: diverse service enivronments , Enhancements X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dave Cridland wrote: > On Mon May 14 19:44:15 2007, Eric Burger wrote: > >> OK, so the #1 complaint has been that on the one hand, we do not want to >> allow clients to specify an arbitrarily small search interval, as >> that can >> lock-up the server. > > No, it can't. :-) > > The size of the value given as argument to OLDER or YOUNGER has no > effect whatsoever on server load. Agreed. It is not different from (e.g.) SINCE search criterion. > What affects it is how often the server has to re-evaluate it. > > Rather than mess about with granularity of the OLDER/YOUNGER, why not > replace paragraph 2/3 of section 2 with: > > In those cases where the search criteria are used to provide > dynamically updated results, the strict definition of YOUNGER and > OLDER above means that the target date and time requires recalculating > every second, leading to new comparisons every second in turn. Servers > may be unable, or unwilling, to do this, and in these cases, the > target date and time MAY be recalculated less frequently. Servers MUST > recalculate the target date and time at least once every X seconds, or > as frequently as required by the dynamic search mechanism. > > For example, if a SEARCH command with YOUNGER 1 is executed at any > time against a mailbox containing a message which arrived one second > ago, that message will match. However, if used with a dynamic search, > it may be up to X seconds until that message is removed from the > result set. I like that. > You get to pick X, I don't care too much. I suggest we stick with 1 hour as agreed before. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue May 15 12:52:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho0G6-0008RW-Di; Tue, 15 May 2007 12:52:22 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Ho0G5-0008O3-Ol for lemonade-confirm+ok@megatron.ietf.org; Tue, 15 May 2007 12:52:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho0G5-0008MG-DL for lemonade@ietf.org; Tue, 15 May 2007 12:52:21 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ho0G3-0006RU-9u for lemonade@ietf.org; Tue, 15 May 2007 12:52:21 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4FGqFF28753 for ; Tue, 15 May 2007 16:52:16 GMT Received: from americasm01.nt.com ([47.129.40.188] RDNS failed) by zcarhxm0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 May 2007 12:52:15 -0400 Date: Tue, 15 May 2007 12:52:13 -0400 Mime-Version: 1.0 (Apple Message framework v553) From: "Glenn Parsons" To: lemonade@ietf.org Message-Id: X-Mailer: Apple Mail (2.553) X-OriginalArrivalTime: 15 May 2007 16:52:15.0290 (UTC) FILETIME=[641849A0:01C79711] X-Spam-Score: 0.1 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Subject: [lemonade] Interim meeting logistics X-BeenThere: lemonade@ietf.org X-Mailman-Version: 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="===============1051521081==" Errors-To: lemonade-bounces@ietf.org --===============1051521081== Content-Type: multipart/alternative; boundary=Apple-Mail-12--922728918 --Apple-Mail-12--922728918 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; format=flowed Folks, The details on the interim meeting starting tomorrow can be found on=20 the supplemental website: http://standardstrack.com/ietf/lemonade/ But as a reminder I've pasted it below. Cheers, Glenn. Start Times & Venue 1200 - 1700 Eastern Time 16 May 2007 BEA Mississauga Room 734 0900 - 1300 Eastern Time 17 May 2007 =A0BEA Mississauga Room 734 BEA Systems Ltd. 2425 Matheson Blvd. East 7th Floor Mississauga (Toronto), ON =A0 L4W 5K4 +1.905.361.2850 phone Remote connectivity Jabber server: jabber.ietf.org Room: lemonade Logs: http://www3.ietf.org/meetings/ietf-logs/lemonade/ Nortel MCS Audio Bridge Participant Passcode: =A0=A039375821# Local Dial in Numbers North Carolina +1 919-997-8994 Massachusetts +1 978-288-4793 Texas +1 972-362-0170 California +1 408-495-5113 Ottawa +1 613-765-0170 Toronto +1 905-863-9705 Montreal +1 514-818-3524 Calgary +1 403-769-5487 Vancouver +1 604-631-4051 UK +44 162 843 1170 Ireland +353 9 173 2770 France +33 16 955 2170 Germany +49 696 697 3170 Italy +39 065 152 9170 Spain +34 91 709 4370 Holland +31 23 567 3170 Australia +61 2-8870-5504=20= --Apple-Mail-12--922728918 Content-Transfer-Encoding: quoted-printable Content-Type: text/enriched; charset=ISO-8859-1 Folks, The details on the interim meeting starting tomorrow can be found on the supplemental website: http://standardstrack.com/ietf/lemonade/ But as a reminder I've pasted it below. Cheers, Glenn. TimesStart Times & Venue=20 = Times0000,0000,FFFF1200 - 1700 Eastern Time 16 May 2007 BEA Mississauga Room 734=20 0000,0000,FFFF0900 - 1300 Eastern Time 17 May 2007 =A0BEA Mississauga Room 734=20 BEA Systems Ltd.=20 2425 Matheson Blvd. East 7th Floor=20 Mississauga (Toronto), ON =A0 L4W 5K4=20 +1.905.361.2850 phone=20 Remote connectivity Jabber server: jabber.ietf.org Room: lemonade 0000,0000,FFFF Logs: = 0000,0000,FFFFhttp://www3.ietf.org/meetings/ietf-log= s/lemonade/ Nortel MCS Audio Bridge Participant Passcode: =A0=A039375821#=20 Local Dial in Numbers=20 North Carolina +1 919-997-8994=20 Massachusetts +1 978-288-4793=20 Texas +1 972-362-0170=20 California +1 408-495-5113=20 Ottawa +1 613-765-0170=20 Toronto +1 905-863-9705=20 Montreal +1 514-818-3524=20 Calgary +1 403-769-5487=20 Vancouver +1 604-631-4051=20 UK +44 162 843 1170=20 Ireland +353 9 173 2770=20 France +33 16 955 2170=20 Germany +49 696 697 3170=20 Italy +39 065 152 9170=20 Spain +34 91 709 4370=20 Holland +31 23 567 3170=20 Australia +61 2-8870-5504 = --Apple-Mail-12--922728918-- --===============1051521081== 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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============1051521081==-- From lemonade-bounces@ietf.org Wed May 16 00:50:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoBSe-0006ci-LM; Wed, 16 May 2007 00:50:04 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HoBSe-0006ca-3q for lemonade-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 00:50:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoBSd-0006cS-Py for lemonade@ietf.org; Wed, 16 May 2007 00:50:03 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoBSd-0004gZ-8F for lemonade@ietf.org; Wed, 16 May 2007 00:50:03 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l4G4nx21014897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 15 May 2007 21:50:00 -0700 Received: from [[192.168.1.13]] (vpn-10-50-0-54.qualcomm.com [10.50.0.54]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l4G4npYV005891; Tue, 15 May 2007 21:49:58 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <1259253957.4021175574674855.JavaMail.root@dogfood.liquidsys.com> References: <1259253957.4021175574674855.JavaMail.root@dogfood.liquidsys.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Tue, 15 May 2007 13:59:09 -0700 To: Dan Karp , Eric Burger From: Randall Gellens Subject: Re: [lemonade] Expert Review: annotatemore (like WGLC) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: Enhancements to Internet email to support diverse service enivronments , IMAP Extensions WG X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I hope this isn't too late to be useful. At 9:31 PM -0700 4/2/07, Dan Karp wrote: > A user can only set and retrieve private or shared annotations on a > mailbox which exists and is returned to them via a LIST or LSUB > command, irrespective of whether they have read or write access to > the actual message content of the mailbox. If the client attempts to > set or retrieve annotations on other mailboxes, the server MUST > respond with a NO response. > > I can understand the logic behind requiring LIST/LSUB access for reading > public mailbox annotations and for setting private annotations. But > that seems to be a very low bar for setting public mailbox annotations. > Adding a new ACL permission for setting annotations would make this > extension more complex and would also introduce a dependency on the ACL > extension, but perhaps requiring [READ-WRITE] access to the mailbox > might be reasonable? Seems reasonable. It's interesting that any user can set a shared server annotation. Note that, separate from Dan's comments, the description of the SETMETADATA command should explicitly mention that an empty string is used to set server annotations, and should include some examples of doing so. Perhaps servers should be permitted to reject an attempt to set shared server annotations if, based on internal configuration (that is, not standardized) the user isn't allowed to do so? That would allow servers to, for example, have some users that can set any shared server annotations, others that can set none, and some that can set some. I think trying to standardize this would require ACL extensions and introduce an ACL dependency, which we don't want to do. This could always be done in the future, based on operational experience. > This command sets the specified list of entries by adding or > replacing the specified attributes with the values provided, on the > specified existing mailboxes. Clients can use NIL for values of > attributes it wants to remove from entries. The server MAY return a > METADATA response containing the updated annotation data. > > In this case, the server may return a METADATA response that doesn't > contain the updated annotation data or a LIST response that does, > correct? The server might return a METADATA response containing incorrect data? > This extension adds the GETMETADATA command. This allows clients to > retrieve server annotations. Mailbox annotations are retrieved via > the extended LIST command described in the next section. > > This extension adds the SETMETADATA command. This allows clients to > set annotations. > > It's a little incongruous that GETMETADATA is used only to retrieve > server annotations, but SETMETADATA can be used to set both server and > mailbox annotations. I understand that the mailbox-level function of > GETMETADATA has been passed to the LIST-EXTENDED feature, but generally > it's clearer when a GETFOO and SETFOO pair cover the same target space. I agree, this is odd. > /sort > Defines the default sort criteria [I-D.ietf-imapext-sort] to use > when first displaying the mailbox contents to the user, or NIL if > sorting is not required. Note that the presence of this attribute > does not imply that the server supports the IMAP SORT > [I-D.ietf-imapext-sort] extension - servers can choose to support > or not support SORT independently of this extension. In the > absence of the SORT extension, clients can choose to interpret > this entry as suggesting a client-side sort ordering of the > corresponding mailbox. > > /thread > Defines the default thread criteria [I-D.ietf-imapext-sort] to use > when first displaying the mailbox contents to the user, or NIL if > threading is not required. If both sort and thread are not NIL, > then threading should take precedence over sorting. Note that the > presence of this attribute does not imply that the server supports > the IMAP THREAD [I-D.ietf-imapext-sort] extension - servers can > choose to support or not support THREAD independently of this > extension. In the absence of the THREAD extension, clients can > choose to interpret this entry as a client-side thread ordering of > the corresponding mailbox. > > These registered annotations are odd ducks. They seem most appropriate > as private annotations on a mailbox, but in practice they may be > confusing to the end user because sorting and threading preferences are > often client-specific, not user-specific. > > For instance, a user may prefer to read their mail nonthreaded on the > desktop, but on a mobile device they may want to make use of the reduced > visual footprint of a threaded display. Likewise, more likely than not > a user won't expect their sort preferences to automatically be > transferred between their devices and clients. One thought would be to keep the current "/sort" and "/thread" entries, but specify that "/sort/client/" and "/thread/client/" may exist and if so apply to specific clients. If the server supports threading and sorting and knows the for the session (using some to-be-specified-in-the-future mechanism) it uses the client-specific entry, otherwise it uses the default entry. This assumes that a level in the hierarchy can have attributes and child levels. If the server doesn't support threading or sorting, the client can always use a vendor-specific entry. > Each annotation is an entry that has a hierarchical name, with each > component of the name separated by a slash ("/"). An entry name MUST > NOT contain two consecutive "/" characters and MUST NOT end with a > "/" character. > > Each entry is made up of a set of attributes. Each attribute has a > hierarchical name, with each component of the name separated by a > period ("."). An attribute name MUST NOT contain two consecutive "." > characters and MUST NOT end with a "." character. > > My last comment is personal preference: I fear that this may be a bit of > overkill for folder annotation. I understand the need for this type of > flexible syntax for ACAP's purposes, but the use cases for IMAP appear > significantly more limited in scope. In accordance with the KISS > philosophy, is there any chance I might be able to convince everyone to > consider shedding a layer of hierarchy here? I think we need the entry hierarchy. It might be possible to eliminate the attribute hierarchy. Didn't we end up doing something like that for ANNOTATE? -- 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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed May 16 00:50:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoBSj-0006dq-S0; Wed, 16 May 2007 00:50:09 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HoBSi-0006dl-JA for lemonade-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 00:50:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoBSi-0006dd-9G for lemonade@ietf.org; Wed, 16 May 2007 00:50:08 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoBSg-0004gg-VJ for lemonade@ietf.org; Wed, 16 May 2007 00:50:08 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l4G4o4QY014914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 15 May 2007 21:50:04 -0700 Received: from [[192.168.1.13]] (vpn-10-50-0-54.qualcomm.com [10.50.0.54]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l4G4npYZ005891; Tue, 15 May 2007 21:50:03 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <4616327C.5040203@isode.com> References: <5933.1175598309.377419@peirce.dave.cridland.net> <4616327C.5040203@isode.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Tue, 15 May 2007 14:07:09 -0700 To: Alexey Melnikov , Dave Cridland From: Randall Gellens Subject: Re: [lemonade] Profile Bis updated Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 12:43 PM +0100 4/6/07, Alexey Melnikov wrote: > If I remember correctly, ENABLE was born around EXPUNGED/QRESYNC > WGLC. In particular there was a suggestion to use ENABLE with > CONDSTORE and QRESYNC. Is this something that people still would > like to be able to do in Lemonade Profile Bis? That's my recollection as well, and I still think it is a good idea. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- "Contrariwise," continued Tweedledee, "if it was so, it might be, and if it were so, it would be; but as it isn't, it ain't. That's logic!" _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed May 16 03:28:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoDvh-0001qn-Uc; Wed, 16 May 2007 03:28:13 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HoDvh-0001qh-AH for lemonade-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 03:28:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoDvd-0001q8-Rt for lemonade@ietf.org; Wed, 16 May 2007 03:28:09 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoDvd-0005JA-Gn for lemonade@ietf.org; Wed, 16 May 2007 03:28:09 -0400 Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4G7S8Gi021654 for ; Wed, 16 May 2007 07:28:09 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JI400B01HWHAA00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for lemonade@ietf.org; Wed, 16 May 2007 01:28:08 -0600 (MDT) Received: from [10.1.110.5] (216-165-236-126.championbroadband.com [216.165.236.126]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JI400GNNI2TLM00@mail-amer.sun.com> for lemonade@ietf.org; Wed, 16 May 2007 01:28:08 -0600 (MDT) Date: Wed, 16 May 2007 00:28:06 -0700 From: Chris Newman To: lemonade@ietf.org Message-id: <7CB41CC1AD859AC968313FAB@[10.0.1.21]> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: [lemonade] concerns with draft-ietf-lemonade-reconnect-client-04.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I'm concerned there are architectural issues with draft-ietf-lemonade-reconnect-client-04.txt that may create problems with IETF consensus on the document. I wanted to verify that the WG has consensus on these specific architectural issues in addition to the document as a whole before I start IETF last call, as it may be more difficult to resolve these issues in an IETF-wide or IESG scope than in a more narrow WG scope. My intention is not to force any specific changes, but rather to encourage making changes prior to IETF last call that might be helpful to speed IETF consensus. 1. Implicit server behavior changes This extension has several cases where client commands trigger a server behavior change as a side-effect of a client command. There has been significant discussion in other IETF contexts (EAI design team, IMAPEXT, ENABLE extension) that such behavior is undesirable and that if a server behavior change is to occur it should be explicit and early in the protocol exchange. I would like to confirm the WG has consensus on this specific issue as I suspect it is likely be problematic during IETF last call. 2. Change in IMAP untagged response model For better or worse, IMAP is a cache update protocol model rather than a request/response protocol model. That means an untagged response is not bound to a particular command, but rather the portion of the client's cache state that is updated can be determined solely from the untagged response itself (the SEARCH response being a notable exception). This extension changes that model by binding the VANISHED response to a specific command with the TAG correlator. Are there servers which execute client commands out-of-order so that such binding would be necessary? Does the WG believe changing the fundamental IMAP model in this case is the best way to accomplish this specific task? 3. VANISHED response sometimes but not always implying EXISTS change The VANISHED response is used in two different ways: one to replace the EXPUNGE response to indicate a change in mailbox state at that moment (including an implicit EXISTS update), and one to indicate that messages were removed before the mailbox was selected in response to a QRESYNC select modifier or VANISHED UID FETCH modifier. I suspect the logic the client must use to distinguish these cases is a bit subtle. Perhaps a simplification to VANISHED to address issue 2 & 3 should be considered? 4. Complex interaction with CONDSTORE and UIDPLUS This extension requires CONDSTORE and requires the server to advertise CONDSTORE. That means there's a silly state where the server advertises QRESYNC but not CONDSTORE. Perhaps there's a simple way to eliminate the silly state? Furthermore, there is a great deal of variation in server behaviors and client codepaths between un-extended IMAP, IMAP + CONDSTORE, IMAP + CONDSTORE + QRESYNC and IMAP + CONDSTORE + QRESYNC + UIDPLUS. Is the WG really comfortable with this complexity? Perhaps QRESYNC should require UIDPLUS in addition to CONDSTORE? Perhaps QRESYNC is really a refinement of CONDSTORE rather than an extension to it, so perhaps QRESYNC should subsume CONDSTORE and obsolete it? - Chris Newman Applications Area Director _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed May 16 04:13:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoEdS-0002MH-UF; Wed, 16 May 2007 04:13:26 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HoEdN-0002IB-Us for lemonade-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 04:13:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoEdN-0002H5-5f for lemonade@ietf.org; Wed, 16 May 2007 04:13:21 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoEdL-0000xD-El for lemonade@ietf.org; Wed, 16 May 2007 04:13:21 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 74F0D4AC2B for ; Wed, 16 May 2007 10:13:18 +0200 (CEST) Message-Id: Date: Wed, 16 May 2007 10:19:53 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] concerns with draft-ietf-lemonade-reconnect-client-04.txt References: <7CB41CC1AD859AC968313FAB@[10.0.1.21]> In-Reply-To: <7CB41CC1AD859AC968313FAB@[10.0.1.21]> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Chris Newman X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org VERY well put. Your message describes almost everything that makes me uneasy about QRESYNC. Just one comment: Chris Newman writes: > 2. Change in IMAP untagged response model > > For better or worse, IMAP is a cache update protocol model rather than > a request/response protocol model. That means an untagged response > is not bound to a particular command, but rather the portion of the > client's cache state that is updated can be determined solely from > the untagged response itself (the SEARCH response being a notable > exception). This extension changes that model by binding the > VANISHED response to a specific command with the TAG correlator. Are > there servers which execute client commands out-of-order so that such > binding would be necessary? There are servers which execute client commands concurrently. My day job is one, and I think there is another now. I do not know whether this necessitates the TAG correlator. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed May 16 08:10:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoILA-0000nC-HY; Wed, 16 May 2007 08:10:48 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HoIL9-0000n7-5y for lemonade-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 08:10:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoIL8-0000mz-Sd for lemonade@ietf.org; Wed, 16 May 2007 08:10:46 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoIL5-00045P-ET for lemonade@ietf.org; Wed, 16 May 2007 08:10:46 -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 ; Wed, 16 May 2007 13:10:42 +0100 Message-ID: <464AD49A.5020103@isode.com> Date: Wed, 16 May 2007 10:53:30 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Zoltan.Ordogh@nokia.com Subject: Re: [lemonade] Updated Draft: draft-cridland-imap-context References: <13829.1177506908.404308@peirce.dave.cridland.net> <4C38DC11F6B4FF4FAEA73E30DB5AA157812F7D@esebe199.NOE.Nokia.com> <30512.1179167917.106478@peirce.dave.cridland.net> <4C38DC11F6B4FF4FAEA73E30DB5AA1578136E9@esebe199.NOE.Nokia.com> In-Reply-To: <4C38DC11F6B4FF4FAEA73E30DB5AA1578136E9@esebe199.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Zoltan.Ordogh@nokia.com wrote: >>>Section A.1. >>>14. CONTEXT is a replacement for VFOLDER. >>> >>> >>No, it isn't. It's an alternate mechanism for achieving similar >>results. Arnt (and others) will tell you, quite rightly, that VFOLDER >>is optimized for different cases, and covers different requirements. >> >> >>> VFOLDER had the advantage of re-using virtual folders: I could >>>easily create new virtual folders from virtual folders, and >>>altering one virtual folder in the "path" would alter all "child" >>>virtual folders. It appears (or, I missed something) that it is no >>>longer possible using this extension. >>> >>> >>Not directly. The mechanism one might use for doing this is Alexey's >>named filter draft, which would allow you to build composite >>user-defined search keys. I have no idea what the desired result of >>changing one used by an update context would be. >> >> >This draft You are referring to is not part of LEMONADE, is it? > I think this is an open issue. My personal opinion is that my draft should be included in the Lemonade Profile Bis, because it is a missing piece of the whole solution. >Is this draft published somewhere? > > draft-melnikov-imapext-filters-01.txt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed May 16 09:10:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoJGo-0000HF-GM; Wed, 16 May 2007 09:10:22 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HoJGn-0000H8-T3 for lemonade-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 09:10:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoJGn-0000Gj-HZ; Wed, 16 May 2007 09:10:21 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoJGl-0002F6-As; Wed, 16 May 2007 09:10:21 -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 ; Wed, 16 May 2007 14:10:18 +0100 Message-ID: <464B0277.3000905@isode.com> Date: Wed, 16 May 2007 14:09:11 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Internet Drafts Submission Content-Type: multipart/mixed; boundary="------------000007040502060501060708" X-Spam-Score: 0.1 (/) X-Scan-Signature: 880a8a97dfe9ef08c1612a7c933970ae Cc: Lemonade WG Subject: [lemonade] Updated draft: draft-ietf-lemonade-convert X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --------------000007040502060501060708 Content-type: text/plain; charset="us-ascii" Thank you! Alexey --------------000007040502060501060708 Content-type: unknown/exe; name="draft-ietf-lemonade-convert-07.txt" Content-transfer-encoding: 7bit Content-Disposition: inline; filename="draft-ietf-lemonade-convert-07.txt" Internet Draft: CONVERT A. Melnikov (Ed.) Document: draft-ietf-lemonade-convert-07 Isode Limited Intended status: Standard Track R. Cromwell (Ed.) S. H. Maes (Ed.) Oracle Expires: November 2007 May 2007 IMAP CONVERT extension Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Distribution of this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract CONVERT defines extensions to IMAP allowing clients to request adaptation and/or transcoding of attachments. Clients can specify the conversion details or allow servers to decide based on knowledge of client capabilities, on user or administrator preferences or its settings. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. When describing the general syntax, some definitions are omitted as they are defined in [RFC3501]. Table of Contents Status of this Memo ....................................... 1 Copyright Notice........................................... 1 Abstract................................................... 1 Conventions used in this document.......................... 1 Table of Contents.......................................... 2 1. Introduction............................................ 3 2. Relation with other E-mail specifications............... 3 3. Scope of Conversions.................................... 4 4. Discovery with the CAPABILITY and GETMETADATA Commands.. 4 4.1. CAPABILITY......................................... 4 4.2. GETMETADATA ....................................... 4 5. CONVERT extension to BODY and BINARY FETCH data items... 5 6. CONVERT transcoding parameters.......................... 7 6.1. Mandatory Transcoding support...................... 7 6.1.1. Additional features for mobile usage.......... 8 7. FETCH response extensions............................... 8 8. Status responses, Response code extensions.............. 8 9. Formal Syntax........................................... 9 10. IANA Considerations.................................... 11 11. IANA Entry and Attribute registrations ................ 11 11.1. IANA Entry "/convert"............................. 11 11.2. IANA Attribute "types"............................ 12 11.3. IANA Attribute "params"........................... 12 Security Considerations.................................... 12 Normative References....................................... 13 Informative References..................................... 14 Version History............................................ 14 Acknowledgments............................................ 15 Authors' Addresses........................................ 15 Intellectual Property Statement........................... 16 Disclaimer of Validity.................................... 16 Copyright Statement .......................................16 1. Introduction This document defines the CONVERT extension to IMAP4 [RFC3501]. CONVERT provides adaptation and transcoding of body parts as needed by the client. Conversion (adaptation, transcoding) may be requested by the client and performed by the server on a best effort basis or, when requested by the client, decided by the server based on server's knowledge of the client capabilities, user or administrator preferences or servers settings. This extension is primarily intended to be useful to mobile clients. It satisfies requirements specified in [MEMAIL] and [OMA-ME-RD]. A server that supports CONVERT can convert body parts to other formats to be viewed on a mobile device. The client can explicitly request a particular conversion or ask the server to select the best available conversion. When allowed by the client, the server determines how to convert based on its own strategy (e.g. based on knowledge of the client as discussed hereafter). If the server knows the characteristics of the device or can determine them (out of scope for CONVERT), the attachments can also be optimized for the capabilities of the devices (e.g. form factor of pictures). 2. Relation with other E-mail specifications The CONVERT extension does not address conversion during streaming of attachments. CONVERT depends on the METADATA extension [METADATA] to support discovery of supported conversion formats. In addition, to use CONVERT, the server MUST support the IMAP Binary specification [RFC3516]. 3. Scope of Conversions Conversions only affect what is sent to the client; the original data in the message store MUST NOT be altered. This document does not specify how the server performs conversions. Note: The requirement that original data be unaltered allows such data to remain accessible by other clients, permits replies or forwards of the original documents, permits signature verification (the converted body parts are not likely to contain any signatures), and preserves BODYSTRUCTURE and related information. 4. Discovery with the CAPABILITY and GETMETADATA Commands 4.1. CAPABILITY A server that supports the CONVERT extension MUST return "CONVERT", "METADATA", and "BINARY" in the CAPABILITY response. Example: A server that implements CONVERT C: a001 CAPABILITY S: * CAPABILITY IMAP4rev1 CONVERT BINARY METADATA [...] S: a001 OK CAPABILITY completed 4.2. GETMETADATA To determine which conversions are supported, server annotations are used. For each MIME format (/ [MIME-IMT]) that can be converted, an annotation with the name "/convert///types" SHOULD exist. The "value.shared" attribute of this annotation contains a semicolon separated list of type/subtype output formats. The selection of available conversions MAY be adjustable by the server administrator, and MAY be sensitive to the current user. The selection of available conversions MAY also depend on information about the client obtained through a different mechanism outside the scope of CONVERT (e.g. dynamically through device description mechanisms or when the device was associated to the account). For each source MIME type that the client is interested in, it SHOULD determine which target conversions are supported by reading the "value.shared" attribute. In addition to the subtype-specific annotations, a special "wildcard" annotation named "/convert//@/types" MAY be used to reference any subtype of media type. A client that doesn't find an "/convert///types" annotation SHOULD check the value of the "/convert//@/types" annotation. Note that names of server annotations are case-sensitive (see [METADATA]). In order to guaranty interoperability, clients and servers MUST use the lowercases version of and when constructing an annotation name described above. Example: Discover all image conversions C: a GETMETADATA "/convert/image/@/types" value.shared S: * METADATA "/convert/image/@/types" (value.shared "image/jpeg;image/png;image/gif;image/wbmp") S: a OK GETMETADATA complete The above example shows that the server supports one kind of input image transcoding, from image/jpeg to four different outputs: JPEG, PNG, GIF, and WBMP. For a given conversion, optional transcoding parameters MAY be present. These are mapped into the "value.shared" attribute in the "/convert/////params" annotation. A client wishing to use a conversion parameter SHOULD check if the server will accept it by reading the "value.shared" attribute. Example: Discover optional parameters for image/jpeg -> image/gif. C: a GETMETADATA /convert/image/jpeg/image/gif/params "value.shared" S: * METADATA /convert/image/jpeg/image/gif/params ("value.shared" "width;height;depth;interlaced") S: a OK GETMETADATA complete The above example shows that to convert from image/jpeg to image/gif, the transcoding supports the following types of option parameters: width, height, depth, and interlaced. A client MAY use these values to check whether or not a desired conversion is possible, or it might, for example, present the parameters as a GUI preferences pane for the user to customize. This document relies on registry of transcoding parameters established by <<[MEDIAFEAT-REG]>>. The registry can be used to discover the underlying legal values that these parameters may take. Additional transcoding parameters, such as defined by [OMA-STI], are expected to be standardized in the future. 5. CONVERT extension to BODY and BINARY FETCH data items CONVERT defines a FETCH extension used to transcode the media type of a MIME part into another media type, and/or the same media type with different encoding parameters. It adds new options to the section-spec part of the BODY data item, a new FETCH data item CONVERT.SIZE, a new FETCH response data item BODYPARTSTRUCTURE, and new response codes. It is also expected to work with the IMAP BINARY data item extension, whose grammar is modified as well. The response to a CONVERT request always includes a BODYPARTSTRUCTURE. Each request for a BODY or BINARY FETCH data item that contains CONVERT MUST result in a FETCH response containing BODY/BINARY and BODYPARTSTRUCTURE data items containing the same section specifier (including the CONVERT keyword and its parameters). This is needed so that the client can match the requested data items with the received ones. This also allows the client to request multiple conversions of the same body part in a single request. Typically clients will request conversion of leaf body parts. In addition to support of leaf body part conversion, servers MAY offer conversion of non-leaf body parts (e.g. conversion from multipart/related). Instead of specifying the exact target MIME media type the client wants to convert to, the client MAY use a special marker NIL (also known as "default conversion") to request the server to pick a suitable target media type. This document doesn't describe how the server makes such choice. For example, the server can know characteristics of the device through a device description mechanism, or it can have a prioritized lists of MIME types based on how widespread they are, how difficult their rendering is, etc. Note that servers are REQUIRED to support "default conversion" requests. CONVERT's syntax is modeled after the HEADER.FIELDS syntax in [RFC3501], and is generally structured as: BODY[section-part.CONVERT[.STRICT] ("media type/subtype" (parameters))] BODY.PEEK[section-part.CONVERT[.STRICT] ("media type/subtype" (parameters))] BINARY[section-part.CONVERT[.STRICT] ("media type/subtype" (parameters))] BINARY.PEEK[section-part.CONVERT[.STRICT] ("media type/subtype" (parameters))] BINARY.SIZE[section-part.CONVERT[.STRICT] ("media type/subtype" (parameters))] CONVERT.SIZE[section-part[.STRICT] ("media type/subtype" (parameters))] Example: The client fetches body part section 3 in the message with the message sequence number of 2 and asks to have that attachment converted to pdf format. C: a001 FETCH 2 BODY[3.CONVERT ("APPLICATION/PDF")] S: * 2 FETCH (BODYPARTSTRUCTURE[3.CONVERT ("APPLICATION/PDF")] ("APPLICATION" "PDF" () NIL NIL "Base64" 2135 NIL NIL NIL) BODY[3.CONVERT ("APPLICATION/PDF")] {2135} ) S: a001 OK FETCH COMPLETED Example: The client requests for conversion of a text/html section as text/plain and asks for a charset of us-ascii. The server cannot respect the charset conversion request because there are non-us-ascii characters in the html code, so it fails the request with tagged NO response, containing the BADPARAMETERS response code (see section 8). C: b001 FETCH 2 BODY[3.CONVERT.STRICT ("text/plain" ("charset" "us-ascii"))] S: b001 NO [BADPARAMETERS text/html text/plain (charset)] Source text has non us-ascii The same example without .STRICT can look like this: C: b001 FETCH 2 BODY[3.CONVERT ("text/plain" ("charset" "us-ascii"))] S: * 2 FETCH (BODYPARTSTRUCTURE[3.CONVERT ("text/plain" ("charset" "us-ascii"))] ("TEXT" "PLAIN" ("charset" "us-ascii") NIL NIL "Base64" 2135 181 NIL NIL NIL) BODY [3.CONVERT ("text/plain" ("charset" "us-ascii"))] {2135} ) S: b001 OK FETCH COMPLETED The server chose to replace non-us-ascii characters with a us-ascii character such as "?". Example: The client first requests the converted size of a text/html body part converted to text/plain: C: c000 FETCH 2 CONVERT.SIZE[4.STRICT ("TEXT/PLAIN" ("CHARSET" "us-ascii"))] S: * 2 FETCH (CONVERT.SIZE[4.STRICT ("TEXT/PLAIN" ("CHARSET" "us-ascii"))] 2135) S: c000 OK FETCH COMPLETED Later on the client requests 1000 bytes from the converted bodypart, starting from byte 2001: C: c001 FETCH 2 BODY[4.CONVERT.STRICT ("TEXT/PLAIN" ("CHARSET" "us-ascii"))]<2001.1000> S: * 2 FETCH (BODYPARTSTRUCTURE[4.CONVERT.STRICT ("TEXT/PLAIN" ("CHARSET" "us-ascii"))] ("TEXT" "PLAIN" ("charset" "us-ascii") NIL NIL "7bit" 2135 181 NIL NIL NIL) BODY[4.CONVERT.STRICT ("TEXT/PLAIN" ("CHARSET" "us-ascii"))] <2001>{135} ) S: c001 OK FETCH COMPLETED The server is REQUIRED to respect the target MIME type specified by the client in the transcoding request, whether the STRICT qualifier is specified or not. The server is NOT REQUIRED to respect other transcoding request parameters unless the STRICT qualifier is used, although it SHOULD try to make a best effort to fulfill that request if the STRICT qualifier is omitted. Indeed, the server may know a priori information about the client obtained through a different mechanism outside the scope of CONVERT (e.g. dynamically through device description mechanisms or when the device was associated to the account). These preferences MAY be used to predefine what conversions are possible. In addition, this information may also allow attachment adaptation (e.g. picture form factor) instead of solely format conversion. 6. CONVERT transcoding parameters IMAP servers which support CONVERT MAY support additional transcoding parameters for each media type, as defined by the registry established by <<[MEDIAFEAT-REG]>>. All such servers MUST minally support recognition of the "charset" <<[CHARSET-REG]>> parameter for text/plain, text/html, text/css, text/csv, text/enriched and text/xml MIME types. (Note, a server implementation is not required to implement any conversion from the text MIME subtypes specified above, except for the mandatory to implement conversion described in section 6.1. I.e., a server implementation MUST support the "charset" parameter for text/csv, only it supports any conversion from text/csv.) <> C: d001 UID FETCH 100 BINARY[2.CONVERT ("IMAGE/JPG" ( "WIDTH" "128" "HEIGHT" "96"))] S: * 2 FETCH (UID 100 BODYPARTSTRUCTURE[2.CONVERT ( "IMAGE/JPG" ("WIDTH" "128" "HEIGHT" "96"))] ("IMAGE/JPG" () NIL NIL "8bit" 4182 NIL NIL NIL) BINARY[2.CONVERT ("IMAGE/JPG" ("WIDTH" "128" "HEIGHT" "96"))] ~{4182} ) S: d001 OK UID FETCH COMPLETED 6.1. Mandatory Transcoding support A server implementing CONVERT MUST support character set conversions for the text/plain MIME type, and MUST support character set conversions from iso-8859-1, iso-8859-2, iso-8859-3, iso-8859-4, iso-8859-5, iso-8859-6, iso-8859-7, iso-8859-8 and iso-8859-15 to utf-8. The server MUST list "text/plain" as an allowed destination conversion in the "/convert/text/plain/types" annotation. A request for annotation "/convert/text/plain/text/plain/params" MUST return "charset" as a supported transcoding parameter. Servers SHOULD offer additional character encoding conversions where they make sense as character conversion libraries are generally available on many platforms. If STRICT is specified and the server cannot carry out the trancoding while preserving all the characters (i.e. a source character can't be represented in the target character set), the MUST return the BADPARAMETERS response code (see section 8). 6.1.1. Additional features for mobile usage This section is non normative. Based on the expected usage of convert in mobile environments, server implementors should consider support for the following conversions: - Conversion of HTML and XHTML documents to text/plain in ways that preserve at the minimum the document structure and tables. - Image conversions among the types image/gif, image/jpeg and image/png for at least the following parameters: o Size limit (i.e. reduce quality), o width, o height, o resize directive (crop, stretch, aspect ratio) The support for "depth" may also be of interest. Audio conversion is also of interest but the relevant formats depend significantly on the usage context. 7. FETCH request/response extensions 7.1. BODYPARTSTRUCTURE FETCH response item The BODYPARTSTRUCTURE data item is introduced when using the CONVERT extension. Its data follows the exact syntax specified in the [RFC3501] BODYSTRUCTURE data item, but contains information for only the converted part. All information contained in BODYPARTSTRUCTURE pertains to the state of the part after it is converted, such as the converted MIME type, sub-type, size, or charset. The client must respect the return values and not assume the conversion request succeeds exactly as requested unless the STRICT qualifier is used. Note that the client can expect the returned MIME type to match the one it requested (as the server is required to obey the requested MIME type) and can treat mismatch as an error. 7.2. CONVERT.SIZE FETCH request and response item CONVERT.SIZE[section-part[.STRICT] ("media type/subtype" (parameters))] Requests the converted size of the section (i.e., the size to expect in response to the corresponding FETCH BODY request). Note: client authors are cautioned that this might be an expensive operation for some server implementations. Needlessly issuing this request could result in degraded performance due to servers having to calculate the value every time the request is issued. 8. Status responses, Response code extensions A syntactically invalid MIME media type SHOULD generate a BAD tagged response from the server. An unrecognized MIME media type generates a NO tagged response. Some transcodings may require parameters. If a transcoding request with no parameters is sent for a format which requires parameters, the server MUST reply with a tagged NO response that contains the MISSINGPARAMETERS response code. If the server is unable to perform the requested conversion because a resource is temporary unavailable (e.g., lack of disk space, temporary internal error, transcoding service down) then the server MUST return a tagged NO response. The response SHOULD contain the TEMPFAIL response code (see below). If the requested conversion cannot be performed because of a permanent error, for example if a proprietary document format has no existing transcoding implementation, the server MUST return a tagged NO response. Otherwise, the server returns an OK response. The client in general can tell from the BODYPARTSTRUCTURE response whether or not its request was honored exactly, but may not know the reasons why. The following extension response codes are provided for OK and NO responses to disambiguate those situations<<, or warn about possible important data loss>>: TEMPFAIL - the transcoding request failed temporarily. It might succeed later, so the client may retry. BADPARAMETERS from-concrete-mime-type to-mime-type "(" convert-params ")" - the listed parameters were not understood, not valid for the source/destination MIME type pair, had invalid value or could not be honored for another reason noted in the human readable text that follows the response code. <>. MISSINGPARAMETERS from-concrete-mime-type to-mime-type "(" convert-params ")" - the listed parameters are required for conversion of the specified source MIME type to the destination MIME type, but were not seen in the request. 9. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (ABNF) notation as used in [ABNF], and incorporates by reference the Core Rules defined in that document. This syntax augments the grammar specified in [RFC3501] and [RFC3516]. Non-terminals not defined in this document can be found in [RFC3501], [RFC3516] and [MIME-MTSRP]. In the ABNF section-msgtext grammar in section 9 of [RFC3501], Section-msgtext is hereby amended to read: section-convert = "CONVERT" [".STRICT"] SP convert-params section-msgtext =/ section-convert convert-params = "(" (quoted-to-mime-type / default-conversion) [SP "(" transcoding-params ")"] ")" quoted-to-mime-type = DQUOTE to-mime-type DQUOTE transcoding-params = transcoding-param *(SP transcoding-param) transcoding-param = transcoding-param-name SP transcoding-param-value transcoding-param-name = astring ; represented as a quoted, ; literal or atom. Note that ; allows for "%" which is ; not allowed in atoms. Such values must be ; represented as quoted or literal. transcod-param-name-nq = ALPHA *( ALPHA / DIGIT / ":" / "/" / "." / "-" /"%" ) ; <> transcoding-param-value = astring default-conversion = "NIL" fetch-att =/ "CONVERT.SIZE" convert-size-section msg-att-static =/ "CONVERT.SIZE" convert-size-section SP number convert-size-section = "[" section-part [".STRICT"] SP convert-params "]" In the ABNF syntax "section-binary" of [RFC3516], is amended to: section-binary = "[" [section-binary-spec] "]" section-binary-spec = section-part ["." section-convert] / section-convert ; Note that conversion of a top level ; multipart/* is allowed. In the ABNF syntax "msg-att-static" of [RFC3501], is amended to: msg-att-static =/ "BODYPARTSTRUCTURE" section SP "(" body-type-1part ")" <> In the ABNF syntax "resp-text-code" of [RFC3501], is amended to: resp-text-code =/ "TEMPFAIL" / bad-params-resp-code / missing-params-resp-code / mimetype-and-params = from-concrete-mime-type SP to-mime-type SP "(" transcoding-params ")" ; The values can't include the ']' character, as this ; non-terminal is returned in an IMAP response code. <> bad-params-resp-code = "BADPARAMETERS" 1*(SP mimetype-and-params) missing-params-resp-code = "MISSINGPARAMETERS" SP 1*(SP mimetype-and-params) In addition, the following ABNF describes the syntax of the GETMETADATA entries in Section 4.2 convert-entry-req = available-conversions / available-transcoding-parameters available-conversions = "/convert/" from-mime-type "/types" any-mime-type = "@" from-mime-type = (type-name "/" any-mime-type) / concrete-mime-type ; "type/@" or "type/subtype" ; type-name is defined in [MIME-MTSRP]. concrete-mime-type = type-name "/" subtype-name ; i.e. "type/subtype". ; type-name and subtype-name ; are defined in [MIME-MTSRP]. <> from-concrete-mime-type = concrete-mime-type to-mime-type = concrete-mime-type available-transcoding-parameters = "/convert/" from-concrete-mime-type "/" to-mime-type "/params" ; Name of an annotation containing transcoding parameters. ; i.e. /convert/frmtype/frmsubtype/totype/tosubtype/params. The "value.shared" syntax of any "/convert///types" annotation has the following syntax: types-shared-value = from-concrete-mime-type *(";" from-concrete-mime-type) The "value.shared" syntax of any "/convert/// //params" annotation has the following syntax: params-shared-value = transcoding-param-name *(";" transcoding-param-name) 10. IANA Considerations IMAP4 capabilities are registered by publishing a standards track or IESG approved experimental RFC. The registry is currently located at . This document defines the CONVERT IMAP capability. This extension shall be submitted to the IANA IMAP Capability registry. 10.1. IANA Entry and Attribute registrations The following sections specify IANA registrations for entries and attributes used in this document. 10.1.1. IANA Entry "/convert" To: iana@iana.org Subject: IMAP METADATA Registration Please register the following IMAP METADATA item: [x] Entry [ ] Attribute [ ] Mailbox [x] Server Name: /convert Description: All annotations below this one are reserved for use by [this RFC] and its extensions. Content-type: text/plain; charset=utf-8 Contact person: Alexey Melnikov email: alexey.melnikov@isode.com <> 10.1.2. IANA Entry "/convert///types" To: iana@iana.org Subject: IMAP METADATA Registration Please register the following IMAP METADATA item: [x] Entry [ ] Attribute [ ] Mailbox [x] Server Name: /convert///types Description: Defined in [this RFC], Section 4.2. Content-type: text/plain; charset=us-ascii Contact person: Alexey Melnikov email: alexey.melnikov@isode.com 10.1.3. IANA Entry "/convert/.../params" To: iana@iana.org Subject: IMAP METADATA Registration Please register the following IMAP METADATA item: [x] Entry [ ] Attribute [ ] Mailbox [x] Server Name: /convert//// /params Description: Defined in [this RFC], Section 4.2. Content-type: text/plain; charset=utf-8 Contact person: Alexey Melnikov email: alexey.melnikov@isode.com 11. Security Considerations It is to be noted that some conversions may present security threats (e.g. converting a document to a damaging executable, exploiting a buffer overflow in a media codec/parser, or a denial of service attack against a client or server such as requesting an image be scaled to extremely large dimensions). Clients should be careful when requesting conversions or processing transformed attachments. Servers should avoid dangerous conversions if possible. Whenever possible, servers should perform verification of the converted attachments before returning them to the client. A client can create a carefully crafted bad message with the APPEND command followed by the FETCH command to attack the server. If the server's conversion function or library has a security problem, this could result in provilege escalation or Denial of Service. On bandwidth limited mobile networks where users pay per data volumes, spam may become an important issue. It can be mitigated with appropriate filters and server-side spam prevention tools. These are of course outside the scope of CONVERT. Deployments in which the actual transcoding is done outside the IMAP server in a separate server are recommended to keep the servers in the same trusted domain (e.g. subnet) 12. References 12.1. Normative References [METADATA] Daboo, C., "IMAP METADATA Extension", work in progress, draft-daboo-imap-annotatemore-11, 2007. [ABNF] D. Crocker, et al. "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. http://www.ietf.org/rfc/rfc4234 [RFC2119] Brader, S. "Keywords for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. http://www.ietf.org/rfc/rfc2119 [RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol Version 4 rev1", RFC 3501, March 2003. http://www.ietf.org/rfc/rfc3501 [RFC3516] Nerenberg, L. "IMAP4 Binary Content Extension", RFC 3516, April 2003. http://www.ietf.org/rfc/rfc3516.txt [MIME-IMT] Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail Extensions) Part Two: Media Types", RFC 2046, November 1996. [MIME-MTSRP] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", RFC 4288, December 2005. <> 12.2. Informative References [MEMAIL] Maes, S.H., "Lemonade and Mobile e-mail", draft-maes- lemonade-mobile-email-xx.txt, (work in progress). [OMA-ME-RD] Open Mobile Alliance Mobile Email Requirement Document, work in progress, http://www.openmobilealliance.org/ [OMA-STI] Open Mobile Alliance, Standard Transcoding Interface Specification, version 1.0, work in progress, . 13. Acknowledgments The authors want to specifically acknowledge the excellent criticism and comments received from Randall Gellens (Qualcomm), Arnt Gulbrandsen (Oryx), Zoltan Ordogh (Nokia), Ben Last (Emccsoft), Dan Karp (Zimbra) which improved the quality of the CONVERT specification considerably. The authors also want to thank all who have contributed key insight and extensively reviewed and discussed the concepts of CONVERT and its predecessor P-IMAP. In particular, this includes the authors of the LCONVERT draft: Rafiul Ahad (Oracle Corporation), Eugene Chiu (Oracle Corporation), Ray Cromwell (Oracle Corporation), Jia-der Day (Oracle Corporation), Vi Ha (Oracle Corporation), Wook- Hyun Jeong (Samsung Electronics Co. LTF), Chang Kuang (Oracle Corporation), Rodrigo Lima (Oracle Corporation), Stephane H. Maes (Oracle Corporation), Gustaf Rosell (Sony Ericsson), Jean Sini (Symbol Technologies), Sung-Mu Son (LG Electronics), Fan Xiaohui (CHINA MOBILE COMMUNICATIONS CORPORATION (CMCC)), Zhao Lijun (CHINA MOBILE COMMUNICATIONS CORPORATION (CMCC)). 14. Authors' Addresses Stephane H. Maes (Editor) Oracle Corporation 500 Oracle Parkway M/S 4op634 Redwood Shores, CA 94065 USA Phone: +1-650-607-6296 Email: stephane.maes@oracle.com Ray Cromwell (Editor) Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065 USA Alexey Melnikov (Editor) Isode Limited 5 Castle Business Village, 36 Station Road, Hampton, Middlesex, TW12 2BX, UK Email: Alexey.Melnikov@isode.com Version History Note to RFC-editor: Please delete this section before publication Open Issues - Should conversion *to* non-leaf body parts be allowed? - Remove .STRICT specifier? Are there any cases when the client would like to specify a transcoding parameter that can be ignored by the server? - Reuse IANA registry from RFC 2506 or define our own? - Use METADATA or define own commands for requesting possible conversions and associated parameters? ToDo - If IANA registry from RFC 2506 is selected, then "width" and "height" in examples will need to be replaced with "pix-x" and "pix-y" Release 07 - Made default conversion mandatory for servers to support - Added CONVERT.SIZE FETCH data item - Removed INFORMATIONLOSS and SERVEROVERRIDE response codes - Added TEMPFAIL and MISSINGPARAMETERS response codes - Addressed editorial comments from Randy Gellens - Updated examples and ABNF Release 06 - Allow conversion of non-leaf body parts. - Clarified that the target MIME type must be obeyed. - Changed from using new annotation attributes to standard ones - Major corrections to the ABNF section. - Disallow /convert/* annotation entry. - The * character is not allowed in annotation names, so the @ character is used instead. - Clarified handling of default conversion. - Updated examples to match ABNF. - Updated or added missing references. Release 05 - Client not mandated to support BINARY - Misc syntax and spelling fixes - New abstract contributed by Randall Gellens Release 04 - Remove compression and encryption - Update to use latest METADATA draft - Add IANA registrations Release 03 - Add mandatory character set conversions. - Add object level compression - Add object level encryption Release 02 Fixed a normative example to be informative. Added formal syntax for BODYPARTSTUCTURE, response text codes, and formal structure of composite GETANNOTATE values. Release 01 Corrected some grammatical mistakes. Clarified meaning of GETTANNOTATION response properties. Changed CONVERT grammar to merge media type and subtype into a single parameter instead of two parameters. Clarified that BODYSTRUCTURERESPONSE is always returned for CONVERT requests. Moved transcoding parameter discussion to main body from appendix. Release 00 Initial release published in October 2005 based on draft-maes- lemonade-lconvert-00 and the comments received at the London face to face meeting end of September 2005. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. --------------000007040502060501060708 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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --------------000007040502060501060708-- From lemonade-bounces@ietf.org Wed May 16 09:13:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoJJY-0000xB-Qv; Wed, 16 May 2007 09:13:12 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HoJJX-0000x6-UP for lemonade-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 09:13:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoJJX-0000wy-Ko for lemonade@ietf.org; Wed, 16 May 2007 09:13:11 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoJJU-0002lm-Pj for lemonade@ietf.org; Wed, 16 May 2007 09:13:11 -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 ; Wed, 16 May 2007 14:13:07 +0100 Message-ID: <464B0321.1000304@isode.com> Date: Wed, 16 May 2007 14:12:01 +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: Lemonade WG References: <464B0277.3000905@isode.com> In-Reply-To: <464B0277.3000905@isode.com> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [lemonade] Re: Updated draft: draft-ietf-lemonade-convert X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 just realized that I forgot to submit -07. Changes in the latest version: - Made default conversion mandatory for servers to support - Added CONVERT.SIZE FETCH data item - Removed INFORMATIONLOSS and SERVEROVERRIDE response codes - Added TEMPFAIL and MISSINGPARAMETERS response codes - Addressed editorial comments from Randy Gellens - Updated examples and ABNF _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed May 16 09:44:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoJoF-0005Qq-Od; Wed, 16 May 2007 09:44:55 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HoJoF-0005Qb-1b for lemonade-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 09:44:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoJoE-0005QM-Ns for lemonade@ietf.org; Wed, 16 May 2007 09:44:54 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoJoD-0005PR-9K for lemonade@ietf.org; Wed, 16 May 2007 09:44:54 -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 ; Wed, 16 May 2007 14:44:52 +0100 Message-ID: <464B0A92.1050601@isode.com> Date: Wed, 16 May 2007 14:43: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: Lemonade WG 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: c1c65599517f9ac32519d043c37c5336 Subject: [lemonade] Status of various Lemonade WG documents X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Here is the updated status of various WG documents as I see it. Please let me know if you want to correct/add something: draft-ietf-lemonade-search-within-04.txt - Dave has suggested some text, which looks fine to me. Arnt has suggested (privately) similar text. Message Events (currently draft-ietf-lemonade-msgevent-02.txt) - - Most of my issues were addresses, a couple of minor nits remain. The document is ready for WGLC. IMAP URL (draft-ietf-lemonade-rfc2192bis-06.txt) - WGLC has ended. -06 addressed concerns raised by Ted and Zoltan. There a couple of minor issues, but once they are addressed the document will be ready for IESG. IMAP CONTEXT (draft-cridland-imap-context-02.txt) - WGLC ended. Dave has published -02, which addressed most of the received comments. Dave needs to reply to Zoltan, after that he should either publish -03, or -02 can be sent to IESG for publication. IMAP CONVERT - I forgot to post -07 (done now). Remaining issues that need to be discussed: - Removal of .STRICT specifier - IANA registry for transcoding parameters - Use of METADATA extension or defining ad-hoc commands for requesting possible conversions and associated parameters This document needs to be discussed during the interim. Once the decision on each issue is made, I can update the document quickly. draft-ietf-lemonade-streaming-02.txt - People need to review if it addressed the issues raised during WGLC. The issue of fetching bodyparts as binary is still pending. - Need to find a volunteer for writing up a small document with extension to URLAUTH (as suggested by Dave) IMAP QRESYNC - Chris just sent out a list of 4 concerns. Dave and I need to followup on them. One of the issues can be partially addressed by making QRESYNC depend on Arnt's ENABLE extension. IMAP NOTIFY (currently draft-gulbrandsen-imap-notify-06.txt) - Arnt and/or I will send a list of open issues separately. -06 is getting close to be done, but we need to wait for at least -07 before starting WGLC. There would be some syntactic changes between -06 and -07. ENABLE - As per my comment above, the WG needs to decide if this should be a part of Lemonade Profile Bis. IMAP extension for stored searches (draft-melnikov-imapext-filters-01.txt) - The document is ready for IESG. - Need to decide if this is a part of Lemonade Profile Bis. draft-ietf-lemonade-notifications-04.txt - Randy should tell us what the status of the document is. I don't think the document is ready for WGLC. SMTP QUICKRESTART - need to reach WG consensus on whether to include this in Lemonade Profile Bis or not. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed May 16 09:59:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoK22-000542-4N; Wed, 16 May 2007 09:59:10 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HoK21-00053x-16 for lemonade-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 09:59:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoK20-00053m-Nb for lemonade@ietf.org; Wed, 16 May 2007 09:59:08 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoK1z-0002KK-BF for lemonade@ietf.org; Wed, 16 May 2007 09:59:08 -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 ; Wed, 16 May 2007 14:59:06 +0100 Message-ID: <464B0DE7.3040802@isode.com> Date: Wed, 16 May 2007 14:57:59 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lemonade WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [lemonade] Suggested changes to draft-ietf-lemonade-rfc2192bis-06.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 There are two minor issues remaining in the document. 1). In section 3.2: >If no user name and no authentication mechanism is supplied, >the client must authenticate as anonymous to the server. I would like change "must" to "MUST". Any objections? 2). In section 5 >An IMAP URL referring to a list of messages has the following form: > > imap:///[][?] > >The field is optional. If it is present, it MUST be the >same as the value of IMAP4 UIDVALIDITY response code at the time the URL >was created. This SHOULD be used by the program interpreting the IMAP >URL to determine if the URL is stale. I would like to change the SHOULD to the MUST. Any objections? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed May 16 10:07:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoKA0-0002Lz-SR; Wed, 16 May 2007 10:07:24 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HoK9z-0002Lu-Qk for lemonade-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 10:07:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoK9z-0002Lm-H9 for lemonade@ietf.org; Wed, 16 May 2007 10:07:23 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoK9x-0005DP-Uq for lemonade@ietf.org; Wed, 16 May 2007 10:07:23 -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 ; Wed, 16 May 2007 15:07:20 +0100 Message-ID: <464B0FD5.1060305@isode.com> Date: Wed, 16 May 2007 15:06:13 +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: Lemonade WG 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: c1c65599517f9ac32519d043c37c5336 Subject: [lemonade] Suggested agenda for the Lemonade interim X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org My take on the agenda for the Interim meeting: Wednesday 16: Quick status of several drafts: 1) draft-cridland-imap-context-02.txt 2) draft-ietf-lemonade-streaming-02.txt - Volunteer for URLAUTH extension? 3) draft-ietf-lemonade-search-within-04.txt - confirm WG consensus on Dave's text. 4) draft-ietf-lemonade-rfc2192bis-06.txt - Do we need a syntactic extension for "must use STARTTLS" (in this document or in a separate one)? - two minor open issues (a separate email was just sent) 5) draft-ietf-lemonade-msgevent-02.txt - Make MailboxSubscribe and MailboxUnSubscribe a single event with boolean parameter? - Should the document describe how ACLs are to be returned - Naming of events (e.g. MessageExpunge instead of ExpungeMessage) ENABLE - is it part of Lemonade Profile Bis? draft-melnikov-imapext-filters-01.txt - is it part of Lemonade Profile Bis? IMAP NOTIFY (currently draft-gulbrandsen-imap-notify-06.txt) - Arnt and/or myself will send a list of open issues separately. -06 is getting close to be done, but we need to wait for at least -07 before starting WGLC. There would be some syntactic changes between -06 and -07. Thursday 17th: IMAP CONVERT - Removal of .STRICT specifier - IANA registry for transcoding parameters - Use of METADATA extension or defining ad-hoc commands for requesting possible conversions and associated parameters draft-ietf-lemonade-notifications-04.txt Any other business Does this seem reasonable? Alexey P.S. I would like to deal with Arnt's documents today, as he is in holidays tomorrow. I would also like to let Dave talk about his documents earlier in the day. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed May 16 10:54:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoKtR-0000hu-LO; Wed, 16 May 2007 10:54:21 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HoKtP-0000hS-N2 for lemonade-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 10:54:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoKtP-0000hH-DI for lemonade@ietf.org; Wed, 16 May 2007 10:54:19 -0400 Received: from mxout4.cac.washington.edu ([140.142.33.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoKtN-0007L1-VW for lemonade@ietf.org; Wed, 16 May 2007 10:54:19 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout4.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l4GEsGfE003069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 May 2007 07:54:16 -0700 X-Auth-Received: from Ningyo-no-Mori.Panda.COM (D-69-91-141-133.dhcp4.washington.edu [69.91.141.133]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l4GEsGXk002131 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 16 May 2007 07:54:16 -0700 Date: Wed, 16 May 2007 07:54:05 -0700 (Pacific Daylight Time) From: Mark Crispin To: Arnt Gulbrandsen Subject: Re: [lemonade] concerns with draft-ietf-lemonade-reconnect-client-04.txt In-Reply-To: Message-ID: References: <7CB41CC1AD859AC968313FAB@[10.0.1.21]> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.5.16.73936 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: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: lemonade@ietf.org, Chris Newman X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 I very much oppose any change to IMAP's core principles. On Wed, 16 May 2007, Arnt Gulbrandsen wrote: > VERY well put. Your message describes almost everything that makes me uneasy > about QRESYNC. > > Just one comment: > > Chris Newman writes: >> 2. Change in IMAP untagged response model >> >> For better or worse, IMAP is a cache update protocol model rather than a >> request/response protocol model. That means an untagged response is not >> bound to a particular command, but rather the portion of the client's cache >> state that is updated can be determined solely from the untagged response >> itself (the SEARCH response being a notable exception). This extension >> changes that model by binding the VANISHED response to a specific command >> with the TAG correlator. Are there servers which execute client commands >> out-of-order so that such binding would be necessary? > > There are servers which execute client commands concurrently. My day job is > one, and I think there is another now. I do not know whether this > necessitates the TAG correlator. > > Arnt > > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade > Supplemental Web Site: > http://www.standardstrack.com/ietf/lemonade > -- 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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed May 16 11:04:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoL3V-0007yt-9i; Wed, 16 May 2007 11:04:45 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HoL3V-0007yo-2l for lemonade-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 11:04:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoL3U-0007yg-PL for lemonade@ietf.org; Wed, 16 May 2007 11:04:44 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoL3T-0002ql-F9 for lemonade@ietf.org; Wed, 16 May 2007 11:04:44 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l4GF4fcu023342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 16 May 2007 08:04:41 -0700 Received: from [[192.168.1.13]] (vpn-10-50-0-54.qualcomm.com [10.50.0.54]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l4GF4b5H005695; Wed, 16 May 2007 08:04:37 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <463FACDD.8020300@isode.com> References: <001d01c78938$55e9fb80$01bdf280$@org> <463B6CA1.3060308@isode.com> <000e01c78eb6$f9f60330$ede20990$@org> <463FACDD.8020300@isode.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Wed, 16 May 2007 08:04:04 -0700 To: Alexey Melnikov , Larry Masinter From: Randall Gellens Subject: Re: [lemonade] RE: Review request for draft-ietf-lemonade-convert-06.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: 79899194edc4f33a41f49410777972f8 Cc: 'Ted Hardie' , lemonade@ietf.org, 'Graham Klyne' X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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:49 PM +0100 5/7/07, Alexey Melnikov wrote: >> Under what circumstances is it preferable >> for the client to supply conversion parameters rather than >> output constraints based on client capabilities? >> > I can't think of any at the moment. Perhaps user override? For example, a message contains a PowerPoint file, which the device can't render. User asks to see content. Client asks server to convert to HTML, shows that to user, but it looks so bad the user can't figure it out. So the user asks to see it as an image. This is a bit of a stretch, I'll grant. -- 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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed May 16 15:50:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoPWF-00015m-P9; Wed, 16 May 2007 15:50:44 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HoPW5-0000nK-GI for lemonade-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 15:50:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoPW5-0000mf-15; Wed, 16 May 2007 15:50:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HoPW4-0005Zk-Mw; Wed, 16 May 2007 15:50:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 8C75C17640; Wed, 16 May 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HoPVa-0006BH-4q; Wed, 16 May 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 16 May 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-07.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to Support Diverse Service Environments Working Group of the IETF. Title : IMAP CONVERT extension Author(s) : S. Maes, et al. Filename : draft-ietf-lemonade-convert-07.txt Pages : 0 Date : 2007-5-16 CONVERT defines extensions to IMAP allowing clients to request adaptation and/or transcoding of attachments. Clients can specify the conversion details or allow servers to decide based on knowledge of client capabilities, on user or administrator preferences or its settings. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-convert-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-convert-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-convert-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-5-16110141.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-convert-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-convert-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-16110141.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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --NextPart-- From lemonade-bounces@ietf.org Wed May 16 17:24:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoQyW-0000U7-DF; Wed, 16 May 2007 17:24:00 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HoQyV-0000Pz-8Q for lemonade-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 17:23:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoQyU-0000Pr-Un for lemonade@ietf.org; Wed, 16 May 2007 17:23:58 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoQyT-0001Gz-Ah for lemonade@ietf.org; Wed, 16 May 2007 17:23:58 -0400 Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4GLNuP1026593 for ; Wed, 16 May 2007 21:23:56 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JI500E01KG9KP00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for lemonade@ietf.org; Wed, 16 May 2007 15:23:56 -0600 (MDT) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JI5008Z8KRTTR10@mail-amer.sun.com>; Wed, 16 May 2007 15:23:56 -0600 (MDT) Date: Wed, 16 May 2007 14:23:54 -0700 From: Chris Newman Subject: Re: [lemonade] QUICKSTART update In-reply-to: To: Tony Finch , lemonade@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 Finch wrote on 4/19/07 19:56 +0100: > draft-fanf-smtp-quickstart-a-00 and draft-fanf-smtp-quickstart-b-00 have > been published. I've separated it into two documents to make the two > different profiles clearer. I prefer the -B profile but I'd like opinions > from others about the trade-off between complexity and effectiveness. Taking off my area director hat, and speaking as a technical participant: It's my opinion that the way profile B interacts with the TLS layer is problematic for implementations. The server code I work on uses the NSS (Mozilla) SSL/TLS library. While it would be possible to implement profile B using that SSL/TLS library, it's very difficult as it requires writing a special NSPR I/O layer that slots below the SSL stack and deals with the STARTTLS server response after the client has activated the TLS state machine. Requiring tricky code like that for security integration is never a good idea. The problem is that activating the TLS layer is a software state change that takes over both socket directions. So it really shouldn't happen until the only subsequent protocol will be TLS packets. Having secure and non-secure packets in-transit at the same time is not a good idea from a state management point of view. If you want additional input on the topic, I suggest asking on the TLS WG mailing list. - Chris _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed May 16 18:12:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoRja-0008S2-CV; Wed, 16 May 2007 18:12:38 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HoRjY-0008NH-Sn for lemonade-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 18:12:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoRjY-0008N9-It for lemonade@ietf.org; Wed, 16 May 2007 18:12:36 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoRjY-0006TM-1o for lemonade@ietf.org; Wed, 16 May 2007 18:12:36 -0400 Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4GMCZ1Y022517 for ; Wed, 16 May 2007 22:12:35 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JI500001MQX5Q00@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Wed, 16 May 2007 16:12:35 -0600 (MDT) Received: from kluane ([206.47.36.82]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JI500D9UN0YENU2@mail-amer.sun.com> for lemonade@ietf.org; Wed, 16 May 2007 16:12:35 -0600 (MDT) Date: Wed, 16 May 2007 18:12:33 -0400 From: Peter Coates To: lemonade@ietf.org Message-id: <00dd01c79807$4e248e00$ea6daa00$%coates@sun.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-ca Thread-index: AceYB0z8qwxusF3xR02Awd5itMXvHg== X-Spam-Score: 0.0 (/) X-Scan-Signature: 958aa603499a3de6b2b87d68741ed60e Subject: [lemonade] minutes of lemonade interim 16 May 2007 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 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="===============0388711814==" Errors-To: lemonade-bounces@ietf.org This is a multipart message in MIME format. --===============0388711814== Content-type: multipart/alternative; boundary="Boundary_(ID_PgqUMsFxpFSMwWQoV1TdwQ)" Content-language: en-ca This is a multipart message in MIME format. --Boundary_(ID_PgqUMsFxpFSMwWQoV1TdwQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT In the Room: Eric burger, Bea Peter Coates, Sun Darryl Champagne, Funambol Glenn Parsons, Nortel Brook Hayes, RIM Randy Gellens Pete Resnick On the Phone: Anil Srivastava, Sun Arnt Gulbrandsen Phil Guenther Alexey Melnikov Chris Newman Cyrus Daboo Greg Vandreuil Intent: go through docs looking at status. Search within: Search within in a context is a dynamic search A static search is exact. Plea to client writers. If the server does not tell the client when the updates are going to happen does the client care. Arnt's server with have configuration option for update frequency Eric: suggest new messages appear immediately, old messages go away eventually Alexey's update immediately Long argument about the sentence about how often WITHIN gets evaluated. Very Long. Very very long Eric sent to the list text con which there was a consensus in the room and on the call. IMAP URLS Add element to IMAP URLS to requite TLS? . not for now Convert phrase in URL? .not for now The chairs may decide to put this to working group last call based on their judgment on the level of churn in the document since -04 Message events ACLs are not being discussed in the message event document. Subscribe/unsubscribe remain separate events AI Randy: Event names will be systematized AI Glen: This needs to go to last call Notify: The draft will be modified so that notifications on message events will be specified by mailboxes with no wild carding or subtrees or anything like that. Notifications on mailbox events will be on mailboxes or subtrees. Notifications will be additive; that is, issuing a notify command adds to notifications already in effect unless it is a notification reset command which clears notifications down. If a mailbox is deleted, any subscription to notifications on that mailbox is cancelled. If a mailbox is renamed, subscriptions to notifications on that mailbox are carried across (Is that what we said?) Arnt will have -07 on Tuesday Last call on -08 Enable goes into lemonade BIS QRESYNCH will require ENABLE IMAP XFilter Alexey will push forward and see if anyone cares about this. Context Useful for low bandwidth, low memory clients. But not a lot of use without sort. Needs reworking with sort. AI David: rework with sort and we'll look at it again. There is consensus that sort to should be in profile bis Extension to URLFETCH to return binary This is important for streaming to make the interface between the streaming server and IMAP "clean". Dave AI: to do update URLETCH, N Cook to update the streaming doc to reflect the changes. --Boundary_(ID_PgqUMsFxpFSMwWQoV1TdwQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

In the Room:

Eric burger, Bea

Peter Coates, Sun

Darryl Champagne, Funambol

Glenn Parsons, Nortel

Brook Hayes, RIM

Randy Gellens

Pete Resnick

 

On the Phone:

Anil Srivastava, Sun

Arnt Gulbrandsen

Phil Guenther

Alexey Melnikov

Chris Newman

Cyrus Daboo

Greg Vandreuil

 

Intent: go through docs looking at status.

 

Search within:

Search within in a context is a dynamic search

A static search is exact.

Plea to client writers.  If the server does not tell the client when the updates are going to happen does the client care.

Arnt’s server with have configuration option for update frequency

Eric: suggest new messages appear immediately, old messages go away eventually

Alexey’s update immediately

Long argument about the sentence about how often WITHIN gets evaluated.  Very Long.  Very very long

Eric sent to the list text con which there was a consensus in the room and on the call.

 

IMAP URLS

Add element to IMAP URLS to requite TLS?  … not for now

Convert phrase in URL?  …not for now

The chairs may decide to put this to working group last call based on their judgment on the level of churn in the document since -04

 

Message events

ACLs are not being discussed in the message event document.

Subscribe/unsubscribe remain separate events

AI Randy: Event names will be systematized

AI Glen: This needs to go to last call

 

Notify:

The draft will be modified so that notifications on message events will be specified by mailboxes with no wild carding or subtrees or anything like that.

Notifications on mailbox events will be on mailboxes or subtrees.

Notifications will be additive;   that is, issuing a notify command adds to notifications already in effect unless it is a notification reset command which clears notifications down.

If a mailbox is deleted, any subscription to notifications on that mailbox is cancelled.

If a mailbox is renamed, subscriptions to notifications on that mailbox are carried across (Is that what we said?)

Arnt will have -07 on Tuesday

Last call on -08

 

Enable goes into lemonade BIS

QRESYNCH will require ENABLE

 

IMAP XFilter

Alexey will push forward and see if anyone cares about this.

 

Context

Useful for low bandwidth, low memory clients.  But not a lot of use without sort.  Needs reworking with sort.

AI David: rework with sort and we’ll look at it again.

There is consensus that sort to should be in profile bis

 

Extension to URLFETCH to return binary

This is important for streaming to make the interface between the streaming server and IMAP “clean”.

Dave AI: to do update URLETCH, N Cook to update the streaming doc to reflect the changes.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

--Boundary_(ID_PgqUMsFxpFSMwWQoV1TdwQ)-- --===============0388711814== 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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============0388711814==-- From lemonade-bounces@ietf.org Wed May 16 23:30:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoWhP-00082x-3a; Wed, 16 May 2007 23:30:43 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HoWhN-00082r-6R for lemonade-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 23:30:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoWhM-00082j-Qs for lemonade@ietf.org; Wed, 16 May 2007 23:30:40 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoWhJ-00078q-DJ for lemonade@ietf.org; Wed, 16 May 2007 23:30:40 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4H3UX4T025680 for ; Wed, 16 May 2007 20:30:33 -0700 Received: from rcpbex01.amer.bea.com (repbex01.bea.com [10.168.26.17] (may be forged)) by repmmr01.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4H3UVII016871 for ; Wed, 16 May 2007 20:30:32 -0700 Received: from 172.24.28.63 ([172.24.28.63]) by rcpbex01.amer.bea.com ([10.168.26.17]) with Microsoft Exchange Server HTTP-DAV ; Thu, 17 May 2007 03:31:28 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Wed, 16 May 2007 23:30:29 -0400 From: Eric Burger To: Message-ID: Thread-Topic: Proposed SEARCH WITHIN Text Thread-Index: AceYM7dW9iQ0OQQmEdykVwAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [lemonade] Proposed SEARCH WITHIN Text X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org OLDER/YOUNGER always result in exact matching, to the resolution of a second. However, if one is doing a dynamic evaluation, for example, in a context, one needs to be aware the server might perform the evaluation periodically and the updates may be delayed. Note the lack of any 2119 words. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu May 17 06:43:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HodS6-0000mB-PJ; Thu, 17 May 2007 06:43:22 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HodS5-0000m6-VH for lemonade-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 06:43:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HodS5-0000ly-Kx for lemonade@ietf.org; Thu, 17 May 2007 06:43:21 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HodS4-0002gM-CK for lemonade@ietf.org; Thu, 17 May 2007 06:43:21 -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 ; Thu, 17 May 2007 11:43:16 +0100 Message-ID: <464C3181.3030808@isode.com> Date: Thu, 17 May 2007 11:42:09 +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] Proposed SEARCH WITHIN Text 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: 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 Eric Burger wrote: >OLDER/YOUNGER always result in exact matching, to the resolution of a >second. However, if one is doing a dynamic evaluation, for example, in a >context, one needs to be aware the server might perform the evaluation > > Change "context" to "CONTEXT", otherwise it is ambiguous. >periodically and the updates may be delayed. > > Looks fine to me otherwise. >Note the lack of any 2119 words. > > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu May 17 11:49:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoiDu-000104-Ju; Thu, 17 May 2007 11:49:02 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HoiDt-0000zw-OO for lemonade-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 11:49:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoiDt-0000zo-Ec; Thu, 17 May 2007 11:49:01 -0400 Received: from dovecot.org ([213.157.71.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoiDr-0006bn-TS; Thu, 17 May 2007 11:49:01 -0400 Received: from [192.168.10.2] (82-203-162-146.dsl.gohome.fi [82.203.162.146]) by dovecot.org (Postfix) with ESMTP id 5F374F0C89; Thu, 17 May 2007 18:48:58 +0300 (EEST) From: Timo Sirainen To: Dave Cridland In-Reply-To: <30512.1179169211.052893@peirce.dave.cridland.net> References: <30512.1179169211.052893@peirce.dave.cridland.net> Date: Thu, 17 May 2007 18:48:58 +0300 Message-Id: <1179416938.32181.856.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: Enhancements to Internet email to support diverse service enivronments , Messaging Organization Subject: [lemonade] Re: [MORG] Context update X-BeenThere: lemonade@ietf.org X-Mailman-Version: 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="===============1023990504==" Errors-To: lemonade-bounces@ietf.org --===============1023990504== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Cxgj+DZE95MEsL9pGgJZ" --=-Cxgj+DZE95MEsL9pGgJZ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2007-05-14 at 20:00 +0100, Dave Cridland wrote: > I've just submitted update to my IMAP CONTEXT draft. >=20 > I've put it up at=20 > http://dave.cridland.net/draft-cridland-imap-context-02.txt until=20 > it's announced. I'm planning on implementing virtual mailboxes to my server, but I think CONTEXT won't be integrated with that feature. CONTEXT seems like it's useful for temporary views of mailboxes, while actual virtual mailboxes are more permanent and often generated from multiple physical mailboxes. For example CONTEXT mentions virtual Trash, but people usually want the Trash to contain \Deleted messages from all the mailboxes, not just one. Also since CONTEXT requires that the mailbox is selected and so all the flag changes, expunges etc. are sent to clients, this doesn't really give server the possibility of optimizing the search views the same way as separate virtual mailboxes would. I could still implement CONTEXT, but I think saying virtual mailboxes could be implemented with it is a bit misleading. At least I was expecting CONTEXT to be quite different. I read the draft now for the first time without knowing anything about CONTEXT before that. Some comments: 3.1: "Such servers also accept three additional return options, and provide three new result data items, and no new responses." I've no idea what return options or result data items are at this point. After reading far enough down I finally figure out it's talking about ESEARCH. So mentioning [ESEARCH] already in the first sentence would be helpful. 3.2: "The return option CONTEXT SHOULD be used by a client to indicate that subsequent use of the criteria are likely." "the search criteria" would have helped me to understand this more easily. 3.3.2: The client MUST process (and the server MUST generate) ADDTO and REMOVEFROM return data items in order, including those within a single ESEARCH response. What order? 3.3.3: The ADDTO return data item MAY include several new results to be inserted - therefore it is imporant to note that the positions included in a single ADDTO return data item contain positions before the shifting due to other new results take place. I can't parse that sentence. I'm guessing it means that if there are multiple results the shifting needs to be done after processing the next result. Or exactly the opposite. If the position is non-zero, the new results in the update are to be What if it's zero? I don't think I understand this position thing at all since it can even be ignored by clients. Or is it related to SORT? 3.3.4: S: * ESEARCH (TAG "B01") UID REMOVEFROM 32768 C: B03 NOOP S: * EXPUNGE 23762 S: B03 OK Nothing done. "* 23762 EXPUNGE". And maybe a note that the REMOVEFROM MUST be sent before the EXPUNGE (at least with sequences). 3.3.5: The server MAY free any resource associated with a context so disabled. ? 3.4: Where a PARTIAL search return option references results which do not exist, by using a range which starts or ends higher than the COUNT of results, then the server returns those results which are in the set. This yields a PARTIAL return data item which has, as payload, the original range and a potentially missing set of results which may be shorter than the extent of the range. This paragraph is somewhat weird. It's not necessary to do COUNT for a partial SEARCH, so mentioning COUNT in there isn't probably right. And if the mailbox had changed since the COUNT was returned, the range does exist. Unless that's what the last sentence tries to say with "missing set of results"? Also the section doesn't mention anything about problems if the mailbox changes. So: C: A03 UID SEARCH RETURN (PARTIAL 1:500) UNDELETED UNKEYWORD $Junk .. C: A04 UID SEARCH RETURN (PARTIAL 501:1000) UNDELETED UNKEYWORD $Junk S: * 1 FETCH (FLAGS $Junk) .. Now this most likely means that the original 501th result was actually skipped, because the first message had $Junk keyword set and the partial result set got moved by one. Right? --=-Cxgj+DZE95MEsL9pGgJZ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBGTHlqyUhSUUBViskRAlyiAKCGv3svs//rReQWZDBE39JLfcaAlACgok3c EtC1MmeIKbhsqLY9s8K7ebo= =K3jB -----END PGP SIGNATURE----- --=-Cxgj+DZE95MEsL9pGgJZ-- --===============1023990504== 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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============1023990504==-- From lemonade-bounces@ietf.org Thu May 17 12:42:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hoj46-0005zy-1w; Thu, 17 May 2007 12:42:58 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hoj44-0005yj-Fo for lemonade-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 12:42:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hoj44-0005yO-5p for lemonade@ietf.org; Thu, 17 May 2007 12:42:56 -0400 Received: from ppsw-3.csi.cam.ac.uk ([131.111.8.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hoj42-0008U4-Sz for lemonade@ietf.org; Thu, 17 May 2007 12:42:56 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:52823) by ppsw-3.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.153]:25) with esmtpa (EXTERNAL:fanf2) id 1Hoj3z-0002LH-Cm (Exim 4.63) (return-path ); Thu, 17 May 2007 17:42:51 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Hoj3z-0007wV-UI (Exim 4.54) (return-path ); Thu, 17 May 2007 17:42:51 +0100 Date: Thu, 17 May 2007 17:42:51 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Chris Newman Subject: Re: [lemonade] QUICKSTART update In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed, 16 May 2007, Chris Newman wrote: > > It's my opinion that the way profile B interacts with the TLS layer is > problematic for implementations. [...] > > The problem is that activating the TLS layer is a software state change > that takes over both socket directions. So it really shouldn't happen > until the only subsequent protocol will be TLS packets. Having secure > and non-secure packets in-transit at the same time is not a good idea > from a state management point of view. Thanks for looking into this, and especially for having a go at implementing it. I have to agree even though it makes me sad that this means it probably isn't possible to safely eliminate the last RTT. In the next revision I'll replace pipelined STARTTLS with QTLS, and make sure that the cleartext/TLS boundary is simple. Tony. -- f.a.n.finch http://dotat.at/ VIKING NORTH UTSIRE SOUTH UTSIRE: NORTHERLY BACKING SOUTHERLY 4, INCREASING 5 TO 7, PERHAPS GALE 8 LATER. SLIGHT, BECOMING MODERATE OR ROUGH. RAIN LATER. MODERATE OR GOOD. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri May 18 04:56:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoyG2-0005Np-NC; Fri, 18 May 2007 04:56:18 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HoyG1-0005JK-Kk for lemonade-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 04:56:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoyG1-0005Gv-6s for lemonade@ietf.org; Fri, 18 May 2007 04:56:17 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoyFz-0007Xa-O9 for lemonade@ietf.org; Fri, 18 May 2007 04:56:17 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4I8tUGc027920; Fri, 18 May 2007 11:56:07 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 May 2007 11:55:55 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 May 2007 11:55:55 +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] Re: [MORG] Context update Date: Fri, 18 May 2007 11:55:55 +0300 Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA15784EB38@esebe199.NOE.Nokia.com> In-Reply-To: <1179416938.32181.856.camel@hurina> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Re: [MORG] Context update Thread-Index: AceYmu3TDAhBJJ/JQ/qSb1FrgvViCgAjX1cw References: <30512.1179169211.052893@peirce.dave.cridland.net> <1179416938.32181.856.camel@hurina> From: To: , X-OriginalArrivalTime: 18 May 2007 08:55:55.0148 (UTC) FILETIME=[583DF4C0:01C7992A] X-Nokia-AV: Clean 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 Dave, there is another problem related to one of the comments sent by Timo. Please find it below Timo's comment. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 >-----Original Message----- >From: ext Timo Sirainen [mailto:tss@iki.fi]=20 >Sent: 17 May, 2007 18:49 >To: Dave Cridland >Cc: Enhancements to Internet email to support diverse service=20 >enivronments; Messaging Organization >Subject: [lemonade] Re: [MORG] Context update > >3.3.3: > > The ADDTO return data item MAY include several new results to be > inserted - therefore it is imporant to note that the positions > included in a single ADDTO return data item contain positions before > the shifting due to other new results take place. > >I can't parse that sentence. I'm guessing it means that if=20 >there are multiple results the shifting needs to be done after=20 >processing the next result. Or exactly the opposite. > > If the position is non-zero, the new results in the update are to be > >What if it's zero? I don't think I understand this position=20 >thing at all since it can even be ignored by clients. Or is it=20 >related to SORT? The contents of the ADDTO data item is not sorted, therefore there is a = problem when there are some items to be inserted one after another = immediately. Let me elaborate using an example. I have made a search, and I have 10 results. My current "window" is over = results 1-5, like this: 1 0xAAAA 2 0xBBBB 3 0xCCCC 4 0xDDDD 5 0xEEEE Now, the server sends an update, where ADDTO says that the client needs = to insert these to the list: 3 0xBBCC 3 0xBCCC 3 0XBBBC Now, it's pretty cleat that the result on position 3 shifts to position = 6, but how does the client know which result one will occupy positions = 3, 4, 5 in the updated result list (since the contents of the ADDTO data = item are not sorted)? My suggestion would be to sort ADDTO data items by position. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri May 18 08:33:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp1eJ-0004av-3e; Fri, 18 May 2007 08:33:35 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hp1eH-0004ah-TO for lemonade-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 08:33:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp1eH-0004aZ-JU for lemonade@ietf.org; Fri, 18 May 2007 08:33:33 -0400 Received: from [2001:838:378:0:2a0:d2ff:fe1b:110f] (helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp1eF-0005BG-Rh for lemonade@ietf.org; Fri, 18 May 2007 08:33:33 -0400 Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id ; Fri, 18 May 2007 13:33:30 +0100 Subject: RE: [lemonade] Re: [MORG] Context update References: <30512.1179169211.052893@peirce.dave.cridland.net> <1179416938.32181.856.camel@hurina> <4C38DC11F6B4FF4FAEA73E30DB5AA15784EB38@esebe199.NOE.Nokia.com> In-Reply-To: <4C38DC11F6B4FF4FAEA73E30DB5AA15784EB38@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Message-Id: <5253.1179491610.320822@peirce.dave.cridland.net> Date: Fri, 18 May 2007 13:33:30 +0100 From: Dave Cridland To: "Zoltan.Ordogh@nokia.com" Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Spam-Score: -2.4 (--) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Enhancements to Internet email to support diverse service enivronments , Timo Sirainen X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 May 18 09:55:55 2007, Zoltan.Ordogh@nokia.com wrote: > The contents of the ADDTO data item is not sorted, therefore there > is a problem when there are some items to be inserted one after > another immediately. Yes, that's missing - the new results are inserted as a block, in the order they appear. > Let me elaborate using an example. > I have made a search, and I have 10 results. My current "window" is > over results 1-5, like this: > 1 0xAAAA > 2 0xBBBB > 3 0xCCCC > 4 0xDDDD > 5 0xEEEE > Now, the server sends an update, where ADDTO says that the client > needs to insert these to the list: > 3 0xBBCC > 3 0xBCCC > 3 0XBBBC > Now, it's pretty cleat that the result on position 3 shifts to > position 6, but how does the client know which result one will > occupy positions 3, 4, 5 in the updated result list (since the > contents of the ADDTO data item are not sorted)? > My suggestion would be to sort ADDTO data items by position. Yes, or rather, by the order specified (or in mailbox order, for searches). Dave. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri May 18 09:24:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp2RG-0005oh-W9; Fri, 18 May 2007 09:24:11 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hp2RG-0005ms-B5 for lemonade-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 09:24:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp2RF-0005kP-Pp; Fri, 18 May 2007 09:24:09 -0400 Received: from [2001:838:378:0:2a0:d2ff:fe1b:110f] (helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp2RB-0004vO-DU; Fri, 18 May 2007 09:24:09 -0400 Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id ; Fri, 18 May 2007 14:24:02 +0100 References: <30512.1179169211.052893@peirce.dave.cridland.net> <1179416938.32181.856.camel@hurina> In-Reply-To: <1179416938.32181.856.camel@hurina> MIME-Version: 1.0 Message-Id: <5253.1179494641.466607@peirce.dave.cridland.net> Date: Fri, 18 May 2007 14:24:01 +0100 From: Dave Cridland To: Timo Sirainen Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Spam-Score: -2.8 (--) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Cc: Enhancements to Internet email to support diverse service enivronments , Messaging Organization Subject: [lemonade] Re: [MORG] Context update X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 May 17 16:48:58 2007, Timo Sirainen wrote: > I'm planning on implementing virtual mailboxes to my server, but I > think > CONTEXT won't be integrated with that feature. CONTEXT seems like > it's > useful for temporary views of mailboxes, while actual virtual > mailboxes > are more permanent and often generated from multiple physical > mailboxes. > For example CONTEXT mentions virtual Trash, but people usually want > the > Trash to contain \Deleted messages from all the mailboxes, not just > one. > > Right, although it certainly helps with the non-trash view. The problem with modelling the output of what one might call a volatile search - one which matches on mutable properties of a message, such as the \Deleted flag - as a mailbox is that you'd be removing and reinserting messages from a mailbox rather a lot. > Also since CONTEXT requires that the mailbox is selected and so all > the > flag changes, expunges etc. are sent to clients, this doesn't really > give server the possibility of optimizing the search views the same > way > as separate virtual mailboxes would. > > Sure, but in practise, I'm not convinced this is actually an issue to be worried about - you're unlikely to see much in the way of flag changes and expunges in most cases. And if that is a problem for clients, they can use NOTIFY to prevent flag changes from being sent, at least. (They can also prevent expunges, although that's less suitable for many clients). > I could still implement CONTEXT, but I think saying virtual > mailboxes > could be implemented with it is a bit misleading. At least I was > expecting CONTEXT to be quite different. > > It allows for implementing simple views. In a lot of cases, that's all you need. It's certainly what I use most. > I read the draft now for the first time without knowing anything > about > CONTEXT before that. Some comments: > > 3.1: > > "Such servers also accept three additional return options, and > provide > three new result data items, and no new responses." > > I've no idea what return options or result data items are at this > point. > After reading far enough down I finally figure out it's talking > about > ESEARCH. So mentioning [ESEARCH] already in the first sentence > would be > helpful. > > Right. > 3.2: > > "The return option CONTEXT SHOULD be used by a client to indicate > that > subsequent use of the criteria are likely." > > "the search criteria" would have helped me to understand this more > easily. > > Okay. > 3.3.2: > > The client MUST process (and the server MUST generate) ADDTO and > REMOVEFROM return data items in order, including those within a > single ESEARCH response. > > What order? > > I'll change "order" to "the order they appear". > 3.3.3: > > The ADDTO return data item MAY include several new results to be > inserted - therefore it is imporant to note that the positions > included in a single ADDTO return data item contain positions > before > the shifting due to other new results take place. > > I can't parse that sentence. I'm guessing it means that if there are > multiple results the shifting needs to be done after processing the > next > result. Or exactly the opposite. > > Yes, that's confusing. :-) > If the position is non-zero, the new results in the update are > to be > > What if it's zero? I don't think I understand this position thing > at all > since it can even be ignored by clients. Or is it related to SORT? > > This is related to SORT, which is now going back into the document, so a lot of this will make more sense. SORT related ADDTOs cannot have a zero position. > 3.3.4: > > S: * ESEARCH (TAG "B01") UID REMOVEFROM 32768 > C: B03 NOOP > S: * EXPUNGE 23762 > S: B03 OK Nothing done. > > "* 23762 EXPUNGE". And maybe a note that the REMOVEFROM MUST be sent > before the EXPUNGE (at least with sequences). > > Very good point. I'd completely forgotten that. > 3.3.5: > > The server MAY free any resource associated with a context so > disabled. > > ? > > Servers aren't obliged to remove local state for a context that's freed, primarily because the client is still allowed to perform PARTIAL requests from it. Servers just aren't allowed to send updates anymore. > 3.4: > > Where a PARTIAL search return option references results which do > not > exist, by using a range which starts or ends higher than the > COUNT of > results, then the server returns those results which are in the > set. > This yields a PARTIAL return data item which has, as payload, the > original range and a potentially missing set of results which > may be > shorter than the extent of the range. > > This paragraph is somewhat weird. It's not necessary to do COUNT > for a > partial SEARCH, so mentioning COUNT in there isn't probably right. > And > if the mailbox had changed since the COUNT was returned, the range > does > exist. Unless that's what the last sentence tries to say with > "missing > set of results"? > > Yes, that's it. > Also the section doesn't mention anything about problems if the > mailbox > changes. So: > > C: A03 UID SEARCH RETURN (PARTIAL 1:500) UNDELETED UNKEYWORD $Junk > .. > C: A04 UID SEARCH RETURN (PARTIAL 501:1000) UNDELETED UNKEYWORD > $Junk > S: * 1 FETCH (FLAGS $Junk) > .. > > Now this most likely means that the original 501th result was > actually > skipped, because the first message had $Junk keyword set and the > partial > result set got moved by one. Right? > > Yes, it does - this is why clients almost certainly want to use PARTIAL in one of two ways: 1) For snapshot views of part of a SEARCH/SORT result. A typical use-case might be a webmail, where you don't have a particularly long-running connection. 2) With UPDATE - in which case you won't "miss" the result. The thing you don't want to be doing is trying to walk the result without UPDATE - you are indeed very likely to miss results as the mailbox changes. I should probably add something about this. 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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri May 18 15:50:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp8TG-0006Uy-Pb; Fri, 18 May 2007 15:50:38 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hp8TE-0006U3-M2 for lemonade-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 15:50:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp8TD-0006T6-W0; Fri, 18 May 2007 15:50:36 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hp8TC-00020x-Hn; Fri, 18 May 2007 15:50:35 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 7900B2ACDA; Fri, 18 May 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hp8Sg-0000R7-83; Fri, 18 May 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 18 May 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-08.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 : IMAP CONVERT extension Author(s) : S. Maes, et al. Filename : draft-ietf-lemonade-convert-08.txt Pages : 0 Date : 2007-5-18 CONVERT defines extensions to IMAP allowing clients to request adaptation and/or transcoding of attachments. Clients can specify the conversion details or allow servers to decide based on knowledge of client capabilities, on user or administrator preferences or its settings. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-convert-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-convert-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-convert-08.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: <2007-5-18113842.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-convert-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-convert-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-18113842.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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --NextPart-- From lemonade-bounces@ietf.org Sun May 20 13:02:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HponU-0004kl-2p; Sun, 20 May 2007 13:02:20 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HponS-0004kR-24 for lemonade-confirm+ok@megatron.ietf.org; Sun, 20 May 2007 13:02:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HponR-0004kJ-Oh; Sun, 20 May 2007 13:02:17 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HponQ-0000lC-CS; Sun, 20 May 2007 13:02:17 -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 ; Sun, 20 May 2007 18:02:12 +0100 Message-ID: <46503E2B.7050908@isode.com> Date: Sun, 20 May 2007 13:25:15 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Dave Cridland References: <30512.1179169211.052893@peirce.dave.cridland.net> <1179416938.32181.856.camel@hurina> <5253.1179494641.466607@peirce.dave.cridland.net> In-Reply-To: <5253.1179494641.466607@peirce.dave.cridland.net> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: diverse service enivronments , Timo Sirainen , Enhancements, Messaging Organization Subject: [lemonade] Re: [MORG] Context update X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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: >> 3.3.5: >> >> The server MAY free any resource associated with a context so >> disabled. >> >> ? > > Servers aren't obliged to remove local state for a context that's > freed, primarily because the client is still allowed to perform > PARTIAL requests from it. Servers just aren't allowed to send updates > anymore. What you say was not obvious to me when I've reviewed your draft. I suggest you clarify this in the next revision. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sun May 20 13:02:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HponS-0004kZ-Ul; Sun, 20 May 2007 13:02:18 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HponR-0004kE-2z for lemonade-confirm+ok@megatron.ietf.org; Sun, 20 May 2007 13:02:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HponQ-0004k6-Pc for lemonade@ietf.org; Sun, 20 May 2007 13:02:16 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HponQ-0000lD-CE for lemonade@ietf.org; Sun, 20 May 2007 13:02:16 -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 ; Sun, 20 May 2007 18:02:11 +0100 Message-ID: <4650394E.9060201@isode.com> Date: Sun, 20 May 2007 13:04:30 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Zoltan.Ordogh@nokia.com Subject: Re: [lemonade] Updated Draft: draft-cridland-imap-context References: <13829.1177506908.404308@peirce.dave.cridland.net> <4C38DC11F6B4FF4FAEA73E30DB5AA157812F7D@esebe199.NOE.Nokia.com> <46488CD1.2020308@isode.com> <4C38DC11F6B4FF4FAEA73E30DB5AA1578135E3@esebe199.NOE.Nokia.com> In-Reply-To: <4C38DC11F6B4FF4FAEA73E30DB5AA1578135E3@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: 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 Zoltan.Ordogh@nokia.com wrote: >>>6. "The search return option UPDATE, if used by a client, causes the server to ..." >>> >>> >>>Should we make it mandatory? >>> >>> >>Mandatory for clients to use? >> >> >For all LEMONADE clients and servers. Reasoning below. > It would not be possible to have such a requirement on clients, as clients are free to implement anything they want. The document can only give an advice on the best way to achieve things. But you are right about the requirement on servers. The draft doesn't say that servers are required to implement UPDATE. I also think that the document needs to say that every server MUST be able to support at least X contexts per connection. I suggest X=2. > I know that the draft is independent of LEMONADE, therefore it is not very convenient to enforce it in this draft. > > Agreed. >>>At least I would not want to see a client that supports >>> >>>notifications (IDLE/NOTIFY will be in all LEMONADE clients >>>anyway) but cannot coop with search result updates. Server and >>>client will get seriously out of sync without notifications, >>>so when the client requests a next window, some results might >>>be displayed again (when new results have been inserted before >>>the current window) and some might be missed as well (when >>>obsolete results have been removed before the current window). >>> >>> >>>Section A.1. >>>14. CONTEXT is a replacement for VFOLDER. VFOLDER had the >>> >>>advantage of re-using virtual folders: I could easily create >>>new virtual folders from virtual folders, and altering one >>>virtual folder in the "path" would alter all "child" virtual >>>folders. It appears (or, I missed something) that it is no >>>longer possible using this extension. >>> >>> >>This is still possible by constructing a SEARCH criterion >>which logically ANDs two or more SEARCH criteria. >> >> >Yes, but the entire path would not exist, would it? > > I don't think that a change in an intermediate virtual folder is a sufficiently frequent event, so I don't think there is a need to optimize for it. As Dave already pointed out, one might be able to use my FILTER draft. It adds a new FILTER SEARCH key, that gets expanded when the SEARCH criteria gets evaluated. If the client changes one of the FILTERs, it can recreate the whole context. (I can show a protocol example, if this is not sufficiently clear). _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sun May 20 18:42:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hpu6I-0006SO-8K; Sun, 20 May 2007 18:42:06 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hpu6H-0006SJ-Me for lemonade-confirm+ok@megatron.ietf.org; Sun, 20 May 2007 18:42:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hpu6H-0006SB-Cq for lemonade@ietf.org; Sun, 20 May 2007 18:42:05 -0400 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hpu6G-0001E6-1z for lemonade@ietf.org; Sun, 20 May 2007 18:42:05 -0400 Received: from source ([192.150.20.142]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Sun, 20 May 2007 15:41:55 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l4KMfjSd005513; Sun, 20 May 2007 15:41:49 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l4KMfI0m001470; Sun, 20 May 2007 15:41:34 -0700 (PDT) Received: from namail1.corp.adobe.com ([10.8.192.62]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 20 May 2007 15:41:25 -0700 Received: from masinterlap06 ([10.7.240.101]) by namail1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 20 May 2007 15:41:25 -0700 From: "Larry Masinter" To: "'Randall Gellens'" , "'Alexey Melnikov'" References: <001d01c78938$55e9fb80$01bdf280$@org> <463B6CA1.3060308@isode.com> <000e01c78eb6$f9f60330$ede20990$@org> <463FACDD.8020300@isode.com> In-Reply-To: Subject: RE: [lemonade] RE: Review request for draft-ietf-lemonade-convert-06.txt Date: Sun, 20 May 2007 15:41:29 -0700 Message-ID: <001801c79b30$025419b0$06fc4d10$@org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AceXy4ikLQi42yBuTUeGIHhG57y/oQDY71kw Content-Language: en-us X-OriginalArrivalTime: 20 May 2007 22:41:25.0919 (UTC) FILETIME=[FFB552F0:01C79B2F] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: 'Ted Hardie' , lemonade@ietf.org, 'Graham Klyne' X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Show this to me "as an image" vs "as HTML" is still supplying output constraints. Now, it's common for desktop applications that do conversion to allow you to supply parameters for the conversion process, e.g., Photoshop, when scaling an image, offers 5 different algorithms. But I don't think that's a use case for messaging, where you are trying to deal with content that you otherwise can't render. Larry -----Original Message----- From: Randall Gellens [mailto:randy@qualcomm.com] Sent: Wednesday, May 16, 2007 8:04 AM To: Alexey Melnikov; Larry Masinter Cc: 'Ted Hardie'; lemonade@ietf.org; 'Graham Klyne' Subject: Re: [lemonade] RE: Review request for draft-ietf-lemonade-convert-06.txt At 11:49 PM +0100 5/7/07, Alexey Melnikov wrote: >> Under what circumstances is it preferable >> for the client to supply conversion parameters rather than >> output constraints based on client capabilities? >> > I can't think of any at the moment. Perhaps user override? For example, a message contains a PowerPoint file, which the device can't render. User asks to see content. Client asks server to convert to HTML, shows that to user, but it looks so bad the user can't figure it out. So the user asks to see it as an image. This is a bit of a stretch, I'll grant. -- 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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon May 21 15:54:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqDxy-0004Xx-Aj; Mon, 21 May 2007 15:54:50 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HqDts-0008Eh-22 for lemonade-confirm+ok@megatron.ietf.org; Mon, 21 May 2007 15:50:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqDtp-00089z-Qf; Mon, 21 May 2007 15:50:34 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HqDto-00040A-Fq; Mon, 21 May 2007 15:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 69B9A175E4; Mon, 21 May 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HqDtK-0002Wi-5U; Mon, 21 May 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 21 May 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-deployments-08.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to Support Diverse Service Environments Working Group of the IETF. Title : Deployment Considerations for lemonade-compliant Mobile Email Author(s) : R. Gellens Filename : draft-ietf-lemonade-deployments-08.txt Pages : 13 Date : 2007-5-21 This document discusses deployment issues and describes requirements for successful deployment of mobile email which are implicit in the IETF lemonade documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-deployments-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-deployments-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-deployments-08.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: <2007-5-21112144.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-deployments-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-deployments-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-21112144.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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --NextPart-- From lemonade-bounces@ietf.org Tue May 22 11:39:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqWSZ-00084M-T4; Tue, 22 May 2007 11:39:39 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HqWSZ-00084H-3q for lemonade-confirm+ok@megatron.ietf.org; Tue, 22 May 2007 11:39:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqWSY-00083k-Q4 for lemonade@ietf.org; Tue, 22 May 2007 11:39:38 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqWSV-0007op-8J for lemonade@ietf.org; Tue, 22 May 2007 11:39:38 -0400 Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4MFdYov028430 for ; Tue, 22 May 2007 15:39:34 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIG00H018T0YK00@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Tue, 22 May 2007 09:39:34 -0600 (MDT) Received: from kluane ([199.247.238.5]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIG003WQ8TVLS80@mail-amer.sun.com> for lemonade@ietf.org; Tue, 22 May 2007 09:39:34 -0600 (MDT) Date: Tue, 22 May 2007 08:39:20 -0700 From: Peter Coates To: lemonade@ietf.org Message-id: <012601c79c87$5ef91a50$1ceb4ef0$%coates@sun.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-ca Thread-index: Acech10V0pWqteSvTtygZFQojL5k3Q== X-Spam-Score: 0.1 (/) X-Scan-Signature: b058151374d77ee76edaac850f7449fb Subject: [lemonade] minutes of lemonade interim 16 May 2007 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 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="===============0257679728==" Errors-To: lemonade-bounces@ietf.org This is a multipart message in MIME format. --===============0257679728== Content-type: multipart/alternative; boundary="Boundary_(ID_bAM9Ur/TBWw/c/ZluwJqUw)" Content-language: en-ca This is a multipart message in MIME format. --Boundary_(ID_bAM9Ur/TBWw/c/ZluwJqUw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT (sorry about the delay in getting these minutes out. I hope they are an accurate reflection of decisions taken. If not, let me know and I'll correct. Similarly if I missed out a participant. Peter.) In the Room: Eric burger, Bea Peter Coates, Sun Darryl Champagne, Funambol Glenn Parsons, Nortel Brook Hayes, RIM Randy Gellens Pete Resnick Virtually present: Alexey Melnikov Chris Newman Arnt Abhijit Menon-Sen Pvanhoof Cyrus Daboo Convert: There was more or less a decision to remove strict. IANA registry for transcoding parameters Remove dependency on metadata What about convert to multipart. then how do you get a part of the new multipart? Matter left open. AI Pete: send a message to the list with suggested syntax Open question if IMAP URL can refer to a converted bodypart. Or refer to parts of converted bodypart. Consensus is that once URLs can refer to a converted bodypart, the output can be used in catenate, and the problem goes away What about storage of convert capabilities: metadata, extended capability, or. The consensus is that this is an open issue. For an open issue with no strongly held opinions it was an active debate. Leave the spec asking for metadata for the moment. Strict: There was a long and rather uninformed discussion about this which remarkably converged on an action item on Pete. AI Pete: provide some text to Alexey on conversion. Basically to add a USEDEVICEINFO to give the server permission to be "helpful". Strict gets consigned to the dustbin of history. IANA registration: Open issue use conneg syntax rather than IMAP syntax (rfc 2913) AI Glen: to work out how to map STI parameters on conneg Notifications: AI Peter: Peter accidentally volunteered to update the message events doc AI Glenn & Randy to rework on the notification doc into the arch doc that is needed, will talk to Lisa Dusseault on this. Status: Draft-ietf-lemonade-deployments: Chairs to deal with "discuss" comments. Draft-ietf-lemonade-reconnect-client: new revision coming to address AD comments Draft-ietf-lemonade-search-within: comments Draft-ietf-lemonade-reconnect replaced by Draft-ietf-lemonade-reconnect-client Draft-ietf-lemonade-firewall-binding and Draft-ietf-lemonade-tcp-challenged-environments more than expired: now deemed dead. New doc called for: using convert for encryption, but not add it to -bis. A decision on the urgency of this is to be made by chairs. Draft-ietf-lemonade-convert: new draft and onto WG last call Draft-ietf-lemonade-sieve: news more work. chairs will encourage progress and perhaps adds a co-editor Draft-ietf-lemonade-msgevent: new draft to be produced Draft-ietf-lemonade-notifications: new draft for internal consumption Draft-ietf-lemonade-rfc2192bis: Alexey to produce new draft "quick fix" Draft-ietf-lemonade-streaming: chairs to followup with editors (Eric to fins SIP reviewer) Draft-ietf-lemonade-context: Dave will put sort back, other comments to be included. Then will go to IESG Draft-gulbradsen-imap-notify: will be change to Draft-ietf-lemonade-notify with revisions, then one more revision before WG last call Draft-ietf-lemonade-profile-bis: add sort and enable to -bis plus some minor cleanup --Boundary_(ID_bAM9Ur/TBWw/c/ZluwJqUw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

(sorry about the delay in getting these minutes out.  I hope they are an accurate reflection of decisions taken.  If not, let me know and I’ll correct.  Similarly if I missed out a participant.

Peter.)

 

In the Room:

Eric burger, Bea

Peter Coates, Sun

Darryl Champagne, Funambol

Glenn Parsons, Nortel

Brook Hayes, RIM

Randy Gellens

Pete Resnick

 

Virtually present:

Alexey Melnikov

Chris Newman

Arnt

Abhijit Menon-Sen

Pvanhoof

Cyrus Daboo

 

Convert:

There was more or less a decision to remove strict.

IANA registry for transcoding parameters

Remove dependency on metadata

What about convert to multipart… then how do you get a part of the new multipart?

Matter left open.

AI Pete: send a message to the list with suggested syntax

Open question if IMAP URL can refer to a converted bodypart.  Or refer to parts of converted bodypart.

Consensus is that once URLs can refer to a converted bodypart, the output can be used in catenate, and the problem goes away

What about storage of convert capabilities: metadata, extended capability, or…

The consensus is that this is an open issue.  For an open issue with no strongly held opinions it was an active debate.  Leave the spec asking for metadata for the moment.

Strict:

There was a long and rather uninformed discussion about this which remarkably converged on an action item on Pete.

AI Pete: provide some text to Alexey on conversion.  Basically to add a USEDEVICEINFO to give the server permission to be “helpful”.  Strict gets consigned to the dustbin of history.

IANA registration:

Open issue use conneg syntax rather than IMAP syntax (rfc 2913)

AI Glen: to work out how to map STI parameters on conneg

 

Notifications:

AI Peter: Peter accidentally volunteered to update the message events doc

AI Glenn & Randy to rework on the notification doc into the arch doc that is needed, will talk to Lisa Dusseault on this.

 

Status:

Draft-ietf-lemonade-deployments: Chairs to deal with “discuss” comments.

Draft-ietf-lemonade-reconnect-client: new revision coming to address AD comments

Draft-ietf-lemonade-search-within: comments

Draft-ietf-lemonade-reconnect replaced by Draft-ietf-lemonade-reconnect-client

Draft-ietf-lemonade-firewall-binding and Draft-ietf-lemonade-tcp-challenged-environments more than expired: now deemed dead.

 

New doc called for: using convert for encryption, but not add it to –bis.  A decision on the urgency of this is to be made by chairs.

 

Draft-ietf-lemonade-convert: new draft and onto WG last call

Draft-ietf-lemonade-sieve: news more work… chairs will encourage progress and perhaps adds a co-editor

Draft-ietf-lemonade-msgevent: new draft to be produced

Draft-ietf-lemonade-notifications: new draft for internal consumption

Draft-ietf-lemonade-rfc2192bis: Alexey to produce new draft “quick fix”

Draft-ietf-lemonade-streaming: chairs to followup with editors (Eric to fins SIP reviewer)

Draft-ietf-lemonade-context: Dave will put sort back, other comments to be included.  Then will go to IESG 

Draft-gulbradsen-imap-notify: will be change to Draft-ietf-lemonade-notify with revisions, then one more revision before WG last call

 

Draft-ietf-lemonade-profile-bis: add sort and enable to –bis plus some minor cleanup

 

--Boundary_(ID_bAM9Ur/TBWw/c/ZluwJqUw)-- --===============0257679728== 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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============0257679728==-- From lemonade-bounces@ietf.org Tue May 22 11:49:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqWbx-0004Le-FG; Tue, 22 May 2007 11:49:21 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HqWbw-0004KB-EY for lemonade-confirm+ok@megatron.ietf.org; Tue, 22 May 2007 11:49:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqWbw-0004Je-3X for lemonade@ietf.org; Tue, 22 May 2007 11:49:20 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqWbt-0002Vb-Go for lemonade@ietf.org; Tue, 22 May 2007 11:49:20 -0400 Received: from fe-amer-10.sun.com ([192.18.108.184]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4MFnG7Z029530 for ; Tue, 22 May 2007 15:49:17 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIG00G0192YZC00@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Tue, 22 May 2007 09:49:16 -0600 (MDT) Received: from kluane ([199.247.238.5]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIG00KWM9A2SFHZ@mail-amer.sun.com> for lemonade@ietf.org; Tue, 22 May 2007 09:49:16 -0600 (MDT) Date: Tue, 22 May 2007 08:49:04 -0700 From: Peter Coates To: lemonade@ietf.org Message-id: <014501c79c88$ba58b710$2f0a2530$%coates@sun.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-ca Thread-index: Acech10V0pWqteSvTtygZFQojL5k3QAASghQ X-Spam-Score: 0.1 (/) X-Scan-Signature: e3901bdd61b234d82da85cc76f05a7e8 Subject: [lemonade] Correction 1 of minutes of lemonade interim 16 May 2007 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 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="===============1185486677==" Errors-To: lemonade-bounces@ietf.org This is a multipart message in MIME format. --===============1185486677== Content-type: multipart/alternative; boundary="Boundary_(ID_xSlSDZihAhxQFyhECiuFTQ)" Content-language: en-ca This is a multipart message in MIME format. --Boundary_(ID_xSlSDZihAhxQFyhECiuFTQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT (sorry about the delay in getting these minutes out. I hope they are an accurate reflection of decisions taken. If not, let me know and I'll correct. Similarly if I missed out a participant. Peter.) In the Room: Eric burger, Bea Peter Coates, Sun Darryl Champagne, Funambol Glenn Parsons, Nortel Brook Hayes, RIM Randy Gellens Pete Resnick Virtually present: Alexey Melnikov Chris Newman Arnt Abhijit Menon-Sen Pvanhoof Cyrus Daboo Dave Cridland Convert: There was more or less a decision to remove strict. IANA registry for transcoding parameters Remove dependency on metadata What about convert to multipart. then how do you get a part of the new multipart? Matter left open. AI Pete: send a message to the list with suggested syntax Open question if IMAP URL can refer to a converted bodypart. Or refer to parts of converted bodypart. Consensus is that once URLs can refer to a converted bodypart, the output can be used in catenate, and the problem goes away What about storage of convert capabilities: metadata, extended capability, or. The consensus is that this is an open issue. For an open issue with no strongly held opinions it was an active debate. Leave the spec asking for metadata for the moment. Strict: There was a long and rather uninformed discussion about this which remarkably converged on an action item on Pete. AI Pete: provide some text to Alexey on conversion. Basically to add a USEDEVICEINFO to give the server permission to be "helpful". Strict gets consigned to the dustbin of history. IANA registration: Open issue use conneg syntax rather than IMAP syntax (rfc 2913) AI Glen: to work out how to map STI parameters on conneg Notifications: AI Peter: Peter accidentally volunteered to update the message events doc AI Glenn & Randy to rework on the notification doc into the arch doc that is needed, will talk to Lisa Dusseault on this. Status: Draft-ietf-lemonade-deployments: Chairs to deal with "discuss" comments. Draft-ietf-lemonade-reconnect-client: new revision coming to address AD comments Draft-ietf-lemonade-search-within: comments Draft-ietf-lemonade-reconnect replaced by Draft-ietf-lemonade-reconnect-client Draft-ietf-lemonade-firewall-binding and Draft-ietf-lemonade-tcp-challenged-environments more than expired: now deemed dead. New doc called for: using convert for encryption, but not add it to -bis. A decision on the urgency of this is to be made by chairs. Draft-ietf-lemonade-convert: new draft and onto WG last call Draft-ietf-lemonade-sieve: news more work. chairs will encourage progress and perhaps adds a co-editor Draft-ietf-lemonade-msgevent: new draft to be produced Draft-ietf-lemonade-notifications: new draft for internal consumption Draft-ietf-lemonade-rfc2192bis: Alexey to produce new draft "quick fix" Draft-ietf-lemonade-streaming: chairs to followup with editors (Eric to fins SIP reviewer) Draft-ietf-lemonade-context: Dave will put sort back, other comments to be included. Then will go to IESG Draft-gulbradsen-imap-notify: will be change to Draft-ietf-lemonade-notify with revisions, then one more revision before WG last call Draft-ietf-lemonade-profile-bis: add sort and enable to -bis plus some minor cleanup --Boundary_(ID_xSlSDZihAhxQFyhECiuFTQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

 (sorry about the delay in getting these minutes out.  I hope they are an accurate reflection of decisions taken.  If not, let me know and I’ll correct.  Similarly if I missed out a participant.

Peter.)

 

In the Room:

Eric burger, Bea

Peter Coates, Sun

Darryl Champagne, Funambol

Glenn Parsons, Nortel

Brook Hayes, RIM

Randy Gellens

Pete Resnick

 

Virtually present:

Alexey Melnikov

Chris Newman

Arnt

Abhijit Menon-Sen

Pvanhoof

Cyrus Daboo

Dave Cridland

 

Convert:

There was more or less a decision to remove strict.

IANA registry for transcoding parameters

Remove dependency on metadata

What about convert to multipart… then how do you get a part of the new multipart?

Matter left open.

AI Pete: send a message to the list with suggested syntax

Open question if IMAP URL can refer to a converted bodypart.  Or refer to parts of converted bodypart.

Consensus is that once URLs can refer to a converted bodypart, the output can be used in catenate, and the problem goes away

What about storage of convert capabilities: metadata, extended capability, or…

The consensus is that this is an open issue.  For an open issue with no strongly held opinions it was an active debate.  Leave the spec asking for metadata for the moment.

Strict:

There was a long and rather uninformed discussion about this which remarkably converged on an action item on Pete.

AI Pete: provide some text to Alexey on conversion.  Basically to add a USEDEVICEINFO to give the server permission to be “helpful”.  Strict gets consigned to the dustbin of history.

IANA registration:

Open issue use conneg syntax rather than IMAP syntax (rfc 2913)

AI Glen: to work out how to map STI parameters on conneg

 

Notifications:

AI Peter: Peter accidentally volunteered to update the message events doc

AI Glenn & Randy to rework on the notification doc into the arch doc that is needed, will talk to Lisa Dusseault on this.

 

Status:

Draft-ietf-lemonade-deployments: Chairs to deal with “discuss” comments.

Draft-ietf-lemonade-reconnect-client: new revision coming to address AD comments

Draft-ietf-lemonade-search-within: comments

Draft-ietf-lemonade-reconnect replaced by Draft-ietf-lemonade-reconnect-client

Draft-ietf-lemonade-firewall-binding and Draft-ietf-lemonade-tcp-challenged-environments more than expired: now deemed dead.

 

New doc called for: using convert for encryption, but not add it to –bis.  A decision on the urgency of this is to be made by chairs.

 

Draft-ietf-lemonade-convert: new draft and onto WG last call

Draft-ietf-lemonade-sieve: news more work… chairs will encourage progress and perhaps adds a co-editor

Draft-ietf-lemonade-msgevent: new draft to be produced

Draft-ietf-lemonade-notifications: new draft for internal consumption

Draft-ietf-lemonade-rfc2192bis: Alexey to produce new draft “quick fix”

Draft-ietf-lemonade-streaming: chairs to followup with editors (Eric to fins SIP reviewer)

Draft-ietf-lemonade-context: Dave will put sort back, other comments to be included.  Then will go to IESG 

Draft-gulbradsen-imap-notify: will be change to Draft-ietf-lemonade-notify with revisions, then one more revision before WG last call

 

Draft-ietf-lemonade-profile-bis: add sort and enable to –bis plus some minor cleanup

 

--Boundary_(ID_xSlSDZihAhxQFyhECiuFTQ)-- --===============1185486677== 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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============1185486677==-- From lemonade-bounces@ietf.org Tue May 22 14:02:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqYgS-00043e-PP; Tue, 22 May 2007 14:02:08 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HqYgS-00043X-Ba for lemonade-confirm+ok@megatron.ietf.org; Tue, 22 May 2007 14:02:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqYgR-000439-JL for lemonade@ietf.org; Tue, 22 May 2007 14:02:07 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqYgO-0005dG-Vs for lemonade@ietf.org; Tue, 22 May 2007 14:02:07 -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 ; Tue, 22 May 2007 19:02:01 +0100 Message-ID: <46532FD0.5020903@isode.com> Date: Tue, 22 May 2007 19:00:48 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: lemonade@ietf.org 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: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [lemonade] Update draft-ietf-lemonade-convert-08.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Internet-Drafts@ietf.org wrote: >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-lemonade-convert-08.txt > Changes from -07 and my comments: - Updated the document to use the media feature IANA registry established by RFC 2506 Nobody suggested a reason not to use RFC 2506, so the document was updated accordingly - Allow for conversion to non-leaf body parts As per discussion during the Lemonade interim, I've updated ABNF to allow for that. - Removed .STRICT (all conversion is strict now) Please check the new text. I am still waiting for a paragraph from Pete describing that a compliant server should not try to be helpful and guess things about the client unless explicitly allowed to. - Added replace-unknown-character media feature tag This mostly based on the long mailing list discussion about charset conversions. I've decided that clients might want to have both: "convert the charset, but only if all characters can be preserved" and "convert the charset and replacing characters that can't be converted is Ok". So I've added a new conversion parameter. ========== It is worth noting that -07 had one more open issue that resulted in no change to the document: use of METADATA extension versa new command(s). This was discussed during the Lemonade interop. Dan Karp send me a private email asking if it would be worth replacing dependency on METADATA with a new command. His main argument was about ugly syntax which is not very easy to understand, plus a requirement to implement an additional extension. The latter is a non issue for Lemonade, as Lemonade Profile bis is likely to depend on METADATA extension anyway. I would note that consensus on this was particularly rough. Most people treated this as a syntactic issue. So at this point I would advise: 1). Anybody who has a strong preference one way or the other should speak up now. 2). Dan should correct me if I misrepresented or forgot one of his important arguments against using METADATA. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue May 22 14:05:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqYjF-0008Ps-W1; Tue, 22 May 2007 14:05:01 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HqYjD-0008Pi-PG for lemonade-confirm+ok@megatron.ietf.org; Tue, 22 May 2007 14:04:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqYjD-0008PZ-FO for lemonade@ietf.org; Tue, 22 May 2007 14:04:59 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqYjC-00067c-3P for lemonade@ietf.org; Tue, 22 May 2007 14:04:59 -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 ; Tue, 22 May 2007 19:04:57 +0100 Message-ID: <46533081.80906@isode.com> Date: Tue, 22 May 2007 19:03:45 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: lemonade@ietf.org References: <46532FD0.5020903@isode.com> In-Reply-To: <46532FD0.5020903@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [lemonade] Another WGLC on draft-ietf-lemonade-convert-08.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 Alexey Melnikov wrote: > Internet-Drafts@ietf.org wrote: > >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-lemonade-convert-08.txt > Due to the number of changes to the document, I would like to start another 2 weeks Working Group Last Call. Please send your comments to me and/or to the mailing list before June 6th. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue May 22 19:21:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqdBt-0000YV-SJ; Tue, 22 May 2007 18:50:54 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HqdB7-0007wf-Bx for lemonade-confirm+ok@megatron.ietf.org; Tue, 22 May 2007 18:50:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqdB5-0007vq-MI; Tue, 22 May 2007 18:50:04 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqdB4-0004RK-TI; Tue, 22 May 2007 18:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id D826F32934; Tue, 22 May 2007 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HqdB4-0000x7-OI; Tue, 22 May 2007 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 22 May 2007 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-rfc2192bis-07.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to Support Diverse Service Environments Working Group of the IETF. Title : IMAP URL Scheme Author(s) : A. Melnikov, et al. Filename : draft-ietf-lemonade-rfc2192bis-07.txt Pages : 31 Date : 2007-5-22 IMAP (RFC 3501) is a rich protocol for accessing remote message stores. It provides an ideal mechanism for accessing public mail- ing list archives as well as private and shared message stores. This document defines a URL scheme for referencing objects on an IMAP server. This document obsoletes RFC 2192. It also updates RFC 4467. Together with update to RFC 4467 they will obsolete RFC 4467. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-rfc2192bis-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-rfc2192bis-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-rfc2192bis-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-5-22165616.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-rfc2192bis-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-rfc2192bis-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-22165616.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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --NextPart-- From lemonade-bounces@ietf.org Wed May 23 09:34:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqqz3-00038L-A2; Wed, 23 May 2007 09:34:33 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hqqz1-00037t-G3 for lemonade-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 09:34:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqqz1-00037l-6B for lemonade@ietf.org; Wed, 23 May 2007 09:34:31 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hqqz0-0005bH-M7 for lemonade@ietf.org; Wed, 23 May 2007 09:34:31 -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 ; Wed, 23 May 2007 14:34:28 +0100 Message-ID: <4654196C.5000606@isode.com> Date: Wed, 23 May 2007 11:37:32 +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: lemonade@ietf.org Subject: Re: [lemonade] concerns with draft-ietf-lemonade-reconnect-client-04.txt References: <7CB41CC1AD859AC968313FAB@[10.0.1.21]> In-Reply-To: <7CB41CC1AD859AC968313FAB@[10.0.1.21]> 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: 32b73d73e8047ed17386f9799119ce43 Cc: Chris Newman X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Chris Newman wrote: > I'm concerned there are architectural issues with > draft-ietf-lemonade-reconnect-client-04.txt that may create problems > with IETF consensus on the document. I wanted to verify that the WG > has consensus on these specific architectural issues in addition to > the document as a whole before I start IETF last call, as it may be > more difficult to resolve these issues in an IETF-wide or IESG scope > than in a more narrow WG scope. My intention is not to force any > specific changes, but rather to encourage making changes prior to IETF > last call that might be helpful to speed IETF consensus. > > 1. Implicit server behavior changes > > This extension has several cases where client commands trigger a > server behavior change as a side-effect of a client command. There > has been significant discussion in other IETF contexts (EAI design > team, IMAPEXT, ENABLE extension) that such behavior is undesirable and > that if a server behavior change is to occur it should be explicit and > early in the protocol exchange. I would like to confirm the WG has > consensus on this specific issue as I suspect it is likely be > problematic during IETF last call. As per discussion during the Lemonade interim, Dave and I will change QRESYNC to depend on Arnt's ENABLE extension. The change will address this issue. > 2. Change in IMAP untagged response model > > For better or worse, IMAP is a cache update protocol model rather than > a request/response protocol model. That means an untagged response is > not bound to a particular command, but rather the portion of the > client's cache state that is updated can be determined solely from the > untagged response itself (the SEARCH response being a notable > exception). This extension changes that model by binding the VANISHED > response to a specific command with the TAG correlator. Are there > servers which execute client commands out-of-order so that such > binding would be necessary? Does the WG believe changing the > fundamental IMAP model in this case is the best way to accomplish this > specific task? > > 3. VANISHED response sometimes but not always implying EXISTS change > > The VANISHED response is used in two different ways: one to replace > the EXPUNGE response to indicate a change in mailbox state at that > moment (including an implicit EXISTS update), and one to indicate that > messages were removed before the mailbox was selected in response to a > QRESYNC select modifier or VANISHED UID FETCH modifier. I suspect the > logic the client must use to distinguish these cases is a bit subtle. > Perhaps a simplification to VANISHED to address issue 2 & 3 should be > considered? Based on subsequent discussion with Chris: QRESYNC will be updated to rename the TAG parameter to EARLIER and remove the associated command tag, as it was not used. Text describing that the VANISHED response with the EARLIER parameter doesn't decrement EXISTS would be also clarified. Note, that the VANISHED response never changed the IMAP model. The TAG parameter was only used to distinguish two cases: earlier expunged messages and currently expunged messages. > 4. Complex interaction with CONDSTORE and UIDPLUS > > This extension requires CONDSTORE and requires the server to advertise > CONDSTORE. That means there's a silly state where the server > advertises QRESYNC but not CONDSTORE. Perhaps there's a simple way to > eliminate the silly state? Furthermore, there is a great deal of > variation in server behaviors and client codepaths between un-extended > IMAP, IMAP + CONDSTORE, IMAP + CONDSTORE + QRESYNC and IMAP + > CONDSTORE + QRESYNC + UIDPLUS. Is the WG really comfortable with this > complexity? Perhaps QRESYNC should require UIDPLUS in addition to > CONDSTORE? Perhaps QRESYNC is really a refinement of CONDSTORE rather > than an extension to it, so perhaps QRESYNC should subsume CONDSTORE > and obsolete it? Thinking more about this: clients that would like to use the VANISHED responses would also likely want to use UID EXPUNGE (i.e. the UIDPLUS extension). So personally I am slightly in preference of making the UIDPLUS a requirement for all QRESYNC-compliant servers. However, if we do this change, it would make no difference as far as Lemonade Profile Bis is concerned, because servers are required to implement both extensions anyway. And existing IMAP clients already have to deal with absence of UIDPLUS extension. Having said that I would like to poll the WG regarding making QRESYNC require UIDPLUS. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed May 23 09:34:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqqz6-00038y-FL; Wed, 23 May 2007 09:34:36 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hqqz5-00038k-9H for lemonade-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 09:34:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqqz4-00038c-Vp for lemonade@ietf.org; Wed, 23 May 2007 09:34:34 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hqqz4-0005bb-H7 for lemonade@ietf.org; Wed, 23 May 2007 09:34:34 -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 ; Wed, 23 May 2007 14:34:33 +0100 Message-ID: <465423EF.4060209@isode.com> Date: Wed, 23 May 2007 12:22:23 +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-LanguaFrom lemonade-bounces@ietf.org Wed May 23 09:34:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqqz3-00038L-A2; Wed, 23 May 2007 09:34:33 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hqqz1-00037t-G3 for lemonade-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 09:34:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqqz1-00037l-6B for lemonade@ietf.org; Wed, 23 May 2007 09:34:31 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hqqz0-0005bH-M7 for lemonade@ietf.org; Wed, 23 May 2007 09:34:31 -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 ; Wed, 23 May 2007 14:34:28 +0100 Message-ID: <4654196C.5000606@isode.com> Date: Wed, 23 May 2007 11:37:32 +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: lemonade@ietf.org Subject: Re: [lemonade] concerns with draft-ietf-lemonade-reconnect-client-04.txt References: <7CB41CC1AD859AC968313FAB@[10.0.1.21]> In-Reply-To: <7CB41CC1AD859AC968313FAB@[10.0.1.21]> 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: 32b73d73e8047ed17386f9799119ce43 Cc: Chris Newman X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Chris Newman wrote: > I'm concerned there are architectural issues with > draft-ietf-lemonade-reconnect-client-04.txt that may create problems > with IETF consensus on the document. I wanted to verify that the WG > has consensus on these specific architectural issues in addition to > the document as a whole before I start IETF last call, as it may be > more difficult to resolve these issues in an IETF-wide or IESG scope > than in a more narrow WG scope. My intention is not to force any > specific changes, but rather to encourage making changes prior to IETF > last call that might be helpful to speed IETF consensus. > > 1. Implicit server behavior changes > > This extension has several cases where client commands trigger a > server behavior change as a side-effect of a client command. There > has been significant discussion in other IETF contexts (EAI design > team, IMAPEXT, ENABLE extension) that such behavior is undesirable and > that if a server behavior change is to occur it should be explicit and > early in the protocol exchange. I would like to confirm the WG has > consensus on this specific issue as I suspect it is likely be > problematic during IETF last call. As per discussion during the Lemonade interim, Dave and I will change QRESYNC to depend on Arnt's ENABLE extension. The change will address this issue. > 2. Change in IMAP untagged response model > > For better or worse, IMAP is a cache update protocol model rather than > a request/response protocol model. That means an untagged response is > not bound to a particular command, but rather the portion of the > client's cache state that is updated can be determined solely from the > untagged response itself (the SEARCH response being a notable > exception). This extension changes that model by binding the VANISHED > response to a specific command with the TAG correlator. Are therFrom lemonade-bounces@ietf.org Wed May 23 09:34:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqqz3-00038L-A2; Wed, 23 May 2007 09:34:33 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hqqz1-00037t-G3 for lemonade-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 09:34:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqqz1-00037l-6B for lemonade@ietf.org; Wed, 23 May 2007 09:34:31 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hqqz0-0005bH-M7 for lemonade@ietf.org; Wed, 23 May 2007 09:34:31 -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 ; Wed, 23 May 2007 14:34:28 +0100 Message-ID: <4654196C.5000606@isode.com> Date: Wed, 23 May 2007 11:37:32 +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: lemonade@ietf.org Subject: Re: [lemonade] concerns with draft-ietf-lemonade-reconnect-client-04.txt References: <7CB41CC1AD859AC968313FAB@[10.0.1.21]> In-Reply-To: <7CB41CC1AD859AC968313FAB@[10.0.1.21]> 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: 32b73d73e8047ed17386f9799119ce43 Cc: Chris Newman X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Chris Newman wrote: > I'm concerned there are architectural issues with > draft-ietf-lemonade-reconnect-client-04.txt that may create problems > with IETF consensus on the document. I wanted to verify that the WG > has consensus on these specific architectural issues in addition to > the document as a whole before I start IETF last call, as it may be > more difficult to resolve these issues in an IETF-wide or IESG scope > than in a more narrow WG scope. My intention is not to force any > specific changes, but rather to encourage making changes prior to IETF > last call that might be helpful to speed IETF consensus. > > 1. Implicit server behavior changes > > This extension has several cases where client commands trigger a > server behavior change as a side-effect of a client command. There > has been significant discussion in other IETF contexts (EAI design > team, IMAPEXT, ENABLE extension) that such behavior is undesirable and > that if a server behavior change is to occur it should be explicit and > early in the protocol exchange. I would like to confirm the WG has > consensus on this specific issue as I suspect it is likely be > problematic during IETF last call. As per discussion during the Lemonade interim, Dave and I will change QRESYNC to depend on Arnt's ENABLE extension. The change will address this issue. > 2. Change in IMAP untagged response model > > For better or worse, IMAP is a cache update protocol model rather than > a request/response protocol model. That means an untagged response is > not bound to a particular command, but rather the portion of the > client's cache state that is updated can be determined solely from the > untagged response itself (the SEARCH response being a notable > exception). This extension changes that model by binding the VANISHED > response to a specific command with the TAG correlator. Are therge: en-us, en To: Randall Gellens Subject: Re: [lemonade] Expert Review: annotatemore (like WGLC) References: <1259253957.4021175574674855.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: Cyrus Daboo , to Internet email to support diverse service enivronments , IMAP Extensions WG , Enhancements X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Randy, Randall Gellens wrote: > I hope this isn't too late to be useful. > > At 9:31 PM -0700 4/2/07, Dan Karp wrote: > >> A user can only set and retrieve private or shared annotations on a >> mailbox which exists and is returned to them via a LIST or LSUB >> command, irrespective of whether they have read or write access to >> the actual message content of the mailbox. If the client >> attempts to >> set or retrieve annotations on other mailboxes, the server MUST >> respond with a NO response. >> >> I can understand the logic behind requiring LIST/LSUB access for >> reading >> public mailbox annotations and for setting private annotations. But >> that seems to be a very low bar for setting public mailbox annotations. >> Adding a new ACL permission for setting annotations would make this >> extension more complex and would also introduce a dependency on the ACL >> extension, but perhaps requiring [READ-WRITE] access to the mailbox >> might be reasonable? > > Seems reasonable. It's interesting that any user can set a shared > server annotation. I was also advocating a new ACL right, but Cyrus didn't think it was needed. > Note that, separate from Dan's comments, the description of the > SETMETADATA command should explicitly mention that an empty string is > used to set server annotations, and should include some examples of > doing so. > > Perhaps servers should be permitted to reject an attempt to set shared > server annotations if, based on internal configuration (that is, not > standardized) the user isn't allowed to do so? That would allow > servers to, for example, have some users that can set any shared > server annotations, others that can set none, and some that can set some. Well yes, but implementations can already do that no matter what the spec says. > I think trying to standardize this would require ACL extensions and > introduce an ACL dependency, which we don't want to do. This could > always be done in the future, based on operational experience. [...] >> Each annotation is an entry that has a hierarchical name, with each >> component of the name separated by a slash ("/"). An entry name >> MUST >> NOT contain two consecutive "/" characters and MUST NOT end with a >> "/" character. >> >> Each entry is made up of a set of attributes. Each attribute has a >> hierarchical name, with each component of the name separated by a >> period ("."). An attribute name MUST NOT contain two consecutive >> "." >> characters and MUST NOT end with a "." character. >> >> My last comment is personal preference: I fear that this may be a >> bit of >> overkill for folder annotation. I understand the need for this type of >> flexible syntax for ACAP's purposes, but the use cases for IMAP appear >> significantly more limited in scope. In ace > servers which execute client commands out-of-order so that such > binding would be necessary? Does the WG believe changing the > fundamental IMAP model in this case is the best way to accomplish this > specific task? > > 3. VANISHED response sometimes but not always implying EXISTS change > > The VANISHED response is used in two different ways: one to replace > the EXPUNGE response to indicate a change in mailbox state at that > moment (including an implicit EXISTS update), and one to indicate that > messages were removed before the mailbox was selected in response to a > QRESYNC select modifier or VANISHED UID FETCH modifier. I suspect the > logic the client must use to distinguish these cases is a bit subtle. > Perhaps a simplification to VANISHED to address issue 2 & 3 should be > considered? Based on subsequent discussion with Chris: QRESYNC will be updated to rename the TAG parameter to EARLIER and remove the associated command tag, as it was not used. Text describing that the VANISHED response with the EARLIER parameter doesn't decrement EXISTS would be also clarified. Note, that the VANISHED response never changed the IMAP model. The TAG parameter was only used to distinguish two cases: earlier expunged messages and currently expunged messages. > 4. Complex interaction with CONDSTORE and UIDPLUS > > This extension requires CONDSTORE and requires the server to advertise > CONDSTORE. That means there's a silly state where the server > advertises QRESYNC but not CONDSTORE. Perhaps there's a simple way to > eliminate the silly state? Furthermore, there is a great deal of > variation in server behaviors and client codepaths between un-extended > IMAP, IMAP + CONDSTORE, IMAP + CONDSTORE + QRESYNC and IMAP + > CONDSTORE + QRESYNC + UIDPLUS. Is the WG really comfortable with this > complexity? Perhaps QRESYNC should require UIDPLUS in addition to > CONDSTORE? Perhaps QRESYNC is really a refinement of CONDSTORE rather > than an extension to it, so perhaps QRESYNC should subsume CONDSTORE > and obsolete it? Thinking more about this: clients that would like to use the VANISHED responses would also likely want to use UID EXPUNGE (i.e. the UIDPLUS extension). So personally I am slightly in preference of making the UIDPLUS a requirement for all QRESYNC-compliant servers. However, if we do this change, it would make no difference as far as Lemonade Profile Bis is concerned, because servers are required to implement both extensions anyway. And existing IMAP clients already have to deal with absence of UIDPLUS extension. Having said that I would like to poll the WG regarding making QRESYNC require UIDPLUS. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed May 23 09:34:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqqz6-00038y-FL; Wed, 23 May 2007 09:34:36 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hqqz5-00038k-9H for lemonade-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 09:34:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqqz4-00038c-Vp for lemonade@ietf.org; Wed, 23 May 2007 09:34:34 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hqqz4-0005bb-H7 for lemonade@ietf.org; Wed, 23 May 2007 09:34:34 -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 ; Wed, 23 May 2007 14:34:33 +0100 Message-ID: <465423EF.4060209@isode.com> Date: Wed, 23 May 2007 12:22:23 +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-Languae > servers which execute client commands out-of-order so that such > binding would be necessary? Does the WG believe changing the > fundamental IMAP model in this case is the best way to accomplish this > specific task? > > 3. VANISHED response sometimes but not always implying EXISTS change > > The VANISHED response is used in two different ways: one to replace > the EXPUNGE response to indicate a change in mailbox state at that > moment (including an implicit EXISTS update), and one to indicate that > messages were removed before the mailbox was selected in response to a > QRESYNC select modifier or VANISHED UID FETCH modifier. I suspect the > logic the client must use to distinguish these cases is a bit subtle. > Perhaps a simplification to VANISHED to address issue 2 & 3 should be > considered? Based on subsequent discussion with Chris: QRESYNC will be updated to rename the TAG parameter to EARLIER and remove the associated command tag, as it was not used. Text describing that the VANISHED response with the EARLIER parameter doesn't decrement EXISTS would be also clarified. Note, that the VANISHED response never changed the IMAP model. The TAG parameter was only used to distinguish two cases: earlier expunged messages and currently expunged messages. > 4. Complex interaction with CONDSTORE and UIDPLUS > > This extension requires CONDSTORE and requires the server to advertise > CONDSTORE. That means there's a silly state where the server > advertises QRESYNC but not CONDSTORE. Perhaps there's a simple way to > eliminate the silly state? Furthermore, there is a great deal of > variation in server behaviors and client codepaths between un-extended > IMAP, IMAP + CONDSTORE, IMAP + CONDSTORE + QRESYNC and IMAP + > CONDSTORE + QRESYNC + UIDPLUS. Is the WG really comfortable with this > complexity? Perhaps QRESYNC should require UIDPLUS in addition to > CONDSTORE? Perhaps QRESYNC is really a refinement of CONDSTORE rather > than an extension to it, so perhaps QRESYNC should subsume CONDSTORE > and obsolete it? Thinking more about this: clients that would like to use the VANISHED responses would also likely want to use UID EXPUNGE (i.e. the UIDPLUS extension). So personally I am slightly in preference of making the UIDPLUS a requirement for all QRESYNC-compliant servers. However, if we do this change, it would make no difference as far as Lemonade Profile Bis is concerned, because servers are required to implement both extensions anyway. And existing IMAP clients already have to deal with absence of UIDPLUS extension. Having said that I would like to poll the WG regarding making QRESYNC require UIDPLUS. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed May 23 09:34:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqqz6-00038y-FL; Wed, 23 May 2007 09:34:36 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hqqz5-00038k-9H for lemonade-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 09:34:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqqz4-00038c-Vp for lemonade@ietf.org; Wed, 23 May 2007 09:34:34 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hqqz4-0005bb-H7 for lemonade@ietf.org; Wed, 23 May 2007 09:34:34 -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 ; Wed, 23 May 2007 14:34:33 +0100 Message-ID: <465423EF.4060209@isode.com> Date: Wed, 23 May 2007 12:22:23 +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-Languacordance with the KISS >> philosophy, is there any chance I might be able to convince everyone to >> consider shedding a layer of hierarchy here? > > I think we need the entry hierarchy. It might be possible to > eliminate the attribute hierarchy. Didn't we end up doing something > like that for ANNOTATE? Attribute hierarchy only has two levels, e.g. "value" . "shared". I think this is a non issue. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed May 23 09:34:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqqz8-00039F-K7; Wed, 23 May 2007 09:34:38 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hqqz6-00039A-Mp for lemonade-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 09:34:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqqz6-00038q-Bz for lemonade@ietf.org; Wed, 23 May 2007 09:34:36 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hqqz5-0005bb-27 for lemonade@ietf.org; Wed, 23 May 2007 09:34:36 -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 ; Wed, 23 May 2007 14:34:34 +0100 Message-ID: <4654359A.3010803@isode.com> Date: Wed, 23 May 2007 13:37:47 +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: Dan Karp Subject: Re: [lemonade] Expert Review: annotatemore (like WGLC) References: <1259253957.4021175574674855.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Randall Gellens , Cyrus Daboo , to Internet email to support diverse service enivronments , Enhancements, IMAP Extensions 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 Randall Gellens wrote:** >> This command sets the specified list of entries by adding or >> replacing the specified attributes with the values provided, on the >> specified existing mailboxes. > This sentence should have "or on the server (if the mailbox parameter is the empty string)" at the end. >> Clients can use NIL for values of >> attributes it wants to remove from entries. The server MAY return a >> METADATA response containing the updated annotation data. >> >> In this case, the server may return a METADATA response that doesn't >> contain the updated annotation data or a LIST response that does, >> correct? > You are right. The METADATA response is returned if per-server annotation is changed, the LIST response is returned if per-mailbox annotation is changes. Hmm, the METADATA response is not unsolicited, so it can contain the update value. So I think the last quoted sentence should be replaced with something like the following: If the client modified a server annotation then the serverge: en-us, en To: Randall Gellens Subject: Re: [lemonade] Expert Review: annotatemore (like WGLC) References: <1259253957.4021175574674855.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: Cyrus Daboo , to Internet email to support diverse service enivronments , IMAP Extensions WG , Enhancements X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Randy, Randall Gellens wrote: > I hope this isn't too late to be useful. > > At 9:31 PM -0700 4/2/07, Dan Karp wrote: > >> A user can only set and retrieve private or shared annotations on a >> mailbox which exists and is returned to them via a LIST or LSUB >> command, irrespective of whether they have read or write access to >> the actual message content of the mailbox. If the client >> attempts to >> set or retrieve annotations on other mailboxes, the server MUST >> respond with a NO response. >> >> I can understand the logic behind requiring LIST/LSUB access for >> reading >> public mailbox annotations and for setting private annotations. But >> that seems to be a very low bar for setting public mailbox annotations. >> Adding a new ACL permission for setting annotations would make this >> extension more complex and would also introduce a dependency on the ACL >> extension, but perhaps requiring [READ-WRITE] access to the mailbox >> might be reasonable? > > Seems reasonable. It's interesting that any user can set a shared > server annotation. I was also advocating a new ACL right, but Cyrus didn't think it was needed. > Note that, separate from Dan's comments, the description of the > SETMETADATA command should explicitly mention that an empty string is > used to set server annotations, and should include some examples of > doing so. > > Perhaps servers should be permitted to reject an attempt to set shared > server annotations if, based on internal configuration (that is, not > standardized) the user isn't allowed to do so? That would allow > servers to, for example, have some users that can set any shared > server annotations, others that can set none, and some that can set some. Well yes, but implementations can already do that no matter what the spec says. > I think trying to standardize this would require ACL extensions and > introduce an ACL dependency, which we don't want to do. This could > always be done in the future, based on operational experience. [...] >> Each annotation is an entry that has a hierarchical name, with each >> component of the name separated by a slash ("/"). An entry name >> MUST >> NOT contain two consecutive "/" characters and MUST NOT end with a >> "/" character. >> >> Each entry is made up of a set of attributes. Each attribute has a >> hierarchical name, with each component of the name separated by a >> period ("."). An attribute name MUST NOT contain two consecutive >> "." >> characters and MUST NOT end with a "." character. >> >> My last comment is personal preference: I fear that this may be a >> bit of >> overkill for folder annotation. I understand the need for this type of >> flexible syntax for ACAP's purposes, but the use cases for IMAP appear >> significantly more limited in scope. In acge: en-us, en To: Randall Gellens Subject: Re: [lemonade] Expert Review: annotatemore (like WGLC) References: <1259253957.4021175574674855.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: Cyrus Daboo , to Internet email to support diverse service enivronments , IMAP Extensions WG , Enhancements X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Randy, Randall Gellens wrote: > I hope this isn't too late to be useful. > > At 9:31 PM -0700 4/2/07, Dan Karp wrote: > >> A user can only set and retrieve private or shared annotations on a >> mailbox which exists and is returned to them via a LIST or LSUB >> command, irrespective of whether they have read or write access to >> the actual message content of the mailbox. If the client >> attempts to >> set or retrieve annotations on other mailboxes, the server MUST >> respond with a NO response. >> >> I can understand the logic behind requiring LIST/LSUB access for >> reading >> public mailbox annotations and for setting private annotations. But >> that seems to be a very low bar for setting public mailbox annotations. >> Adding a new ACL permission for setting annotations would make this >> extension more complex and would also introduce a dependency on the ACL >> extension, but perhaps requiring [READ-WRITE] access to the mailbox >> might be reasonable? > > Seems reasonable. It's interesting that any user can set a shared > server annotation. I was also advocating a new ACL right, but Cyrus didn't think it was needed. > Note that, separate from Dan's comments, the description of the > SETMETADATA command should explicitly mention that an empty string is > used to set server annotations, and should include some examples of > doing so. > > Perhaps servers should be permitted to reject an attempt to set shared > server annotations if, based on internal configuration (that is, not > standardized) the user isn't allowed to do so? That would allow > servers to, for example, have some users that can set any shared > server annotations, others that can set none, and some that can set some. Well yes, but implementations can already do that no matter what the spec says. > I think trying to standardize this would require ACL extensions and > introduce an ACL dependency, which we don't want to do. This could > always be done in the future, based on operational experience. [...] >> Each annotation is an entry that has a hierarchical name, with each >> component of the name separated by a slash ("/"). An entry name >> MUST >> NOT contain two consecutive "/" characters and MUST NOT end with a >> "/" character. >> >> Each entry is made up of a set of attributes. Each attribute has a >> hierarchical name, with each component of the name separated by a >> period ("."). An attribute name MUST NOT contain two consecutive >> "." >> characters and MUST NOT end with a "." character. >> >> My last comment is personal preference: I fear that this may be a >> bit of >> overkill for folder annotation. I understand the need for this type of >> flexible syntax for ACAP's purposes, but the use cases for IMAP appear >> significantly more limited in scope. In ac MAY return a METADATA response containing the updated annotation data (see section 4.5.1). If the client modified a mailbox annotation then the server MAY return an extended LIST response containing the METADATA item with the updated annotation data (see section 4.3). But the more I think about the more I get convinced that the MAYs should be changed to SHOULD NOTs. /* */ _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade cordance with the KISS >> philosophy, is there any chance I might be able to convince everyone to >> consider shedding a layer of hierarchy here? > > I think we need the entry hierarchy. It might be possible to > eliminate the attribute hierarchy. Didn't we end up doing something > like that for ANNOTATE? Attribute hierarchy only has two levels, e.g. "value" . "shared". I think this is a non issue. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed May 23 09:34:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqqz8-00039F-K7; Wed, 23 May 2007 09:34:38 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hqqz6-00039A-Mp for lemonade-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 09:34:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqqz6-00038q-Bz for lemonade@ietf.org; Wed, 23 May 2007 09:34:36 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hqqz5-0005bb-27 for lemonade@ietf.org; Wed, 23 May 2007 09:34:36 -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 ; Wed, 23 May 2007 14:34:34 +0100 Message-ID: <4654359A.3010803@isode.com> Date: Wed, 23 May 2007 13:37:47 +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: Dan Karp Subject: Re: [lemonade] Expert Review: annotatemore (like WGLC) References: <1259253957.4021175574674855.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Randall Gellens , Cyrus Daboo , to Internet email to support diverse service enivronments , Enhancements, IMAP Extensions 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 Randall Gellens wrote:** >> This command sets the specified list of entries by adding or >> replacing the specified attributes with the values provided, on the >> specified existing mailboxes. > This sentence should have "or on the server (if the mailbox parameter is the empty string)" at the end. >> Clients can use NIL for values of >> attributes it wants to remove from entries. The server MAY return a >> METADATA response containing the updated annotation data. >> >> In this case, the server may return a METADATA response that doesn't >> contain the updated annotation data or a LIST response that does, >> correct? > You are right. The METADATA response is returned if per-server annotation is changed, the LIST response is returned if per-mailbox annotation is changes. Hmm, the METADATA response is not unsolicited, so it can contain the update value. So I think the last quoted sentence should be replaced with something like the following: If the client modified a server annotation then the servercordance with the KISS >> philosophy, is there any chance I might be able to convince everyone to >> consider shedding a layer of hierarchy here? > > I think we need the entry hierarchy. It might be possible to > eliminate the attribute hierarchy. Didn't we end up doing something > like that for ANNOTATE? Attribute hierarchy only has two levels, e.g. "value" . "shared". I think this is a non issue. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed May 23 09:34:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqqz8-00039F-K7; Wed, 23 May 2007 09:34:38 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hqqz6-00039A-Mp for lemonade-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 09:34:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqqz6-00038q-Bz for lemonade@ietf.org; Wed, 23 May 2007 09:34:36 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hqqz5-0005bb-27 for lemonade@ietf.org; Wed, 23 May 2007 09:34:36 -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 ; Wed, 23 May 2007 14:34:34 +0100 Message-ID: <4654359A.3010803@isode.com> Date: Wed, 23 May 2007 13:37:47 +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: Dan Karp Subject: Re: [lemonade] Expert Review: annotatemore (like WGLC) References: <1259253957.4021175574674855.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Randall Gellens , Cyrus Daboo , to Internet email to support diverse service enivronments , Enhancements, IMAP Extensions 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 Randall Gellens wrote:** >> This command sets the specified list of entries by adding or >> replacing the specified attributes with the values provided, on the >> specified existing mailboxes. > This sentence should have "or on the server (if the mailbox parameter is the empty string)" at the end. >> Clients can use NIL for values of >> attributes it wants to remove from entries. The server MAY return a >> METADATA response containing the updated annotation data. >> >> In this case, the server may return a METADATA response that doesn't >> contain the updated annotation data or a LIST response that does, >> correct? > You are right. The METADATA response is returned if per-server annotation is changed, the LIST response is returned if per-mailbox annotation is changes. Hmm, the METADATA response is not unsolicited, so it can contain the update value. So I think the last quoted sentence should be replaced with something like the following: If the client modified a server annotation then the server MAY return a METADATA response containing the updated annotation data (see section 4.5.1). If the client modified a mailbox annotation then the server MAY return an extended LIST response containing the METADATA item with the updated annotation data (see section 4.3). But the more I think about the more I get convinced that the MAYs should be changed to SHOULD NOTs. /* */ _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade MAY return a METADATA response containing the updated annotation data (see section 4.5.1). If the client modified a mailbox annotation then the server MAY return an extended LIST response containing the METADATA item with the updated annotation data (see section 4.3). But the more I think about the more I get convinced that the MAYs should be changed to SHOULD NOTs. /* */ _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu May 24 10:54:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrEhu-0008EE-JC; Thu, 24 May 2007 10:54:26 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HrEht-0008E8-Ex for lemonade-confirm+ok@megatron.ietf.org; Thu, 24 May 2007 10:54:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrEht-0008E0-5E; Thu, 24 May 2007 10:54:25 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrEhs-000191-OL; Thu, 24 May 2007 10:54:25 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l4OEsNLU008609; Thu, 24 May 2007 07:54:23 -0700 Received: from rcpbex01.amer.bea.com (repbex01.bea.com [10.168.26.17] (may be forged)) by repmmr02.bea.com (Switch-3.2.7/Switch-3.2.5) with ESMTP id l4OEsK2a030577; Thu, 24 May 2007 07:54:21 -0700 Received: from 10.128.4.27 ([10.128.4.27]) by rcpbex01.amer.bea.com ([10.168.26.17]) with Microsoft Exchange Server HTTP-DAV ; Thu, 24 May 2007 14:54:20 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 24 May 2007 15:59:34 +0800 From: Eric Burger To: Chris Newman , IESG Secretary Message-ID: Thread-Topic: Publication Request: IMAP URL Scheme Thread-Index: Aced2XdmtggW6QnMEdyU+wAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.2 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: lemonade@ietf.org, Glenn Parsons Subject: [lemonade] Publication Request: IMAP URL Scheme X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org DOCUMENT: IMAP URL Scheme draft-ietf-lemonade-rfc2192bis-07 (Standards Track) (1.a) Document Shepherd: Eric Burger, eburger@bea.com, personally reviewed this document. This document is ready for publication. (1.b) Work group review: The lemonade work group provided review of this document. (1.c) Further review required: This document does not need further specialized review, as it has received review by many members of the IMAP community. There are no concerns regarding internationalization, as one of the co-editors is an expert on internationalization. (1.d.i) Document Shepherd Comfort Level: High (1.d.ii) Document Useful and Needed: Yes (1.d.iii) IPR Disclosures: None known (1.e) Work Group Consensus: There is a solid WG consensus behind the document. Note that the document is a normative dependency of the Lemonade Profile Bis document. (1.f) There are no members with objections or concerns. There are no threats of appeal or process issues. (1.g.i) ID-nits: Checked and verified with idnits 2.04.07; warnings are a lack of TOC, a lack of (or rather, bizarre) page separators, an incorrectly identified unused reference [DATETIME] which appears in an ABNF comment, and the self-reference RFCXXXX. The real errors of the page separators and the self-reference are for the RFC Editor to correct. (1.g.ii) MIB Doctor: Not applicable (1.g.iii) Media Type: Not applicable (1.g.iv) URI Type: As it defines a URI scheme, it should have URI expert review. Ted Hardie, one of the URI experts, reviewed the document. However, I forgot to send a note to the URI review list. That will happen in parallel with this request to publish. (1.h.i) Reference split: Yes (1.h.ii) Downward normative references: No (1.h.iii) References to drafts: No (1.i) IANA Considerations: Yes, correct, consistent, and follows RFC 3501 rules. (1.j) ABNF: Passes Bill's ABNF parser. (1.k) Document Announcement: Technical Summary IMAP (RFC 3501) is a rich protocol for accessing remote message stores. It provides an ideal mechanism for accessing public mailing list archives as well as private and shared message stores. This document defines a URL scheme for referencing objects on an IMAP server. This document obsoletes RFC 2192 and updates RFC 4467. Working Group Summary This document removed support for IMAP URLs for listing the contents of a mailbox. There was a clear consensus that this feature (originally described in RFC 2192) was never implemented. Some of the changes to the document were a result of the Lemonade interoperability event of October 2006 held in London, England. Document Quality The document received several positive reviews. In particular it is worth noting Ted Hardie and Zoltan Ordogh have done detailed reviews of the document. This document addresses all issues raised. Personnel Eric Burger shepherds this document on behalf of Chris Newman, the responsible Area Director. Eric Burger reviewed this document and believes it is ready for forwarding to the IESG for publication. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu May 24 18:44:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrM2v-0002Us-EV; Thu, 24 May 2007 18:44:37 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HrM2u-0002Ud-Ca for lemonade-confirm+ok@megatron.ietf.org; Thu, 24 May 2007 18:44:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrM2u-0002UU-2o; Thu, 24 May 2007 18:44:36 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrM2s-0006CL-Nx; Thu, 24 May 2007 18:44:36 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l4OMiRxR023997; Thu, 24 May 2007 15:44:27 -0700 Received: from rcpbex01.amer.bea.com (rcpbex01.bea.com [10.168.26.17]) by repmmr01.bea.com (Switch-3.2.7/Switch-3.2.5) with ESMTP id l4OMiQ4o005438; Thu, 24 May 2007 15:44:26 -0700 Received: from 10.128.4.37 ([10.128.4.37]) by rcpbex01.amer.bea.com ([10.168.26.17]) with Microsoft Exchange Server HTTP-DAV ; Thu, 24 May 2007 22:44:26 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 25 May 2007 06:44:23 +0800 From: Eric Burger To: Message-ID: Thread-Topic: Request for review: draft-ietf-lemonade-rfc2192bis-07 Thread-Index: AceeVRLoUT6s8gpIEdyPCQAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 1.1 (+) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: lemonade@ietf.org Subject: [lemonade] Request for review: draft-ietf-lemonade-rfc2192bis-07 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org draft-ietf-lemonade-rfc2192bis-07 describes an update to RFC 2192, the IMAP URI Scheme. The document has been reviewed by Ted Hardie, but if anyone else is interested, please have at it. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri May 25 07:15:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrXlu-0006Xy-Da; Fri, 25 May 2007 07:15:50 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HrXls-0006Xl-PM for lemonade-confirm+ok@megatron.ietf.org; Fri, 25 May 2007 07:15:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrXls-0006Xd-EB for lemonade@ietf.org; Fri, 25 May 2007 07:15:48 -0400 Received: from mail.freax.org ([86.39.154.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrXlr-00086S-4j for lemonade@ietf.org; Fri, 25 May 2007 07:15:48 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.freax.org (Postfix) with ESMTP id 7835E19F203 for ; Fri, 25 May 2007 12:57:40 +0200 (CEST) Received: from mail.freax.org ([127.0.0.1]) by localhost (mail.freax.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtT0E7xP8lHy for ; Fri, 25 May 2007 12:57:40 +0200 (CEST) Received: from [192.168.1.113] (d54C0EE14.access.telenet.be [84.192.238.20]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.freax.org (Postfix) with ESMTP id 3F87119F202 for ; Fri, 25 May 2007 12:57:40 +0200 (CEST) From: Philip Van Hoof To: lemonade@ietf.org Content-Type: text/plain Date: Fri, 25 May 2007 13:15:45 +0200 Message-Id: <1180091745.6187.39.camel@schtrumpf> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [lemonade] QRESYNC, I'd like to do a proof of concept X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Although busy with a lot of things, I'm very interested in implementing full support for QRESYNC in Tinymail. I'm looking for server developers to get it implemented in their server, so that we can make it work at both sides. Perhaps for now as some sort of proof of concept? For seeing where the difficulties are. CONDSTORE introduces quite a lot of difficulties for knowing whether or not expunges have happened. I think we should avoid this in future. That "VANISHED" line might actually solve a lot of these problems, but I can really only know .. more (as testing equals "knowing more") once I have a working QRESYNC enabled SELECT. Who's with me? Cyrus? Mbox? Dovecot? Courier perhaps? Oryx? I mean, let's just do it. Right? -- Philip Van Hoof, software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://www.pvanhoof.be/blog _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri May 25 07:27:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrXxQ-0004B0-VL; Fri, 25 May 2007 07:27:44 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HrXxP-0004Av-7m for lemonade-confirm+ok@megatron.ietf.org; Fri, 25 May 2007 07:27:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrXxO-0004An-D5 for lemonade@ietf.org; Fri, 25 May 2007 07:27:42 -0400 Received: from py-out-1112.google.com ([64.233.166.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrXxM-0002FY-6F for lemonade@ietf.org; Fri, 25 May 2007 07:27:42 -0400 Received: by py-out-1112.google.com with SMTP id a25so788534pyi for ; Fri, 25 May 2007 04:27:39 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=H8ZgQvl4uoRKKeKAIIbzQi9EaxbPnx9LBnPmIiffKuVzqcA1EGJhmXqx4qSn31rzTdXCcYM5bGU09Xqr5Tm8rowGFwV6oxKDwIuYpL0N+Su012l0r5XqwJwYpB4YiMRT96jeXtoeUmMUCgaXzx7PUFXBcW2EdJw4jzirOQfnc3I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=fvBeAKyIC+kBw7/g39kkbiqATzs6c1OD1fweSIvaziq1Ef4SD32vz3Ptigw1xbSicB/WRDwT8M+ZMKN5mQcsefU0OaFzKTVWLWUWDrh6muds/T01pPY5p775lDPJ8525PYQ4qjyNjjHXgcOa3NyBY/M9xgBoxp9gL6nolE8hgOQ= Received: by 10.65.53.3 with SMTP id f3mr5570657qbk.1180092459342; Fri, 25 May 2007 04:27:39 -0700 (PDT) Received: by 10.65.20.1 with HTTP; Fri, 25 May 2007 04:27:39 -0700 (PDT) Message-ID: Date: Fri, 25 May 2007 13:27:39 +0200 From: "=?ISO-8859-1?Q?DINH_Vi=EAt_Ho=E0?=" To: "Philip Van Hoof" Subject: Re: [lemonade] QRESYNC, I'd like to do a proof of concept In-Reply-To: <1180091745.6187.39.camel@schtrumpf> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1180091745.6187.39.camel@schtrumpf> X-Google-Sender-Auth: 1b4a39398d52ce1a X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On 5/25/07, Philip Van Hoof wrote: > Although busy with a lot of things, I'm very interested in implementing > full support for QRESYNC in Tinymail. > > I'm looking for server developers to get it implemented in their server, > so that we can make it work at both sides. Perhaps for now as some sort > of proof of concept? For seeing where the difficulties are. > > CONDSTORE introduces quite a lot of difficulties for knowing whether or > not expunges have happened. I think we should avoid this in future. Could you describe the problem between EXPUNGE and CONDSTORE ? --=20 DINH Vi=EAt Ho=E0 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri May 25 07:50:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrYJV-0005IM-T8; Fri, 25 May 2007 07:50:33 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HrYJU-0005IH-Fx for lemonade-confirm+ok@megatron.ietf.org; Fri, 25 May 2007 07:50:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrYJU-0005I9-6L for lemonade@ietf.org; Fri, 25 May 2007 07:50:32 -0400 Received: from mail.freax.org ([86.39.154.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrYJS-0006E1-PR for lemonade@ietf.org; Fri, 25 May 2007 07:50:32 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.freax.org (Postfix) with ESMTP id 4B32119F22E; Fri, 25 May 2007 13:32:24 +0200 (CEST) Received: from mail.freax.org ([127.0.0.1]) by localhost (mail.freax.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrWFNYPXRZiJ; Fri, 25 May 2007 13:32:24 +0200 (CEST) Received: from [192.168.1.113] (d54C0EE14.access.telenet.be [84.192.238.20]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.freax.org (Postfix) with ESMTP id 2024F19F21B; Fri, 25 May 2007 13:32:24 +0200 (CEST) Subject: Re: [lemonade] QRESYNC, I'd like to do a proof of concept From: Philip Van Hoof To: DINH =?ISO-8859-1?Q?Vi=EAt_Ho=E0?= In-Reply-To: References: <1180091745.6187.39.camel@schtrumpf> Content-Type: text/plain; charset=UTF-8 Date: Fri, 25 May 2007 13:50:29 +0200 Message-Id: <1180093829.6187.51.camel@schtrumpf> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Fri, 2007-05-25 at 13:27 +0200, DINH Vi=C3=AAt Ho=C3=A0 wrote: > On 5/25/07, Philip Van Hoof wrote: > > Although busy with a lot of things, I'm very interested in implementi= ng > > full support for QRESYNC in Tinymail. > > > > I'm looking for server developers to get it implemented in their serv= er, > > so that we can make it work at both sides. Perhaps for now as some so= rt > > of proof of concept? For seeing where the difficulties are. > > > > CONDSTORE introduces quite a lot of difficulties for knowing whether = or > > not expunges have happened. I think we should avoid this in future. >=20 > Could you describe the problem between EXPUNGE and CONDSTORE ? Well, if using CONDSTORE with the sequences, it's only save to use this if no expunges have happened. Else I might be flipping flags of locally cached messages that are not the ones that the query's result set intends. Having to use the uids means a hash-table lookup (which is not always interesting for a lot of messages on a mobile device). I'm right now asking for the UID and comparing it (the message that is to be updated) against that too, and falling back to old synchronisation code if one message is not in sync. I also added quite a lot of checks to 'guess' whether an expunge might have happened, before doing the UID FETCH 1:* (FLAGS) (CHANGEDSINCE 12345) query. None of that checking is really atomic, it's sub optimal and it's a lot of code that can go wrong in my opinion. With QRESYNC I would atomically know about the expunges. So I could update my local sequence table and be sure that both remotely and locally the syncing would be correct. -- People don't like it when a message gets wrongly flagged as removed, so it's not that I can take any risks here -- --=20 Philip Van Hoof, software developer home: me at pvanhoof dot be=20 gnome: pvanhoof at gnome dot org=20 http://www.pvanhoof.be/blog _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri May 25 08:02:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrYV3-0003Tt-O4; Fri, 25 May 2007 08:02:29 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HrYV2-0003Rv-Es for lemonade-confirm+ok@megatron.ietf.org; Fri, 25 May 2007 08:02:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrYV2-0003Rn-56 for lemonade@ietf.org; Fri, 25 May 2007 08:02:28 -0400 Received: from py-out-1112.google.com ([64.233.166.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrYUz-0000ZO-Sl for lemonade@ietf.org; Fri, 25 May 2007 08:02:28 -0400 Received: by py-out-1112.google.com with SMTP id a25so803686pyi for ; Fri, 25 May 2007 05:02:25 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=ZHJXQJLIiJLsxL7F8qhd/zKGOVYiYfPvxs7BDKvT4GMAstjV4VApDJRY1IXrDAuodH6/w+W6cdNzxgPldKqN62qFrfNQE+4WngPkS1V8QcUbSdVlD8Ry51nM1lqfEb1L7Kz8swJEWRCZwjRp7z+YB8hphCpz9+Ja1Yt8ZQYz28M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=OixR4x9DykPbXnDvbp7zpCHkNeUIaiEy7BrnFWgpLa8gvAO9W5oz5RwuNA92caq/A12BFgswteZ53YInZoGGOvnK1XOv/bZm3RMV8oY86nkk86S+By+LhoJYp6WpF1W0zRzzxMDCLTJO1KWLkNiDbpry6B0EuSdZv3dLkpaJajY= Received: by 10.64.220.8 with SMTP id s8mr5615020qbg.1180094545414; Fri, 25 May 2007 05:02:25 -0700 (PDT) Received: by 10.65.20.1 with HTTP; Fri, 25 May 2007 05:02:25 -0700 (PDT) Message-ID: Date: Fri, 25 May 2007 14:02:25 +0200 From: "=?ISO-8859-1?Q?DINH_Vi=EAt_Ho=E0?=" To: "Philip Van Hoof" Subject: Re: [lemonade] QRESYNC, I'd like to do a proof of concept In-Reply-To: <1180093829.6187.51.camel@schtrumpf> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1180091745.6187.39.camel@schtrumpf> <1180093829.6187.51.camel@schtrumpf> X-Google-Sender-Auth: a1972b73d3b6b769 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 On 5/25/07, Philip Van Hoof wrote: > On Fri, 2007-05-25 at 13:27 +0200, DINH Vi=EAt Ho=E0 wrote: > > On 5/25/07, Philip Van Hoof wrote: > > > Although busy with a lot of things, I'm very interested in implementi= ng > > > full support for QRESYNC in Tinymail. > > > > > > I'm looking for server developers to get it implemented in their serv= er, > > > so that we can make it work at both sides. Perhaps for now as some so= rt > > > of proof of concept? For seeing where the difficulties are. > > > > > > CONDSTORE introduces quite a lot of difficulties for knowing whether = or > > > not expunges have happened. I think we should avoid this in future. > > > > Could you describe the problem between EXPUNGE and CONDSTORE ? > > Well, if using CONDSTORE with the sequences, it's only save to use this > if no expunges have happened. Else I might be flipping flags of locally > cached messages that are not the ones that the query's result set > intends. Having to use the uids means a hash-table lookup (which is not > always interesting for a lot of messages on a mobile device). > > I'm right now asking for the UID and comparing it (the message that is > to be updated) against that too, and falling back to old synchronisation > code if one message is not in sync. maybe a simple heuristic for this is to store what the flags looked like on server when you stored that local flags. And when synchronizing local changes to the server, first get the flags of the messages you are going to modify from the server and if this match what you expected, change the flags on the server to the value you have locally. And if it does not match, don't apply flags. I think that will fit most cases. --=20 DINH Vi=EAt Ho=E0 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sat May 26 00:06:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrnXw-0002Wf-KN; Sat, 26 May 2007 00:06:28 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HrnXv-0002WL-GS for lemonade-confirm+ok@megatron.ietf.org; Sat, 26 May 2007 00:06:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrnXu-0002WD-VQ for lemonade@ietf.org; Sat, 26 May 2007 00:06:26 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrnXt-0006UD-Il for lemonade@ietf.org; Sat, 26 May 2007 00:06:26 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l4Q46NTe001371 for ; Fri, 25 May 2007 21:06:23 -0700 Received: from rcpbex01.amer.bea.com (rcpbex01.bea.com [10.168.26.17]) by repmmr01.bea.com (Switch-3.2.7/Switch-3.2.5) with ESMTP id l4Q46C2M003023 for ; Fri, 25 May 2007 21:06:22 -0700 Received: from 10.43.242.9 ([10.43.242.9]) by rcpbex01.amer.bea.com ([10.168.26.17]) with Microsoft Exchange Server HTTP-DAV ; Sat, 26 May 2007 04:06:18 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 25 May 2007 23:30:49 -0400 From: Eric Burger To: "lemonade@ietf.org" Message-ID: Thread-Topic: Preliminary IETF 69 Schedule Thread-Index: AcefRkD5f6qLggs5EdyUaQAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.5 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [lemonade] Preliminary IETF 69 Schedule X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org MONDAY, July 23, 2007 1300-1500 Afternoon Session I Breakout 5 APP lemonade Enhancements to Internet email to Support Diverse Service Environments WG TUESDAY, July 24, 2007 1520-1720 Afternoon Session II Breakout 3 APP lemonade Enhancements to Internet email to Support Diverse Service Environments WG As always, subject to change with little or no notice. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon May 28 12:41:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsiHy-0000pt-P5; Mon, 28 May 2007 12:41:46 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HsiHx-0000po-1S for lemonade-confirm+ok@megatron.ietf.org; Mon, 28 May 2007 12:41:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsiHw-0000pg-O2 for lemonade@ietf.org; Mon, 28 May 2007 12:41:44 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsiHu-0005hm-S7 for lemonade@ietf.org; Mon, 28 May 2007 12:41:44 -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 ; Mon, 28 May 2007 17:41:40 +0100 Message-ID: <465ADE65.1040409@isode.com> Date: Mon, 28 May 2007 14:51:33 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Philip Van Hoof Subject: Re: [lemonade] QRESYNC, I'd like to do a proof of concept References: <1180091745.6187.39.camel@schtrumpf> <1180093829.6187.51.camel@schtrumpf> In-Reply-To: <1180093829.6187.51.camel@schtrumpf> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 Philip Van Hoof wrote: >>Could you describe the problem between EXPUNGE and CONDSTORE ? >> >> >Well, if using CONDSTORE with the sequences, it's only save to use this >if no expunges have happened. Else I might be flipping flags of locally >cached messages that are not the ones that the query's result set >intends. Having to use the uids means a hash-table lookup (which is not >always interesting for a lot of messages on a mobile device). > If your client is using FETCH (as opposed to UID FETCH), an IMAP server is not allowed to send any EXPUNGE responses while processing it. >I'm right now asking for the UID and comparing it (the message that is >to be updated) against that too, and falling back to old synchronisation >code if one message is not in sync. > > This is a good coding practice anyway. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade