From lemonade-bounces@ietf.org Wed Nov 01 06:01:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfDpu-0004O6-1C; Wed, 01 Nov 2006 06:00:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfDGI-0000li-BX for lemonade@ietf.org; Wed, 01 Nov 2006 05:23:58 -0500 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfDGG-0005TS-Ss for lemonade@ietf.org; Wed, 01 Nov 2006 05:23:58 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA1ANtZD018054; Wed, 1 Nov 2006 12:23:55 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 12:23:55 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 12:23:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-04.txt Date: Wed, 1 Nov 2006 12:23:01 +0200 Message-ID: <0FA975F2D8295A448BE3ADC161244657018AD2CF@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-04.txt Thread-Index: Acb9I3MOllFsy552QQCxDh99tno4yQAfAFMg From: To: , X-OriginalArrivalTime: 01 Nov 2006 10:23:55.0145 (UTC) FILETIME=[D5930F90:01C6FD9F] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061101122356-3EB6CBB0-59C371DB/0-0/0-1 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 Randall, >>>> (3) In Section "4.3. Message size declaration", the text: >>>> LEMONADE compliant mail submission servers MUST=20 >resolve all BURL >>>> parts before enforcing a message size limit. >>>> >>>> Requires the servers to expand all BURL parts, even if=20 >the message =20 >>>> already exceeds the message size limit. A while back I suggested =20 >>>> saying "Servers MUST NOT consider a message's size to be >>>acceptable if >>>> it has not expanded all BURL parts." I'm not wedded to that >>>phrasing, >>>> but I do think we should allow servers to reject messages before =20 >>>> expanding everything. >>> >>>I am not exactly happy with your replacement text, this might be too=20 >>>subtle for people to notice. I need to think about better=20 >>>alternatives. >> I would prefer writing it down as well. I am not sure how=20 >to put it =20 >> though. Here is another attempt: >> LEMONADE compliant mail submission servers MUST resolve all BURL=20 >> parts before enforcing a message size limit and MUST NOT=20 >reject email=20 >> messages where the total size of the email message reassembled from=20 >> BURL parts is smaller than the message size limit. > >The problem with that text is that the first sentence is=20 >identical to the original text and thus doesn't fix the flaw=20 >that I discuss (see the quoted text from me, above). The new=20 >suggested text I sent in yesterday does fix it and also=20 >addresses Alexey's concerns. Also, the second sentence in=20 >your text doesn't permit servers to reject messages for any=20 >reason other than size, which I'm sure isn't your intent :-) No, it is not my intent. I thought that the "where..." part would care of that. It's tricky to come up with a good wording that pleases everyone; obviously mine was a poor attempt. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 01 06:22:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfEAi-0003Ry-LW; Wed, 01 Nov 2006 06:22:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfDaK-0004Ro-UE for lemonade@ietf.org; Wed, 01 Nov 2006 05:44:41 -0500 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfDaJ-0008I6-E2 for lemonade@ietf.org; Wed, 01 Nov 2006 05:44:40 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA1Aibix011459; Wed, 1 Nov 2006 12:44:38 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 12:44:37 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 12:44:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-compress-05.txt - comments Date: Wed, 1 Nov 2006 12:43:43 +0200 Message-ID: <0FA975F2D8295A448BE3ADC161244657018AD334@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] I-D ACTION:draft-ietf-lemonade-compress-05.txt - comments Thread-Index: Acb9KklUA4j7nHd2RDCx9Q2CZePRBwAdXmMA From: To: , X-OriginalArrivalTime: 01 Nov 2006 10:44:36.0952 (UTC) FILETIME=[B9BFC580:01C6FDA2] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061101124438-22318BB0-2BFAFC49/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.8 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Randall, >> 3. Wording change suggestion in section 3: >> OK The server will compress its responses and expects the client to=20 >> compress its commands. >> to: >> OK The server and the client will compress all data that it may send > >"data that it may send" sounds funny. The original text is=20 >very clear about which side compresses what (commands versus=20 >responses).=20 >Is there something about it you don't like? Yes, in another thread I replied already that it is the "expects" that I do not like. That's what I tried to change, but I collapsed the client commands and server responses into a single "data", I guess this is something I should not have done. I would like to get rid of "expects" though because it hints that it might not happen. >> 4. Wording change suggestion in section 3: >> The client MUST NOT send any further commands until it has seen the=20 >> result of COMPRESS. >> to: >> After the client has sent the COMPRESS command, the client MUST NOT=20 >> send any commands until it has seen the result of COMPRESS. > >I think the original wording is better as it is more compact and says=20 >what it needs to. But perhaps I'm missing something. What about it=20 >don't you like? Here, the intent was to clarify the exact interval - I mean only the end of the interval clear, but the beginning is not. What I miss here is that the client MUST NOT send anything between issuing the COMPRESS command and receiving the response to it. We do not know when the "client silence" starts. >> 5. Clarification/wording change suggestion in section 3: >> (Responses issued by the server before the OK response will, of=20 >> course, still be uncompressed.) >> to: >> Therefore, responses issued by the server before the OK response=20 >> will all be uncompressed, and delayed client requests that have=20 >> been sent uncompressed (before turning compression on) may result=20 >> in compressed responses. > >What are "delayed client requests"? Do you mean commands sent by the=20 >client before it sent COMPRESS that were delayed by underlying=20 >network (perhaps routed differently)? Or do you mean something else?=20 >If the server receives uncompressed commands after it has sent the OK=20 >to COMPRESS, will it interpret them correctly? The original text=20 >implies no, but your suggested text states yes. No, this is exactly what I meant - perhaps the wording is not right, but this is what I tried to capture. Latency of commands/responses. I did not think about the second question You raised, but it's a good one - I looked at it from the client point view only. Let's check using a use case here. Let's assume that client issues commands a, b, COMPRESS, d, e. My proposal: - server receives a, b, COMPRESS, d, e (the right order) - server responds a, b, COMPRESS, d, e (the right order, again). - there is some latency, therefore client receives repsonses a, COMPRESS, b, d, e Your question: - server receives a, COMPRESS, b, d, e (not in the right order) In theory, TCP/IP should guarantee the right order and we should not worry about his at all. Just a tought that's been bugging me. It's better to ask than not to say anything. >> 7. Wording change suggestion in section 4: >> the same way as is recommended for servers >> the same way as it is recommended for servers later > >Why do you want to change "as is" to "as it is"? The suggested=20 >wording sounds awkward to me, and implies that a source other than=20 >this draft is doing the recommending. It sounded like the "it" was missing. >> 9. Question in section 5: >> capability =3D/ "COMPRESS=3D" algorithm >> ;; multiple COMPRESS capabilities allowed >> So, if I had multiple algorithms, would it be COMPRESS=3D1,2,3 or=20 >> COMPRESS=3D1,COMPRESS=3D2,COMPRESS=3D3? I would guess the second. > >That's correct, and matches what has been done for some other=20 >extensions. > >Note that the ABNF for your first alternate would be > "COMPRESS=3D" algorithm *( "," algorithm ) This is what I wanted to hear - should it be described already here? (To prepare clients/servers to deal with the *( "," algorithm ) part? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 01 06:22:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfEAk-0003WV-Gq; Wed, 01 Nov 2006 06:22:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfDc6-00061G-2U for lemonade@ietf.org; Wed, 01 Nov 2006 05:46:30 -0500 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfDc4-00007V-L5 for lemonade@ietf.org; Wed, 01 Nov 2006 05:46:30 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA1AkF6g029291; Wed, 1 Nov 2006 12:46:27 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 12:46:23 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 12:46:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-compress-05.txt - comments Date: Wed, 1 Nov 2006 12:45:29 +0200 Message-ID: <0FA975F2D8295A448BE3ADC161244657018AD339@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] I-D ACTION:draft-ietf-lemonade-compress-05.txt - comments Thread-Index: Acb9MvfvrufUvndTTnOEy9mzZEAI6gAb77uA From: To: , X-OriginalArrivalTime: 01 Nov 2006 10:46:21.0768 (UTC) FILETIME=[F8396C80:01C6FDA2] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Philip, >>> So, if I had multiple algorithms, would it be COMPRESS=3D1,2,3 or=20 >>> COMPRESS=3D1,COMPRESS=3D2,COMPRESS=3D3? I would guess the second. > >It would be COMPRESS=3D1 COMPRESS=3D2 COMPRESS=3D3. Capabilities=20 >are separated by spaces, not commas. c.f. RFC 3501 page 25=20 >for an example involving multiple AUTH=3D capabilities. This is the exact opposite of what Randall said. Should it be clarified then? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 01 06:22:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfEAw-00041n-0u; Wed, 01 Nov 2006 06:22:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfDsP-00082p-Bb for lemonade@ietf.org; Wed, 01 Nov 2006 06:03:21 -0500 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfDkO-000133-59 for lemonade@ietf.org; Wed, 01 Nov 2006 05:55:05 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA1Asq9A016462; Wed, 1 Nov 2006 12:54:56 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 12:53:32 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 12:53:32 +0200 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 Deployments Date: Wed, 1 Nov 2006 12:52:38 +0200 Message-ID: <0FA975F2D8295A448BE3ADC161244657018AD34B@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] WGLC Deployments Thread-Index: Acb9QhTU9ZK/7ERST5e9ZMVTFu+LfgAYPW5g From: To: , , X-OriginalArrivalTime: 01 Nov 2006 10:53:32.0185 (UTC) FILETIME=[F8C5D890:01C6FDA3] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061101125456-3DB65BB0-6E58F723/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 Randall, >> 2. Wording change suggestion in section 3: >> "It should be noted that systems which don't support TCP on=20 >arbitrary=20 >> ports aren't full Internet clients." >> to: >> "Noted that systems which do not support TCP on arbitrary ports are=20 >> not considered full Internet clients." > >Why? I added a typo, it should start out as "Note", not "Noted". The reson is simple: "It should be noted" in my opinion does not mean anything. The "which" and "considered" You can ignore, I though it sounds better. But then change "aren't" to "are not". >> 3. Missing reference in section 4: >> "The requirements and advice in [HOST-REQUIREMENTS] SHOULD=20 >be followed." >> I do not have a clue what it includes, so I cannot really=20 >comment on=20 >> it apart from adding the reference, but I think that this sounds >> better: >> [HOST-REQUIREMENTS] includes a collection of requirements and=20 >> advices, which SHOULD be followed and considered by all lemonade=20 >> depoyments. > >How is the reference missing? It's there. However, I have=20 >moved it from Informative to Normative. Oh, my mistake, sorry. Ignore this comment please. I agree that the normative references section is better for this. Thank You. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 01 07:14:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfEzD-0002sK-20; Wed, 01 Nov 2006 07:14:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfEzB-0002qZ-Ql for lemonade@ietf.org; Wed, 01 Nov 2006 07:14:25 -0500 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfEz1-0007AJ-W6 for lemonade@ietf.org; Wed, 01 Nov 2006 07:14:25 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1GfEz0-0000xJ-9h; Wed, 01 Nov 2006 12:14:14 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 4C1ED498004; Wed, 1 Nov 2006 12:23:28 +0000 (GMT) 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 06483-09; Wed, 1 Nov 2006 12:23:15 +0000 (GMT) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id C2BE4498003; Wed, 1 Nov 2006 12:23:15 +0000 (GMT) Date: Wed, 01 Nov 2006 12:13:58 +0000 Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-compress-05.txt - comments References: <0FA975F2D8295A448BE3ADC161244657018AD334@esebe199.NOE.Nokia.com> In-Reply-To: <0FA975F2D8295A448BE3ADC161244657018AD334@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Message-Id: <14974.1162383241.326640@peirce.dave.cridland.net> From: Dave Cridland To: "Zoltan.Ordogh@nokia.com" Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Rutherford-IP: [217.155.137.60] X-Spam-Score: 0.5 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Enhancements to Internet email to support diverse service enivronments , Randall Gellens , Arnt Gulbrandsen X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed Nov 1 10:43:43 2006, Zoltan.Ordogh@nokia.com wrote: > In theory, TCP/IP should guarantee the right order and we should not > worry about his at all. Just a tought that's been bugging me. It's > better to ask than not to say anything. > > No, we shouldn't worry about it at all. I vaguely recall something about reliable streams in RFC3501, but basically any protocol used below IMAP in the stack has to sort this out for us. TCP does, as do COMPRESS=DEFLATE and TLS. (Which both gain reliability from lower down in the stack and simply pass it up) > >Note that the ABNF for your first alternate would be > > "COMPRESS=" algorithm *( "," algorithm ) > > This is what I wanted to hear - should it be described already > here? (To > prepare clients/servers to deal with the *( "," algorithm ) part? No, it'd be "[...] COMPRESS=DEFLATE COMPRESS=NEWONE [...]", like AUTH= works, and that's already covered by the ABNF. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 01 08:23:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfG43-0002HH-Bc; Wed, 01 Nov 2006 08:23:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfG41-0002H9-Oz for lemonade@ietf.org; Wed, 01 Nov 2006 08:23:29 -0500 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfG40-0002kf-42 for lemonade@ietf.org; Wed, 01 Nov 2006 08:23:29 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA1DNPCt005546; Wed, 1 Nov 2006 15:23:25 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 15:23:25 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 15:23:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-compress-05.txt - comments Date: Wed, 1 Nov 2006 15:22:31 +0200 Message-ID: <0FA975F2D8295A448BE3ADC161244657018AD56F@esebe199.NOE.Nokia.com> In-Reply-To: <14974.1162383241.326640@peirce.dave.cridland.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] I-D ACTION:draft-ietf-lemonade-compress-05.txt - comments Thread-Index: Acb9r1KTKt/din2pQ8yrUtLQEh/NGAACS1Nw From: To: X-OriginalArrivalTime: 01 Nov 2006 13:23:23.0578 (UTC) FILETIME=[E80F89A0:01C6FDB8] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061101152326-131B7BB0-065DFD64/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: lemonade@ietf.org, randy@qualcomm.com, arnt@oryx.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Thank You Dave, >> In theory, TCP/IP should guarantee the right order and we should not=20 >> worry about his at all. Just a tought that's been bugging me. It's=20 >> better to ask than not to say anything. >>=20 >>=20 >No, we shouldn't worry about it at all. > >I vaguely recall something about reliable streams in RFC3501,=20 >but basically any protocol used below IMAP in the stack has to=20 >sort this out for us. TCP does, as do COMPRESS=3DDEFLATE and=20 >TLS. (Which both gain reliability from lower down in the stack=20 >and simply pass it up) In a related thread - because I did not provide enough information - it was mentioned that the different order might originate from server processing the commands in different order. I guess this is something we do not need to worry about, because it's a basic requirement in IMAP to process the commands in an orderly fashion, right? >> >Note that the ABNF for your first alternate would be >> > "COMPRESS=3D" algorithm *( "," algorithm ) >>=20 >> This is what I wanted to hear - should it be described already here?=20 >> (To prepare clients/servers to deal with the *( "," algorithm ) part? > >No, it'd be "[...] COMPRESS=3DDEFLATE COMPRESS=3DNEWONE [...]",=20 >like AUTH=3D works, and that's already covered by the ABNF. Ok. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 01 08:44:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfGNn-0008Cs-E0; Wed, 01 Nov 2006 08:43:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfGNm-0008BI-70 for lemonade@ietf.org; Wed, 01 Nov 2006 08:43:54 -0500 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfGNi-0007t7-OP for lemonade@ietf.org; Wed, 01 Nov 2006 08:43:54 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.50) id 1GfGNh-0004Ja-86; Wed, 01 Nov 2006 13:43:49 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id D6E49498005; Wed, 1 Nov 2006 13:53:03 +0000 (GMT) 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 08037-06; Wed, 1 Nov 2006 13:52:50 +0000 (GMT) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 2BC89498004; Wed, 1 Nov 2006 13:52:50 +0000 (GMT) Date: Wed, 01 Nov 2006 13:43:33 +0000 Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-compress-05.txt - comments References: <0FA975F2D8295A448BE3ADC161244657018AD56F@esebe199.NOE.Nokia.com> In-Reply-To: <0FA975F2D8295A448BE3ADC161244657018AD56F@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Message-Id: <14974.1162388615.054174@peirce.dave.cridland.net> From: Dave Cridland To: "Zoltan.Ordogh@nokia.com" Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Heisenberg-IP: [217.155.137.60] X-Spam-Score: 0.5 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Enhancements to Internet email to support diverse service enivronments , Randall Gellens , Arnt Gulbrandsen X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed Nov 1 13:22:31 2006, Zoltan.Ordogh@nokia.com wrote: > In a related thread - because I did not provide enough information > - it > was mentioned that the different order might originate from server > processing the commands in different order. I guess this is > something we > do not need to worry about, because it's a basic requirement in > IMAP to > process the commands in an orderly fashion, right? > > No, that's *not* a basic requirement. IMAP servers can process commands in any order they like, including concurrently, as long as the reordering has no side-effects. Equally, clients which depend on certain commands being processed in-order need to issue them one at a time, and not pipeline them. I think someone suggested the example of: C: A01 CAPABILITY C: A02 COMPRESS DEFLATE S: A02 OK Compression starts here // Now compressed S: * CAPABILITY [...] S: A01 OK completed The untagged capability response is here compressed, but it isn't in this next example: C: A01 CAPABILITY C: A02 COMPRESS DEFLATE S: * CAPABILITY [...] S: A02 OK Compression starts here // Now compressed S: A01 OK completed However, this is pretty contrived - COMPRESS needs to be issued as early as possible in IMAP, and you need the CAPABILITY strings to know whether to use it or not, and nothing else can be pipelined either in an obviously useful way, as far as I can think of. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 01 09:05:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfGhw-0003ab-H6; Wed, 01 Nov 2006 09:04:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfGhu-0003a3-Mf for lemonade@ietf.org; Wed, 01 Nov 2006 09:04:42 -0500 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfGhn-0004I8-DC for lemonade@ietf.org; Wed, 01 Nov 2006 09:04:42 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA1E4Swp002054; Wed, 1 Nov 2006 16:04:30 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 16:04:30 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 16:04:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-compress-05.txt - comments Date: Wed, 1 Nov 2006 16:03:36 +0200 Message-ID: <0FA975F2D8295A448BE3ADC161244657018AD605@esebe199.NOE.Nokia.com> In-Reply-To: <14974.1162388615.054174@peirce.dave.cridland.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] I-D ACTION:draft-ietf-lemonade-compress-05.txt - comments Thread-Index: Acb9vCBSoT0iCI26SmGNxAvikq9BMAAAhqnQ From: To: X-OriginalArrivalTime: 01 Nov 2006 14:04:28.0546 (UTC) FILETIME=[A54BCE20:01C6FDBE] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061101160431-069F6BB0-71EACEB2/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: lemonade@ietf.org, randy@qualcomm.com, arnt@oryx.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Thank You Dave, >IMAP servers can process commands in any order they like,=20 >including concurrently, as long as the reordering has no=20 >side-effects. Equally, clients which depend on certain=20 >commands being processed in-order need to issue them one at a=20 >time, and not pipeline them. > >I think someone suggested the example of: > >C: A01 CAPABILITY >C: A02 COMPRESS DEFLATE >S: A02 OK Compression starts here >// Now compressed >S: * CAPABILITY [...] >S: A01 OK completed > >The untagged capability response is here compressed, but it=20 >isn't in this next example: > >C: A01 CAPABILITY >C: A02 COMPRESS DEFLATE >S: * CAPABILITY [...] >S: A02 OK Compression starts here >// Now compressed >S: A01 OK completed > >However, this is pretty contrived - COMPRESS needs to be=20 >issued as early as possible in IMAP, and you need the=20 >CAPABILITY strings to know whether to use it or not, and=20 >nothing else can be pipelined either in an obviously useful=20 >way, as far as I can think of. Now this does not sound bulletproof, but I am not worried because we are not server vendors, so we have nothing to worry about as long as the server works correctly. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 01 09:38:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfHEx-0006BX-6T; Wed, 01 Nov 2006 09:38:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfHEv-0006Am-Uw for lemonade@ietf.org; Wed, 01 Nov 2006 09:38:49 -0500 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfHEs-0003gt-KC for lemonade@ietf.org; Wed, 01 Nov 2006 09:38:49 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.50) id 1GfHEq-0006sa-AA; Wed, 01 Nov 2006 14:38:44 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 42114498003; Wed, 1 Nov 2006 14:47:59 +0000 (GMT) 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 08882-02; Wed, 1 Nov 2006 14:47:43 +0000 (GMT) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 2C470498006; Wed, 1 Nov 2006 14:47:25 +0000 (GMT) Date: Wed, 01 Nov 2006 14:38:08 +0000 Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-compress-05.txt - comments References: <0FA975F2D8295A448BE3ADC161244657018AD605@esebe199.NOE.Nokia.com> In-Reply-To: <0FA975F2D8295A448BE3ADC161244657018AD605@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Message-Id: <6051.1162391889.756227@peirce.dave.cridland.net> From: Dave Cridland To: "Zoltan.Ordogh@nokia.com" Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Pythagoras-IP: [217.155.137.60] X-Spam-Score: 0.5 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Enhancements to Internet email to support diverse service enivronments , Randall Gellens , Arnt Gulbrandsen X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed Nov 1 14:03:36 2006, Zoltan.Ordogh@nokia.com wrote: > Now this does not sound bulletproof, but I am not worried because > we are > not server vendors, so we have nothing to worry about as long as the > server works correctly. Both AUTHENTICATE and STARTTLS have almost precisely the same properties, since they both alter the protocol stack by inserting layers, so it's a well known issue. COMPRESS and AUTHENTICATE both negotiate the layer properties in the application layer, which is nice, because a failure to negotiate is easily recoverable, whereas STARTTLS negotiates the layer properties within TLS, but nevertheless, the general technique is well known. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 01 12:14:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfJe6-0003rd-8p; Wed, 01 Nov 2006 12:12:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfJe5-0003rE-Fp for lemonade@ietf.org; Wed, 01 Nov 2006 12:12:57 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfJe3-00041m-4E for lemonade@ietf.org; Wed, 01 Nov 2006 12:12:57 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kA1HCq58015837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 1 Nov 2006 09:12:53 -0800 Received: from [[192.168.1.13]] (vpn-10-50-0-167.qualcomm.com [10.50.0.167]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA1HCnj3011251; Wed, 1 Nov 2006 09:12:51 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <0FA975F2D8295A448BE3ADC161244657018AD339@esebe199.NOE.Nokia.com> References: <0FA975F2D8295A448BE3ADC161244657018AD339@esebe199.NOE.Nokia.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Wed, 1 Nov 2006 09:07:36 -0800 To: , From: Randall Gellens Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-compress-05.txt - comments Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.6 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 12:45 PM +0200 11/1/06, wrote: > Hi Philip, > >>>> So, if I had multiple algorithms, would it be COMPRESS=1,2,3 or >>>> COMPRESS=1,COMPRESS=2,COMPRESS=3? I would guess the second. >> >>It would be COMPRESS=1 COMPRESS=2 COMPRESS=3. Capabilities >>are separated by spaces, not commas. c.f. RFC 3501 page 25 >>for an example involving multiple AUTH= capabilities. > > This is the exact opposite of what Randall said. Should it be clarified > then? It is the same as what I said, not the opposite. In re-reading what I said, I can see how it could be misread, because I was sloppy about what I was replying to. Sorry for that. I also included some ABNF in my message to illustrate why the ABNF in the document it doesn't permit commas, by showing what ABNF that does use commas would look like. It seems that was misread as me saying commas were used. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Q: How many surrealists does it take to screw in a light bulb? A: A Fish. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 01 14:21:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfLeD-0000vx-Pa; Wed, 01 Nov 2006 14:21:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfLeC-0000vm-EG for lemonade@ietf.org; Wed, 01 Nov 2006 14:21:12 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfLe8-0006Zj-NM for lemonade@ietf.org; Wed, 01 Nov 2006 14:21:12 -0500 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 kA1JL6eo031074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 1 Nov 2006 11:21:07 -0800 Received: from [[192.168.1.13]] (vpn-10-50-0-167.qualcomm.com [10.50.0.167]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA1JKn2i004785; Wed, 1 Nov 2006 11:21:05 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <0FA975F2D8295A448BE3ADC161244657018AD34B@esebe199.NOE.Nokia.com> References: <0FA975F2D8295A448BE3ADC161244657018AD34B@esebe199.NOE.Nokia.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Wed, 1 Nov 2006 11:18:48 -0800 To: , From: Randall Gellens Subject: RE: [lemonade] WGLC Deployments 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: 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 At 12:52 PM +0200 11/1/06, wrote: > >> 2. Wording change suggestion in section 3: >>> "It should be noted that systems which don't support TCP on >>arbitrary >>> ports aren't full Internet clients." >>> to: >>> "Noted that systems which do not support TCP on arbitrary ports are >>> not considered full Internet clients." >> >>Why? > > I added a typo, it should start out as "Note", not "Noted". > The reson is simple: "It should be noted" in my opinion does not mean > anything. > The "which" and "considered" You can ignore, I though it sounds better. > But then change "aren't" to "are not". I agree that "It should be" is passive voice and should be changed to active, and I'll also replace the contractions with the full words. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- It's the menace that everyone loves to hate but can't seem to live without. --Paddy Chayevsky, quoted in _Newsweek_, Nov. 22, 1976 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 01 14:37:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfLta-0001NO-UP; Wed, 01 Nov 2006 14:37:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfLtZ-0001NJ-KY for lemonade@ietf.org; Wed, 01 Nov 2006 14:37:05 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfLtV-0001EO-FR for lemonade@ietf.org; Wed, 01 Nov 2006 14:37:05 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kA1Jaxas000361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 1 Nov 2006 11:36:59 -0800 Received: from [[192.168.1.13]] (vpn-10-50-0-167.qualcomm.com [10.50.0.167]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA1JaoKA000413; Wed, 1 Nov 2006 11:36:53 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <0FA975F2D8295A448BE3ADC161244657018AD334@esebe199.NOE.Nokia.com> References: <0FA975F2D8295A448BE3ADC161244657018AD334@esebe199.NOE.Nokia.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Wed, 1 Nov 2006 11:33:30 -0800 To: , From: Randall Gellens Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-compress-05.txt - comments Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.6 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 12:43 PM +0200 11/1/06, wrote: > Hi Randall, > >>> 3. Wording change suggestion in section 3: >>> OK The server will compress its responses and expects the client to >>> compress its commands. >>> to: >>> OK The server and the client will compress all data that it may send >> >>"data that it may send" sounds funny. The original text is >>very clear about which side compresses what (commands versus >>responses). >>Is there something about it you don't like? > > Yes, in another thread I replied already that it is the "expects" that I > do not like. That's what I tried to change, but I collapsed the client > commands and server responses into a single "data", I guess this is > something I should not have done. > I would like to get rid of "expects" though because it hints that it > might not happen. But we're talking about an example of a comment inserted by the server in its tagged command response. This is very, very different from normative language in a specification. Please see my more detailed comments on this in my message from yesterday. I think the existing wording is fine. > >> 4. Wording change suggestion in section 3: > >> The client MUST NOT send any further commands until it has seen the >>> result of COMPRESS. >>> to: >>> After the client has sent the COMPRESS command, the client MUST NOT >>> send any commands until it has seen the result of COMPRESS. >> >>I think the original wording is better as it is more compact and says >>what it needs to. But perhaps I'm missing something. What about it >>don't you like? > > Here, the intent was to clarify the exact interval - I mean only the end > of the interval clear, but the beginning is not. What I miss here is > that the client MUST NOT send anything between issuing the COMPRESS > command and receiving the response to it. We do not know when the > "client silence" starts. I think the existing wording is very clear: "MUST NOT send any further commands". However, in re-reading the text in the draft, I do have some unrelated suggestions: The client MUST NOT send any further commands until it has seen the result of COMPRESS. If the response was OK, the client MUST compress starting with the first command after COMPRESS. If the server response was BAD or NO, the client MUST NOT turn on compression. The past-tense "was" should be changed to the present-tense "is": The client MUST NOT send any further commands until it has seen the result of COMPRESS. If the response is OK, the client MUST compress starting with the first command after COMPRESS. If the server response is BAD or NO, the client MUST NOT turn on compression. > >> 5. Clarification/wording change suggestion in section 3: >>> (Responses issued by the server before the OK response will, of >>> course, still be uncompressed.) >>> to: >>> Therefore, responses issued by the server before the OK response >>> will all be uncompressed, and delayed client requests that have >>> been sent uncompressed (before turning compression on) may result >>> in compressed responses. >> >>What are "delayed client requests"? Do you mean commands sent by the >>client before it sent COMPRESS that were delayed by underlying >>network (perhaps routed differently)? Or do you mean something else? >>If the server receives uncompressed commands after it has sent the OK >>to COMPRESS, will it interpret them correctly? The original text >>implies no, but your suggested text states yes. > > No, this is exactly what I meant - perhaps the wording is not right, but > this is what I tried to capture. Latency of commands/responses. Keep in mind that IMAP uses TCP, which provides a reliable, ordered stream. > I did not think about the second question You raised, but it's a good > one - I looked at it from the client point view only. > Let's check using a use case here. Let's assume that client issues > commands a, b, COMPRESS, d, e. > My proposal: > - server receives a, b, COMPRESS, d, e (the right order) > - server responds a, b, COMPRESS, d, e (the right order, again). > - there is some latency, therefore client receives repsonses a, > COMPRESS, b, d, e TCP provides a reliable, ordered stream, so the responses won't be out of order unless the server sends them out of order. > Your question: > - server receives a, COMPRESS, b, d, e (not in the right order) My question about the server receiving uncompressed commands after sending the OK for COMPRESS is about a situation that would occur if the client violates the specification by sending an uncompressed command after COMPRESS. In such a case, I'm not sure what the compression library will do with the uncompressed data. > In theory, TCP/IP should guarantee the right order and we should not > worry about his at all. Just a tought that's been bugging me. It's > better to ask than not to say anything. This isn't anything we need to discuss, because TCP is used and we can rely on it. > >> 7. Wording change suggestion in section 4: >>> the same way as is recommended for servers >>> the same way as it is recommended for servers later >> >>Why do you want to change "as is" to "as it is"? The suggested >>wording sounds awkward to me, and implies that a source other than >>this draft is doing the recommending. > > It sounded like the "it" was missing. I think the existing wording is better. > >>> 9. Question in section 5: >>> capability =/ "COMPRESS=" algorithm >>> ;; multiple COMPRESS capabilities allowed >>> So, if I had multiple algorithms, would it be COMPRESS=1,2,3 or >>> COMPRESS=1,COMPRESS=2,COMPRESS=3? I would guess the second. >> >>That's correct, and matches what has been done for some other >>extensions. >> > >Note that the ABNF for your first alternate would be >> "COMPRESS=" algorithm *( "," algorithm ) > > This is what I wanted to hear - should it be described already here? (To > prepare clients/servers to deal with the *( "," algorithm ) part? My apologies: when I said "that's correct" I was incorrect because both of your examples use commas, so I was sloppy in my reply. The ABNF I wrote above was to illustrate why commas are not used: if they were used, the ABNF in the document would look like what I wrote. Since the ABNF doesn't look like that, commas are not used. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- I distrust those people who know so well what God wants them to do, because I notice it always coincides with their own desires. --Susan B. Anthony _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Nov 02 06:27:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfajT-00088K-92; Thu, 02 Nov 2006 06:27:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfajS-00088E-CF for lemonade@ietf.org; Thu, 02 Nov 2006 06:27:38 -0500 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfajN-0005yk-IT for lemonade@ietf.org; Thu, 02 Nov 2006 06:27:38 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA2BRRCY019934; Thu, 2 Nov 2006 13:27:30 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 13:27:21 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 13:27:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-compress-05.txt - comments Date: Thu, 2 Nov 2006 13:26:26 +0200 Message-ID: <0FA975F2D8295A448BE3ADC161244657018ADD7A@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] I-D ACTION:draft-ietf-lemonade-compress-05.txt - comments Thread-Index: Acb97TK1AWoOm1z5SXCGfx/0EUJ+OAAhBpTA From: To: , X-OriginalArrivalTime: 02 Nov 2006 11:27:21.0191 (UTC) FILETIME=[DC915770:01C6FE71] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061102132730-49B6BBB0-52E5543E/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.8 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Randall, >> >> 4. Wording change suggestion in section 3: >> >> The client MUST NOT send any further commands until it=20 >has seen=20 >> the >>>> result of COMPRESS. >>>> to: >>>> After the client has sent the COMPRESS command, the client MUST=20 >>>> NOT send any commands until it has seen the result of COMPRESS. >>> >>>I think the original wording is better as it is more compact=20 >and says=20 >>>what it needs to. But perhaps I'm missing something. What about it=20 >>>don't you like? >> >> Here, the intent was to clarify the exact interval - I mean=20 >only the=20 >> end of the interval clear, but the beginning is not. What I=20 >miss here=20 >> is that the client MUST NOT send anything between issuing the=20 >> COMPRESS command and receiving the response to it. We do not know=20 >> when the "client silence" starts. > >I think the existing wording is very clear: "MUST NOT send any=20 >further commands". > >However, in re-reading the text in the draft, I do have some=20 >unrelated suggestions: > > The client MUST NOT send any further commands until it=20 >has seen the > result of COMPRESS. If the response was OK, the client=20 >MUST compress > starting with the first command after COMPRESS. If the server > response was BAD or NO, the client MUST NOT turn on compression. > >The past-tense "was" should be changed to the present-tense "is": > > The client MUST NOT send any further commands until it=20 >has seen the > result of COMPRESS. If the response is OK, the client=20 >MUST compress > starting with the first command after COMPRESS. If the server > response is BAD or NO, the client MUST NOT turn on compression. This sounds good - it would settle my comment. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 05 14:38:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggnod-00062o-8U; Sun, 05 Nov 2006 14:37:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggnoc-00062h-PV for lemonade@ietf.org; Sun, 05 Nov 2006 14:37:58 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ggnob-0006GI-A5 for lemonade@ietf.org; Sun, 05 Nov 2006 14:37:58 -0500 Received: from [130.129.67.117] ((unknown) [130.129.67.117]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 5 Nov 2006 19:37:45 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <454B2F9D.2050502@isode.com> Date: Fri, 03 Nov 2006 12:01:33 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Randall Gellens Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-04.txt References: <453FB28E.1090500@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: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: lemonade@ietf.org, "Stephane H. Maes" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Randall Gellens wrote: > At 7:53 PM +0100 10/25/06, Alexey Melnikov wrote: > >> Randall Gellens wrote: >> >>> A few comments on this version: >>> >>> ---------------------------------------- >>> (1) Please explicitly state that servers MUST support [message >>> submission] on port 587. Also, Lemonade clients MUST use port 587 >>> by default. (I proposed this on the list back in March and saw some >>> agreement and no disagreement.) The current document says that it >>> "assumes RFC 4409" but I think it would be helpful to be more clear >>> about this. >> >> Tell me which section should say that. > > I was thinking either a short new paragraph at the end of either > Section 3.5 "Normative statements related to forward without > download", or, if you prefer, Section 6 "Additional requirements on > MUAs". IMHO, section number 3.5 is not the right place for this. I've added the following sentence to section 6: By default LEMONADE compliant clients MUST use port 587 for message submission. And I've also added the following sentence to the subsequent section (section 6 only talks about MUAs) "Summary of the required IMAP and SMTP extensions": Note that LEMONADE compliant servers MUST support message submission on port 587. >>> ---------------------------------------- >>> (3) In Section "4.3. Message size declaration", the text: >>> LEMONADE compliant mail submission servers MUST resolve all BURL >>> parts before enforcing a message size limit. >>> >>> Requires the servers to expand all BURL parts, even if the message >>> already exceeds the message size limit. A while back I suggested >>> saying "Servers MUST NOT consider a message's size to be acceptable >>> if it has not expanded all BURL parts." I'm not wedded to that >>> phrasing, but I do think we should allow servers to reject messages >>> before expanding everything. >> >> I am not exactly happy with your replacement text, this might be too >> subtle for people to notice. I need to think about better alternatives. > > If you'd like to make the situation very explicit and clear, how about: This is much better because it gives explanation for the requirement. Thanks! Some minor comments below. > Interoperability problems and user confusion would result from > submission servers accepting a message with a 2xx result code, and > then, after expanding BURL parts, determining that the final size of > the message is too large. IMHO, this can still happen if the message exceeds per user SMTP quota, which can be lower than the advertised SIZE limit. But I am not sure if there is any point of tweaking the text any further in order to clarify "too large". > In such cases, the submission server would then generate an DSN > bounce, which the client would need to receive and process during some > subsequent mail check. Correct matching of the DSN to the original > message is difficult, subject to unpredictable delay, and much user > annoyance. If the bounce contains the expanded BURL parts, its size > could make it difficult for the client to receive it. Therefore, > servers MUST NOT consider a message's size to be acceptable before all > of its BURL parts have not been expanded. "have been expanded"? > Servers MAY reject a message as being too large before expanding all > BURL parts, and it is RECOMMENDED that servers check the message's > size after expanding each BURL, to guard against denial of service > attacks. Ok, I've added this text, replacing "have not been expanded" with "have been expanded" above. I've also replaced "it's" with "its". _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 05 19:39:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgsVt-0008R6-TD; Sun, 05 Nov 2006 19:38:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgsVr-0008OQ-Sh for lemonade@ietf.org; Sun, 05 Nov 2006 19:38:55 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgsVp-00032a-Gg for lemonade@ietf.org; Sun, 05 Nov 2006 19:38:55 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kA60cpBW012413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 5 Nov 2006 16:38:52 -0800 Received: from [0127bhost18.starwoodbroadband.com] (vpn-10-50-16-98.qualcomm.com [10.50.16.98]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA60cmka004408; Sun, 5 Nov 2006 16:38:49 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <454B2F9D.2050502@isode.com> References: <453FB28E.1090500@isode.com> <454B2F9D.2050502@isode.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Sun, 5 Nov 2006 16:35:46 -0800 To: Alexey Melnikov From: Randall Gellens Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-04.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: 7aafa0432175920a4b3e118e16c5cb64 Cc: lemonade@ietf.org, "Stephane H. Maes" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 12:01 PM +0000 11/3/06, Alexey Melnikov wrote: > I've added the following sentence to section 6: > > By default LEMONADE compliant clients MUST use port 587 for > message submission. > > And I've also added the following sentence to the subsequent > section (section 6 only talks about MUAs) "Summary of the required > IMAP and SMTP extensions": > > Note that LEMONADE compliant servers MUST support message > submission on port 587. Excellent. Thank you. > IMHO, this can still happen if the message exceeds per user SMTP > quota, which can be lower than the advertised SIZE limit. > But I am not sure if there is any point of tweaking the text any > further in order to clarify "too large". I agree on both points (it can still happen, but there is no benefit from further tweaking the text). >> In such cases, the submission server would then generate an DSN >> bounce, which the client would need to receive and process during >> some subsequent mail check. Correct matching of the DSN to the >> original message is difficult, subject to unpredictable delay, and >> much user annoyance. If the bounce contains the expanded BURL >> parts, its size could make it difficult for the client to receive >> it. Therefore, servers MUST NOT consider a message's size to be >> acceptable before all of its BURL parts have not been expanded. > > "have been expanded"? You are correct of course (I originally wrote "if ... not been expanded" and then tried to change it to "before ... been expanded" but didn't complete the edit). > Ok, I've added this text, replacing "have not been expanded" with > "have been expanded" above. > I've also replaced "it's" with "its". Thank you. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Not a shred of evidence exists in favor of the idea that life is serious. --Brendan Gill _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 06 03:53:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh0Dv-0001Vu-5n; Mon, 06 Nov 2006 03:52:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh0Du-0001Sa-3X for lemonade@ietf.org; Mon, 06 Nov 2006 03:52:54 -0500 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ggzyc-0005NP-Su for lemonade@ietf.org; Mon, 06 Nov 2006 03:37:08 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA68b0Zm028568; Mon, 6 Nov 2006 10:37:04 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 10:36:41 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 10:36:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-04.txt Date: Mon, 6 Nov 2006 10:35:47 +0200 Message-ID: <0FA975F2D8295A448BE3ADC161244657018F9A2C@esebe199.NOE.Nokia.com> In-Reply-To: <454B2F9D.2050502@isode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-04.txt Thread-Index: AccBEqtlmEivUpeWRUu+BRf0Gq//vAAa5lgQ From: To: , X-OriginalArrivalTime: 06 Nov 2006 08:36:40.0637 (UTC) FILETIME=[AE5FCED0:01C7017E] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061106103705-6F214BB0-6AD656F0/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: lemonade@ietf.org, stephane.maes@oracle.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi all, I am not sure about this statement: > By default LEMONADE compliant clients MUST use port 587=20 >for message submission. By default... MUST... Should we describe what MUST happen in a non-default case? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 06 10:34:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh6Ud-0004yE-PX; Mon, 06 Nov 2006 10:34:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh6Ub-0004xb-Ss for lemonade@ietf.org; Mon, 06 Nov 2006 10:34:34 -0500 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh6TP-0008Cn-G5 for lemonade@ietf.org; Mon, 06 Nov 2006 10:33:24 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA6FXHWc002915; Mon, 6 Nov 2006 17:33:17 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 17:32:55 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 17:32:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-04.txt Date: Mon, 6 Nov 2006 17:32:02 +0200 Message-ID: <0FA975F2D8295A448BE3ADC1612446570195381D@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-04.txt Thread-Index: AccBuApcp71vF7pKSvKh+r5BOC7MIwAAB2DA From: To: , X-OriginalArrivalTime: 06 Nov 2006 15:32:58.0288 (UTC) FILETIME=[D636E300:01C701B8] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061106173317-0B28FBB0-635DFFDE/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: lemonade@ietf.org, stephane.maes@oracle.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Randalll, >>> By default LEMONADE compliant clients MUST use port 587 for=20 >>>message submission. >> >> By default... MUST... >> Should we describe what MUST happen in a non-default case? > >I don't think we need to say any more. The client is free to=20 >use several approaches, including falling back to port 25 if=20 >port 587 doesn't work. By mandating that servers support port=20 >587, and that clients use port 587 as the default, we provide=20 >a basis for interoperability. If we mandate 587 for servers, what is the benefit of specifying anything for the client? I mean 587 is always going to be available on every single server (because it is mandatory), but it will be there also when the server provides access on other ports as well (again, because 587 is mandatory) - so why specify anything for the client? It should be obvious from the server requirement. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 06 10:36:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh6W7-0006h2-IC; Mon, 06 Nov 2006 10:36:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh6Ut-0005N9-IB for lemonade@ietf.org; Mon, 06 Nov 2006 10:34:51 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh6LX-0007FD-QS for lemonade@ietf.org; Mon, 06 Nov 2006 10:25:27 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kA6FP9Es017439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 6 Nov 2006 07:25:10 -0800 Received: from [0127bhost18.starwoodbroadband.com] (vpn-10-50-16-63.qualcomm.com [10.50.16.63]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA6FP35h009288; Mon, 6 Nov 2006 07:25:06 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <0FA975F2D8295A448BE3ADC161244657018F9A2C@esebe199.NOE.Nokia.com> References: <0FA975F2D8295A448BE3ADC161244657018F9A2C@esebe199.NOE.Nokia.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Mon, 6 Nov 2006 07:21:13 -0800 To: , From: Randall Gellens Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-04.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: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: lemonade@ietf.org, stephane.maes@oracle.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 10:35 AM +0200 11/6/06, wrote: > Hi all, Hi Zoltan, > I am not sure about this statement: > >> By default LEMONADE compliant clients MUST use port 587 >>for message submission. > > By default... MUST... > Should we describe what MUST happen in a non-default case? I don't think we need to say any more. The client is free to use several approaches, including falling back to port 25 if port 587 doesn't work. By mandating that servers support port 587, and that clients use port 587 as the default, we provide a basis for interoperability. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Waiter: "Tea or coffee, gentlemen?" 1st customer: "I'll have tea." 2nd customer: "Me, too -- and be sure the glass is clean!" (Waiter exits, returns) Waiter: "Two teas. Which one asked for the clean glass?" _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 06 10:43:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh6dQ-00026s-EL; Mon, 06 Nov 2006 10:43:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh6dP-00025X-7A for lemonade@ietf.org; Mon, 06 Nov 2006 10:43:39 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh6dG-0001su-9T for lemonade@ietf.org; Mon, 06 Nov 2006 10:43:39 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id EC2F24AC8B; Mon, 6 Nov 2006 16:43:18 +0100 (CET) Message-Id: Date: Mon, 6 Nov 2006 16:46:11 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-04.txt References: <0FA975F2D8295A448BE3ADC1612446570195381D@esebe199.NOE.Nokia.com> In-Reply-To: <0FA975F2D8295A448BE3ADC1612446570195381D@esebe199.NOE.Nokia.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: randy@qualcomm.com, Alexey.Melnikov@isode.com, stephane.maes@oracle.com, Zoltan.Ordogh@nokia.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Zoltan.Ordogh@nokia.com writes: > I mean 587 is always going to be available on every single server > (because it is mandatory), but it will be there also when the server > provides access on other ports as well (again, because 587 is > mandatory) - so why specify anything for the client? It should be > obvious from the server requirement. Almost. There's a lot of client code today that uses port 25 by default. The document makes a requirement on that code, "change the default to 587". It's friendly and helpful to say so directly, rather than expecting those client authors to care about the the server requirement list. As it is, a client is compliant when it does everything the document says a "client MUST" or "client SHOULD" do. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 06 11:29:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh7LH-0002zE-5e; Mon, 06 Nov 2006 11:28:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh7LG-0002vq-E0 for lemonade@ietf.org; Mon, 06 Nov 2006 11:28:58 -0500 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh7LA-000871-3k for lemonade@ietf.org; Mon, 06 Nov 2006 11:28:58 -0500 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M98HH11RWG00XIKW@mauve.mrochek.com> for lemonade@ietf.org; Mon, 6 Nov 2006 08:28:18 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M98H08654G00UHS2@mauve.mrochek.com>; Mon, 06 Nov 2006 08:28:16 -0800 (PST) Message-id: <01M98HH0AEQI00UHS2@mauve.mrochek.com> Date: Mon, 06 Nov 2006 08:25:33 -0800 (PST) From: Ned Freed Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-04.txt In-reply-to: "Your message dated Mon, 06 Nov 2006 17:32:02 +0200" <0FA975F2D8295A448BE3ADC1612446570195381D@esebe199.NOE.Nokia.com> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <0FA975F2D8295A448BE3ADC1612446570195381D@esebe199.NOE.Nokia.com> To: Zoltan.Ordogh@nokia.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: randy@qualcomm.com, alexey.melnikov@isode.com, lemonade@ietf.org, stephane.maes@oracle.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > Hi Randalll, > >>> By default LEMONADE compliant clients MUST use port 587 for > >>>message submission. > >> > >> By default... MUST... > >> Should we describe what MUST happen in a non-default case? > > > >I don't think we need to say any more. The client is free to > >use several approaches, including falling back to port 25 if > >port 587 doesn't work. By mandating that servers support port > >587, and that clients use port 587 as the default, we provide > >a basis for interoperability. > If we mandate 587 for servers, what is the benefit of specifying > anything for the client? > I mean 587 is always going to be available on every single server > (because it is mandatory), but it will be there also when the server > provides access on other ports as well (again, because 587 is mandatory) > - so why specify anything for the client? It should be obvious from the > server requirement. Without a client mandate there's nothing to prevent clients from failing to implement support for port 587 and still claiming compliance with the specification. If past experience is any indication, this is a serious concern if we want support for submit to deploy as widely as possible. It should also be noted that mandating support is different from mandating actual use. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 06 12:40:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh8Sg-0007mH-TF; Mon, 06 Nov 2006 12:40:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh8Sf-0007m8-O1 for lemonade@ietf.org; Mon, 06 Nov 2006 12:40:41 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh8Sd-0000Qs-CL for lemonade@ietf.org; Mon, 06 Nov 2006 12:40:41 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kA6HeYgn005628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 6 Nov 2006 09:40:38 -0800 Received: from [[130.129.71.164]] (vpn-10-50-0-142.qualcomm.com [10.50.0.142]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA6HeUeI004952; Mon, 6 Nov 2006 09:40:32 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <0FA975F2D8295A448BE3ADC1612446570195381D@esebe199.NOE.Nokia.com> References: <0FA975F2D8295A448BE3ADC1612446570195381D@esebe199.NOE.Nokia.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Mon, 6 Nov 2006 09:39:34 -0800 To: , From: Randall Gellens Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-04.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: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: lemonade@ietf.org, stephane.maes@oracle.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 5:32 PM +0200 11/6/06, wrote: > Hi Randalll, Hi Zoltan, > >>>> By default LEMONADE compliant clients MUST use port 587 for >>>>message submission. >>> >>> By default... MUST... >>> Should we describe what MUST happen in a non-default case? >> >>I don't think we need to say any more. The client is free to >>use several approaches, including falling back to port 25 if >>port 587 doesn't work. By mandating that servers support port >>587, and that clients use port 587 as the default, we provide >>a basis for interoperability. > > If we mandate 587 for servers, what is the benefit of specifying > anything for the client? > I mean 587 is always going to be available on every single server > (because it is mandatory), but it will be there also when the server > provides access on other ports as well (again, because 587 is mandatory) > - so why specify anything for the client? It should be obvious from the > server requirement. It's not as obvious as it needs to be, given the practice of using port 25 for both submission and relay. By making a clear and simple statement that servers MUST support port 587, and clients MUST use port 587 by default, we make guarantee interoperability. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- We adore chaos because we love to produce order. --M. C. Escher _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 06 14:07:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh9oJ-00011B-FR; Mon, 06 Nov 2006 14:07:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh9oH-0000wM-TR for lemonade@ietf.org; Mon, 06 Nov 2006 14:07:05 -0500 Received: from outbound.cantata.com ([208.236.123.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh9oG-0002TE-DH for lemonade@ietf.org; Mon, 06 Nov 2006 14:07:05 -0500 Received: from ma02exchtmp01.Cantata.com ([10.128.18.41]) by outbound.Cantata.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 14:06:59 -0500 Received: from 10.128.41.42 ([10.128.41.42]) by ma02exchtmp01.Cantata.com ([10.128.18.41]) with Microsoft Exchange Server HTTP-DAV ; Mon, 6 Nov 2006 19:06:58 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Mon, 06 Nov 2006 14:06:56 -0500 From: Eric Burger To: IETF LEMONADE Message-ID: Thread-Topic: Call for Scribes and Transcribes Thread-Index: AccB1roW+HvG2m3JEduSmQAWy5cvmw== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 06 Nov 2006 19:06:59.0928 (UTC) FILETIME=[BC6DA580:01C701D6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [lemonade] Call for Scribes and Transcribes X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Want your names in lights, but you are not ready to write a draft? How about trying to be a Scribe (note taker) or Transcriber (Jabber note taker and channel for remote participants - they write something, you say something). Drop me (Eric, eburger@cantata.com) a note if you are interested. We need one for Tuesday and one for Thursday. Thanks! _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 07 06:35:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhPEs-0007vN-SY; Tue, 07 Nov 2006 06:35:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhPEr-0007uB-BV for lemonade@ietf.org; Tue, 07 Nov 2006 06:35:33 -0500 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhPEp-00053o-Pi for lemonade@ietf.org; Tue, 07 Nov 2006 06:35:33 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA7BYl34009080; Tue, 7 Nov 2006 13:35:20 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 13:34:55 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 13:34:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-04.txt Date: Tue, 7 Nov 2006 13:34:01 +0200 Message-ID: <0FA975F2D8295A448BE3ADC16124465701953F9A@esebe199.NOE.Nokia.com> In-Reply-To: <01M98HH0AEQI00UHS2@mauve.mrochek.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-04.txt Thread-Index: AccBwh5M1mkIygdARteJmSTgu6tNngAnNx4g From: To: X-OriginalArrivalTime: 07 Nov 2006 11:34:54.0937 (UTC) FILETIME=[BF163C90:01C70260] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: randy@qualcomm.com, alexey.melnikov@isode.com, lemonade@ietf.org, stephane.maes@oracle.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Ned, >> If we mandate 587 for servers, what is the benefit of specifying=20 >> anything for the client? >> I mean 587 is always going to be available on every single server=20 >> (because it is mandatory), but it will be there also when the server=20 >> provides access on other ports as well (again, because 587 is=20 >> mandatory) >> - so why specify anything for the client? It should be obvious from=20 >> the server requirement. > >Without a client mandate there's nothing to prevent clients=20 >from failing to implement support for port 587 and still=20 >claiming compliance with the specification. If past experience=20 >is any indication, this is a serious concern if we want=20 >support for submit to deploy as widely as possible. > >It should also be noted that mandating support is different=20 >from mandating actual use. Exactly. So why mandate support for something that might not be used at all? How are You going to IOP test this (I support something that I do not ever use)? It's kind of like the seatbelt - most people use it only when they find it appropriate according to their current environment (e.g highways). But, for example In Finland there are scenarios when it is actually forbidden to use the seatbelts. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 07 06:40:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhPJN-00020l-Oi; Tue, 07 Nov 2006 06:40:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhPJM-00020g-H7 for lemonade@ietf.org; Tue, 07 Nov 2006 06:40:12 -0500 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhPJK-0005c9-2N for lemonade@ietf.org; Tue, 07 Nov 2006 06:40:12 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA7BdhKF026218; Tue, 7 Nov 2006 13:40:08 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 13:40:02 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 13:40:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-04.txt Date: Tue, 7 Nov 2006 13:39:08 +0200 Message-ID: <0FA975F2D8295A448BE3ADC16124465701953FB0@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-04.txt Thread-Index: AccByvUDEGedbmsQTTeqAFS3BS3R2QAlbPHw From: To: , , X-OriginalArrivalTime: 07 Nov 2006 11:40:02.0292 (UTC) FILETIME=[7648E340:01C70261] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: lemonade@ietf.org, stephane.maes@oracle.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Arnt and Randall, >>>>> By default LEMONADE compliant clients MUST use port 587 for=20 >>>>>message submission. >>>> >>>> By default... MUST... >>>> Should we describe what MUST happen in a non-default case? >>> >>>I don't think we need to say any more. The client is free to use=20 >>>several approaches, including falling back to port 25 if port 587=20 >>>doesn't work. By mandating that servers support port 587, and that=20 >>>clients use port 587 as the default, we provide a basis for=20 >>>interoperability. >> >> If we mandate 587 for servers, what is the benefit of specifying =20 >> anything for the client? >> I mean 587 is always going to be available on every single server =20 >> (because it is mandatory), but it will be there also when=20 >the server =20 >> provides access on other ports as well (again, because 587 is=20 >> mandatory) >> - so why specify anything for the client? It should be obvious from=20 >> the server requirement. > >It's not as obvious as it needs to be, given the practice of=20 >using port 25 for both submission and relay. By making a=20 >clear and simple statement that servers MUST support port 587,=20 >and clients MUST use port 587 by default, we make guarantee=20 >interoperability. I though the deployment considerations draft was pretty clear on port 25 being obsolete and using port 587 instead. I think that's the closest we can get when we attept to clarify this issue. Why not reference it instead? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 07 09:00:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhRUz-0006Gv-GG; Tue, 07 Nov 2006 09:00:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhRUw-0006GD-77 for lemonade@ietf.org; Tue, 07 Nov 2006 09:00:18 -0500 Received: from mxout4.cac.washington.edu ([140.142.33.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhRUq-0003j6-Rx for lemonade@ietf.org; Tue, 07 Nov 2006 09:00:18 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141]) by mxout4.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id kA7E0Bm6026237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 Nov 2006 06:00:11 -0800 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id kA7E09xJ010686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Nov 2006 06:00:10 -0800 Date: Tue, 7 Nov 2006 06:00:09 -0800 (PST) From: Mark Crispin To: Zoltan.Ordogh@nokia.com Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-04.txt In-Reply-To: <0FA975F2D8295A448BE3ADC16124465701953F9A@esebe199.NOE.Nokia.com> Message-ID: References: <0FA975F2D8295A448BE3ADC16124465701953F9A@esebe199.NOE.Nokia.co m> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.1.279297, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.11.7.54932 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: randy@qualcomm.com, alexey.melnikov@isode.com, lemonade@ietf.org, ned.freed@mrochek.com, stephane.maes@oracle.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue, 7 Nov 2006, Zoltan.Ordogh@nokia.com wrote: > >It should also be noted that mandating support is different > >from mandating actual use. > Exactly. So why mandate support for something that might not be used at > all? How are You going to IOP test this (I support something that I do > not ever use)? Spammers and viruses are doing an excellent job of abolishing SMTP-only clients. At an increasing number of sites, use of 587 is is mandatory. Clients that do not support 587 simply will not work. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 07 09:03:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhRYF-0000lR-MP; Tue, 07 Nov 2006 09:03:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhRYF-0000lM-83 for lemonade@ietf.org; Tue, 07 Nov 2006 09:03:43 -0500 Received: from mxout1.cac.washington.edu ([140.142.32.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhRY8-0004TM-TX for lemonade@ietf.org; Tue, 07 Nov 2006 09:03:43 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141]) by mxout1.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id kA7E3aij010631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 Nov 2006 06:03:36 -0800 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id kA7E3Y70010846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Nov 2006 06:03:35 -0800 Date: Tue, 7 Nov 2006 06:03:34 -0800 (PST) From: Mark Crispin To: Zoltan.Ordogh@nokia.com Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-04.txt In-Reply-To: Message-ID: References: <0FA975F2D8295A448BE3ADC16124465701953F9A@esebe199.NOE.Nokia.co m> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.1.279297, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.11.7.55432 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue, 7 Nov 2006, Mark Crispin wrote: > At an increasing number of sites, use of 587 is is mandatory. Clients > that do not support 587 simply will not work. As a follow-up; I simply can not believe that there is any debate or dispute about the need to require 587. SMTP is dead for message submission, long live SUBMISSION. How about being blunt, and state "support for port 587 (SUBMISSION) is mandatory. Any implementation that does not support (and use) port 587 is, by definition of this standard, a non-compliant piece of garbage whose vendor deserves public humiliation." ??? ;-) With tongue firmly in cheek, -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 07 10:16:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhSgb-00021g-GK; Tue, 07 Nov 2006 10:16:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhSga-00021Z-6E for lemonade@ietf.org; Tue, 07 Nov 2006 10:16:24 -0500 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhSgV-0001x5-NN for lemonade@ietf.org; Tue, 07 Nov 2006 10:16:24 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA7FFLKb023286; Tue, 7 Nov 2006 17:16:10 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 17:14:22 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 17:14:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-04.txt Date: Tue, 7 Nov 2006 17:13:26 +0200 Message-ID: <0FA975F2D8295A448BE3ADC16124465701995239@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-04.txt Thread-Index: AccCdcH40adplqwmRZOjm+21BZIrxQACNXFA From: To: X-OriginalArrivalTime: 07 Nov 2006 15:14:21.0613 (UTC) FILETIME=[67098DD0:01C7027F] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) 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 Hi Mark, >> At an increasing number of sites, use of 587 is is=20 >mandatory. Clients=20 >> that do not support 587 simply will not work. > >As a follow-up; I simply can not believe that there is any=20 >debate or dispute about the need to require 587. SMTP is dead=20 >for message submission, long live SUBMISSION. > >How about being blunt, and state "support for port 587=20 >(SUBMISSION) is mandatory. Any implementation that does not=20 >support (and use) port 587 is, by definition of this standard,=20 >a non-compliant piece of garbage whose vendor deserves public=20 >humiliation." ??? ;-) I have no problem with stating this - since it removes the in-my-opinion not-so-good by-default-MUST. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 07 12:55:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhV9p-0004je-1l; Tue, 07 Nov 2006 12:54:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhV9o-0004jZ-64 for lemonade@ietf.org; Tue, 07 Nov 2006 12:54:44 -0500 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhV9j-0004yt-Qm for lemonade@ietf.org; Tue, 07 Nov 2006 12:54:44 -0500 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M99YRMP71C00XFT3@mauve.mrochek.com> for lemonade@ietf.org; Tue, 7 Nov 2006 09:54:00 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M99YC1WERK0008CX@mauve.mrochek.com>; Tue, 07 Nov 2006 09:53:58 -0800 (PST) Message-id: <01M99YRLDF8K0008CX@mauve.mrochek.com> Date: Tue, 07 Nov 2006 09:43:14 -0800 (PST) From: Ned Freed Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-04.txt In-reply-to: "Your message dated Tue, 07 Nov 2006 13:34:01 +0200" <0FA975F2D8295A448BE3ADC16124465701953F9A@esebe199.NOE.Nokia.com> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <01M98HH0AEQI00UHS2@mauve.mrochek.com> <0FA975F2D8295A448BE3ADC16124465701953F9A@esebe199.NOE.Nokia.com> To: Zoltan.Ordogh@nokia.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: randy@qualcomm.com, alexey.melnikov@isode.com, lemonade@ietf.org, ned.freed@mrochek.com, stephane.maes@oracle.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > Hi Ned, > >> If we mandate 587 for servers, what is the benefit of specifying > >> anything for the client? > >> I mean 587 is always going to be available on every single server > >> (because it is mandatory), but it will be there also when the server > >> provides access on other ports as well (again, because 587 is > >> mandatory) > >> - so why specify anything for the client? It should be obvious from > >> the server requirement. > > > >Without a client mandate there's nothing to prevent clients > >from failing to implement support for port 587 and still > >claiming compliance with the specification. If past experience > >is any indication, this is a serious concern if we want > >support for submit to deploy as widely as possible. > > > >It should also be noted that mandating support is different > >from mandating actual use. > Exactly. So why mandate support for something that might not be used at > all? So it can be used if it is needed. > How are You going to IOP test this (I support something that I do > not ever use)? We take stuff to test events all the time prior to it being used in the field. Perhaps there's something odd about the OMA process that somehow prevents testing stuff that isn't in use, but if so that's a bug in the OMA IOP process. > It's kind of like the seatbelt - most people use it only when they find > it appropriate according to their current environment (e.g highways). > But, for example In Finland there are scenarios when it is actually > forbidden to use the seatbelts. Whatever. The bottom line is that the IETF mandates implementation but not use of important features all the time and there's a strong and broad consensus that this is an effective way to get stuff to deploy. During the discussions leading up to creation of the Danvers Doctrine (which basically says that it is a good thing to require implementation of strong crypto even if there are no requirements that it actually be used) all of the arguments you've given here were raised, and many others as well. The IETF pushed forward with the requirements anyway, and in hindsight it if pretty clear that this was the right choice and thw world is a better place for our having done so. I don't think the case for this requirement is quite as strong, but it is plenty strong enough. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 07 15:50:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhXtZ-00070z-TE; Tue, 07 Nov 2006 15:50:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhXtW-0006yU-5p for lemonade@ietf.org; Tue, 07 Nov 2006 15:50:06 -0500 Received: from outbound.cantata.com ([208.236.123.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhXtT-0002Mq-Uv for lemonade@ietf.org; Tue, 07 Nov 2006 15:50:06 -0500 Received: from ma02exchtmp01.Cantata.com ([10.128.18.41]) by outbound.Cantata.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 15:49:55 -0500 Received: from 10.128.41.47 ([10.128.41.47]) by ma02exchtmp01.Cantata.com ([10.128.18.41]) with Microsoft Exchange Server HTTP-DAV ; Tue, 7 Nov 2006 20:49:54 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Tue, 07 Nov 2006 10:47:43 -0500 From: Eric Burger To: IETF LEMONADE Message-ID: Thread-Topic: WGLC Search Within Thread-Index: AccChA/0Tq5ucm53Edus8wAWy5cvmw== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 07 Nov 2006 20:49:55.0598 (UTC) FILETIME=[47D3DAE0:01C702AE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: [lemonade] WGLC 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 Have at it. WGLC closes 11/21/06. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 07 17:01:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhZ0I-0001DH-MS; Tue, 07 Nov 2006 17:01:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhZ0H-0001D3-2X for lemonade@ietf.org; Tue, 07 Nov 2006 17:01:09 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhZ0D-0003nu-LK for lemonade@ietf.org; Tue, 07 Nov 2006 17:01:09 -0500 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kA7M12kf028889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 7 Nov 2006 14:01:03 -0800 Received: from [dhcp66-21.ietf67.org] (vpn-10-50-0-19.qualcomm.com [10.50.0.19]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA7M0tP8016427; Tue, 7 Nov 2006 14:00:56 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <0FA975F2D8295A448BE3ADC16124465701953FB0@esebe199.NOE.Nokia.com> References: <0FA975F2D8295A448BE3ADC16124465701953FB0@esebe199.NOE.Nokia.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Tue, 7 Nov 2006 14:00:12 -0800 To: , , From: Randall Gellens Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-04.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: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: lemonade@ietf.org, stephane.maes@oracle.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 1:39 PM +0200 11/7/06, wrote: > >It's not as obvious as it needs to be, given the practice of >>using port 25 for both submission and relay. By making a >>clear and simple statement that servers MUST support port 587, >>and clients MUST use port 587 by default, we make guarantee >>interoperability. > > I though the deployment considerations draft was pretty clear on port 25 > being obsolete and using port 587 instead. I think that's the closest we > can get when we attept to clarify this issue. Why not reference it > instead? I don't see any benefit from having the Profile document reference the Deployments document for the purpose of mandating support for port 587. Why not just say "Clients MUST use port 587 by default"? The "by default" means "when opening a connection to the submission server, clients MUST attempt to open port 587 on the submission server. Clients MUST NOT try a different port unless this attempt fails, or the client has been explicitly configured to use a different port." -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Ever notice that people who are late are much jollier than the people who have to wait for them? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 08 01:15:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhgfL-0000kb-3z; Wed, 08 Nov 2006 01:12:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhgfJ-0000jN-6H for lemonade@ietf.org; Wed, 08 Nov 2006 01:12:01 -0500 Received: from dispatch.cs.umd.edu ([128.8.128.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhgUz-00068o-Vt for lemonade@ietf.org; Wed, 08 Nov 2006 01:01:23 -0500 Received: from delegate.pc.cs.umd.edu (exchange.cs.umd.edu [128.8.130.248]) by dispatch.cs.umd.edu (8.13.1/8.12.5) with ESMTP id kA861IO3015343 for ; Wed, 8 Nov 2006 01:01:18 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 8 Nov 2006 01:01:13 -0500 Message-ID: <5B211F0A44261848B86EC460096A555A1BAC84@delegate.pc.cs.umd.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CFP IEEE NetCri 07 Thread-Index: AccC+0upBjmPMPgjQESpbxJ7bJeRiw== From: "Elsharnouby, Tamer" To: X-CSD-MailScanner-Information: Please email staff@cs.umd.edu for more information X-CSD-MailScanner: Found to be clean X-CSD-MailScanner-SpamCheck: not spam, SpamAssassin (cached, score=-1.44, required 5, ALL_TRUSTED -1.44) X-CSD-MailScanner-From: sharno@cs.umd.edu X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Subject: [lemonade] CFP IEEE NetCri 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 [Apologies for multiple postings] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Call for Papers NetCri 07 The First International Workshop on=20 Research Challenges in Next Generation Networks for=20 First Responders and Critical Infrastructures http://www.cs.umd.edu/~sharno/NetCri07 = =20 In Conjunction with=20 IEEE IPCCC 2007, New Orleans, Louisiana, April 11-13 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D As advances in pervasive computing, wireless communication and sensor = networks continue, more opportunities are open to first responders and critical = infra- structures to benefit from these technologies. Providing first = responders with the best possible technology, infrastructure and services help save the = lives of the general public and the first responders as well. One of the main = challenges to the operations of first responders and critical = infrastructures is to deploy a communication network that is dependable, secure, and = rapidly deployable. In order to operate effectively, the deployed network = supports services such as location determination, audio and video communication, = and in site and remote sensing. Another key feature for first responders and = critical infrastructures networks is to support interactions among multiple = heterogen- eous networks.=20 =20 This workshop provides a forum for researchers, industry, and government = agencies to discuss the challenges facing the design, deployment and = operation- al issues for next generation network support for first responders and = critical infrastructure. The workshop will identify and define fundamental = concepts and=20 techniques, resolve conflicts between different approaches in the area, = and=20 provide a common ground for an advanced research and development agenda. = Topics of interest include, but are not limited to: - Smart environments (buildings, roads, vehicles, etc.)=20 - Fast roaming in heterogonous network environment - Localization and time synchronization=20 - Rapidly deployable and self configuring services and networks - Security, dependability, privacy, and performance trade-offs - QoS in heterogeneous wireless networks - Sensor and actuator networks for information gathering and real-time = control - Network and system support for augmented reality and visual = analytics - Simulation studies of first responders and critical infrastructures' = networks - Novel and adaptive communication protocols to support first = responders and critical infrastructure' operation - Resource management and allocation - Power control management - Admission, load and flow control - Performance analysis and experimentation of heterogeneous wireless = networks - Security techniques and methods for heterogeneous wireless networks - Interoperability among WLANs, Cellular, WSN and wired networks - Metrics and measurements on heterogeneous networks - Mobility models and traffic patterns in disaster areas - Cross-layer design - Testbeds Paper Submission Papers should describe original, previously unpublished work, not = currently=20 under review by another conference, workshop, or journal. Authors are = invited to submit a maximum of 6 pages papers including the abstract, figures = and=20 references. Papers should include the title, author(s), authors' = affiliation and an abstract. The formatting should be according to IEEE rules. = Papers=20 should be submitted in a PDF format using the EDAS submission system. Accepted papers will be accessible through the IEEE digital library and = are=20 included in the conference proceedings. =20 Important Dates Submission deadline: November 30, 2006 Notification of acceptance: January 5, 2007 Camera ready version: January 26, 2007 Workshop Organizing Committee Program Co-Chairs Mohamed Eltoweissy, Virginia Tech, USA Moustafa Youssef, University of Maryland, USA=20 Publicity Co-Chairs Tamer Elsharnouby, Microsoft Corporation, USA James Joshi, University of Pittsburg, USA Technical Program Committee=20 Arup Acharya, IBM, USA Ashok Agrawala, University of Maryland, USA Jonathan Agre, Fujitsu Lab, USA Mustaque Ahamad, Georgia Tech, USA Nils Aschenbruck, University of Bonn, Germany Farag Azzedine, King Fahd University, Saudi Arabia Doreen Cheng, Samsung Research, USA Nagwa Elmakky, Alexandria University, Egypt Mohamed Gouda, University of Texas, USA Elena Guara, Coventry University, UK Wendi Heinzelman, University of Rochester, USA James Joshi, University of Pittsburgh, USA P. Krishnan, Avaya Labs, USA Scott Midkiff, Virginia Tech, USA Tamer Nadeem, Siemens Research, USA Dragos Niculescu, NEC Labs, USA Stephan Olariu, Old Dominion University, USA Krishna Sivalingam, University of Maryland at BC, USA Stephen D. Wolthusen, University of London, USA Mohamed Younis, University of Maryland at BC, USA Adel Youssef, Google, USA _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 08 03:25:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhikI-0005Zu-Vo; Wed, 08 Nov 2006 03:25:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhikH-0005Zn-GB for lemonade@ietf.org; Wed, 08 Nov 2006 03:25:17 -0500 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhikG-0000wM-1l for lemonade@ietf.org; Wed, 08 Nov 2006 03:25:17 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA88PCFU021465; Wed, 8 Nov 2006 10:25:14 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 10:25:10 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 10:25:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-04.txt Date: Wed, 8 Nov 2006 10:24:15 +0200 Message-ID: <0FA975F2D8295A448BE3ADC16124465701995647@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-04.txt Thread-Index: AccCuEmOWZ/wxFjDQ7C0GGkw/bJ1/QAVugiA From: To: , , X-OriginalArrivalTime: 08 Nov 2006 08:25:10.0608 (UTC) FILETIME=[67E93D00:01C7030F] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061108102514-5241DBB0-367A7F32/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: lemonade@ietf.org, stephane.maes@oracle.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Randall, >The "by default" means "when opening a connection to the=20 >submission server, clients MUST attempt to open port 587 on=20 >the submission server. Clients MUST NOT try a different port=20 >unless this attempt fails, or the client has been explicitly=20 >configured to use a different port." Could we add this then? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 08 03:58:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhjGW-0006Re-9N; Wed, 08 Nov 2006 03:58:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhjGU-0006QF-Fk for lemonade@ietf.org; Wed, 08 Nov 2006 03:58:34 -0500 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhjGS-0006R9-VH for lemonade@ietf.org; Wed, 08 Nov 2006 03:58:34 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA88wLha016714; Wed, 8 Nov 2006 10:58:31 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 10:58:25 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 10:58:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] WGLC Search Within - Comments Date: Wed, 8 Nov 2006 10:57:31 +0200 Message-ID: <0FA975F2D8295A448BE3ADC161244657019956D9@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] WGLC Search Within - Comments Thread-Index: AccChA/0Tq5ucm53Edus8wAWy5cvmwAi2SPg From: To: X-OriginalArrivalTime: 08 Nov 2006 08:58:25.0808 (UTC) FILETIME=[0D249900:01C70314] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061108105831-3DCA8BB0-63FC2C31/0-0/0-0 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: stephane.maes@oracle.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi all, here are the comments I have on the WITHIN draft: 1. Could we change this in section 2: search-key /=3D "OLDER" SP nz-number / "YOUNGER" SP nz-number=20 ; search-key defined in [RFC3501] =20 To this: search-key /=3D ( "OLDER" SP nz-number ) / ( "YOUNGER" SP = nz-number ) / ( "OLDER" SP nz-number SP "YOUNGER" SP nz-number ) ; search-key defined in [RFC3501] =20 Which essentially means two things: - correct sequences using the brackets, - we can specify both ends of the time interval (this is an actual = proposal). 2. Normative references and informative references do not have a section = number. 3. Normative references: URL is missing from [ABNFEXTEND]. URLs are = there for the other two references, so the URL should be added to = ABNFEXTEND, or removed from the other two. 4. Unused reference: [P-IMAP], suggest removal. Later on I noticed that = it's used in Acknowledgements section. 5. Future work: [1] Decide whether other interval units are necessary. I think that the day/months should be added as well. Here is the syntax = I have in mind (assuming that comment 1. was accepted): search-key /=3D ( ( "OLDER" SP nz-number ) / ( "YOUNGER" SP = nz-number ) / ( "OLDER" SP nz-number SP "YOUNGER" SP nz-number ) ) = i-unit ; search-key defined in [RFC3501]=20 i-unit =3D "d" / "D" / "h" / "H" / "m" / "M" ; either days (d, D), hours (h, H) or months (m , = M) So, the example in section 3 would be ('h' added to the end): C: a1 SEARCH UNSEEN YOUNGER 72h 6. There are two acknowledgement sections - is this OK or should these = be merged? One is called "Acknowledgements", the other one is called = "Acknowledgement". 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@cantata.com]=20 >Sent: 07 November, 2006 17:48 >To: IETF LEMONADE >Subject: [lemonade] WGLC Search Within > >draft-ietf-lemonade-search-within-02.txt> > >Have at it. WGLC closes 11/21/06. > > >_______________________________________________ >lemonade mailing list >lemonade@ietf.org >https://www1.ietf.org/mailman/listinfo/lemonade > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 08 04:59:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhkDT-0001TB-6N; Wed, 08 Nov 2006 04:59:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhkDS-0001T3-Gs; Wed, 08 Nov 2006 04:59:30 -0500 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhkDR-00062u-1o; Wed, 08 Nov 2006 04:59:30 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA89Y7lR012822; Wed, 8 Nov 2006 11:37:03 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 11:33:31 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 11:33:31 +0200 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 Search Within - Comments Date: Wed, 8 Nov 2006 11:32:36 +0200 Message-ID: <0FA975F2D8295A448BE3ADC1612446570199576E@esebe199.NOE.Nokia.com> In-Reply-To: <0FA975F2D8295A448BE3ADC161244657019956D9@esebe199.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] WGLC Search Within - Comments Thread-Index: AccChA/0Tq5ucm53Edus8wAWy5cvmwAi2SPgAAJGABA= From: To: , X-OriginalArrivalTime: 08 Nov 2006 09:33:31.0357 (UTC) FILETIME=[F425E0D0:01C70318] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: stephane.maes@oracle.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Whoops, I left an error here: >5. Future work: > [1] Decide whether other interval units are necessary. >I think that the day/months should be added as well. Here is=20 >the syntax I have in mind (assuming that comment 1. was accepted): > search-key /=3D ( ( "OLDER" SP nz-number ) / ( "YOUNGER"=20 >SP nz-number ) / ( "OLDER" SP nz-number SP "YOUNGER" SP=20 >nz-number ) ) i-unit > ; search-key defined in [RFC3501]=20 > i-unit =3D "d" / "D" / "h" / "H" / "m" / "M" > ; either days (d, D), hours (h, H) or=20 >months (m , M) > >So, the example in section 3 would be ('h' added to the end): >C: a1 SEARCH UNSEEN YOUNGER 72h It should have been: search-key /=3D ( ( "OLDER" SP nz-number ) / ( "YOUNGER" SP nz-number ) i-unit ) / ( "OLDER" SP nz-number i-unit SP "YOUNGER" SP nz-number i-unit) ; search-key defined in [RFC3501]=20 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 08 05:03:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhkHf-00032q-Ho; Wed, 08 Nov 2006 05:03:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhkHe-00032W-Ac for lemonade@ietf.org; Wed, 08 Nov 2006 05:03:50 -0500 Received: from pathbreaker.com ([64.71.130.73]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GhkHc-0006Qz-UC for lemonade@ietf.org; Wed, 08 Nov 2006 05:03:50 -0500 Received: (qmail 8954 invoked by uid 89); 8 Nov 2006 10:00:56 -0000 Received: from localhost (HELO ?192.168.1.100?) (ray%logicaldepth.com@127.0.0.1) by 0 with SMTP; 8 Nov 2006 10:00:56 -0000 Message-ID: <4551AB62.2030103@pathbreaker.com> Date: Wed, 08 Nov 2006 02:03:14 -0800 From: Ray Cromwell User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Zoltan.Ordogh@nokia.com Subject: Re: [lemonade] WGLC Search Within - Comments References: <0FA975F2D8295A448BE3ADC161244657019956D9@esebe199.NOE.Nokia.com> In-Reply-To: <0FA975F2D8295A448BE3ADC161244657019956D9@esebe199.NOE.Nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: lemonade@ietf.org, stephane.maes@oracle.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Zoltan.Ordogh@nokia.com wrote: > > To this: > search-key /= ( "OLDER" SP nz-number ) / ( "YOUNGER" SP nz-number ) / ( "OLDER" SP nz-number SP "YOUNGER" SP nz-number ) > ; search-key defined in [RFC3501] > I agree the parenthesis are needed, but wouldn't the third option simply be written "OLDER x AND YOUNGER y"? > 5. Future work: > [1] Decide whether other interval units are necessary. > I think that the day/months should be added as well. Here is the syntax I have in mind (assuming that comment 1. was accepted): > search-key /= ( ( "OLDER" SP nz-number ) / ( "YOUNGER" SP nz-number ) / ( "OLDER" SP nz-number SP "YOUNGER" SP nz-number ) ) i-unit > ; search-key defined in [RFC3501] > i-unit = "d" / "D" / "h" / "H" / "m" / "M" > ; either days (d, D), hours (h, H) or months (m , M) > I don't have a huge problem with this, but the draft is very simple and I hope it can make it past WGLC without too many revs, so we can concentrate on other drafts. I fear an endless debate over time interval formats and calendar semantics dragging out for weeks (exactly how long is 3 months?! In a leap year?) , when the important thing is to settle on the minimum time granularity and accuracy supported by the server. The client can always compute any arbitrary interval from the minimum granularity, so the extra-interval units seem to be syntactic sugar to avoid somewhat trivial arithmetic on the client. -Ray _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 08 05:25:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhkcS-0005Dh-VN; Wed, 08 Nov 2006 05:25:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhkcQ-0005Cq-UE for lemonade@ietf.org; Wed, 08 Nov 2006 05:25:18 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhkWh-0007Ty-1M for lemonade@ietf.org; Wed, 08 Nov 2006 05:19:25 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 74C974ACC1; Wed, 8 Nov 2006 11:19:16 +0100 (CET) Message-Id: Date: Wed, 8 Nov 2006 11:19:20 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] WGLC Search Within - Comments References: <0FA975F2D8295A448BE3ADC161244657019956D9@esebe199.NOE.Nokia.com> <4551AB62.2030103@pathbreaker.com> In-Reply-To: <4551AB62.2030103@pathbreaker.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: stephane.maes@oracle.com, Zoltan.Ordogh@nokia.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Ray Cromwell writes: > Zoltan.Ordogh@nokia.com wrote: >> To this: >> search-key /= ( "OLDER" SP nz-number ) / ( "YOUNGER" SP >> nz-number ) / ( "OLDER" SP nz-number SP "YOUNGER" SP nz-number >> ) >> ; search-key defined in [RFC3501] > I agree the parenthesis are needed, but wouldn't the third option > simply be written "OLDER x AND YOUNGER y"? "a SEARCH UNSEEN OLDER 1 YOUNGER 2" is a valid command in the current draft: IMAP search has an implicit AND and all three conditions must be true, so that commmand finds unseen mail that's 1-2 hours old. (It takes a little time to get used to IMAP search syntax ;) > I don't have a huge problem with this, but the draft is very simple > and I hope it can make it past WGLC without too many revs, so we can > concentrate on other drafts. I fear an endless debate over time > interval formats and calendar semantics dragging out for weeks > (exactly how long is 3 months?! In a leap year?) , when the important > thing is to settle on the minimum time granularity and accuracy > supported by the server. Yes! Yes! Yes! Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 08 05:41:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhksB-0007lb-Vc; Wed, 08 Nov 2006 05:41:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhksA-0007ko-6R for lemonade@ietf.org; Wed, 08 Nov 2006 05:41:34 -0500 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghks8-0001ZW-NL for lemonade@ietf.org; Wed, 08 Nov 2006 05:41:34 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA8AfO1e014894; Wed, 8 Nov 2006 12:41:31 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 12:41:28 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 12:41:28 +0200 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 Search Within - Comments Date: Wed, 8 Nov 2006 12:40:33 +0200 Message-ID: <0FA975F2D8295A448BE3ADC16124465701995892@esebe199.NOE.Nokia.com> In-Reply-To: <4551AB62.2030103@pathbreaker.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] WGLC Search Within - Comments Thread-Index: AccDHeJjSYwGvpY3Qp6u0OilZBrIXwABBVcA From: To: X-OriginalArrivalTime: 08 Nov 2006 10:41:28.0590 (UTC) FILETIME=[725E42E0:01C70322] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: lemonade@ietf.org, stephane.maes@oracle.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Ray, >> To this: >> search-key /=3D ( "OLDER" SP nz-number ) / ( "YOUNGER"=20 >SP nz-number ) / ( "OLDER" SP nz-number SP "YOUNGER" SP nz-number ) >> ; search-key defined in [RFC3501] >> =20 >I agree the parenthesis are needed, but wouldn't the third=20 >option simply be written "OLDER x AND YOUNGER y"? You mean adding search-key twice? Yes, that works too, consider this withdrawn. >> 5. Future work: >> [1] Decide whether other interval units are necessary. >> I think that the day/months should be added as well. Here is=20 >the syntax I have in mind (assuming that comment 1. was accepted): >> search-key /=3D ( ( "OLDER" SP nz-number ) / ( "YOUNGER"=20 >SP nz-number ) / ( "OLDER" SP nz-number SP "YOUNGER" SP=20 >nz-number ) ) i-unit >> ; search-key defined in [RFC3501]=20 >> i-unit =3D "d" / "D" / "h" / "H" / "m" / "M" >> ; either days (d, D), hours (h, H) or=20 >months (m=20 >> , M) >> =20 > >I don't have a huge problem with this, but the draft is very=20 >simple and I hope it can make it past WGLC without too many=20 >revs, so we can concentrate on other drafts. I fear an endless=20 >debate over time interval formats and calendar semantics=20 >dragging out for weeks (exactly how long is 3 months?! In a=20 >leap year?) , when the important thing is to settle on the=20 >minimum time granularity and accuracy supported by the server. =20 >The client can always compute any arbitrary interval from the=20 >minimum granularity, so the extra-interval units seem to be=20 >syntactic sugar to avoid somewhat trivial arithmetic on the client. Ok, then let's drop months then, but days should still be OK. =20 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 08 06:02:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhlBq-0002TO-6p; Wed, 08 Nov 2006 06:01:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhlBo-0002TF-KR for lemonade@ietf.org; Wed, 08 Nov 2006 06:01:52 -0500 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhlBm-0003jg-II for lemonade@ietf.org; Wed, 08 Nov 2006 06:01:52 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA8B1D8t000332; Wed, 8 Nov 2006 13:01:49 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 13:01:40 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 13:01:40 +0200 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 Search Within - Comments Date: Wed, 8 Nov 2006 13:00:45 +0200 Message-ID: <0FA975F2D8295A448BE3ADC161244657019958FE@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] WGLC Search Within - Comments Thread-Index: AccDIHbdMOu18PWESmmJJvBKKMjMeQAA8wng From: To: , X-OriginalArrivalTime: 08 Nov 2006 11:01:40.0134 (UTC) FILETIME=[44813460:01C70325] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: stephane.maes@oracle.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Arnt, >Ray Cromwell writes: >> Zoltan.Ordogh@nokia.com wrote: >>> To this: >>> search-key /=3D ( "OLDER" SP nz-number ) / ( "YOUNGER" SP=20 >>> nz-number ) / ( "OLDER" SP nz-number SP "YOUNGER" SP=20 >nz-number=20 >>> ) >>> ; search-key defined in [RFC3501] >> I agree the parenthesis are needed, but wouldn't the third option=20 >> simply be written "OLDER x AND YOUNGER y"? > >"a SEARCH UNSEEN OLDER 1 YOUNGER 2" is a valid command in the current >draft: IMAP search has an implicit AND and all three=20 >conditions must be true, so that commmand finds unseen mail=20 >that's 1-2 hours old. (It takes a little time to get used to=20 >IMAP search syntax ;) I take it You are saying the same thing as Ray, right? So, this we have settled. > >> I don't have a huge problem with this, but the draft is very simple=20 >> and I hope it can make it past WGLC without too many revs, so we can=20 >> concentrate on other drafts. I fear an endless debate over time=20 >> interval formats and calendar semantics dragging out for weeks=20 >> (exactly how long is 3 months?! In a leap year?) , when the=20 >important=20 >> thing is to settle on the minimum time granularity and accuracy=20 >> supported by the server. > >Yes! Yes! Yes! Erm... Does it mean that You agree with Ray? I replied to Him saying that we can drop the month - keeping the day if possible. Dropping the day should not be a problem either because it's simply multiplied by 24 - but I would rather keep it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 08 06:05:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhlFV-0004yV-Cl; Wed, 08 Nov 2006 06:05:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhlFT-0004wg-Ph for lemonade@ietf.org; Wed, 08 Nov 2006 06:05:39 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhlFR-0004As-AU for lemonade@ietf.org; Wed, 08 Nov 2006 06:05:39 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 19DDA4AC64; Wed, 8 Nov 2006 12:05:36 +0100 (CET) Message-Id: <+v9QhAjYCAd39V7FMI043A.md5@libertango.oryx.com> Date: Wed, 8 Nov 2006 12:05:39 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] WGLC Search Within - Comments References: <0FA975F2D8295A448BE3ADC161244657019958FE@esebe199.NOE.Nokia.com> In-Reply-To: <0FA975F2D8295A448BE3ADC161244657019958FE@esebe199.NOE.Nokia.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: stephane.maes@oracle.com, Zoltan.Ordogh@nokia.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Zoltan.Ordogh@nokia.com writes: > Hi Arnt, >> Ray Cromwell writes: >>> I don't have a huge problem with this, but the draft is very simple >>> and I hope it can make it past WGLC without too many revs, so we >>> can concentrate on other drafts. I fear an endless debate over >>> time interval formats and calendar semantics dragging out for >>> weeks (exactly how long is 3 months?! In a leap year?) , when the >>> important thing is to settle on the minimum time granularity and >>> accuracy supported by the server. >> >> Yes! Yes! Yes! > > Erm... Does it mean that You agree with Ray? Yes I do. Simplicity is a fine and desirable feature. > I replied to Him saying that we can drop the month - keeping the day > if possible. > Dropping the day should not be a problem either because it's simply > multiplied by 24 - but I would rather keep it. Do you have an argument to justify the additional argument? Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 08 06:12:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhlLz-0008Nf-2B; Wed, 08 Nov 2006 06:12:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhlLy-0008Na-4k for lemonade@ietf.org; Wed, 08 Nov 2006 06:12:22 -0500 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhlLw-0004t0-L0 for lemonade@ietf.org; Wed, 08 Nov 2006 06:12:22 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1GhlLu-0006G3-VV; Wed, 08 Nov 2006 11:12:19 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id E83F3498005; Wed, 8 Nov 2006 11:22:43 +0000 (GMT) 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 05352-07; Wed, 8 Nov 2006 11:22:37 +0000 (GMT) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 3D961498004; Wed, 8 Nov 2006 11:22:37 +0000 (GMT) Date: Wed, 08 Nov 2006 11:12:09 +0000 Subject: Re: [lemonade] WGLC Search Within - Comments References: <0FA975F2D8295A448BE3ADC161244657019956D9@esebe199.NOE.Nokia.com> <4551AB62.2030103@pathbreaker.com> In-Reply-To: <4551AB62.2030103@pathbreaker.com> MIME-Version: 1.0 Message-Id: <26359.1162984332.023328@peirce.dave.cridland.net> From: Dave Cridland To: Ray Cromwell Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Rutherford-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: Enhancements to Internet email to support diverse service enivronments , "Zoltan.Ordogh@nokia.com" , "Stephane H. Maes" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I'll comment on some comments (meta-comments?) and add some of my own. On Wed Nov 8 10:03:14 2006, Ray Cromwell wrote: > Zoltan.Ordogh@nokia.com wrote: >> To this: >> search-key /= ( "OLDER" SP nz-number ) / ( "YOUNGER" SP >> nz-number ) / ( "OLDER" SP nz-number SP "YOUNGER" SP nz-number ) >> ; search-key defined in [RFC3501] > I agree the parenthesis are needed, but wouldn't the third option > simply be written "OLDER x AND YOUNGER y"? > > The parenthesis aren't needed, RFC3501's search (and search-key) productions handle the combination case fine, too. I think the ABNF is fine as it is - the precedence of the / operator takes care of everything, just as it does in RFC3501's search-key production. >> 5. Future work: >> [1] Decide whether other interval units are necessary. >> I think that the day/months should be added as well. Here is the >> syntax I have in mind (assuming that comment 1. was accepted): >> search-key /= ( ( "OLDER" SP nz-number ) / ( "YOUNGER" SP >> nz-number ) / ( "OLDER" SP nz-number SP "YOUNGER" SP nz-number ) ) >> i-unit >> ; search-key defined in [RFC3501] >> i-unit = "d" / "D" / "h" / "H" / "m" / "M" >> ; either days (d, D), hours (h, H) or >> months (m , M) >> > > I don't have a huge problem with this, but the draft is very simple > and I hope it can make it past WGLC without too many revs, so we > can concentrate on other drafts. I fear an endless debate over time > interval formats and calendar semantics dragging out for weeks > (exactly how long is 3 months?! In a leap year?) , when the > important thing is to settle on the minimum time granularity and > accuracy supported by the server. I hate to bring this up, but anything other than seconds will have this problem. Certain minutes have 61 seconds, for example, leading to certain hours having 3601 seconds. Is a client likely to care? No, almost certainly not. I don't see a real problem with having the server be allowed some leeway in updating these results, either - currently the draft essentially dictates that servers have to treat an hour as 3600 (or 3601) seconds accordingly, and doesn't talk about the granularity of the criteria, merely the granularity of how the criteria can be specified. 1) Paragraph 2 of section 1 implies that YOUNGER and OLDER use an interval of hours from which a date is calculated, and the use of the phrase "after the date calculated" could be read to imply that servers round off to a date, and not a time. Since this code will exist in a base IMAP server, you might find people quite happy to take this somewhat literally. 2) Also, the use of the phrase "[...] depositied in the mailbox after the date calculated [...]" is in itself problematic, since it implies that a third date, neither the Date header field nor the INTERNALDATE, is used for this. 3) A nit: The example in section 3 contains no tagged OK response. 4) As a general comment, I'd personally apprciate a new section inserted between the Introduction (which I generally read expecting a non-normative summary) and the formal syntax, giving a strictly worded definition of OLDER and YOUNGER. By way of a suggestion: 2. Protocol Changes For both new search keys, a date and time is calculated by subtracting the interval on the current date and time of the server. Servers need not maintain a greater precision than an hour in this calculation. The resultant date and time is then compared against the INTERNALDATE (as specified in [RFC3501]). For OLDER, messages match if the date and time is less recent then the INTERNALDATE, for YOUNGER, messages match if the date and time is more recent then the INTERNALDATE. If the date and time matches the INTERNALDATE precisely,the message will be matched by both OLDER and YOUNGER. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 08 07:38:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhmhM-0006ue-Rk; Wed, 08 Nov 2006 07:38:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhmhM-0006uZ-8n for lemonade@ietf.org; Wed, 08 Nov 2006 07:38:32 -0500 Received: from pathbreaker.com ([64.71.130.73]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GhmhK-0005hd-SZ for lemonade@ietf.org; Wed, 08 Nov 2006 07:38:32 -0500 Received: (qmail 4451 invoked by uid 89); 8 Nov 2006 12:35:42 -0000 Received: from localhost (HELO ?192.168.1.100?) (ray%logicaldepth.com@127.0.0.1) by 0 with SMTP; 8 Nov 2006 12:35:42 -0000 Message-ID: <4551CFA9.7060904@pathbreaker.com> Date: Wed, 08 Nov 2006 04:38:01 -0800 From: Ray Cromwell User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Dave Cridland Subject: Re: [lemonade] WGLC Search Within - Comments References: <0FA975F2D8295A448BE3ADC161244657019956D9@esebe199.NOE.Nokia.com> <4551AB62.2030103@pathbreaker.com> <26359.1162984332.023328@peirce.dave.cridland.net> In-Reply-To: <26359.1162984332.023328@peirce.dave.cridland.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Enhancements to Internet email to support diverse service enivronments , "Zoltan.Ordogh@nokia.com" , "Stephane H. Maes" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dave Cridland wrote: > I hate to bring this up, but anything other than seconds will have > this problem. Certain minutes have 61 seconds, for example, leading to > certain hours having 3601 seconds. > Apropos, proposals are floating to eliminate leap-seconds for precisely the reason that they make interval calculation non-trivial if you desire accuracy. But this just shows the can of worms that can open up when we start getting creative with interval formats, which is why the original search-within draft used seconds as a unit, since it is straight forward for clients to pick whatever definition of minutes, hours, days, months, they desire and translate them into interval seconds, and seconds is already a convenient input to date/time interval routines on many platforms. It was only changed because of concerns of accuracy guarantees that were raised, but in hindsight, we could have stuck with seconds, and simply mandated that servers guarantee no more than minute, or hour accuracy. The multiple unit proposal simply brings to light the fact that units and server accuracy (or granularity if you prefer) are separate issues. > I don't see a real problem with having the server be allowed some > leeway in updating these results, either - currently the draft > essentially dictates that servers have to treat an hour as 3600 (or > 3601) seconds accordingly, and doesn't talk about the granularity of > the criteria, merely the granularity of how the criteria can be > specified. > Yes, this was a mistake I think, in trying to address original concerns of per-second granularity, especially with vfolder (do I need to recompute all vfolder criteria every second!!!?), we settled on changing the interval units, instead of leaving them as is, and mandating / relaxing accuracy. Anyone in favor of a return to seconds? :) > > 4) As a general comment, I'd personally apprciate a new section > inserted between the Introduction (which I generally read expecting a > non-normative summary) and the formal syntax, giving a strictly worded > definition of OLDER and YOUNGER. > Yes, in discussions with Arnt, he has pointed out the need to define what "NOT OLDER" and "YOUNGER" mean, e.g. synonyms/semantic equivalence? -Ray _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 08 08:03:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghn5U-0003Lv-0X; Wed, 08 Nov 2006 08:03:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghn5S-0003Ki-K7 for lemonade@ietf.org; Wed, 08 Nov 2006 08:03:26 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghmxy-0007co-Ca for lemonade@ietf.org; Wed, 08 Nov 2006 07:55:43 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 4AF664ACBD; Wed, 8 Nov 2006 13:55:41 +0100 (CET) Message-Id: Date: Wed, 8 Nov 2006 13:55:45 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] WGLC Search Within - Comments References: <0FA975F2D8295A448BE3ADC161244657019956D9@esebe199.NOE.Nokia.com> <4551AB62.2030103@pathbreaker.com> <26359.1162984332.023328@peirce.dave.cridland.net> <4551CFA9.7060904@pathbreaker.com> <51gMO6BzzQXU3AP8E9yJPA.md5@libertango.oryx.com> In-Reply-To: <51gMO6BzzQXU3AP8E9yJPA.md5@libertango.oryx.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: "Stephane H. Maes" , Zoltan.Ordogh@nokia.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Arnt Gulbrandsen writes: > Yes. I suggest: "The client specifies the age limit in seconds. The > server need not recheck every second when using WITHIN with CONTEXTS, > VFOLDER or other mechanisms that cause the search to be repeatedly > executed. The server can use any time between the start and end of > the command processing as base, and may disregard leap seconds when > processing age." Ick. Half the verbs are wrong. I suck. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 08 08:04:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghn5Y-0003Ny-OC; Wed, 08 Nov 2006 08:03:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghn5X-0003ML-9a for lemonade@ietf.org; Wed, 08 Nov 2006 08:03:31 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghmwg-0007Qs-6O for lemonade@ietf.org; Wed, 08 Nov 2006 07:54:23 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 064334AC64; Wed, 8 Nov 2006 13:54:21 +0100 (CET) Message-Id: <51gMO6BzzQXU3AP8E9yJPA.md5@libertango.oryx.com> Date: Wed, 8 Nov 2006 13:54:25 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] WGLC Search Within - Comments References: <0FA975F2D8295A448BE3ADC161244657019956D9@esebe199.NOE.Nokia.com> <4551AB62.2030103@pathbreaker.com> <26359.1162984332.023328@peirce.dave.cridland.net> <4551CFA9.7060904@pathbreaker.com> In-Reply-To: <4551CFA9.7060904@pathbreaker.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: "Stephane H. Maes" , Zoltan.Ordogh@nokia.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Ray Cromwell writes: > Dave Cridland wrote: >> I don't see a real problem with having the server be allowed some >> leeway in updating these results, either - currently the draft >> essentially dictates that servers have to treat an hour as 3600 (or >> 3601) seconds accordingly, and doesn't talk about the granularity of >> the criteria, merely the granularity of how the criteria can be >> specified. > > Yes, this was a mistake I think, in trying to address original > concerns of per-second granularity, especially with vfolder (do I > need to recompute all vfolder criteria every second!!!?), we settled > on changing the interval units, instead of leaving them as is, and > mandating / relaxing accuracy. Anyone in favor of a return to > seconds? :) Yes. I suggest: "The client specifies the age limit in seconds. The server need not recheck every second when using WITHIN with CONTEXTS, VFOLDER or other mechanisms that cause the search to be repeatedly executed. The server can use any time between the start and end of the command processing as base, and may disregard leap seconds when processing age." (I know the second sentence disregards an obvious optimisation.) (And I don't really care how the age is specified so long as it's simple. Seconds, minutes, hours, I don't care. I liked days until Alexey persuaded me otherwise.) Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 08 13:17:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghrtu-0004yp-00; Wed, 08 Nov 2006 13:11:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghrts-0004gW-It for lemonade@ietf.org; Wed, 08 Nov 2006 13:11:48 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghrg3-0000ug-AD for lemonade@ietf.org; Wed, 08 Nov 2006 12:57:32 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kA8HvShA031599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 8 Nov 2006 09:57:29 -0800 Received: from [[192.168.1.13]] (vpn-10-50-16-160.qualcomm.com [10.50.16.160]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA8HvOfA023068; Wed, 8 Nov 2006 09:57:26 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <0FA975F2D8295A448BE3ADC16124465701995647@esebe199.NOE.Nokia.com> References: <0FA975F2D8295A448BE3ADC16124465701995647@esebe199.NOE.Nokia.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Wed, 8 Nov 2006 09:56:35 -0800 To: , , From: Randall Gellens Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-04.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: lemonade@ietf.org, stephane.maes@oracle.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 10:24 AM +0200 11/8/06, wrote: > Hi Randall, > >>The "by default" means "when opening a connection to the >>submission server, clients MUST attempt to open port 587 on >>the submission server. Clients MUST NOT try a different port >>unless this attempt fails, or the client has been explicitly >>configured to use a different port." > > Could we add this then? Personally, I think "by default" covers it, but if you feel that the broader audience for the lemonade Profile document would benefit from more clarification, I'm OK with adding the additional text. Let me try to improve the wording a little, though: ----------------------------- When opening a connection to the submission server, clients MUST do so using port 587 unless explicitly configured to use a different port. If the TCP connection to the submission server fails to open using port 587, the client MAY then immediately retry using a different port, such as 25. See [Submit] for information on why using port 25 is likely to fail depending on the current location of the client, and may result in a failure code during the SMTP transaction. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- A successful tool is used to do something undreamed of by its author. --Johnson _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 08 16:52:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhvLJ-0000bd-Kr; Wed, 08 Nov 2006 16:52:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhvLI-0000bY-0A for lemonade@ietf.org; Wed, 08 Nov 2006 16:52:20 -0500 Received: from ppsw-4.csi.cam.ac.uk ([131.111.8.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhvLC-0003Vw-DI for lemonade@ietf.org; Wed, 08 Nov 2006 16:52:19 -0500 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]:39638) by ppsw-4.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.154]:25) with esmtpa (EXTERNAL:fanf2) id 1GhvL6-0003WO-G4 (Exim 4.63) for lemonade@ietf.org (return-path ); Wed, 08 Nov 2006 21:52:09 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1GhvL6-0003I6-UO (Exim 4.54) for lemonade@ietf.org (return-path ); Wed, 08 Nov 2006 21:52:08 +0000 Date: Wed, 8 Nov 2006 21:52:08 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: lemonade@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [lemonade] checkpoint/resume, rfc1845bis X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Following suggestions from Dave and Alexei, I've finally finished a draft of rfc1845bis, rather later than I hoped... This arose from the "REPLAY" draft I wrote back in March, though all it has in common is that I wrote it. This new version is much more compatible with RFC 1845, has better security, and clearer support for mobility. http://www-uxsup.csx.cam.ac.uk/~fanf2/hermes/doc/qsmtp/ draft-fanf-lemonade-rfc1845bis.html draft-fanf-lemonade-rfc1845bis.txt draft-fanf-lemonade-rfc1845bis.xml Tony. -- f.a.n.finch http://dotat.at/ IRISH SEA: NORTHWEST 5 TO 7 BECOMING VARIABLE 3. MODERATE BECOMING SLIGHT. SQUALLY SHOWERS. GOOD. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 08 20:49:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghz32-0000b9-7o; Wed, 08 Nov 2006 20:49:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghz31-0000Zp-3J for lemonade@ietf.org; Wed, 08 Nov 2006 20:49:43 -0500 Received: from outbound.cantata.com ([208.236.123.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghz2z-0001OQ-T4 for lemonade@ietf.org; Wed, 08 Nov 2006 20:49:43 -0500 Received: from ma02exchtmp01.Cantata.com ([10.128.18.41]) by outbound.Cantata.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 20:49:41 -0500 Received: from 10.128.41.54 ([10.128.41.54]) by ma02exchtmp01.Cantata.com ([10.128.18.41]) with Microsoft Exchange Server HTTP-DAV ; Thu, 9 Nov 2006 01:49:40 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Wed, 08 Nov 2006 20:49:35 -0500 From: Eric Burger To: IETF LEMONADE Message-ID: Thread-Topic: Draft Minutes Thread-Index: AccDoU7MjX0gE2+UEdufmgAWy5cvmw== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 09 Nov 2006 01:49:41.0664 (UTC) FILETIME=[52C57A00:01C703A1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Subject: [lemonade] Draft Minutes X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org If you want real minutes, we will have to find a real minutes taker... http://www3.ietf.org/proceedings/06nov/minutes/lemonade.txt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Nov 09 03:23:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi5Bo-0005If-Rz; Thu, 09 Nov 2006 03:23:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi5Bn-0005IE-T1 for lemonade@ietf.org; Thu, 09 Nov 2006 03:23:11 -0500 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi5Bm-000529-FT for lemonade@ietf.org; Thu, 09 Nov 2006 03:23:11 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA98N1ZI027538; Thu, 9 Nov 2006 10:23:08 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 10:23:05 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 10:23:07 +0200 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-04.txt Date: Thu, 9 Nov 2006 10:22:11 +0200 Message-ID: <0FA975F2D8295A448BE3ADC16124465701996122@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-04.txt Thread-Index: AccDYaweYFKyGgZITyKZlLC3KT/+XwAdjrpw From: To: , , X-OriginalArrivalTime: 09 Nov 2006 08:23:07.0894 (UTC) FILETIME=[492E5160:01C703D8] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061109102308-68208BB0-74FDE8D5/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: lemonade@ietf.org, stephane.maes@oracle.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Randall, Your latest proposal - >----------------------------- >When opening a connection to the submission server, clients=20 >MUST do so using port 587 unless explicitly configured to use=20 >a different port. If the TCP connection to the submission=20 >server fails to open using port 587, the client MAY then=20 >immediately retry using a different port, such as 25. See=20 >[Submit] for information on why using port 25 is likely to=20 >fail depending on the current location of the client, and may=20 >result in a failure code during the SMTP transaction. >-- - covers all of my worries, I hope we can add this to the document. Thank You. 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 From lemonade-bounces@ietf.org Thu Nov 09 03:34:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi5Mu-00022m-Fu; Thu, 09 Nov 2006 03:34:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi5Ms-00022e-Pj for lemonade@ietf.org; Thu, 09 Nov 2006 03:34:38 -0500 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi5Mp-0006ZF-9y for lemonade@ietf.org; Thu, 09 Nov 2006 03:34:37 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA98Y1Ch031668; Thu, 9 Nov 2006 10:34:24 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 10:34:15 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 10:34:17 +0200 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] checkpoint/resume, rfc1845bis Date: Thu, 9 Nov 2006 10:33:20 +0200 Message-ID: <0FA975F2D8295A448BE3ADC1612446570199614E@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] checkpoint/resume, rfc1845bis Thread-Index: AccDgLfJ6MKLzm12Qp2QvoncGfClyQAWEo7g From: To: , X-OriginalArrivalTime: 09 Nov 2006 08:34:17.0533 (UTC) FILETIME=[D8511ED0:01C703D9] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Good day Mr Finch, I could not go to the meeting in San Diego, so I think I am missing = something. Would it be possible to clarify the intent with this draft? I assume the = ultimate goal is to add it to the Profile-bis, right? 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 Tony Finch [mailto:dot@dotat.at]=20 >Sent: 08 November, 2006 23:52 >To: lemonade@ietf.org >Subject: [lemonade] checkpoint/resume, rfc1845bis > >Following suggestions from Dave and Alexei, I've finally=20 >finished a draft of rfc1845bis, rather later than I hoped... > >This arose from the "REPLAY" draft I wrote back in March,=20 >though all it has in common is that I wrote it. This new=20 >version is much more compatible with RFC 1845, has better=20 >security, and clearer support for mobility. > >http://www-uxsup.csx.cam.ac.uk/~fanf2/hermes/doc/qsmtp/ >draft-fanf-lemonade-rfc1845bis.html >draft-fanf-lemonade-rfc1845bis.txt >draft-fanf-lemonade-rfc1845bis.xml > >Tony. >-- >f.a.n.finch http://dotat.at/ IRISH SEA:=20 >NORTHWEST 5 TO 7 BECOMING VARIABLE 3. MODERATE BECOMING SLIGHT. >SQUALLY SHOWERS. GOOD. > >_______________________________________________ >lemonade mailing list >lemonade@ietf.org >https://www1.ietf.org/mailman/listinfo/lemonade > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Nov 09 04:30:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi6Ei-0004FC-FJ; Thu, 09 Nov 2006 04:30:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi6Eg-0004F6-Tn for lemonade@ietf.org; Thu, 09 Nov 2006 04:30:14 -0500 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi6Ef-0007kQ-Jm for lemonade@ietf.org; Thu, 09 Nov 2006 04:30:14 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.50) id 1Gi6Ec-0008OF-0O; Thu, 09 Nov 2006 09:30:10 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 6E5F1498005; Thu, 9 Nov 2006 09:40:44 +0000 (GMT) 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 25332-06; Thu, 9 Nov 2006 09:40:40 +0000 (GMT) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 942D0498003; Thu, 9 Nov 2006 09:40:40 +0000 (GMT) Date: Thu, 09 Nov 2006 09:30:05 +0000 Subject: RE: [lemonade] checkpoint/resume, rfc1845bis References: <0FA975F2D8295A448BE3ADC1612446570199614E@esebe199.NOE.Nokia.com> In-Reply-To: <0FA975F2D8295A448BE3ADC1612446570199614E@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Message-Id: <21613.1163064605.959277@peirce.dave.cridland.net> From: Dave Cridland To: "Zoltan.Ordogh@nokia.com" Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Pythagoras-IP: [217.155.137.60] X-Spam-Score: 0.5 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Tony Finch , 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 Nov 9 08:33:20 2006, Zoltan.Ordogh@nokia.com wrote: > Good day Mr Finch, > I could not go to the meeting in San Diego, so I think I am missing > something. > Would it be possible to clarify the intent with this draft? I > assume the ultimate goal is to add it to the Profile-bis, right? > Thank You. Several people at the WG meeting itself suggested that this wasn't actually wanted for Profile Bis. Essentially, this was based on concern about how difficult it would be to implement well and interoperably. Personally, I think that this extension would be a welcome addition. There have been a few occasions where I've lost the connection after the message data has been sent but before the reply has been received, and while these are few, they represent a level of frustration. (If you develop your own mail client, and also work on the mailserver you use, it looks particularly bad if you send out a duplicate message, of course, so perhaps the problem is more acute for me than for most people). Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Nov 09 04:48:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi6WR-0003mV-1q; Thu, 09 Nov 2006 04:48:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi6WP-0003mQ-8e for lemonade@ietf.org; Thu, 09 Nov 2006 04:48:33 -0500 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi6WN-0001Z0-O7 for lemonade@ietf.org; Thu, 09 Nov 2006 04:48:33 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA99lpAe021924; Thu, 9 Nov 2006 11:48:18 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 11:47:56 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 11:47:56 +0200 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] checkpoint/resume, rfc1845bis Date: Thu, 9 Nov 2006 11:46:59 +0200 Message-ID: <0FA975F2D8295A448BE3ADC161244657019EF2AA@esebe199.NOE.Nokia.com> In-Reply-To: <21613.1163064605.959277@peirce.dave.cridland.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] checkpoint/resume, rfc1845bis Thread-Index: AccD4qOstJDrtyIARVi6nANnMrhU0gAAEYqA From: To: X-OriginalArrivalTime: 09 Nov 2006 09:47:56.0492 (UTC) FILETIME=[2238C0C0:01C703E4] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: dot@dotat.at, lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Dave, thank You for Your response. >Several people at the WG meeting itself suggested that this=20 >wasn't actually wanted for Profile Bis. Essentially, this was=20 >based on concern about how difficult it would be to implement=20 >well and interoperably. Have those issues been expressed clearly? Can those issues be addressed by updating the draft? >Personally, I think that this extension would be a welcome addition.=20 >There have been a few occasions where I've lost the connection=20 >after the message data has been sent but before the reply has=20 >been received, and while these are few, they represent a level=20 >of frustration. (If you develop your own mail client, and also=20 >work on the mailserver you use, it looks particularly bad if=20 >you send out a duplicate message, of course, so perhaps the=20 >problem is more acute for me than for most people). I have felt this pain also while sending emails over unreliable (mobile) = connections - while on the train, I could not send my email out until = the train has stopped which actually jammed the whole connection due to = constant retries. Therefore, personally, I also agree with You, however I sense that the = server vendors are not happy about such proposal. I would like to see = those worries expressed before jumping into any conclusions. 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 From lemonade-bounces@ietf.org Thu Nov 09 05:32:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi7Ct-0005rq-69; Thu, 09 Nov 2006 05:32:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi7Cs-0005rR-9V for lemonade@ietf.org; Thu, 09 Nov 2006 05:32:26 -0500 Received: from ppsw-3.csi.cam.ac.uk ([131.111.8.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi7Cq-0007fS-NM for lemonade@ietf.org; Thu, 09 Nov 2006 05:32:26 -0500 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]:55763) by ppsw-3.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.153]:25) with esmtpa (EXTERNAL:fanf2) id 1Gi7CU-0007HI-Cg (Exim 4.63) (return-path ); Thu, 09 Nov 2006 10:32:02 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Gi7CU-0003hI-A0 (Exim 4.54) (return-path ); Thu, 09 Nov 2006 10:32:02 +0000 Date: Thu, 9 Nov 2006 10:32:02 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Zoltan.Ordogh@nokia.com Subject: RE: [lemonade] checkpoint/resume, rfc1845bis In-Reply-To: <0FA975F2D8295A448BE3ADC161244657019EF2AA@esebe199.NOE.Nokia.com> Message-ID: References: <0FA975F2D8295A448BE3ADC161244657019EF2AA@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: dot@dotat.at, 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 > >Several people at the WG meeting itself suggested that this > >wasn't actually wanted for Profile Bis. Essentially, this was > >based on concern about how difficult it would be to implement > >well and interoperably. > > Have those issues been expressed clearly? Have a look at the third paragraph of section 2.8, which I think is the biggest problem. It's difficult to fix, even if you require big timeouts as in RFC 1845 - and you don't want to do that for interactive mobile clients. Tony. -- f.a.n.finch http://dotat.at/ FISHER GERMAN BIGHT: NORTHWEST 6 TO GALE 8, OCCASIONALLY SEVERE GALE 9, BACKING WEST 4 LATER. ROUGH TO VERY ROUGH, OCCASIONALLY HIGH. SQUALLY SHOWERS. GOOD. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Nov 09 05:32:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi7DC-00060W-L1; Thu, 09 Nov 2006 05:32:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi7DB-0005zX-MF for lemonade@ietf.org; Thu, 09 Nov 2006 05:32:45 -0500 Received: from ppsw-3.csi.cam.ac.uk ([131.111.8.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi74N-0006N0-Mh for lemonade@ietf.org; Thu, 09 Nov 2006 05:23:43 -0500 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]:52595) by ppsw-3.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.153]:25) with esmtpa (EXTERNAL:fanf2) id 1Gi74F-0003O5-C8 (Exim 4.63) (return-path ); Thu, 09 Nov 2006 10:23:32 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Gi74E-0002Am-LW (Exim 4.54) (return-path ); Thu, 09 Nov 2006 10:23:30 +0000 Date: Thu, 9 Nov 2006 10:23:30 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Zoltan.Ordogh@nokia.com Subject: RE: [lemonade] checkpoint/resume, rfc1845bis In-Reply-To: <0FA975F2D8295A448BE3ADC1612446570199614E@esebe199.NOE.Nokia.com> Message-ID: References: <0FA975F2D8295A448BE3ADC1612446570199614E@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.2 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: dot@dotat.at, lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu, 9 Nov 2006, Zoltan.Ordogh@nokia.com wrote: > Would it be possible to clarify the intent with this draft? I became interested in improving RFC 1845 earlier this year so wrote a replacement. Dave and Alexey recently expressed interest in an improved version that would be more compatible with RFC 1845, so I re-wrote the draft in the hope that it would get wider support. Tony. -- f.a.n.finch http://dotat.at/ HUMBER THAMES: NORTHWEST 5 TO 7, OCCASIONALLY GALE 8 IN HUMBER AT FIRST, BACKING SOUTHWEST 4 OR 5 LATER. MODERATE TO ROUGH. SHOWERS. GOOD. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Nov 09 05:35:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi7DP-00065y-J5; Thu, 09 Nov 2006 05:32:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi7DN-00064Z-9u for lemonade@ietf.org; Thu, 09 Nov 2006 05:32:57 -0500 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi704-0005nU-Ct for lemonade@ietf.org; Thu, 09 Nov 2006 05:19:13 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1Gi701-0003GE-3s; Thu, 09 Nov 2006 10:19:09 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id C4B56498005; Thu, 9 Nov 2006 10:29:43 +0000 (GMT) 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 25770-01; Thu, 9 Nov 2006 10:29:36 +0000 (GMT) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 639BB498004; Thu, 9 Nov 2006 10:29:36 +0000 (GMT) Date: Thu, 09 Nov 2006 10:18:59 +0000 Subject: RE: [lemonade] checkpoint/resume, rfc1845bis References: <0FA975F2D8295A448BE3ADC161244657019EF2AA@esebe199.NOE.Nokia.com> In-Reply-To: <0FA975F2D8295A448BE3ADC161244657019EF2AA@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Message-Id: <21613.1163067541.386164@peirce.dave.cridland.net> From: Dave Cridland To: "Zoltan.Ordogh@nokia.com" Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Rutherford-IP: [217.155.137.60] X-Spam-Score: 0.5 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Tony Finch , 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 Nov 9 09:46:59 2006, Zoltan.Ordogh@nokia.com wrote: > Therefore, personally, I also agree with You, however I sense that > the server vendors are not happy about such proposal. I would like > to see those worries expressed before jumping into any conclusions. As an aside here, I think it's possible to implement Tony's draft such that partially received transactions are dumped, and the server instead merely stores the result of transactions for a client to access in a subsequent session. This would mean that a client losing a connection on a particularly large mail would have to resend in entirety, but on the other hand the problem I see as most prevelant - that of losing connectivity after sending the message, before receiving the result - is handled with minimal resource usage on the server. Having the facility in the protocol for partial message resends would be useful, of course, but I believe the protocol as written would allow for a server to avoid the partial message storage that I suspect is one of the more onerous parts of the protocol. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Nov 09 05:37:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi7Hj-0007ox-9b; Thu, 09 Nov 2006 05:37:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi7Hi-0007os-3N for lemonade@ietf.org; Thu, 09 Nov 2006 05:37:26 -0500 Received: from ppsw-7.csi.cam.ac.uk ([131.111.8.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi7Hg-0000is-Qw for lemonade@ietf.org; Thu, 09 Nov 2006 05:37:26 -0500 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]:57380) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1Gi7Gv-0000Ee-Mj (Exim 4.63) (return-path ); Thu, 09 Nov 2006 10:36:37 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Gi7Gt-0004Vq-T2 (Exim 4.54) (return-path ); Thu, 09 Nov 2006 10:36:35 +0000 Date: Thu, 9 Nov 2006 10:36:35 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Dave Cridland Subject: RE: [lemonade] checkpoint/resume, rfc1845bis In-Reply-To: <21613.1163067541.386164@peirce.dave.cridland.net> Message-ID: References: <0FA975F2D8295A448BE3ADC161244657019EF2AA@esebe199.NOE.Nokia.com> <21613.1163067541.386164@peirce.dave.cridland.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Tony Finch , Enhancements to Internet email to support diverse service enivronments , "Zoltan.Ordogh@nokia.com" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu, 9 Nov 2006, Dave Cridland wrote: > > As an aside here, I think it's possible to implement Tony's draft such that > partially received transactions are dumped, and the server instead merely > stores the result of transactions for a client to access in a subsequent > session. That is explicitly permitted in section 2.5 and there's some discussion in section 4.1. Tony. -- f.a.n.finch http://dotat.at/ SHANNON: EAST 3 OR 4 VEERING SOUTH 5 TO 7, PERHAPS GALE 8 LATER. MODERATE TO ROUGH. FAIR. GOOD. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 13 06:51:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjaKo-0001zs-6b; Mon, 13 Nov 2006 06:50:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjaKl-0001wu-Q0 for lemonade@ietf.org; Mon, 13 Nov 2006 06:50:40 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjaKj-0002W6-Ck for lemonade@ietf.org; Mon, 13 Nov 2006 06:50:39 -0500 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, 13 Nov 2006 11:50:26 +0000 Message-ID: <45585BFB.4080501@isode.com> Date: Mon, 13 Nov 2006 03:50:19 -0800 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Randall Gellens Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-04.txt References: <0FA975F2D8295A448BE3ADC16124465701995647@esebe199.NOE.Nokia.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: b19722fc8d3865b147c75ae2495625f2 Cc: lemonade@ietf.org, arnt@oryx.com, stephane.maes@oracle.com, Zoltan.Ordogh@nokia.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Randall Gellens wrote: > At 10:24 AM +0200 11/8/06, wrote: > >> Hi Randall, >> >>> The "by default" means "when opening a connection to the >>> submission server, clients MUST attempt to open port 587 on >>> the submission server. Clients MUST NOT try a different port >>> unless this attempt fails, or the client has been explicitly >>> configured to use a different port." >> >> Could we add this then? > > Personally, I think "by default" covers it, but if you feel that the > broader audience for the lemonade Profile document would benefit from > more clarification, I'm OK with adding the additional text. Let me > try to improve the wording a little, though: > > ----------------------------- > > When opening a connection to the submission server, clients MUST do so > using port 587 unless explicitly configured to use a different port. > If the TCP connection to the submission server fails to open using > port 587, the client MAY then immediately retry using a different > port, such as 25. See [Submit] for information on why using port 25 > is likely to fail depending on the current location of the client, and > may result in a failure code during the SMTP transaction. I like your text and added it to my copy of the document. But what is "may result in a failure code during the SMTP transaction"? Should we just say "may result in a failure of the SMTP transaction"? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 15 04:36:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkHC7-0004es-EP; Wed, 15 Nov 2006 04:36:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkHC6-0004em-6R for lemonade@ietf.org; Wed, 15 Nov 2006 04:36:34 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkHC4-00014h-7A for lemonade@ietf.org; Wed, 15 Nov 2006 04:36:34 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8R007AEMJ81S@szxga03-in.huawei.com> for lemonade@ietf.org; Wed, 15 Nov 2006 17:33:08 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8R0052ZMJ7M7@szxga03-in.huawei.com> for lemonade@ietf.org; Wed, 15 Nov 2006 17:33:08 +0800 (CST) Received: from w48795 ([10.164.120.56]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J8R00F61MJ6KR@szxml03-in.huawei.com> for lemonade@ietf.org; Wed, 15 Nov 2006 17:33:07 +0800 (CST) Date: Wed, 15 Nov 2006 17:32:58 +0800 From: Lingyan Wu Subject: [Lemonade]About draft-gulbrandsen-imap-notify-01 To: Curtis King , lemonade@ietf.org Message-id: <00cf01c70899$0e8a9490$3878a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.6 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Lingyan Wu List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0461634460==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============0461634460== Content-type: multipart/alternative; boundary="Boundary_(ID_pLpT9wO+IrQ0YTy3YxWTWQ)" This is a multi-part message in MIME format. --Boundary_(ID_pLpT9wO+IrQ0YTy3YxWTWQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi Curtis King and All, In 5.1.(FlagChange and AnnotationChange) in this draft there is such a sentence: If so, the server sends a STATUS (HIGHESTMODSEQ) response. What about to add some content(in []) to the sentence as follows? If so, the server sends a STATUS (HIGHESTMODSEQ) response [with mailbox, UID and flags]. Reasons: The client could utilize the mailbox, UID and flags in STATUS response to determine which IMAP mailbox the event occurred in, for which message, and what the event is, so that the client could synchronize the flags of the message in client accordingly. Maybe it'll be more convenient to synchronize flags of emails if the STATUS response are extended to contain such informations. Best Regards, Lingyan --Boundary_(ID_pLpT9wO+IrQ0YTy3YxWTWQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi Curtis King and All,
 
In 5.1.(FlagChange and AnnotationChange) in this draft there is such a sentence: If so, the server sends a STATUS (HIGHESTMODSEQ) response.
 
What about to add some content(in []) to the sentence as follows?
If so, the server sends a STATUS (HIGHESTMODSEQ) response [with mailbox, UID and flags].
 
Reasons:
The client could utilize the mailbox, UID and flags in STATUS response to determine which IMAP mailbox the event occurred in, for which message, and what the event is, so that the client could synchronize the flags of the message in client accordingly. Maybe it'll be more convenient to synchronize flags of emails if the STATUS response are extended to contain such informations.

Best Regards,
Lingyan
--Boundary_(ID_pLpT9wO+IrQ0YTy3YxWTWQ)-- --===============0461634460== 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 --===============0461634460==-- From lemonade-bounces@ietf.org Wed Nov 15 05:46:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkIHE-0007MI-Kq; Wed, 15 Nov 2006 05:45:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkIHD-0007M9-31 for lemonade@ietf.org; Wed, 15 Nov 2006 05:45:55 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkIHB-0003Xx-L0 for lemonade@ietf.org; Wed, 15 Nov 2006 05:45:55 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id B38FB4AC78; Wed, 15 Nov 2006 11:45:52 +0100 (CET) Message-Id: Date: Wed, 15 Nov 2006 11:46:31 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [Lemonade]About draft-gulbrandsen-imap-notify-01 References: <00cf01c70899$0e8a9490$3878a40a@china.huawei.com> In-Reply-To: <00cf01c70899$0e8a9490$3878a40a@china.huawei.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Lingyan Wu writes: > Hi Curtis King and All, > > In 5.1.(FlagChange and AnnotationChange) in this draft there is such a > sentence: If so, the server sends a STATUS (HIGHESTMODSEQ) response. > > What about to add some content(in []) to the sentence as follows? If > so, the server sends a STATUS (HIGHESTMODSEQ) response [with mailbox, > UID and flags]. Not using STATUS. STATUS returns information about a mailbox, not about a particular message. This change would very big change to STATUS. It would be possible to send an URLFETCH response containing the information, though. But that would add quite a bit to the bandwidth requirement, and seems unjustified. How big is the chance that the client and will can use this information? Seems small to me, considering that the client doesn't have the mailbox seelcted and that many/most LEMONADE devices will have a smallish cache (<10MB). (In -02 I was going to add some text about how the server can limit the bandwidth requirements, btw.) Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 15 17:37:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkTNC-0007tM-Q0; Wed, 15 Nov 2006 17:36:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkTNB-0007rf-Ug for lemonade@ietf.org; Wed, 15 Nov 2006 17:36:49 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkTNA-0003EF-Jj for lemonade@ietf.org; Wed, 15 Nov 2006 17:36:49 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kAFMaenj017756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 15 Nov 2006 14:36:41 -0800 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.172.15]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kAFMacd4021510; Wed, 15 Nov 2006 14:36:39 -0800 (PST) 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: Wed, 15 Nov 2006 14:36:23 -0800 To: Eric Burger , IETF LEMONADE , Glenn Parsons From: Randall Gellens Subject: Re: [lemonade] WGLC Deployments Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 10:27 PM -0400 10/10/06, Eric Burger wrote: In response to the WGLC comments, I've just sent in -04. Changes: o New boilerplate text o Wording tweaks from lemonade list (e.g., expanding contractions) o Explicitly state that support for TCP is REQUIRED o Correct reference in timeout text from PROFILE to IMAP o Add RFC number to KEYWORDS reference (nit checker doesn't like BCP number only) o Move HOST-REQUIREMENTS reference to normative from informative o Add TCP reference (since TCP support is REQUIRED) o Add IMAP reference (for port number) o Update PROFILE reference to RFC (from RFC Ed pub queue) -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- But, something that only exists in thought is even better, as you can read for yourself in my favorite book of (English) verse and drawings, "The Space-Child's Mother Goose" (Verses by Frederick Winsor, Illustrations by Marian Parry, Simon and Schuster, 1958, unfortunately out of print): I have a pet hen whose name is Probable. She lays eggs in concept, being a sophist bird. But not in reality at all; those would be inferior eggs; for thought is superior to reality. --unknown _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 15 19:22:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkV1L-0003wZ-0V; Wed, 15 Nov 2006 19:22:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkV1J-0003wS-Eb for lemonade@ietf.org; Wed, 15 Nov 2006 19:22:21 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkV1H-0001fJ-1r for lemonade@ietf.org; Wed, 15 Nov 2006 19:22:21 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kAG0ME2Z016347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 15 Nov 2006 16:22:15 -0800 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.172.15]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kAG0MCkI000411; Wed, 15 Nov 2006 16:22:13 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <26359.1162984332.023328@peirce.dave.cridland.net> References: <0FA975F2D8295A448BE3ADC161244657019956D9@esebe199.NOE.Nokia.com> <4551AB62.2030103@pathbreaker.com> <26359.1162984332.023328@peirce.dave.cridland.net> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Wed, 15 Nov 2006 16:17:36 -0800 To: Dave Cridland , Ray Cromwell From: Randall Gellens Subject: Re: [lemonade] WGLC Search Within - Comments Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Enhancements to Internet email to support diverse service enivronments , "Stephane H. Maes" , "Zoltan.Ordogh@nokia.com" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 11:12 AM +0000 11/8/06, Dave Cridland wrote: > I hate to bring this up, but anything other than seconds will have > this problem. Certain minutes have 61 seconds, for example, leading > to certain hours having 3601 seconds. > > Is a client likely to care? No, almost certainly not. I agree. When people are looking for a message, or a client is resynchronizing a subset of a mailbox, the time range is approximate. > I don't see a real problem with having the server be allowed some > leeway in updating these results, either - currently the draft > essentially dictates that servers have to treat an hour as 3600 (or > 3601) seconds accordingly, and doesn't talk about the granularity > of the criteria, merely the granularity of how the criteria can be > specified. Yes. > 1) Paragraph 2 of section 1 implies that YOUNGER and OLDER use an > interval of hours from which a date is calculated, and the use of > the phrase "after the date calculated" could be read to imply that > servers round off to a date, and not a time. Since this code will > exist in a base IMAP server, you might find people quite happy to > take this somewhat literally. So we need some text specifying the criteria that servers use. > > 2) Also, the use of the phrase "[...] depositied in the mailbox > after the date calculated [...]" is in itself problematic, since it > implies that a third date, neither the Date header field nor the > INTERNALDATE, is used for this. Good point. > 4) As a general comment, I'd personally apprciate a new section > inserted between the Introduction (which I generally read expecting > a non-normative summary) and the formal syntax, giving a strictly > worded definition of OLDER and YOUNGER. > > By way of a suggestion: > > 2. Protocol Changes > > For both new search keys, a date and time is calculated by > subtracting the interval on the current date and time of the > server. Servers need not maintain a greater precision than an hour > in this calculation. > > The resultant date and time is then compared against the > INTERNALDATE (as specified in [RFC3501]). For OLDER, messages match > if the date and time is less recent then the INTERNALDATE, for > YOUNGER, messages match if the date and time is more recent then > the INTERNALDATE. If the date and time matches the INTERNALDATE > precisely,the message will be matched by both OLDER and YOUNGER. This text works for me. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- 1. People to whom you are attracted invariably think you remind them of someone else. 2. The love letter you finally got the courage to send will be delayed in the mail long enough for you to make a fool of yourself in person. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 15 19:32:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkVB5-0000CX-Pv; Wed, 15 Nov 2006 19:32:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkVB4-0000CR-U1 for lemonade@ietf.org; Wed, 15 Nov 2006 19:32:26 -0500 Received: from mxout4.cac.washington.edu ([140.142.33.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkVB3-0003Dw-9G for lemonade@ietf.org; Wed, 15 Nov 2006 19:32:26 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout4.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id kAG0WOHs012127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 Nov 2006 16:32:24 -0800 X-Auth-Received: from Shimo-Tomobiki.panda.com (panda.com [206.124.149.114]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id kAG0WM8T027829 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 15 Nov 2006 16:32:23 -0800 Date: Wed, 15 Nov 2006 16:32:20 -0800 From: Mark Crispin To: Randall Gellens Subject: Re: [lemonade] WGLC Search Within - Comments In-Reply-To: Message-ID: References: <0FA975F2D8295A448BE3ADC161244657019956D9@esebe199.NOE.Nokia.com> <4551AB62.2030103@pathbreaker.com> <26359.1162984332.023328@peirce.dave.cridland.net> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.2.285561, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.11.15.161932 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: 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, 15 Nov 2006, Randall Gellens wrote: > I agree. When people are looking for a message, or a client is > resynchronizing a subset of a mailbox, the time range is approximate. Not that it seems to matter in this discussion: I made the decision to have date ranges instead of date/time in IMAP ~20 years ago. My observation at that time was that date was the best granularity that most people could come up with, and even that was often approximate. I've heard the arguments for time granularity and remain unconvinced. All the use cases for time granularity seem to have better ways to solve the problem. But not all battles are worth fighting, and this one was not. There are no particular ill effects either way. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 15 20:13:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkVom-0003zb-6F; Wed, 15 Nov 2006 20:13:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkVok-0003zR-TW for lemonade@ietf.org; Wed, 15 Nov 2006 20:13:26 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkVoi-0000bf-Hs for lemonade@ietf.org; Wed, 15 Nov 2006 20:13:26 -0500 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kAG1DInu021402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 15 Nov 2006 17:13:20 -0800 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.172.15]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kAG1DFbn005896; Wed, 15 Nov 2006 17:13:17 -0800 (PST) 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: Wed, 15 Nov 2006 17:09:49 -0800 To: Eric Burger , IETF LEMONADE From: Randall Gellens Subject: Re: [lemonade] Draft Minutes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 8:49 PM -0500 11/8/06, Eric Burger wrote: > If you want real minutes, we will have to find a real minutes taker... > > http://www3.ietf.org/proceedings/06nov/minutes/lemonade.txt A few comments: > Contents of Profile-bis: Alexey Melnikov proposed adding four items > to Profile-bis, and we discussed those at length, particularly SMTP > compression (again) and SMTP checkpoint/restart. Consensus not to > add either of those, but to add SASL-IR and in-band notifications. My notes say that there was some support for adding SMTP compression and that the chair suggested/decided to defer any decision on this until after the draft was out. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Down with categorical imperative! _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Nov 16 04:55:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkdxI-00041a-Vl; Thu, 16 Nov 2006 04:54:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkdxI-00041O-0E for lemonade@ietf.org; Thu, 16 Nov 2006 04:54:48 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkdxG-0006rN-E0 for lemonade@ietf.org; Thu, 16 Nov 2006 04:54:47 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 4CC2D4ACD2 for ; Thu, 16 Nov 2006 10:54:45 +0100 (CET) Message-Id: Date: Thu, 16 Nov 2006 10:55:28 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Draft Minutes References: In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Randall Gellens X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Randall Gellens writes: > At 8:49 PM -0500 11/8/06, Eric Burger wrote: >> Contents of Profile-bis: Alexey Melnikov proposed adding four items >> to Profile-bis, and we discussed those at length, particularly SMTP >> compression (again) and SMTP checkpoint/restart. Consensus not to >> add either of those, but to add SASL-IR and in-band notifications. > > My notes say that there was some support for adding SMTP compression > and that the chair suggested/decided to defer any decision on this > until after the draft was out. That matches my memory, but if anyone volunteered to write such a draft, I didn't catch who it was. I've updated SASL-IR. It's not in the I-D archive yet, but a draft I submitted an hour earlier is, so it won't be long now. Still working on notify-02. (Something Ray said made me think and sometimes I think slowly ;) Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Nov 16 07:20:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkgEB-0006QL-Rh; Thu, 16 Nov 2006 07:20:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkgEA-0006Q3-MJ for lemonade@ietf.org; Thu, 16 Nov 2006 07:20:22 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkgE5-00019i-3L for lemonade@ietf.org; Thu, 16 Nov 2006 07:20:22 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8T000WVOQ4VF@szxga02-in.huawei.com> for lemonade@ietf.org; Thu, 16 Nov 2006 20:15:41 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8T00BBLOQ47Z@szxga02-in.huawei.com> for lemonade@ietf.org; Thu, 16 Nov 2006 20:15:40 +0800 (CST) Received: from w48795 ([10.164.120.56]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J8T00M9OOQ2A0@szxml03-in.huawei.com> for lemonade@ietf.org; Thu, 16 Nov 2006 20:15:40 +0800 (CST) Date: Thu, 16 Nov 2006 20:15:38 +0800 From: Lingyan Wu Subject: Re: [Lemonade]About draft-gulbrandsen-imap-notify-01 To: lemonade@ietf.org, Arnt Gulbrandsen Message-id: <00b501c70978$ed9d1a10$3878a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=gb2312; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <00cf01c70899$0e8a9490$3878a40a@china.huawei.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Lingyan Wu List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org ----- Original Message ----- From: "Arnt Gulbrandsen" To: Cc: "Curtis King" ; "Lingyan Wu" Sent: Wednesday, November 15, 2006 6:46 PM Subject: Re: [Lemonade]About draft-gulbrandsen-imap-notify-01 > Lingyan Wu writes: >> Hi Curtis King and All, >> >> In 5.1.(FlagChange and AnnotationChange) in this draft there is such a >> sentence: If so, the server sends a STATUS (HIGHESTMODSEQ) response. >> >> What about to add some content(in []) to the sentence as follows? If so, >> the server sends a STATUS (HIGHESTMODSEQ) response [with mailbox, UID and >> flags]. > > Not using STATUS. STATUS returns information about a mailbox, not about a > particular message. This change would very big change to STATUS. [Lingyan]---------------------------------------------------------------- Only adding UID and FLAGS (or MSGEVENT,e.g. ReadMessages) to STATUS response. > > It would be possible to send an URLFETCH response containing the > information, though. [Lingyan]----------------------------------------------------------------- Maybe URLFETCH response couldn't contain FLAGS (or MSGEVENT), because the URL (the fourth form in RFC2192 which refers to a specific message or message part.) refers to the object returned by a "UID FETCH BODY.PEEK[
]" command while the UID FETCH Command doesn't return flags of emails. I think extended STATUS (only adding UID and FLAGS) is more effective for unselected mailbox. It's just like an unsolicited FETCH response containing UID and FLAGS for the selected mailbox. >But that would add quite a bit to the bandwidth requirement, and seems >unjustified. How big is the chance that the client and will can use this >information? [Lingyan]----------------------------------------------------------------- The client could use the FLAGS in the response to update the flags of the corresponding email in client after receiving the response. Through unsolicited FETCH response and STATUS response, all the mailboxes (selected and unselected mailboxes) could be synchronized expediently. I think such a response would not add quite a bit to the bandwidth requirement. > Seems small to me, considering that the client doesn't have the mailbox > seelcted and that many/most LEMONADE devices will have a smallish cache > (<10MB). > > (In -02 I was going to add some text about how the server can limit the > bandwidth requirements, btw.) > > Arnt > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Nov 16 07:50:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkghD-00039E-LF; Thu, 16 Nov 2006 07:50:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkghC-000399-J5 for lemonade@ietf.org; Thu, 16 Nov 2006 07:50:22 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkghA-0005QG-65 for lemonade@ietf.org; Thu, 16 Nov 2006 07:50:22 -0500 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, 16 Nov 2006 12:50:18 +0000 Message-ID: <455C5E81.7020609@isode.com> Date: Thu, 16 Nov 2006 12:50:09 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Randall Gellens Subject: Re: [lemonade] Draft Minutes 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: 7d33c50f3756db14428398e2bdedd581 Cc: IETF LEMONADE X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Randall Gellens wrote: > At 8:49 PM -0500 11/8/06, Eric Burger wrote: > >> If you want real minutes, we will have to find a real minutes taker... >> >> http://www3.ietf.org/proceedings/06nov/minutes/lemonade.txt > > A few comments: > >> Contents of Profile-bis: Alexey Melnikov proposed adding four items >> to Profile-bis, and we discussed those at length, particularly SMTP >> compression (again) and SMTP checkpoint/restart. Consensus not to >> add either of those, but to add SASL-IR and in-band notifications. > > My notes say that there was some support for adding SMTP compression > and that the chair suggested/decided to defer any decision on this > until after the draft was out. I concur. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Nov 16 08:21:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkhBg-0003Zn-Pu; Thu, 16 Nov 2006 08:21:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkhBf-0003SO-2W for lemonade@ietf.org; Thu, 16 Nov 2006 08:21:51 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkhBd-0001F6-ID for lemonade@ietf.org; Thu, 16 Nov 2006 08:21:51 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 4B8314ACD2; Thu, 16 Nov 2006 14:21:46 +0100 (CET) Message-Id: Date: Thu, 16 Nov 2006 14:22:30 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [Lemonade]About draft-gulbrandsen-imap-notify-01 References: <00cf01c70899$0e8a9490$3878a40a@china.huawei.com> <00b501c70978$ed9d1a10$3878a40a@china.huawei.com> In-Reply-To: <00b501c70978$ed9d1a10$3878a40a@china.huawei.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Lingyan Wu writes: > Only adding UID and FLAGS (or MSGEVENT,e.g. ReadMessages) to STATUS response. I meant that it would be big conceptually, because it would extend STATUS to be about messages. > Maybe URLFETCH response couldn't contain FLAGS (or MSGEVENT), because > the URL (the fourth form in RFC2192 which refers to a specific > message or message part.) refers to the object returned by a "UID > FETCH BODY.PEEK[
]" command while the UID FETCH Command > doesn't return flags of emails. You're absolutely correct. > I think extended STATUS (only adding UID and FLAGS) is more effective > for unselected mailbox. It's just like an unsolicited FETCH response > containing UID and FLAGS for the selected mailbox. Except that it's not for a selected mailbox. > The client could use the FLAGS in the response to update the flags of > the corresponding email in client after receiving the response. > Through unsolicited FETCH response and STATUS response, all the > mailboxes (selected and unselected mailboxes) could be synchronized > expediently. Assuming the message is in the client's cache, yes it would, but what's the benefit of that expedient update? If the client wants to use that mailbox, it will select the mailbox and run the resync algorithm anyway. > I think such a response would not add quite a bit to the bandwidth > requirement. That depends on the number of flag changes in unselected mailboxes, which is unbounded. I presume none of us want our mobile phone to receive 50-100 bytes every time we read a message on our desktops (and thus cause a flag change). That's the gentle case. It's much worse for shared mailboxes. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Nov 16 12:36:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkl9f-000346-Jz; Thu, 16 Nov 2006 12:36:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkl3L-0000yq-6Z for lemonade@ietf.org; Thu, 16 Nov 2006 12:29:31 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkkyS-0001TH-4o for lemonade@ietf.org; Thu, 16 Nov 2006 12:24:29 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kAGHOPc0032063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 16 Nov 2006 09:24:26 -0800 Received: from [[192.168.1.13]] (vpn-10-50-16-137.qualcomm.com [10.50.16.137]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kAGHOMtm020453; Thu, 16 Nov 2006 09:24:24 -0800 (PST) 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: Thu, 16 Nov 2006 09:21:12 -0800 To: Arnt Gulbrandsen , lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] Draft Minutes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Randall Gellens X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 10:55 AM +0100 11/16/06, Arnt Gulbrandsen wrote: > Randall Gellens writes: >> At 8:49 PM -0500 11/8/06, Eric Burger wrote: >>> Contents of Profile-bis: Alexey Melnikov proposed adding four >>> items to Profile-bis, and we discussed those at length, >>> particularly SMTP compression (again) and SMTP >>> checkpoint/restart. Consensus not to add either of those, but >>> to add SASL-IR and in-band notifications. >> >> My notes say that there was some support for adding SMTP >> compression and that the chair suggested/decided to defer any >> decision on this until after the draft was out. > > That matches my memory, but if anyone volunteered to write such a > draft, I didn't catch who it was. It was I :-) -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- To iterate is human; to recurse, divine. --Robert Heller _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Nov 16 15:23:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gknla-0000iJ-90; Thu, 16 Nov 2006 15:23:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GknlZ-0000iB-Ma for lemonade@ietf.org; Thu, 16 Nov 2006 15:23:21 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GknlY-0007Iu-AS for lemonade@ietf.org; Thu, 16 Nov 2006 15:23:21 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id E35284ACBB; Thu, 16 Nov 2006 21:23:14 +0100 (CET) Message-Id: Date: Thu, 16 Nov 2006 21:24:00 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Draft Minutes Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Randall Gellens X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Randall Gellens writes: > At 10:55 AM +0100 11/16/06, Arnt Gulbrandsen wrote: >> That matches my memory, but if anyone volunteered to write such a >> draft, I didn't catch who it was. > > It was I :-) Have fun. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Nov 16 15:50:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkoBx-0004pI-KN; Thu, 16 Nov 2006 15:50:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkoBs-0004oP-VW; Thu, 16 Nov 2006 15:50:32 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkoBs-0003vc-TM; Thu, 16 Nov 2006 15:50:32 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GkoBs-00060k-K4; Thu, 16 Nov 2006 15:50:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 53C541759C; Thu, 16 Nov 2006 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GkoBN-0001Dg-Tw; Thu, 16 Nov 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 16 Nov 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-deployments-04.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to Support Diverse Service Environments Working Group of the IETF. Title : Deployment Considerations for lemonade-compliant Mobile Email Author(s) : R. Gellens Filename : draft-ietf-lemonade-deployments-04.txt Pages : 11 Date : 2006-11-16 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-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-deployments-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-deployments-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-11-16104822.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-deployments-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-deployments-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-16104822.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --NextPart-- From lemonade-bounces@ietf.org Thu Nov 16 15:55:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkoGt-0007Uz-9f; Thu, 16 Nov 2006 15:55:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkoGr-0007Ug-EM for lemonade@ietf.org; Thu, 16 Nov 2006 15:55:41 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkoGp-0004cj-3w for lemonade@ietf.org; Thu, 16 Nov 2006 15:55:41 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kAGKtaUY019869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 16 Nov 2006 12:55:37 -0800 Received: from [[10.70.6.60]] (vpn-10-50-0-44.qualcomm.com [10.50.0.44]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kAGKtYJQ012599; Thu, 16 Nov 2006 12:55:36 -0800 (PST) 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: Thu, 16 Nov 2006 12:49:16 -0800 To: Arnt Gulbrandsen , lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] Draft Minutes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 9:24 PM +0100 11/16/06, Arnt Gulbrandsen wrote: > Randall Gellens writes: >> At 10:55 AM +0100 11/16/06, Arnt Gulbrandsen wrote: >>> That matches my memory, but if anyone volunteered to write such a >>> draft, I didn't catch who it was. >> >> It was I :-) > > Have fun. Tony Finch is the actual author, I'm just the editor stuckee to resolve open issues, handle administrivia, etc. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- If there's a possibility that something might be controversial, then why not eliminate it? --Wild Rose, Wis. district administrator, explaining why _Bury My Heart at Wounded Knee_ by Dee Brown was removed from schools. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Nov 16 21:58:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gktvo-0003tq-O2; Thu, 16 Nov 2006 21:58:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gktvn-0003rJ-Be for lemonade@ietf.org; Thu, 16 Nov 2006 21:58:19 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gktvk-0000PP-Vv for lemonade@ietf.org; Thu, 16 Nov 2006 21:58:19 -0500 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 kAH2w9tg026992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 16 Nov 2006 18:58:09 -0800 Received: from [[192.168.1.13]] (vpn-10-50-0-108.qualcomm.com [10.50.0.108]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kAH2w0a8004871; Thu, 16 Nov 2006 18:58:08 -0800 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: Thu, 16 Nov 2006 18:51:20 -0800 To: Tony Finch , lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] checkpoint/resume, rfc1845bis Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 we've come to expect, another well-written draft from Tony. Thanks for taking this on. I do have a few comments, though: In Section 2.4, under BURL, it says "The SHALL count the size of the content retrieved from the URL parameter to the BURL command." It might be difficult or at least prone to error for clients to have to calculate the exact offset of the final message data after BURL expansion. Since the client isn't sending the data referenced by the BURL, I'm not sure of the benefit of including it. It might be easier to say that the size includes the BURL itself (the reference) but not the data retrieved in response. That way, if the client sends a BURL command and the connection drops before it sees the server's response, it will be clear on reconnection that the client doesn't need to send any data. Typo in Section 3.2: "trandaction" instead of "transaction". Typo in Section 3.3: parenthesized text starting "(using BDAT" has no close parenthesis. (Second sub-bullet in first bullet.) It occurs to me that there are weird potential edge cases where the response to a RCPT TO might be different when the message is resumed as when it was originally sent (assuming the server didn't receive the entire message and thus hasn't delivered it). For example, if the recipient is local and there was a configuration problem with it, or it was over quota, the server might have issued a 4yz or 5yz code originally, but if the problem has since been cleared up, might be able to issue a 2yz when resumed. But it is required to honor the original response. In the case of a previous failed recipient, this is annoying. In the case of a previous success recipient that now must be failed, the server must accept it and then generate a bounce. This is of course no different in RFrom lemonade-bounces@ietf.org Thu Nov 16 21:58:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gktvo-0003tq-O2; Thu, 16 Nov 2006 21:58:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gktvn-0003rJ-Be for lemonade@ietf.org; Thu, 16 Nov 2006 21:58:19 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gktvk-0000PP-Vv for lemonade@ietf.org; Thu, 16 Nov 2006 21:58:19 -0500 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 kAH2w9tg026992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 16 Nov 2006 18:58:09 -0800 Received: from [[192.168.1.13]] (vpn-10-50-0-108.qualcomm.com [10.50.0.108]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kAH2w0a8004871; Thu, 16 Nov 2006 18:58:08 -0800 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: Thu, 16 Nov 2006 18:51:20 -0800 To: Tony Finch , lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] checkpoint/resume, rfc1845bis Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 we've come to expect, another well-written draft from Tony. Thanks for taking this on. I do have a few comments, though: In Section 2.4, under BURL, it says "The SHALL count the size of the content retrieved from the URL parameter to the BURL command." It might be difficult or at least prone to error for clients to have to calculate the exact offset of the final message data after BURL expansion. Since the client isn't sending the data referenced by the BURL, I'm not sure of the benefit of including it. It might be easier to say that the size includes the BURL itself (the reference) but not the data retrieved in response. That way, if the client sends a BURL command and the connection drops before it sees the server's response, it will be clear on reconnection that the client doesn't need to send any data. Typo in Section 3.2: "trandaction" instead of "transaction". Typo in Section 3.3: parenthesized text starting "(using BDAT" has no close parenthesis. (Second sub-bullet in first bullet.) It occurs to me that there are weird potential edge cases where the response to a RCPT TO might be different when the message is resumed as when it was originally sent (assuming the server didn't receive the entire message and thus hasn't delivered it). For example, if the recipient is local and there was a configuration problem with it, or it was over quota, the server might have issued a 4yz or 5yz code originally, but if the problem has since been cleared up, might be able to issue a 2yz when resumed. But it is required to honor the original response. In the case of a previous failed recipient, this is annoying. In the case of a previous success recipient that now must be failed, the server must accept it and then generate a bounce. This is of course no different in RFC 1845, and perhaps is such an edge case that it isn't worth worrying about. But if the client does resend the RCPT TO commands, perhaps the server could be permitted to send updated responses? Presumably both the client and server have held the message in abeyance in the meantime, so both can act on the final results. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- When news of Alexander Graham Bell's invention reached the United Kingdom, the chief engineer of the British Post Office failed to be impressed. "The Americans," he said loftily, "have need of the telephone -- but we do not. We have plenty of messenger boys..." _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Nov 16 21:58:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gktvg-0003p0-Is; Thu, 16 Nov 2006 21:58:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gktve-0003kw-8Y for lemonade@ietf.org; Thu, 16 Nov 2006 21:58:10 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gktvc-0000Oo-Ua for lemonade@ietf.org; Thu, 16 Nov 2006 21:58:10 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kAH2w4jg030106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 16 Nov 2006 18:58:04 -0800 Received: from [[192.168.1.13]] (vpn-10-50-0-108.qualcomm.com [10.50.0.108]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kAH2w0a6004871; Thu, 16 Nov 2006 18:58:02 -0800 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: Thu, 16 Nov 2006 18:55:10 -0800 To: Eric Burger , IETF LEMONADE From: Randall Gellens Subject: Re: [lemonade] Draft Minutes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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 My recollection of the EXPUNGED discussion included consensus to use VANISHED for both the response name and specifier. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- There's nothing wrong with me. Maybe there's something wrong with the universe. --'Dr. Beverly Crusher' in ST:TNG _Remember Me_. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade FC 1845, and perhaps is such an edge case that it isn't worth worrying about. But if the client does resend the RCPT TO commands, perhaps the server could be permitted to send updated responses? Presumably both the client and server have held the message in abeyance in the meantime, so both can act on the final results. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- When news of Alexander Graham Bell's invention reached the United Kingdom, the chief engineer of the British Post Office failed to be impressed. "The Americans," he said loftily, "have need of the telephone -- but we do not. We have plenty of messenger boys..." _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Nov 16 21:58:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gktvg-0003p0-Is; Thu, 16 Nov 2006 21:58:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gktve-0003kw-8Y for lemonade@ietf.org; Thu, 16 Nov 2006 21:58:10 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gktvc-0000Oo-Ua for lemonade@ietf.org; Thu, 16 Nov 2006 21:58:10 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kAH2w4jg030106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 16 Nov 2006 18:58:04 -0800 Received: from [[192.168.1.13]] (vpn-10-50-0-108.qualcomm.com [10.50.0.108]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kAH2w0a6004871; Thu, 16 Nov 2006 18:58:02 -0800 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: Thu, 16 Nov 2006 18:55:10 -0800 To: Eric Burger , IETF LEMONADE From: Randall Gellens Subject: Re: [lemonade] Draft Minutes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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 My recollection of the EXPUNGED discussion included consensus to use VANISHED for both the response name and specifier. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- There's nothing wrong with me. Maybe there's something wrong with the universe. --'Dr. Beverly Crusher' in ST:TNG _Remember Me_. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Nov 16 22:31:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkuSD-0001TP-ST; Thu, 16 Nov 2006 22:31:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkuSC-0001TI-E0 for lemonade@ietf.org; Thu, 16 Nov 2006 22:31:48 -0500 Received: from outbound.cantata.com ([208.236.123.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkuSB-0004GC-6n for lemonade@ietf.org; Thu, 16 Nov 2006 22:31:48 -0500 Received: from ma02exchtmp01.Cantata.com ([10.128.18.41]) by outbound.Cantata.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 22:31:41 -0500 Received: from 10.128.16.242 ([10.128.16.242]) by ma02exchtmp01.Cantata.com ([10.128.18.41]) with Microsoft Exchange Server HTTP-DAV ; Fri, 17 Nov 2006 03:31:40 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Thu, 16 Nov 2006 22:31:39 -0500 Subject: Re: [lemonade] Draft Minutes From: Eric Burger To: Randall Gellens , IETF LEMONADE Message-ID: Thread-Topic: [lemonade] Draft Minutes Thread-Index: AccJ9Deh+09ZsNmJRlajRRc3UYXdTAABKyqN In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 17 Nov 2006 03:31:41.0879 (UTC) FILETIME=[E6022C70:01C709F8] X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1995672154==" Errors-To: lemonade-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1995672154== Content-type: multipart/alternative; boundary="B_3246561099_1166644" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3246561099_1166644 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Wasn=B9t that in IMAPEXT? On 11/16/06 9:55 PM, "Randall Gellens" wrote: > My recollection of the EXPUNGED discussion included consensus to use > VANISHED for both the response name and specifier. > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly-selected tag: --------------- > There's nothing wrong with me. Maybe there's something wrong with > the universe. --'Dr. Beverly Crusher' in ST:TNG _Remember Me_. >=20 --B_3246561099_1166644 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [lemonade] Draft Minutes Wasn&= #8217;t that in IMAPEXT?


On 11/16/06 9:55 PM, "Randall Gellens" <randy@qualcomm.com>= wrote:

My recollection of the EXPUNGED discussion included con= sensus to use
VANISHED for both the response name and specifier.
--
Randall Gellens
Opinions are personal;    facts are suspect;   &nb= sp;I speak for myself only
-------------- Randomly-selected tag: ---------------
There's nothing wrong with me.  Maybe there's something wrong with
the universe.       --'Dr. Beverly Crusher' i= n ST:TNG _Remember Me_.


 --B_3246561099_1166644-- --===============1995672154== 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 --===============1995672154==-- From lemonade-bounces@ietf.org Thu Nov 16 23:11:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkv4T-0004mJ-64; Thu, 16 Nov 2006 23:11:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkv4R-0004mD-UH for lemonade@ietf.org; Thu, 16 Nov 2006 23:11:19 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkv4Q-0000o3-KU for lemonade@ietf.org; Thu, 16 Nov 2006 23:11:19 -0500 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 kAH4BCsi032483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 16 Nov 2006 20:11:13 -0800 Received: from [[192.168.1.13]] (vpn-10-50-0-108.qualcomm.com [10.50.0.108]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kAH4BB9O018365; Thu, 16 Nov 2006 20:11:11 -0800 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: Thu, 16 Nov 2006 20:11:06 -0800 To: Eric Burger , IETF LEMONADE From: Randall Gellens Subject: Re: [lemonade] Draft Minutes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 10:31 PM -0500 11/16/06, Eric Burger wrote: > Wasn't that in IMAPEXT? Yes, sorry, brain fade. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- The attention span of a computer is only as long as its electrical cord. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Nov 16 23:25:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkvIF-0002SI-P1; Thu, 16 Nov 2006 23:25:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkvIF-0002SC-6A for lemonade@ietf.org; Thu, 16 Nov 2006 23:25:35 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkvI1-0002Lj-QZ for lemonade@ietf.org; Thu, 16 Nov 2006 23:25:35 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8U00MB8X77UX@szxga02-in.huawei.com> for lemonade@ietf.org; Fri, 17 Nov 2006 12:16:20 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8U00F17X77ZM@szxga02-in.huawei.com> for lemonade@ietf.org; Fri, 17 Nov 2006 12:16:19 +0800 (CST) Received: from w48795 ([10.164.120.56]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J8U00H2AX76AB@szxml04-in.huawei.com> for lemonade@ietf.org; Fri, 17 Nov 2006 12:16:19 +0800 (CST) Date: Fri, 17 Nov 2006 12:16:18 +0800 From: Lingyan Wu Subject: Re: [Lemonade]About draft-gulbrandsen-imap-notify-01 To: lemonade@ietf.org, Arnt Gulbrandsen Message-id: <010b01c709ff$21690670$3878a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=gb2312; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <00cf01c70899$0e8a9490$3878a40a@china.huawei.com> <00b501c70978$ed9d1a10$3878a40a@china.huawei.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Lingyan Wu List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org ----- Original Message ----- From: "Arnt Gulbrandsen" To: Cc: "Curtis King" ; "Lingyan Wu" ; "Alexey Melnikov" Sent: Thursday, November 16, 2006 9:22 PM Subject: Re: [Lemonade]About draft-gulbrandsen-imap-notify-01 > Lingyan Wu writes: >> Only adding UID and FLAGS (or MSGEVENT,e.g. ReadMessages) to STATUS >> response. > > I meant that it would be big conceptually, because it would extend STATUS > to be about messages. > >> Maybe URLFETCH response couldn't contain FLAGS (or MSGEVENT), because the >> URL (the fourth form in RFC2192 which refers to a specific message or >> message part.) refers to the object returned by a "UID FETCH >> BODY.PEEK[
]" command while the UID FETCH Command doesn't return >> flags of emails. > > You're absolutely correct. > >> I think extended STATUS (only adding UID and FLAGS) is more effective for >> unselected mailbox. It's just like an unsolicited FETCH response >> containing UID and FLAGS for the selected mailbox. > > Except that it's not for a selected mailbox. > >> The client could use the FLAGS in the response to update the flags of the >> corresponding email in client after receiving the response. Through >> unsolicited FETCH response and STATUS response, all the mailboxes >> (selected and unselected mailboxes) could be synchronized expediently. > > Assuming the message is in the client's cache, yes it would, Almost all of the emails in the client's cache are the emails passing the filters (related with the client) in the server, and only the emails in the client's cache (passing filters) need to be synchronized, so we could synchronize all of the filtered emails in selected and unselected mailboxes through unsolicited FETCH response and STATUS response. >but what's the benefit of that expedient update? If the client wants to use >that mailbox, it will select the mailbox and run the resync algorithm >anyway. The benefit is to furthest keep the consistent flags of emails between the client and server. When the client create a session with INBOX to do some operations, the server could take the chance to send the changed flags of filtered emails in other mailboxes through the extended STATUS response so that all of the emails in the client's catch could keep latest flags. When the user accesses his emails in the disconnected client he could know the latest flags of the emails and could do some operations accordingly if filtered emails in selected and unselected mailboxes could be synchronized. > >> I think such a response would not add quite a bit to the bandwidth >> requirement. > > That depends on the number of flag changes in unselected mailboxes, which > is unbounded. I presume none of us want our mobile phone to receive 50-100 > bytes every time we read a message on our desktops (and thus cause a flag > change). That's the gentle case. It's much worse for shared mailboxes. > > Arnt > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Nov 17 06:50:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl2EJ-00065Q-3b; Fri, 17 Nov 2006 06:49:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl2EI-00065H-0f for lemonade@ietf.org; Fri, 17 Nov 2006 06:49:58 -0500 Received: from ppsw-7.csi.cam.ac.uk ([131.111.8.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl2EC-0005Fl-KU for lemonade@ietf.org; Fri, 17 Nov 2006 06:49:58 -0500 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]:37550) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1Gl2Av-0006vm-Oj (Exim 4.63) (return-path ); Fri, 17 Nov 2006 11:46:29 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Gl2Av-0001zL-Je (Exim 4.54) (return-path ); Fri, 17 Nov 2006 11:46:29 +0000 Date: Fri, 17 Nov 2006 11:46:29 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Randall Gellens Subject: Re: [lemonade] checkpoint/resume, rfc1845bis 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: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Tony Finch , lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu, 16 Nov 2006, Randall Gellens wrote: > Thanks for looking through the draft! I've fixed the typos you spotted. > In Section 2.4, under BURL, it says "The SHALL count the size > of the content retrieved from the URL parameter to the BURL command." It > might be difficult or at least prone to error for clients to have to calculate > the exact offset of the final message data after BURL expansion. Since the > client isn't sending the data referenced by the BURL, I'm not sure of the > benefit of including it. > > It might be easier to say that the size includes the BURL itself (the > reference) but not the data retrieved in response. That way, if the client > sends a BURL command and the connection drops before it sees the server's > response, it will be clear on reconnection that the client doesn't need to > send any data. Yes, this is an awkward design point. The alternative I considered was to count a BURL as one octet, and your idea of counting the URL's length would work equally well. However in 1845 the octet-offset nicely matches the semantics of the SIZE parameter, and I wanted to preserve this. The BURL spec isn't crystal clear about the client's use of SIZE, but since it says that servers must apply SIZE checks (including the retrieved content of the URL) during the SMTP transaction it would make sense for the same to apply to the client. > It occurs to me that there are weird potential edge cases where the response > to a RCPT TO might be different when the message is resumed as when it was > originally sent (assuming the server didn't receive the entire message and > thus hasn't delivered it). I decided that it would be too complicated to allow servers to change their minds about their replies, especially because clients do not have to re-send the corresponding commands (and cannot when using 1845 compatibility mode). If servers could change their minds then a client implementation could not be based on simply freezing and restarting the SMTP state machine. What if a client gets a 550 response to a subset of the recipients originally, bounces the message immediately, then gets a 250 response after resuming the rest of the transaction? If the server insists on changing its mind then it can still 450 after the message data and force the client to retry later. This can be useful for changes from OK to bad if you're really worried about unnecessary bounces from the server. I'm assuming that you will want the RESUME turn-around to be brief, so you will be unlucky for significant changes in server state to happen in that time. Tony. -- f.a.n.finch http://dotat.at/ TYNE DOGGER: SOUTH VEERING SOUTHWEST 5 TO 7, INCREASING GALE 8 OR SEVERE GALE 9 FOR A TIME. MODERATE OR ROUGH, OCCASIONALLY VERY ROUGH IN DOGGER. RAIN OR SHOWERS. MODERATE OR GOOD. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Nov 17 12:11:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl7Ej-0003yz-KH; Fri, 17 Nov 2006 12:10:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl7Ei-0003xY-3H for lemonade@ietf.org; Fri, 17 Nov 2006 12:10:44 -0500 Received: from mta02.zimbra.com ([4.78.240.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl7Ed-0006Ah-QY for lemonade@ietf.org; Fri, 17 Nov 2006 12:10:44 -0500 Received: from dogfood.zimbra.com (dogfood.liquidsys.com [66.92.25.198]) by mta02.zimbra.com (Postfix) with ESMTP id 75EAD810C41; Fri, 17 Nov 2006 09:05:23 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id B3A56C6D43; Fri, 17 Nov 2006 09:10:26 -0800 (PST) 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 lcjNyHmzF-dK; Fri, 17 Nov 2006 09:10:25 -0800 (PST) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id E3A99C6D42; Fri, 17 Nov 2006 09:10:25 -0800 (PST) Message-ID: <37839288.71631163783425682.JavaMail.root@dogfood.zimbra.com> Date: Fri, 17 Nov 2006 09:10:25 -0800 (PST) From: Dan Karp To: Randall Gellens Subject: Re: [lemonade] WGLC Search Within - Comments In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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 > > 2) Also, the use of the phrase "[...] depositied in the mailbox > > after the date calculated [...]" is in itself problematic, since it > > implies that a third date, neither the Date header field nor the > > INTERNALDATE, is used for this. > > Good point. Would it be reasonable to use INTERNALDATE for the OLDER/YOUNGER calculation instead? The cost of the overhead of an extra indexed date per message would probably outweigh the benefit of the WITHIN extension for me. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Nov 17 15:49:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlAe3-0008He-1k; Fri, 17 Nov 2006 15:49:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlAe1-0008HX-NU for lemonade@ietf.org; Fri, 17 Nov 2006 15:49:05 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlAe0-0001yf-1H for lemonade@ietf.org; Fri, 17 Nov 2006 15:49:05 -0500 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kAHKn158009413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 17 Nov 2006 12:49:02 -0800 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.172.15]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kAHKmw0q018046; Fri, 17 Nov 2006 12:48:59 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <45585BFB.4080501@isode.com> References: <0FA975F2D8295A448BE3ADC16124465701995647@esebe199.NOE.Nokia.com> <45585BFB.4080501@isode.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Fri, 17 Nov 2006 12:45:02 -0800 To: Alexey Melnikov From: Randall Gellens Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-04.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: 52e1467c2184c31006318542db5614d5 Cc: lemonade@ietf.org, Zoltan.Ordogh@nokia.com, stephane.maes@oracle.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 3:50 AM -0800 11/13/06, Alexey Melnikov wrote: > Randall Gellens wrote: > >> When opening a connection to the submission server, clients MUST >> do so using port 587 unless explicitly configured to use a >> different port. If the TCP connection to the submission server >> fails to open using port 587, the client MAY then immediately >> retry using a different port, such as 25. See [Submit] for >> information on why using port 25 is likely to fail depending on >> the current location of the client, and may result in a failure >> code during the SMTP transaction. > > I like your text and added it to my copy of the document. But what > is "may result in a failure code during the SMTP transaction"? > Should we just say "may result in a failure of the SMTP > transaction"? "likely to fail depending on the current location of the client" is a reference to port 25 blocking and other modern differences in port 25 behavior depending on the current IP address of the client. Especially with mobile clients, this is a big concern. "may result in a failure code during the SMTP transaction" means the same as "a failure of the SMTP transaction" but was an attempt to be more specific as to how it would fail. But I'm fine with using your phrase. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- They say that 90 per cent of TV is junk. But 90 per cent of *everything* is junk. --Gene Roddenberry, interview in TV Guide, Apr. 27, 1974 (quoting Sturgeon's Revelation: "Ninety percent of everything is crap.") _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Nov 17 15:52:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlAh4-0000Sh-DF; Fri, 17 Nov 2006 15:52:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlAh3-0000Sc-KD for lemonade@ietf.org; Fri, 17 Nov 2006 15:52:13 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlAh2-0002Wr-8q for lemonade@ietf.org; Fri, 17 Nov 2006 15:52:13 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kAHKq4CW009774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 17 Nov 2006 12:52:05 -0800 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.172.15]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kAHKq2fL031522; Fri, 17 Nov 2006 12:52:03 -0800 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: Fri, 17 Nov 2006 12:49:18 -0800 To: Arnt Gulbrandsen , lemonade@ietf.org, Eric Burger From: Randall Gellens Subject: Re: [lemonade] Draft Minutes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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, another brain fade (confusing two drafts in the rush of trying to complete a lot of stuff before I leave for vacation): I volunteered to be the editor stuckee for SMTP quickstart, not SMTP compression. I hope Arnt is willing to do the SMTP compression draft as well as the IMAP compression draft. At 9:21 AM -0800 11/16/06, Randall Gellens wrote: > At 10:55 AM +0100 11/16/06, Arnt Gulbrandsen wrote: > >> Randall Gellens writes: >>> At 8:49 PM -0500 11/8/06, Eric Burger wrote: >>>> Contents of Profile-bis: Alexey Melnikov proposed adding ... >>>> ...snip... >> That matches my memory, but if anyone volunteered to write such a >> draft, I didn't catch who it was. > > It was I :-) At 9:24 PM +0100 11/16/06, Arnt Gulbrandsen wrote: > Randall Gellens writes: >> At 10:55 AM +0100 11/16/06, Arnt Gulbrandsen wrote: >>> That matches my memory, but if anyone volunteered to write such a >>> draft, I didn't catch who it was. >> >> It was I :-) > > Have fun. > > Arnt > Tony Finch is the actual author, I'm just the editor stuckee to > resolve open issues, handle administrivia, etc. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Programs that crash have been proven to be less useful than those that don't. --Apple Technical Note OV04 (formerly Technote #117) developer.apple.com/technotes/ov/ov_04.html _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Nov 17 16:02:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlAqs-000539-1f; Fri, 17 Nov 2006 16:02:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlAqn-0004xm-0J for lemonade@ietf.org; Fri, 17 Nov 2006 16:02:17 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlAnk-0003cE-13 for lemonade@ietf.org; Fri, 17 Nov 2006 15:59:09 -0500 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kAHKwwjq010567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 17 Nov 2006 12:59:00 -0800 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.172.15]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kAHKwqT7021193; Fri, 17 Nov 2006 12:58:57 -0800 (PST) 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: Fri, 17 Nov 2006 12:58:44 -0800 To: Tony Finch From: Randall Gellens Subject: Re: [lemonade] checkpoint/resume, rfc1845bis 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: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 11:46 AM +0000 11/17/06, Tony Finch wrote: > On Thu, 16 Nov 2006, Randall Gellens wrote: >> > > Thanks for looking through the draft! I've fixed the typos you spotted. > >> In Section 2.4, under BURL, it says "The SHALL count the size >> of the content retrieved from the URL parameter to the BURL command." It >> might be difficult or at least prone to error for clients to have >> to calculate >> the exact offset of the final message data after BURL expansion. Since the >> client isn't sending the data referenced by the BURL, I'm not sure of the >> benefit of including it. >> >> It might be easier to say that the size includes the BURL itself (the >> reference) but not the data retrieved in response. That way, if the client >> sends a BURL command and the connection drops before it sees the server's >> response, it will be clear on reconnection that the client doesn't need to >> send any data. > > Yes, this is an awkward design point. The alternative I considered was to > count a BURL as one octet, and your idea of counting the URL's length > would work equally well. However in 1845 the octet-offset nicely matches > the semantics of the SIZE parameter, and I wanted to preserve this. The > BURL spec isn't crystal clear about the client's use of SIZE, but since it > says that servers must apply SIZE checks (including the retrieved content > of the URL) during the SMTP transaction it would make sense for the same > to apply to the client. But the profile document allows clients to be a little sloppy in their size calculation, saying that they must send a size at least as large as the actual size after expansion. So a client can do a rough calculation, add a bit for slop, and send that. In such a case it would be difficult for the client to know how to resume. Likely the only time a client that used BURL would need to resume a message is if it lost the connection before seeing the result, and so wouldn't be sending any data anyway. But I'm concerned that we have an ugly and potentially difficult or confusing area in the specification. > > It occurs to me that there are weird potential edge cases where > the response >> to a RCPT TO might be different when the message is resumed as when it was >> originally sent (assuming the server didn't receive the entire message and >> thus hasn't delivered it). > > I decided that it would be too complicated to allow servers to change > their minds about their replies, especially because clients do not have to > re-send the corresponding commands (and cannot when using 1845 > compatibility mode). If servers could change their minds then a client > implementation could not be based on simply freezing and restarting the > SMTP state machine. What if a client gets a 550 response to a subset of > the recipients originally, bounces the message immediately, then gets a > 250 response after resuming the rest of the transaction? It may be more likely for message submission clients to abort the transaction if any recipient fails (permanent or temporary), while a message relay client is likely to continue with the other recipients, and retry any that were temp-failed. > If the server > insists on changing its mind then it can still 450 after the message data > and force the client to retry later. This can be useful for changes from > OK to bad if you're really worried about unnecessary bounces from the > server. True, and perhaps we should mention this for cases where the server discovers during resumption (to its presumed shock and horror) that it is unable to deliver to previously OK recipients. > I'm assuming that you will want the RESUME turn-around to be brief, so > you will be unlucky for significant changes in server state to happen in > that time. Also true. And I'm Ok with this being a case of being very unlucky so too bad. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- One's need for loneliness is not satisfied if one sits at a table alone. There must be empty chairs as well. --Karl Kraus _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Nov 17 16:53:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlBeA-0004IQ-GQ; Fri, 17 Nov 2006 16:53:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlBe8-0004IJ-Ui for lemonade@ietf.org; Fri, 17 Nov 2006 16:53:16 -0500 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlBe4-0004Aj-CF for lemonade@ietf.org; Fri, 17 Nov 2006 16:53:16 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.50) id 1GlBdy-00029m-Li; Fri, 17 Nov 2006 21:53:06 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 03ABD498005; Fri, 17 Nov 2006 22:05:07 +0000 (GMT) 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 30539-04; Fri, 17 Nov 2006 22:05:01 +0000 (GMT) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id F2525498003; Fri, 17 Nov 2006 22:05:00 +0000 (GMT) Date: Fri, 17 Nov 2006 21:52:59 +0000 Subject: Re: [lemonade] checkpoint/resume, rfc1845bis References: In-Reply-To: MIME-Version: 1.0 Message-Id: <27142.1163800380.340439@peirce.dave.cridland.net> From: Dave Cridland To: Randall Gellens , Tony Finch Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Pythagoras-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Fri Nov 17 20:58:44 2006, Randall Gellens wrote: > But the profile document allows clients to be a little sloppy in > their size calculation, saying that they must send a size at least > as large as the actual size after expansion. So a client can do a > rough calculation, add a bit for slop, and send that. In such a > case it would be difficult for the client to know how to resume. > > Clients can usually not avoid having the size of a BURL chunk. In particular, for sending a leaf body part, they'll have the information in the BODYSTRUCTURE, which they have to have to know there *is* a leaf node to send. For complete messages, they'll have to have requested RFC822.SIZE, unless they happened to APPEND the message themselves *and* did not use IMAP BINARY to do so. I can't recall if they'll be able to find the size for non-leaf body parts, however. > Likely the only time a client that used BURL would need to resume a > message is if it lost the connection before seeing the result, and > so wouldn't be sending any data anyway. But I'm concerned that we > have an ugly and potentially difficult or confusing area in the > specification. > > Another hiccup - clients will likely often have to resend BURL chunks with a different URL than they originally used, if they're using EXPIRES (which they should be) and they lost the connection for more than a few minutes. But... Clients will, I suspect, resend a message using detirministic patterns of BDAT/BURL/DATA. Given a message they're trying to send, they will use the same pattern of commands to send it. The exception being if the capabilities are changed such that the pattern is changed, but I suspect that's pretty rare, especially with a resumed transaction. If the offsets for RESUME where specified as command number and (optional?) offset, then we might side-step the issue quite neatly. So RESUME would say something like "I remember up to the fourth command's fiftieth octet". Then the client looks at what it was trying to send, and it can presumably detirmine which the fourth command would have been, and go from there. If the fourth command was a BURL, then it would be able to assume that the fiftieth octet was at the end, and start with its original fifth command. This doesn't prevent a client from resuming using a different pattern, of course, although I can't see that's likely. It must, however, be able to detirmine what the pattern it would have originally used is. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Nov 17 17:46:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlCTG-0002y9-Lf; Fri, 17 Nov 2006 17:46:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlCTF-0002xx-Cn for lemonade@ietf.org; Fri, 17 Nov 2006 17:46:05 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlCTD-0004cd-11 for lemonade@ietf.org; Fri, 17 Nov 2006 17:46:05 -0500 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kAHMk1wX027343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 17 Nov 2006 14:46:02 -0800 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.172.15]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kAHMjuiV029428; Fri, 17 Nov 2006 14:46:00 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <37839288.71631163783425682.JavaMail.root@dogfood.zimbra.com> References: <37839288.71631163783425682.JavaMail.root@dogfood.zimbra.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Fri, 17 Nov 2006 14:40:22 -0800 To: Dan Karp From: Randall Gellens Subject: Re: [lemonade] WGLC Search Within - Comments Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: 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 9:10 AM -0800 11/17/06, Dan Karp wrote: > > > 2) Also, the use of the phrase "[...] depositied in the mailbox >> > after the date calculated [...]" is in itself problematic, since it >> > implies that a third date, neither the Date header field nor the >> > INTERNALDATE, is used for this. >> >> Good point. > > Would it be reasonable to use INTERNALDATE for the OLDER/YOUNGER > calculation instead? The cost of the overhead of an extra indexed > date per message would probably outweigh the benefit of the WITHIN > extension for me. I think Dave was pointing out that the current wording "deposited..." was problematic, and suggested being explicit about using INTERNALDATE. I don't think anyone intended to create a third date field. At 11:12 AM +0000 11/8/06, Dave Cridland wrote: > By way of a suggestion: > > 2. Protocol Changes > > For both new search keys, a date and time is calculated by > subtracting the interval on the current date and time of the > server. Servers need not maintain a greater precision than an hour > in this calculation. > > The resultant date and time is then compared against the > INTERNALDATE (as specified in [RFC3501]). For OLDER, messages match > if the date and time is less recent then the INTERNALDATE, for > YOUNGER, messages match if the date and time is more recent then > the INTERNALDATE. If the date and time matches the INTERNALDATE > precisely,the message will be matched by both OLDER and YOUNGER. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- ondinnonk (ON-din-onk; Iroquoian; noun): the soul's innermost benevolent desires. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Nov 17 21:57:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlGOL-0008N5-1O; Fri, 17 Nov 2006 21:57:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlGOK-0008N0-DP for lemonade@ietf.org; Fri, 17 Nov 2006 21:57:16 -0500 Received: from ppsw-2.csi.cam.ac.uk ([131.111.8.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlGOF-0004i0-Vx for lemonade@ietf.org; Fri, 17 Nov 2006 21:57:16 -0500 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]:44481) by ppsw-2.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.152]:25) with esmtpa (EXTERNAL:fanf2) id 1GlGOA-0000tj-7j (Exim 4.63) (return-path ); Sat, 18 Nov 2006 02:57:06 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1GlGOA-0003Kw-B8 (Exim 4.54) (return-path ); Sat, 18 Nov 2006 02:57:06 +0000 Date: Sat, 18 Nov 2006 02:57:06 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Dave Cridland Subject: Re: [lemonade] checkpoint/resume, rfc1845bis In-Reply-To: <27142.1163800380.340439@peirce.dave.cridland.net> Message-ID: References: <27142.1163800380.340439@peirce.dave.cridland.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Randall Gellens , Tony Finch , Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Fri, 17 Nov 2006, Dave Cridland wrote: > On Fri Nov 17 20:58:44 2006, Randall Gellens wrote: This SIZE discussion is exactly what the draft needs... > > But the profile document allows clients to be a little sloppy in their size > > calculation, saying that they must send a size at least as large as the > > actual size after expansion. Right, which is why I'm open to alternatives. > Clients can usually not avoid having the size of a BURL chunk. And I hoped this would be the case (not being familiar with the details of BURL). > Another hiccup - clients will likely often have to resend BURL chunks with a > different URL than they originally used, if they're using EXPIRES (which they > should be) and they lost the connection for more than a few minutes. That implies that they might have to redo the GENURLAUTH depending on the server's response to RESUME, which is a bit fiddly. I don't think it demands any changes to the protocol, though. I'm not sure if it's worth explaining this - I've tried to minimise the amount of rationale and other chit-chat to keep the spec short. > If the offsets for RESUME where specified as command number and (optional?) > offset, then we might side-step the issue quite neatly. Hmm, yes that is reasonably neat. It does mean that chunking clients have to keep more information about how they have chunked the message data (though perhaps it'll be the same for all messages from a given client) and it isn't really 1845bis. PS I have made some more updates to http://www-uxsup.csx.cam.ac.uk/~fanf2/hermes/doc/qsmtp/draft-fanf-lemonade-rfc1845bis.html Tony. -- f.a.n.finch http://dotat.at/ HEBRIDES BAILEY: NORTHWEST BECOMING CYCLONIC THEN SOUTHWEST 6 TO GALE 8, OCCASIONALLY SEVERE GALE 9 IN BAILEY. ROUGH OR VERY ROUGH. WINTRY SHOWERS. MAINLY GOOD. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Nov 18 05:15:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlNDv-0006l6-O5; Sat, 18 Nov 2006 05:14:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlNDu-0006kx-AZ for lemonade@ietf.org; Sat, 18 Nov 2006 05:14:58 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlNDs-00026H-Qy for lemonade@ietf.org; Sat, 18 Nov 2006 05:14:58 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 8C5C44AD05; Sat, 18 Nov 2006 11:14:45 +0100 (CET) Message-Id: Date: Sat, 18 Nov 2006 11:15:39 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Draft Minutes References: In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Randall Gellens X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Randall Gellens writes: > Sorry, another brain fade (confusing two drafts in the rush of trying > to complete a lot of stuff before I leave for vacation): Have a good vacation, then ;) > I hope Arnt is willing to do the SMTP compression draft as well as the > IMAP compression draft. I am, on three conditions: 1. Noone else is. 2. It's clear that the draft only goes to RFC if there's WG consensus to. 3. I don't do a -00 until some of my (five!) Lemonade-related drafts are a little further along. I'm not sure whether I've written about this on the list, or only in private email, but I'd better make it clear. I believe that SMTP compression is not worth doing in Lemonade, because the win is too small to justify a stopgap solution. The benefit of SMTP compression is O(n*(b+t+a)), where n is the number of messages sent, b is the size of the boilerplate (RCPT TO, Message-ID, etc), t is the size of what the user types and a is the size of whatever bodyparts are appended, if any. My intuition says that for lemonade devices, a is almost zero (due to FwD, the lack of persistent storage and bandwidth), n is somewhat smaller than for desktops (due to the difficulty of typing), and t is much smaller (typing again - "Sorry if terse"). Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Nov 18 05:37:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlNZa-000752-Me; Sat, 18 Nov 2006 05:37:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlNZa-00074x-2U for lemonade@ietf.org; Sat, 18 Nov 2006 05:37:22 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlNZY-0004qm-Hs for lemonade@ietf.org; Sat, 18 Nov 2006 05:37:22 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 9B6084ACF2; Sat, 18 Nov 2006 11:37:19 +0100 (CET) Message-Id: Date: Sat, 18 Nov 2006 11:38:13 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [Lemonade]About draft-gulbrandsen-imap-notify-01 References: <00cf01c70899$0e8a9490$3878a40a@china.huawei.com> <00b501c70978$ed9d1a10$3878a40a@china.huawei.com> <010b01c709ff$21690670$3878a40a@china.huawei.com> In-Reply-To: <010b01c709ff$21690670$3878a40a@china.huawei.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Lingyan Wu writes: >>> The client could use the FLAGS in the response to update the flags >>> of the corresponding email in client after receiving the response. >>> Through unsolicited FETCH response and STATUS response, all the >>> mailboxes (selected and unselected mailboxes) could be synchronized >>> expediently. >> >> Assuming the message is in the client's cache, yes it would, > > Almost all of the emails in the client's cache are the emails passing > the filters (related with the client) in the server, and only the > emails in the client's cache (passing filters) need to be > synchronized, so we could synchronize all of the filtered emails in > selected and unselected mailboxes through unsolicited FETCH response > and STATUS response. Not quite. We can only synchronize those which are modified while the client has an IMAP connection to the server. And the cost of synchronizing those is that we also send updates for all messages which are NOT in the client's cache. >> but what's the benefit of that expedient update? If the client wants >> to use that mailbox, it will select the mailbox and run the resync >> algorithm anyway. > > The benefit is to furthest keep the consistent flags of emails between > the client and server. That would be desirable, but it cannot really work, since the client is not connected all the time. > When the client create a session with INBOX to do some operations, the > server could take the chance to send the changed flags of filtered > emails in other mailboxes through the extended STATUS response so > that all of the emails in the client's catch could keep latest flags. Wouldn't that duplicate the functionality of CONDSTORE and quick resynchronization? Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Nov 18 16:19:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlXap-00082X-S3; Sat, 18 Nov 2006 16:19:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlXap-00082S-Ee for lemonade@ietf.org; Sat, 18 Nov 2006 16:19:19 -0500 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlXam-0000qN-Eg for lemonade@ietf.org; Sat, 18 Nov 2006 16:19:18 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.50) id 1GlXal-0004uy-Aw; Sat, 18 Nov 2006 21:19:15 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id AB36C498005; Sat, 18 Nov 2006 21:31:25 +0000 (GMT) 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 12055-07; Sat, 18 Nov 2006 21:31:13 +0000 (GMT) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 280A4498003; Sat, 18 Nov 2006 21:31:13 +0000 (GMT) Date: Sat, 18 Nov 2006 21:19:01 +0000 Subject: Re: [lemonade] WGLC Search Within - Comments References: <37839288.71631163783425682.JavaMail.root@dogfood.zimbra.com> In-Reply-To: MIME-Version: 1.0 Message-Id: <27142.1163884742.609586@peirce.dave.cridland.net> From: Dave Cridland To: Randall Gellens Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Pythagoras-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Fri Nov 17 22:40:22 2006, Randall Gellens wrote: > At 9:10 AM -0800 11/17/06, Dan Karp wrote: > >> > > 2) Also, the use of the phrase "[...] depositied in the >> mailbox >>> > after the date calculated [...]" is in itself problematic, >>> since it >>> > implies that a third date, neither the Date header field nor >>> the >>> > INTERNALDATE, is used for this. >>> >>> Good point. >> >> Would it be reasonable to use INTERNALDATE for the OLDER/YOUNGER >> calculation instead? The cost of the overhead of an extra indexed >> date per message would probably outweigh the benefit of the WITHIN >> extension for me. > > I think Dave was pointing out that the current wording > "deposited..." was problematic, and suggested being explicit about > using INTERNALDATE. I don't think anyone intended to create a > third date field. I want more dates! More, I tell you, more! No, seriously, I was indeed suggesting that the document refers explicitly to INTERNALDATE, which is by default the date the message was deposited in the mailbox, but can be specified explicitly on APPEND, and carries over on a COPY. So I'm pretty sure Ray meant INTERNALDATE, and hence I included that in the text I sketched out rather more explicitly. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Nov 18 16:27:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlXir-0002yf-Db; Sat, 18 Nov 2006 16:27:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlXiq-0002yZ-3o for lemonade@ietf.org; Sat, 18 Nov 2006 16:27:36 -0500 Received: from mta02.zimbra.com ([4.78.240.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlXio-0002de-OF for lemonade@ietf.org; Sat, 18 Nov 2006 16:27:36 -0500 Received: from dogfood.zimbra.com (dogfood.liquidsys.com [66.92.25.198]) by mta02.zimbra.com (Postfix) with ESMTP id 01147810C80 for ; Sat, 18 Nov 2006 13:22:30 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id DFAECC6D43 for ; Sat, 18 Nov 2006 13:27:33 -0800 (PST) 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 jJy2R8tw2pf0 for ; Sat, 18 Nov 2006 13:27:33 -0800 (PST) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 30CB4C6D42 for ; Sat, 18 Nov 2006 13:27:33 -0800 (PST) Message-ID: <1448864112.94201163885252860.JavaMail.root@dogfood.zimbra.com> Date: Sat, 18 Nov 2006 13:27:32 -0800 (PST) From: Dan Karp To: Enhancements to Internet email to support diverse service enivronments In-Reply-To: <1671906145.90681163836548485.JavaMail.root@dogfood.zimbra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [lemonade] VFOLDER and mutable fields/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 I've been reading the most recent VFOLDER draft, and it looks pretty good. By making the VFOLDER explicitly a view onto another folder, the message UIDs line up and so a VFOLDER-capable client can correlate (and hence not re-download) messages in the VFOLDER with messages in the backing folder. Unfortunately, this breaks down somewhat when the VFOLDER search-program involves WITHIN and/or dynamic message attributes. The draft states If a server does support search on dynamic attributes, the possibility arises that a message may be included in a vfolder, excluded, and then included again. When this happens, the server MUST generate a new UID each time, and this implies that the order of messages in a vfolder need not match the underlying order of the backing mailbox. VFOLDER aware clients may wish to try and detect this case and prevent duplicate downloads. This issue can even arise just using WITHIN-based searches -- for example, "OR OLDER 5 YOUNGER 3" or even "OR OLDER 5 SUBJECT Lemonade". The MUST in the draft requires either that VFOLDER UIDs diverge from backing folder UIDs (not good) or that backing folder UIDs need to change as well (just plain undesirable due to the effect on other clients). And I really don't see how the client could "detect this case" and correlate the new-UID message with the appropriate old-UID message in the backing mailbox. Would it make sense to change the draft such that the contents of a VFOLDER are set at SELECT time? That way the server isn't responsible for aging messages in/out due to WITHIN criteria and it doesn't have to keep adding and removing (and renumbering) messages if the VFOLDER criteria reference mutable message attributes. Messages added to the underlying mailbox (via COPY, APPEND, or external delivery) would be evaluated when they were inserted into the mailbox and either included or excluded from the VFOLDER at that time. If the client wanted to refresh the VFOLDER, it could be as simple as issuing a new SELECT on the VFOLDER. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Nov 18 17:08:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlYMF-0007h0-Ak; Sat, 18 Nov 2006 17:08:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlYME-0007gY-Ec for lemonade@ietf.org; Sat, 18 Nov 2006 17:08:18 -0500 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlYMB-0007bQ-Vu for lemonade@ietf.org; Sat, 18 Nov 2006 17:08:18 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.50) id 1GlYLu-0001E0-U4; Sat, 18 Nov 2006 22:07:59 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 73395498007; Sat, 18 Nov 2006 22:20:07 +0000 (GMT) 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 12875-02; Sat, 18 Nov 2006 22:19:57 +0000 (GMT) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 6C023498006; Sat, 18 Nov 2006 22:19:57 +0000 (GMT) Date: Sat, 18 Nov 2006 22:07:45 +0000 Subject: Re: [lemonade] VFOLDER and mutable fields/WITHIN References: <1448864112.94201163885252860.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <1448864112.94201163885252860.JavaMail.root@dogfood.zimbra.com> MIME-Version: 1.0 Message-Id: <27142.1163887666.538598@peirce.dave.cridland.net> From: Dave Cridland To: Dan Karp Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Pythagoras-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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 Sat Nov 18 21:27:32 2006, Dan Karp wrote: > I've been reading the most recent VFOLDER draft, and it looks > pretty good. By making the VFOLDER explicitly a view onto another > folder, the message UIDs line up and so a VFOLDER-capable client > can correlate (and hence not re-download) messages in the VFOLDER > with messages in the backing folder. > > As you say, this is only in the case where a virtual mailbox is defined using purely static criteria, or, as per your suggestion, we "fix" dynamic criteria to be static - and even in this latter case I'm unclear if we could rely on UIDs being the same, since UIDs must strictly increase - you can't UNEXPUNGE, even when the client isn't looking. As a client author, I want dynamic virtual folders which back onto multiple mailboxes. As a server developer, I shudder at the mere thought. For single mailbox backed virtual folders, I can emulate it fairly closely using a series of SEARCH commands, plus local evaluation of criteria based on update information, but they'd still be better handled server-side if possible. Singly backed virtual mailboxes are also somewhat easier on the server developer. But then I look at how my client uses this capability, and I note two things: 1) My client has two forms of viewing filter, essentially. The first is predefined filters, stored in ACAP as IMAP SEARCH program text. The one I use more than any other is "UNDELETED UNKEYWORD $Junk UNSEEN", which is of course dynamic. The second form is ad-hoc, and these are usually based on static data for me (typically FROM or SUBJECT searches). 2) I don't use these on one mailbox exclusively - they're not tied to that. Instead, I use these on whichever mailbox I'm reading. Typically, I'll use my Unread filter when catching up email, for instance, whichever folder I'm catching up on. These two factors suggested to me that what we need, in fact, is a dynamically updated SEARCH, or in the parlance of ACAP, a "Context". (ACAP allows you to save the results of a search as a named context, and optionally have these dynamically updated.) Hence draft-cridland-imap-context-00 In this proposal, searches may be made to be dynamically updated - the server doesn't add or remove messages from a mailbox, instead it adds and removes results from a SEARCH. This means that UIDs stay constant, and because no SELECT takes place at all, the client is never in danger of double-download. As a bonus, the general design works with SORT (but not THREAD). There are several other factors in its favour too, but mostly minor. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Nov 18 19:04:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlaAO-0006BH-Oj; Sat, 18 Nov 2006 19:04:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlaAO-0006BC-EE for lemonade@ietf.org; Sat, 18 Nov 2006 19:04:12 -0500 Received: from mta02.zimbra.com ([4.78.240.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlaAN-0006TN-1X for lemonade@ietf.org; Sat, 18 Nov 2006 19:04:12 -0500 Received: from dogfood.zimbra.com (dogfood.liquidsys.com [66.92.25.198]) by mta02.zimbra.com (Postfix) with ESMTP id 49CC0810C80; Sat, 18 Nov 2006 15:59:06 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 41EBCC6D45; Sat, 18 Nov 2006 16:04:10 -0800 (PST) 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 dbsMDrT9evru; Sat, 18 Nov 2006 16:04:09 -0800 (PST) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 1C41EC6D47; Sat, 18 Nov 2006 16:04:09 -0800 (PST) Message-ID: <674166018.95391163894648889.JavaMail.root@dogfood.zimbra.com> Date: Sat, 18 Nov 2006 16:04:08 -0800 (PST) From: Dan Karp To: Dave Cridland Subject: Re: [lemonade] VFOLDER and mutable fields/WITHIN In-Reply-To: <27142.1163887666.538598@peirce.dave.cridland.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) 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 > > I've been reading the most recent VFOLDER draft, and it looks > > pretty good. By making the VFOLDER explicitly a view onto another > > folder, the message UIDs line up and so a VFOLDER-capable client > > can correlate (and hence not re-download) messages in the VFOLDER > > with messages in the backing folder. > > As you say, this is only in the case where a virtual mailbox is > defined using purely static criteria, or, as per your suggestion, we > "fix" dynamic criteria to be static - and even in this latter case > I'm unclear if we could rely on UIDs being the same, since UIDs must > strictly increase - you can't UNEXPUNGE, even when the client isn't > looking. Well, there are ways around that. If the client is VFOLDER-aware and does something like C: A005 SELECT (VFOLDER) "unread msgs" S: * LIST (\Subscribed) "/" "unread msgs" (VFOLDER (INBOX "UNSEEN")) S: * OK [UIDVALIDITY 3857529045] new uidvalidity each time vfolder is selected S: ... you can change the UIDVALIDITY each time the VFOLDER is SELECTed, as the client knows about the backing store folder. (You'd want to send along an LIST-EXTENDED-style unsolicited response to make absolutely sure the client knows.) Or you could simply not return a UIDNEXT value on the VFOLDER and effectively do an "UNEXPUNGE" while the client's not looking. Clients are built defensively enough that introducing a new message whose UID isn't the highest in the mailbox will still work. (It's my secret shame -- trust me on this.) You'd still be abiding by the defining rule for UIDs: A 32-bit value assigned to each message, which when used with the unique identifier validity value (see below) forms a 64-bit value that MUST NOT refer to any other message in the mailbox or any subsequent mailbox with the same name forever. > As a client author, I want dynamic virtual folders which back onto > multiple mailboxes. As a server developer, I shudder at the mere > thought. For us, IMAP is a secondary view onto our mailstore. Our internal search *defaults* to applying to all folders owned by the user (except Trash, its subfolders, and Junk), and I'm racking my brain trying to figure out how to shoehorn that into any of the pending VFOLDER-like drafts. And if you think draft-melnikov-imapext-multimailbox-search-01 or something like it has a chance to become reality, I'm not the only one who's going to have to do some shoehoring. > Hence draft-cridland-imap-context-00 > > In this proposal, searches may be made to be dynamically updated - > the server doesn't add or remove messages from a mailbox, instead it > adds and removes results from a SEARCH. This means that UIDs stay > constant, and because no SELECT takes place at all, the client is > never in danger of double-download. This definitely solves some of the problems, but I'm not convinced it's significantly better than the client just doing a SEARCH and then using notifications to manage the results client-side. But I'm definitely open to convincing. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 19 06:38:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glkzy-0000HX-Fr; Sun, 19 Nov 2006 06:38:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glkzx-0000HS-J5 for lemonade@ietf.org; Sun, 19 Nov 2006 06:38:09 -0500 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Glkzw-0004dB-3g for lemonade@ietf.org; Sun, 19 Nov 2006 06:38:09 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1Glkzp-00021c-QF; Sun, 19 Nov 2006 11:38:02 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 3E69F498006; Sun, 19 Nov 2006 11:50:18 +0000 (GMT) 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 27867-07; Sun, 19 Nov 2006 11:50:11 +0000 (GMT) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 859DB498003; Sun, 19 Nov 2006 11:50:11 +0000 (GMT) Date: Sun, 19 Nov 2006 11:37:53 +0000 Subject: Re: [lemonade] VFOLDER and mutable fields/WITHIN References: <674166018.95391163894648889.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <674166018.95391163894648889.JavaMail.root@dogfood.zimbra.com> MIME-Version: 1.0 Message-Id: <27142.1163936274.930628@peirce.dave.cridland.net> From: Dave Cridland To: Dan Karp Content-Type: text/plain; charset="iso-8859-1"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net Content-Transfer-Encoding: quoted-printable X-Originating-Rutherford-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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 Sun Nov 19 00:04:08 2006, Dan Karp wrote: > > > I've been reading the most recent VFOLDER draft, and it looks >=20 > > pretty good. By making the VFOLDER explicitly a view onto=20 > another > > folder, the message UIDs line up and so a=20 > VFOLDER-capable client > > can correlate (and hence not=20 > re-download) messages in the VFOLDER > > with messages in the=20 > backing folder. > > > As you say, this is only in the case where a virtual mailbox is=20 > > defined using purely static criteria, or, as per your suggestion,=20 > we > "fix" dynamic criteria to be static - and even in this latter=20 > case > I'm unclear if we could rely on UIDs being the same, since=20 > UIDs must > strictly increase - you can't UNEXPUNGE, even when the=20 > client isn't > looking. >=20 > Well, there are ways around that. If the client is VFOLDER-aware=20 > and does something like >=20 > C: A005 SELECT (VFOLDER) "unread msgs" > S: * LIST (\Subscribed) "/" "unread msgs" (VFOLDER (INBOX=20 > "UNSEEN")) > S: * OK [UIDVALIDITY 3857529045] new uidvalidity each time=20 > vfolder is selected > S: ... >=20 > you can change the UIDVALIDITY each time the VFOLDER is SELECTed,=20 > as the client knows about the backing store folder. (You'd want to=20 > send along an LIST-EXTENDED-style unsolicited response to make=20 > absolutely sure the client knows.) >=20 >=20 Well... In fact, I think current proposals prevent selection of=20 virtual mailboxes by na=EFve clients anyway. (Which is their main=20 advantage, IMHO, removed). > Or you could simply not return a UIDNEXT value on the VFOLDER and=20 > effectively do an "UNEXPUNGE" while the client's not looking. =20 > Clients are built defensively enough that introducing a new message=20 > whose UID isn't the highest in the mailbox will still work. (It's=20 > my secret shame -- trust me on this.) You'd still be abiding by=20 > the defining rule for UIDs: >=20 > A 32-bit value assigned to each message, which when used with the > unique identifier validity value (see below) forms a 64-bit value > that MUST NOT refer to any other message in the mailbox or any > subsequent mailbox with the same name forever. >=20 >=20 But then you're going be to breaking the mailbox semantics. (And=20 trust me, there are clients for which reintroducing UIDs will break=20 them. I believe my client is not the only one.) Removing UIDNEXT=20 *and* removing strictly increasing UIDs is just a pain. If you're going to break mailbox semantics, you might as well do away=20 with them entirely. > > Hence draft-cridland-imap-context-00 > > > In this proposal, searches may be made to be dynamically=20 > updated - > the server doesn't add or remove messages from a=20 > mailbox, instead it > adds and removes results from a SEARCH. This=20 > means that UIDs stay > constant, and because no SELECT takes place=20 > at all, the client is > never in danger of double-download. >=20 > This definitely solves some of the problems, but I'm not convinced=20 > it's significantly better than the client just doing a SEARCH and=20 > then using notifications to manage the results client-side. But=20 > I'm definitely open to convincing. Well, it's better in as much as it's a hell of a lot easier to do,=20 and it can be used with SORT, which client-side emulation can't.=20 Also, there's quite some difficulty with trying to manage this=20 without doing a SEARCH command per notification - in many cases, the=20 client simply doesn't have sufficient data, which introduces=20 additional round-trips *and* additional transmission data. Dave. --=20 Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 19 07:43:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glm0m-0004Sv-7q; Sun, 19 Nov 2006 07:43:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glm0k-0004Sp-Ik for lemonade@ietf.org; Sun, 19 Nov 2006 07:43:02 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Glm0j-0001O5-3i for lemonade@ietf.org; Sun, 19 Nov 2006 07:43:02 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id C17E14ACF1; Sun, 19 Nov 2006 13:42:46 +0100 (CET) Message-Id: <5NXr3/VqfG/Xyn++ly2xxQ.md5@libertango.oryx.com> Date: Sun, 19 Nov 2006 13:43:46 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] VFOLDER and mutable fields/WITHIN References: <674166018.95391163894648889.JavaMail.root@dogfood.zimbra.com> <27142.1163936274.930628@peirce.dave.cridland.net> In-Reply-To: <27142.1163936274.930628@peirce.dave.cridland.net> Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dave Cridland writes: > Well... In fact, I think current proposals prevent selection of > virtual mailboxes by na=EFve clients anyway. How so? >> Or you could simply not return a UIDNEXT value on the VFOLDER and >> effectively do an "UNEXPUNGE" while the client's not looking. >> Clients are built defensively enough that introducing a new message >> whose UID isn't the highest in the mailbox will still work. (It's >> my secret shame -- trust me on this.) You'd still be abiding by the >> defining rule for UIDs: >> >> A 32-bit value assigned to each message, which when used with the >> unique identifier validity value (see below) forms a 64-bit value >> that MUST NOT refer to any other message in the mailbox or any >> subsequent mailbox with the same name forever. > > But then you're going be to breaking the mailbox semantics. (And trust > me, there are clients for which reintroducing UIDs will break them. I > believe my client is not the only one.) I suspect (without concrete evidence) this might be the case for many users of c-client. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 19 08:33:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlmnS-0004eQ-Hq; Sun, 19 Nov 2006 08:33:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlmnQ-0004dh-TF for lemonade@ietf.org; Sun, 19 Nov 2006 08:33:20 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlmnP-0005Y1-02 for lemonade@ietf.org; Sun, 19 Nov 2006 08:33:20 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 192584ACD9; Sun, 19 Nov 2006 14:33:18 +0100 (CET) Message-Id: Date: Sun, 19 Nov 2006 14:34:17 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] VFOLDER and mutable fields/WITHIN References: <1448864112.94201163885252860.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <1448864112.94201163885252860.JavaMail.root@dogfood.zimbra.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 Dan Karp writes: > I've been reading the most recent VFOLDER draft, and it looks pretty > good. By making the VFOLDER explicitly a view onto another folder, > the message UIDs line up and so a VFOLDER-capable client can > correlate (and hence not re-download) messages in the VFOLDER with > messages in the backing folder. The experience I have with this is that people hate it when the client redownloads, and they also dislike reading both the vfolder and the backing mailbox. If you try to solve the first problem on its own, you're optimising for a case people don't want. You're optimising for minimal traffic from server to client and disregarding the traffic from screen to eye. What people mostly want is to see the rest of the messages from the backing folder, ie. all those which aren't in a specific vfolder. My suggested solution to that is a new search key, INVFOLDER. (I made a concrete suggestion for that about five months ago, not sure if I cc'd the list.) > Would it make sense to change the draft such that the contents of a > VFOLDER are set at SELECT time? And add a sentence like this in draft-*-vfolder: "Clients SHOULD send an UNSELECT/SELECT pair every two minutes if they want to be informed of updates"? > That way the server isn't responsible for aging messages in/out due to > WITHIN criteria and it doesn't have to keep adding and removing (and > renumbering) messages if the VFOLDER criteria reference mutable > message attributes. No, but it gets to do the same work in the guise of SELECT, UNSELECT, SELECT, UNSELECT, SELECT, UNSELECT (repeat ad infinitum). Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 19 12:54:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlqsS-0003Tn-WA; Sun, 19 Nov 2006 12:54:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlqsR-0003T1-Ph for lemonade@ietf.org; Sun, 19 Nov 2006 12:54:47 -0500 Received: from mta02.zimbra.com ([4.78.240.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlqsP-0003NQ-GU for lemonade@ietf.org; Sun, 19 Nov 2006 12:54:47 -0500 Received: from dogfood.zimbra.com (dogfood.liquidsys.com [66.92.25.198]) by mta02.zimbra.com (Postfix) with ESMTP id 33158810C80; Sun, 19 Nov 2006 09:49:27 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 939DAC6D43; Sun, 19 Nov 2006 09:54:31 -0800 (PST) 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 J6dEEwE-urrY; Sun, 19 Nov 2006 09:54:31 -0800 (PST) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 0636CC6D42; Sun, 19 Nov 2006 09:54:31 -0800 (PST) Message-ID: <542546395.98261163958870883.JavaMail.root@dogfood.zimbra.com> Date: Sun, 19 Nov 2006 09:54:30 -0800 (PST) From: Dan Karp To: Arnt Gulbrandsen Subject: Re: [lemonade] VFOLDER and mutable fields/WITHIN In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > > Would it make sense to change the draft such that the contents of a > > VFOLDER are set at SELECT time? > > And add a sentence like this in draft-*-vfolder: "Clients SHOULD send > an UNSELECT/SELECT pair every two minutes if they want to be informed > of updates"? Well, the client would be informed of updates to messages that were in the VFOLDER at SELECT time, and could assumedly figure out if a message had left the VFOLDER, if that's what you want. But I really think it's better to have the view remain static for the period of the SELECT -- can you imagine having a VFOLDER (INBOX "UNSEEN"), doing a FETCH BODY[] on a message, and getting an immediate EXPUNGE because the implicit STORE +FLAGS \DELETED had disqualified the message from inclusion in the VFOLDER? > > That way the server isn't responsible for aging messages in/out due > > to WITHIN criteria and it doesn't have to keep adding and removing > > (and renumbering) messages if the VFOLDER criteria reference > > mutable message attributes. > > No, but it gets to do the same work in the guise of SELECT, UNSELECT, > SELECT, UNSELECT, SELECT, UNSELECT (repeat ad infinitum). You could do this with SELECT, SELECT, SELECT as well, I think. But this way, the client doesn't have to keep redownloading the messages, right? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 19 13:11:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glr7u-0000hs-BK; Sun, 19 Nov 2006 13:10:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glr7t-0000hm-1m for lemonade@ietf.org; Sun, 19 Nov 2006 13:10:45 -0500 Received: from mta02.zimbra.com ([4.78.240.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Glr7r-0006YF-Po for lemonade@ietf.org; Sun, 19 Nov 2006 13:10:45 -0500 Received: from dogfood.zimbra.com (dogfood.liquidsys.com [66.92.25.198]) by mta02.zimbra.com (Postfix) with ESMTP id D0229810C85; Sun, 19 Nov 2006 10:05:38 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 3424DC6D44; Sun, 19 Nov 2006 10:10:43 -0800 (PST) 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 zL6i8TZ48gBs; Sun, 19 Nov 2006 10:10:42 -0800 (PST) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 34F9BC6D42; Sun, 19 Nov 2006 10:10:42 -0800 (PST) Message-ID: <1292308939.98351163959841919.JavaMail.root@dogfood.zimbra.com> Date: Sun, 19 Nov 2006 10:10:41 -0800 (PST) From: Dan Karp To: Arnt Gulbrandsen Subject: Re: [lemonade] VFOLDER and mutable fields/WITHIN In-Reply-To: <542546395.98261163958870883.JavaMail.root@dogfood.zimbra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed 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 > But I really think it's better to have the view remain static for the > period of the SELECT -- can you imagine having a VFOLDER (INBOX > "UNSEEN"), doing a FETCH BODY[] on a message, and getting an immediate > EXPUNGE because the implicit STORE +FLAGS \DELETED had disqualified > the message from inclusion in the VFOLDER? Crud. That should read "implicit STORE +FLAGS \SEEN". That's what I get for replying to mail before my morning coffee . _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 19 13:27:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlrO8-0005bf-Vt; Sun, 19 Nov 2006 13:27:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlrO7-0005bX-UN for lemonade@ietf.org; Sun, 19 Nov 2006 13:27:31 -0500 Received: from mxout4.cac.washington.edu ([140.142.33.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlrO3-0000pE-JW for lemonade@ietf.org; Sun, 19 Nov 2006 13:27:31 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139] (may be forged)) by mxout4.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id kAJIRPd9011684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 19 Nov 2006 10:27:25 -0800 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id kAJIRFo1014360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 19 Nov 2006 10:27:24 -0800 Date: Sun, 19 Nov 2006 10:27:14 -0800 (PST) From: Mark Crispin To: Dave Cridland Subject: Re: [lemonade] VFOLDER and mutable fields/WITHIN In-Reply-To: <27142.1163936274.930628@peirce.dave.cridland.net> Message-ID: References: <674166018.95391163894648889.JavaMail.root@dogfood.zimbra.com> <27142.1163936274.930628@peirce.dave.cridland.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.2.285561, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.11.19.101432 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: 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 Sun, 19 Nov 2006, Dave Cridland wrote: > On Sun Nov 19 00:04:08 2006, Dan Karp wrote: >> Or you could simply not return a UIDNEXT value on the VFOLDER and >> effectively do an "UNEXPUNGE" while the client's not looking. Clients are >> built defensively enough that introducing a new message whose UID isn't the >> highest in the mailbox will still work. (It's my secret shame -- trust me >> on this.) Any server that does this is broken. Completely, utterly, broken. I am highly offended by the idea that it is is "alright" for a server to do this because some clients may overlook this egregious violation of UID semantics. > But then you're going be to breaking the mailbox semantics. (And trust me, > there are clients for which reintroducing UIDs will break them. I believe my > client is not the only one.) Removing UIDNEXT *and* removing strictly > increasing UIDs is just a pain. > > If you're going to break mailbox semantics, you might as well do away with > them entirely. Dave is completely, absolutely, 100% correct on this. If a developer does not like IMAP's UID semantics, that developer needs to get out of the IMAP business and spawn a new competing protocol. The corrollary is that if one chooses to be in the IMAP business, then one MUST comply with the requirements of IMAP and not warp (or disregard) those requirements that prove to be inconvenient for a particular implementation. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 19 13:43:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlrdO-0003mO-6P; Sun, 19 Nov 2006 13:43:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlrdM-0003mF-Bi for lemonade@ietf.org; Sun, 19 Nov 2006 13:43:16 -0500 Received: from mta02.zimbra.com ([4.78.240.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlrdL-0003ii-37 for lemonade@ietf.org; Sun, 19 Nov 2006 13:43:16 -0500 Received: from dogfood.zimbra.com (dogfood.liquidsys.com [66.92.25.198]) by mta02.zimbra.com (Postfix) with ESMTP id 0574D810C81; Sun, 19 Nov 2006 10:38:06 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 65CFAC6D43; Sun, 19 Nov 2006 10:43:10 -0800 (PST) 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 GGQdhRf8gnH6; Sun, 19 Nov 2006 10:43:09 -0800 (PST) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id BDD83C6D42; Sun, 19 Nov 2006 10:43:09 -0800 (PST) Message-ID: <187383916.98631163961789641.JavaMail.root@dogfood.zimbra.com> Date: Sun, 19 Nov 2006 10:43:09 -0800 (PST) From: Dan Karp To: Mark Crispin Subject: Re: [lemonade] VFOLDER and mutable fields/WITHIN In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org "Mark Crispin" wrote: > > On Sun Nov 19 00:04:08 2006, Dan Karp wrote: > >> Or you could simply not return a UIDNEXT value on the VFOLDER and > >> effectively do an "UNEXPUNGE" while the client's not looking. > >> Clients are built defensively enough that introducing a new message > >> whose UID isn't the highest in the mailbox will still work. (It's > >> my secret shame -- trust me on this.) > > Any server that does this is broken. Completely, utterly, broken. > > I am highly offended by the idea that it is is "alright" for a server > to do this because some clients may overlook this egregious violation > of UID semantics. Mark, the hyperbole is unnecessary. I was only being half-serious about it. But you're still right, it's a bad idea. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 19 13:46:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glrg2-0004Ch-FS; Sun, 19 Nov 2006 13:46:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glrg1-0004Cc-GY for lemonade@ietf.org; Sun, 19 Nov 2006 13:46:01 -0500 Received: from mta02.zimbra.com ([4.78.240.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Glrfy-0003sZ-NX for lemonade@ietf.org; Sun, 19 Nov 2006 13:46:01 -0500 Received: from dogfood.zimbra.com (dogfood.liquidsys.com [66.92.25.198]) by mta02.zimbra.com (Postfix) with ESMTP id CF9EF810C81; Sun, 19 Nov 2006 10:40:53 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 3961DC6D43; Sun, 19 Nov 2006 10:45:58 -0800 (PST) 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 4TrGQSaerrWw; Sun, 19 Nov 2006 10:45:57 -0800 (PST) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 8FC32C6D42; Sun, 19 Nov 2006 10:45:57 -0800 (PST) Message-ID: <200266458.98661163961957407.JavaMail.root@dogfood.zimbra.com> Date: Sun, 19 Nov 2006 10:45:57 -0800 (PST) From: Dan Karp To: Dave Cridland Subject: Re: [lemonade] VFOLDER and mutable fields/WITHIN In-Reply-To: <27142.1163936274.930628@peirce.dave.cridland.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > > > Hence draft-cridland-imap-context-00 > > Well, it's better in as much as it's a hell of a lot easier to do, > and it can be used with SORT, which client-side emulation can't. > Also, there's quite some difficulty with trying to manage this > without doing a SEARCH command per notification - in many cases, the > client simply doesn't have sufficient data, which introduces > additional round-trips *and* additional transmission data. You've got a point. That may indeed be a better solution, as it doesn't require any UID magic and clients may not view messages that transition from matching to non-matching state as EXPUNGEs (which would cause re-downloads if they transition right back to matching). I think that my main sticking point is client-side, not server-side. Whether the client always remains sync'ed with the state of a persistent search or it refreshes only when the user requests it, I'm still a proponent of presenting the user with static views of search results. We've got a product that's fundamentally search-based, and representing searches on dynamic attributes has been one of the more vexing issues. We've found that people would rather run a search once and then work their way through a static snapshot of the result set than have the results vary in real time with changes in the backing store. Your mileage may vary, but our users seemed put off when anything other than a real "delete" caused search results to disappear from their view, or when anything other than newly-deposited mail caused new search results to appear. They'd rather explicitly re-run the search than have it change out from under them. So I'm fine with a protocol that always keeps the client up to date, and I'm equally fine with a protocol that refreshes a client view only when the user revisits a "saved search". I just think that a protocol that EXPUNGEs when a message no longer fits the search criteria will lead to bad user experience. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 19 14:31:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlsNs-0003zO-1T; Sun, 19 Nov 2006 14:31:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlsNq-0003zJ-Ir for lemonade@ietf.org; Sun, 19 Nov 2006 14:31:18 -0500 Received: from mxout3.cac.washington.edu ([140.142.32.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlsNp-0003pJ-7O for lemonade@ietf.org; Sun, 19 Nov 2006 14:31:18 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id kAJJVEc8018531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 19 Nov 2006 11:31:14 -0800 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id kAJJVDYV028228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 19 Nov 2006 11:31:14 -0800 Date: Sun, 19 Nov 2006 11:31:12 -0800 (PST) From: Mark Crispin To: Dan Karp Subject: Re: [lemonade] VFOLDER and mutable fields/WITHIN In-Reply-To: <187383916.98631163961789641.JavaMail.root@dogfood.zimbra.com> Message-ID: References: <187383916.98631163961789641.JavaMail.root@dogfood.zimbra.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.2.285561, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.11.19.111933 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: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Sun, 19 Nov 2006, Dan Karp wrote: > "Mark Crispin" wrote: > > > On Sun Nov 19 00:04:08 2006, Dan Karp wrote: > > >> Or you could simply not return a UIDNEXT value on the VFOLDER and > > >> effectively do an "UNEXPUNGE" while the client's not looking. > > >> Clients are built defensively enough that introducing a new message > > >> whose UID isn't the highest in the mailbox will still work. (It's > > >> my secret shame -- trust me on this.) > > Any server that does this is broken. Completely, utterly, broken. > > I am highly offended by the idea that it is is "alright" for a server > > to do this because some clients may overlook this egregious violation > > of UID semantics. > Mark, the hyperbole is unnecessary. I was only being half-serious about it. > But you're still right, it's a bad idea. Humor, sarcasm, and half-seriousness does not transmit very well in email. The smiley ":-)" was introduced in an attempt to ameliorate the problems brought about by ill-advised levity. Nor is it hyperbole for someone who must deal on a daily basis with people who seriously believe that IMAP's definitions can be so compromised, and/or: . "blurdybloop server works fine with Outlook, therefore it's a bug in your client." . "blurdybloop client works fine with Courier, therefore it's a bug in your server." . "blurdybloop is a commercial product, therefore it's a bug in your product." I had to take the comment seriously; and a serious claim that "Clients are built defensively enough that introducing a new message whose UID isn't the highest in the mailbox will still work" can not go unchallenged. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 19 17:30:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlvAt-0005rz-S1; Sun, 19 Nov 2006 17:30:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlvAr-0005rt-Tx for lemonade@ietf.org; Sun, 19 Nov 2006 17:30:05 -0500 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlvAp-0007S8-Jp for lemonade@ietf.org; Sun, 19 Nov 2006 17:30:05 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.50) id 1GlvAk-0004Io-16; Sun, 19 Nov 2006 22:29:58 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 17857498005; Sun, 19 Nov 2006 22:42:19 +0000 (GMT) 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 08216-01; Sun, 19 Nov 2006 22:42:10 +0000 (GMT) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 41DEE498004; Sun, 19 Nov 2006 22:42:10 +0000 (GMT) Date: Sun, 19 Nov 2006 22:29:48 +0000 Subject: Re: [lemonade] VFOLDER and mutable fields/WITHIN References: <674166018.95391163894648889.JavaMail.root@dogfood.zimbra.com> <27142.1163936274.930628@peirce.dave.cridland.net> <5NXr3/VqfG/Xyn++ly2xxQ.md5@libertango.oryx.com> In-Reply-To: <5NXr3/VqfG/Xyn++ly2xxQ.md5@libertango.oryx.com> MIME-Version: 1.0 Message-Id: <27142.1163975389.023990@peirce.dave.cridland.net> From: Dave Cridland To: Arnt Gulbrandsen Content-Type: text/plain; charset="iso-8859-1"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net Content-Transfer-Encoding: quoted-printable X-Originating-Pythagoras-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 Sun Nov 19 12:43:46 2006, Arnt Gulbrandsen wrote: > Dave Cridland writes: >> Well... In fact, I think current proposals prevent selection of >> virtual mailboxes by na=EFve clients anyway. >=20 > How so? >=20 >=20 I thought there was talk of to require clients to show knowledge of=20 virtual mailboxes before they appear in LIST. Of course, I wrote this=20 without checking the current draft, being the weekend and all, so=20 I've not checked which way the debate settled. IIRC, that debate revolved around na=EFve clients potentially=20 automatically synchronizing all mailboxes without realizing they're=20 downloading many messages multiple times in the case of virtual=20 mailboxes. Dave. --=20 Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 19 17:51:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlvVg-0004R5-AP; Sun, 19 Nov 2006 17:51:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlvVe-0004Pj-Qe for lemonade@ietf.org; Sun, 19 Nov 2006 17:51:34 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlvTw-0005rS-1H for lemonade@ietf.org; Sun, 19 Nov 2006 17:49:49 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id F25F34AD39; Sun, 19 Nov 2006 23:49:44 +0100 (CET) Message-Id: Date: Sun, 19 Nov 2006 23:50:46 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] VFOLDER and mutable fields/WITHIN References: <674166018.95391163894648889.JavaMail.root@dogfood.zimbra.com> <27142.1163936274.930628@peirce.dave.cridland.net> <5NXr3/VqfG/Xyn++ly2xxQ.md5@libertango.oryx.com> <27142.1163975389.023990@peirce.dave.cridland.net> In-Reply-To: <27142.1163975389.023990@peirce.dave.cridland.net> Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dave Cridland writes: > On Sun Nov 19 12:43:46 2006, Arnt Gulbrandsen wrote: >> Dave Cridland writes: >>> Well... In fact, I think current proposals prevent selection of >>> virtual mailboxes by na=EFve clients anyway. >> >> How so? > > I thought there was talk of to require clients to show knowledge of > virtual mailboxes before they appear in LIST. Of course, I wrote this > without checking the current draft, being the weekend and all, so > I've not checked which way the debate settled. It didn't settle, AFAICR. > IIRC, that debate revolved around na=EFve clients potentially > automatically synchronizing all mailboxes without realizing they're > downloading many messages multiple times in the case of virtual > mailboxes. Any lemonade client doing that has a bigger problem than just vfolder ;) I suppose I've mentioned the PDA that ran LIST "" * as the first command after login? It (the PDA) crashed in five seconds on connecting to uw-imapd. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 19 18:25:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glw22-00011x-51; Sun, 19 Nov 2006 18:25:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glw20-00011p-Vl for lemonade@ietf.org; Sun, 19 Nov 2006 18:25:00 -0500 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Glw1y-0000cs-LR for lemonade@ietf.org; Sun, 19 Nov 2006 18:25:00 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1Glw1x-0000HJ-D1; Sun, 19 Nov 2006 23:24:57 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id CE9ED498005; Sun, 19 Nov 2006 23:37:18 +0000 (GMT) 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 09329-08; Sun, 19 Nov 2006 23:37:13 +0000 (GMT) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id E9A9E498003; Sun, 19 Nov 2006 23:37:13 +0000 (GMT) Date: Sun, 19 Nov 2006 23:24:51 +0000 Subject: Re: [lemonade] VFOLDER and mutable fields/WITHIN References: <674166018.95391163894648889.JavaMail.root@dogfood.zimbra.com> <27142.1163936274.930628@peirce.dave.cridland.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <27142.1163978692.319381@peirce.dave.cridland.net> From: Dave Cridland To: Mark Crispin Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Rutherford-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 Sun Nov 19 18:27:14 2006, Mark Crispin wrote: > On Sun, 19 Nov 2006, Dave Cridland wrote: >> But then you're going be to breaking the mailbox semantics. (And >> trust me, there are clients for which reintroducing UIDs will >> break them. I believe my client is not the only one.) Removing >> UIDNEXT *and* removing strictly increasing UIDs is just a pain. >> >> If you're going to break mailbox semantics, you might as well do >> away with them entirely. > > Dave is completely, absolutely, 100% correct on this. If a > developer does not like IMAP's UID semantics, that developer needs > to get out of the IMAP business and spawn a new competing protocol. That's not quite what I meant - I only meant to imply that if you cannot model a continuously (or discretely) updated SEARCH result set as a mailbox efficiently, then the obvious way forward would be to model it as something else. Like a continuously (or discretely) updated SEARCH result, as I propose. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 19 18:26:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glw34-00016O-TX; Sun, 19 Nov 2006 18:26:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glw33-00016I-S6 for lemonade@ietf.org; Sun, 19 Nov 2006 18:26:05 -0500 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Glw32-0000i5-E0 for lemonade@ietf.org; Sun, 19 Nov 2006 18:26:05 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.50) id 1Glw31-0002iH-LP; Sun, 19 Nov 2006 23:26:03 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 17397498006; Sun, 19 Nov 2006 23:38:25 +0000 (GMT) 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 09434-04; Sun, 19 Nov 2006 23:38:15 +0000 (GMT) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id C61F9498005; Sun, 19 Nov 2006 23:38:15 +0000 (GMT) Date: Sun, 19 Nov 2006 23:25:53 +0000 Subject: Re: [lemonade] VFOLDER and mutable fields/WITHIN References: <200266458.98661163961957407.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <200266458.98661163961957407.JavaMail.root@dogfood.zimbra.com> MIME-Version: 1.0 Message-Id: <27142.1163978754.146172@peirce.dave.cridland.net> From: Dave Cridland To: Dan Karp Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Pythagoras-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 Sun Nov 19 18:45:57 2006, Dan Karp wrote: > We've got a product that's fundamentally search-based, and > representing searches on dynamic attributes has been one of the > more vexing issues. We've found that people would rather run a > search once and then work their way through a static snapshot of > the result set than have the results vary in real time with changes > in the backing store. Your mileage may vary, but our users seemed > put off when anything other than a real "delete" caused search > results to disappear from their view, or when anything other than > newly-deposited mail caused new search results to appear. They'd > rather explicitly re-run the search than have it change out from > under them. > > Yes, I get annoyed when I'm using a SEARCH based on UNSEEN, such that messages would vanish as I read them. So I instruct the client, by a checkbox, not to dynamically remove messages from the display which cease to match. It can be done client-side, even with CONTEXTs. On the other hand, I always want to see messages which become matching, whether due to delivery or changes in circumstance. > So I'm fine with a protocol that always keeps the client up to > date, and I'm equally fine with a protocol that refreshes a client > view only when the user revisits a "saved search". I just think > that a protocol that EXPUNGEs when a message no longer fits the > search criteria will lead to bad user experience. One aspect of virtual mailboxes is that should a message cease to match, it not only vanishes in a way that's indistinguishable from the message being EXPUNGEd, but also it vanishes in such a way that it's no longer accessible. In other words, the client cannot choose the behaviour above. This is particularly annoying if the client relies on the implicit \Seen flag setting behaviour of a non-PEEK FETCH, but might actually be frustrating with WITHIN, too. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 20 14:12:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmEZ9-0000sN-2n; Mon, 20 Nov 2006 14:12:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmEZ8-0000sF-D7 for lemonade@ietf.org; Mon, 20 Nov 2006 14:12:26 -0500 Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmEZ4-0003YT-Pq for lemonade@ietf.org; Mon, 20 Nov 2006 14:12:26 -0500 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]:60810) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:fanf2) id 1GmEYP-0006xB-2g (Exim 4.63) for lemonade@ietf.org (return-path ); Mon, 20 Nov 2006 19:11:41 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1GmEYP-00030d-OT (Exim 4.54) for lemonade@ietf.org (return-path ); Mon, 20 Nov 2006 19:11:41 +0000 Date: Mon, 20 Nov 2006 19:11:41 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: lemonade@ietf.org 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: b19722fc8d3865b147c75ae2495625f2 Subject: [lemonade] SMTP quickstart X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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, 17 Nov 2006, Randall Gellens wrote: > > I volunteered to be the editor stuckee for SMTP quickstart, not SMTP > compression. My current pre-draft is at http://www-uxsup.csx.cam.ac.uk/~fanf2/hermes/doc/qsmtp/draft-fanf-smtp-quickstart.html The main problem with it at the moment is complexity. I think some of the features need to be cut out, though I'm not sure what would be best. As it stands, QUICKSTART is as efficient as (non-standard) smtps at getting TLS running, and can get you to MAIL in the client's 3rd packet. QUICKSTART defines two variants of STARTTLS: a pipelined version, which is awkward for both the client and the server but which is necessary for full-speed QUICKSTART, and a simplified version QTLS which saves a little time and is easier to code with restricted APIs but which limits you to MAIL in the 4th packet at the earliest. Should both remain or should we stick with one and if so which one? Should the AUTH optimization be made mandatory? I note that RFC 4468 fails to say that it updates RFC 2554 despite the fact that it specifies a change to AUTH's pipelining behaviour. QUICKSTART has its own option mechanism which allows future extensions to define quickstart variants. This could be useful for COMPRESS, for example. Tony. -- f.a.n.finch http://dotat.at/ BAILEY: CYCLONIC BECOMING NORTHWESTERLY SEVERE GALE 9 TO VIOLENT STORM 11, OCCASIONALLY HURRICANE FORCE 12 IN SOUTH, DECREASING 7 TO SEVERE GALE 9 LATER. HIGH OR VERY HIGH. RAIN OR SQUALLY SHOWERS. MODERATE OR POOR. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 21 06:36:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmTvc-0003Fg-4T; Tue, 21 Nov 2006 06:36:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmTva-0003Et-RY for lemonade@ietf.org; Tue, 21 Nov 2006 06:36:38 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmTvV-0002vM-4n for lemonade@ietf.org; Tue, 21 Nov 2006 06:36:38 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J9200ER9W57AX@szxga02-in.huawei.com> for lemonade@ietf.org; Tue, 21 Nov 2006 19:34:19 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J920031GW579K@szxga02-in.huawei.com> for lemonade@ietf.org; Tue, 21 Nov 2006 19:34:19 +0800 (CST) Received: from w48795 ([10.164.120.76]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J9200383W55SM@szxml03-in.huawei.com> for lemonade@ietf.org; Tue, 21 Nov 2006 19:34:18 +0800 (CST) Date: Tue, 21 Nov 2006 19:34:17 +0800 From: Lingyan Wu Subject: Re: [Lemonade]About draft-gulbrandsen-imap-notify-01 To: lemonade@ietf.org, Arnt Gulbrandsen Message-id: <2ea801c70d60$fab536b0$4c78a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=gb2312; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <00cf01c70899$0e8a9490$3878a40a@china.huawei.com> <00b501c70978$ed9d1a10$3878a40a@china.huawei.com> <010b01c709ff$21690670$3878a40a@china.huawei.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Lingyan Wu List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org ----- Original Message ----- From: "Arnt Gulbrandsen" To: Cc: "Lingyan Wu" Sent: Saturday, November 18, 2006 6:38 PM Subject: Re: [Lemonade]About draft-gulbrandsen-imap-notify-01 > Lingyan Wu writes: >>>> The client could use the FLAGS in the response to update the flags of >>>> the corresponding email in client after receiving the response. Through >>>> unsolicited FETCH response and STATUS response, all the mailboxes >>>> (selected and unselected mailboxes) could be synchronized expediently. >>> >>> Assuming the message is in the client's cache, yes it would, >> >> Almost all of the emails in the client's cache are the emails passing the >> filters (related with the client) in the server, and only the emails in >> the client's cache (passing filters) need to be synchronized, so we could >> synchronize all of the filtered emails in selected and unselected >> mailboxes through unsolicited FETCH response and STATUS response. > > Not quite. We can only synchronize those which are modified while the > client has an IMAP connection to the server. Assuming only synchronize those which are modified while connection, how to notify the client those modified in unselected mailboxes? Is it appropriate through STATUS response? >And the cost of synchronizing those is that we also send updates for all >messages which are NOT in the client's cache. What I wanted to say is, what should be synchronized are those updates passing filters related with the client. >>> but what's the benefit of that expedient update? If the client wants to >>> use that mailbox, it will select the mailbox and run the resync >>> algorithm anyway. >> >> The benefit is to furthest keep the consistent flags of emails between >> the client and server. > > That would be desirable, but it cannot really work, since the client is > not connected all the time. Yes, the client is not connected all the time. Because of this, it would be better to take any chance to synchronize. > >> When the client create a session with INBOX to do some operations, the >> server could take the chance to send the changed flags of filtered emails >> in other mailboxes through the extended STATUS response so that all of >> the emails in the client's catch could keep latest flags. > > Wouldn't that duplicate the functionality of CONDSTORE and quick > resynchronization? If CONSTORE is not supportted, the server could send the tracked changes to the client through FETCH and STATUS response to avoid that "the client must SELECT each folder separately to receive the changes for that folder". If CONSTORE is supportted, the server could send the changes since some known moment (could be according to the HIGHESTMODSEQ catched in client) or just send those which are modified while connection just as what you said (If I misunderstand you, please correct me:)). > > Arnt > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 21 07:31:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmUmR-0000Ix-7c; Tue, 21 Nov 2006 07:31:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmUmP-0000Io-I8 for lemonade@ietf.org; Tue, 21 Nov 2006 07:31:13 -0500 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmUmM-00059w-2l for lemonade@ietf.org; Tue, 21 Nov 2006 07:31:13 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.50) id 1GmUmK-0004Zy-FA; Tue, 21 Nov 2006 12:31:08 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 736E1498005; Tue, 21 Nov 2006 12:43:45 +0000 (GMT) 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 18987-10; Tue, 21 Nov 2006 12:43:32 +0000 (GMT) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 3AE22498004; Tue, 21 Nov 2006 12:43:32 +0000 (GMT) Date: Tue, 21 Nov 2006 12:30:54 +0000 Subject: Re: [Lemonade]About draft-gulbrandsen-imap-notify-01 References: <00cf01c70899$0e8a9490$3878a40a@china.huawei.com> <00b501c70978$ed9d1a10$3878a40a@china.huawei.com> <010b01c709ff$21690670$3878a40a@china.huawei.com> <2ea801c70d60$fab536b0$4c78a40a@china.huawei.com> In-Reply-To: <2ea801c70d60$fab536b0$4c78a40a@china.huawei.com> MIME-Version: 1.0 Message-Id: <4994.1164112254.935270@peirce.dave.cridland.net> From: Dave Cridland To: Lingyan Wu Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Pythagoras-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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 Nov 21 11:34:17 2006, Lingyan Wu wrote: > Assuming only synchronize those which are modified while > connection, how to notify the client those modified in unselected > mailboxes? Is it appropriate through STATUS response? > > Yes, I believe so. The STATUS response can carry sufficient data to indicate whether synchronization is required, whether new messages have arrived, and whether messages have been deleted. The specifics of these events can then be fetched by selecting the mailbox and synchronizing - where QRESYNC is supported, this is at most two round-trips - one for synchronizing FLAG changes and EXPUNGE events, one for downloading new message data. If there are no new messages - and the client can detirmine this via the information in the SELECT (whether enhanced by QRESYNC or not) then the second round-trip is not needed. >> And the cost of synchronizing those is that we also send updates >> for all messages which are NOT in the client's cache. > > What I wanted to say is, what should be synchronized are those > updates passing filters related with the client. > > But if a user is interested in the changes to a mailbox, the user will look at the mailbox. If the user is looking at a mailbox, it should be SELECTed. > If CONSTORE is not supportted, the server could send the tracked > changes to the client through FETCH and STATUS response to avoid > that "the client must SELECT each folder separately to receive the > changes for that folder". If CONDSTORE is not supported, then synchronization is going to be much more expensive. There's little that can be done to avoid that. > If CONSTORE is supportted, the server could send the changes since > some known moment (could be according to the HIGHESTMODSEQ catched > in client) or just send those which are modified while connection > just as what you said (If I misunderstand you, please correct me:)). > > And the client, with NOTIFY and QRESYNC, can not only know that such changes exist, but can obtain them as needed in one or two round-trip. This does two things. From the client perspective, it allows for a client to alter only the mailbox-level data in its cache, avoiding the need to open the message-level cache itself. On resynch, it can then write larger chunks of data at once, which is more efficient for almost any client, but certainly for PDAs and mobile handsets, for which writes are both slow and power-hungry. Ideally, the simplest method for handling this data is to have a single database which maintains mailbox level data, and a second database per-mailbox to handle message data. This means that the client only has two databases open at once, causing far fewer writes. From the server perspective, it's much the same - servers can optimize passing around HIGHESTMODSEQ, EXISTS, and possibly UIDNEXT changes much more easily that by passing around FETCH data. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 21 08:03:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmVHZ-0007g2-MC; Tue, 21 Nov 2006 08:03:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmVHY-0007fC-8z for lemonade@ietf.org; Tue, 21 Nov 2006 08:03:24 -0500 Received: from moutng.kundenserver.de ([212.227.126.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmVHS-0007Fu-Q6 for lemonade@ietf.org; Tue, 21 Nov 2006 08:03:24 -0500 Received: from [84.160.156.59] (helo=noname) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis), id 0MKwh2-1GmVHP2JEo-0001Kx; Tue, 21 Nov 2006 14:03:16 +0100 From: Martin Konold Organization: erfrakon To: Enhancements to Internet email to support diverse service enivronments Date: Tue, 21 Nov 2006 14:03:12 +0100 User-Agent: KMail/1.9.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611211403.12916.martin.konold@erfrakon.de> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:b04c3ed30b43fd5a3d557b6dbc75a710 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [lemonade] New member Martin Konold X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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, I just joined this mailing list. It was recommended to me from Dave Cridland on the ietf-imapext@imc.org mailing list. I am working on IMAP based groupware solutions and especially on the opensource Kolab Groupware server and clients. For this purpose I am working on the opensource KDE Kontact groupware client using disconnected IMAP and on the proprietary MAPI Storage Provider KONSEC Konnektor. On the server side I implemented draft-ietf-imapext-list-extensions-17 on Cyrus Imapd. see also: https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=2875 Initially I want to start asking some questions and then I want to come up with some ideas which stem from my experience in trying to create an Outlook/Exchange comparable Groupware Solution based on IMAP which shall work in high latency / low bandwidth / unreliable network scenarios. Question 1: I need the draft-ietf-imapext-list-extensions as a prerequisite for the IMAP METADATA extension as documented in draft-ietf-imapext-list-extensions. What confuses me is that the latest METADATA draft is dated from October 19, 2006 and refers to LISTEXT as a prerequisit. On the other hand the LISTEXT is expired and the most recent draft-ietf-imapext-list-extensions-18 dated September 21, 2006 only mentions the LIST-EXTENDED capability. I assume that both drafts are part of the lemonade WG. Is this due to lack of consistency in the lemonade working group or am I missing something? I tried to mail the authors privately about my problem but did not get any responses sofar. Yours, -- martin -- http://www.erfrakon.com/ Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 21 08:55:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmW5a-0004Sk-9E; Tue, 21 Nov 2006 08:55:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmW5Z-0004Q9-1d for lemonade@ietf.org; Tue, 21 Nov 2006 08:55:05 -0500 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmW5T-0005Tz-Jz for lemonade@ietf.org; Tue, 21 Nov 2006 08:55:05 -0500 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 kALDfmG03390 for ; Tue, 21 Nov 2006 13:41:49 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Lemonade]About draft-gulbrandsen-imap-notify-01 Date: Tue, 21 Nov 2006 13:54:22 -0000 Message-ID: <22C8A0D5D5E095449AB509FE777B5F800329C80F@svr-exchange.avocado.emccsoft.com> In-Reply-To: <4994.1164112254.935270@peirce.dave.cridland.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Lemonade]About draft-gulbrandsen-imap-notify-01 Thread-Index: AccNaTczZmwCyznUTVqNj5h5+dMcxAACRafg From: "Ben Last" To: "Dave Cridland" X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 >From: Dave Cridland [mailto:dave@cridland.net]=20 >If CONDSTORE is not supported, then synchronization is going to be much more expensive. There's little that can be done to avoid that. Well said. Also; if CONDSTORE is supported, it allows the client to control exactly what mailbox it synchronizes, and when. I believe that the client is best placed to make decisions about when (and how often) it retrieves new mailbox state, since it is the client that is aware of the state of the mobile device, network connection, etc. STATUS gives a way for the client to know what mailboxes have experienced state changes. This approach (STATUS and CONDSTORE) seems, to me, to bring IMAP closer to the delta-notification approach one sees in other push-mail protocols, which provide both: a) notification of events in real time b) a time-stamp-based way to retrieve changes >This does two things. From the client perspective, it allows for a=20 >client to alter only the mailbox-level data in its cache, avoiding=20 >the need to open the message-level cache itself. On resynch, it can=20 >then write larger chunks of data at once, which is more efficient for=20 >almost any client, but certainly for PDAs and mobile handsets, for=20 >which writes are both slow and power-hungry. Absolutely. We're finding that we need to keep the WiFi connections idle as much as possible to save battery life. The chipsets and drivers involved usually have timeouts that power down in stages when the connection is idle. Consequently, it's significantly more efficient to retrieve more data in a few consecutive fetches than to spread that over a series of smaller fetches widely separated by time. >Ideally, the simplest method for handling this data is to have a=20 >single database which maintains mailbox level data, and a second=20 >database per-mailbox to handle message data. This means that the=20 >client only has two databases open at once, causing far fewer writes. That presupposes some elements of client design which aren't really true on Symbian-based platforms :) There's one mail database for everything there. Regards to all Ben=20 Ben Last R&D Manager EMCC Software Ltd _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 21 09:57:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmX3Z-0007Ez-P3; Tue, 21 Nov 2006 09:57:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmX3X-0007DL-Bw for lemonade@ietf.org; Tue, 21 Nov 2006 09:57:03 -0500 Received: from static-71-240-120-213.pitt.east.verizon.net ([71.240.120.213] helo=mulberrymail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmX3W-0002Pc-3R for lemonade@ietf.org; Tue, 21 Nov 2006 09:57:03 -0500 Received: from [17.101.32.44] ([17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id kALEut1M004026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Nov 2006 09:56:57 -0500 Date: Tue, 21 Nov 2006 09:56:50 -0500 From: Cyrus Daboo To: Martin Konold , Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] New member Martin Konold Message-ID: <5C4C9E0FE41BB01CA8931723@Cyrus-Daboo-G5.local> In-Reply-To: <200611211403.12916.martin.konold@erfrakon.de> References: <200611211403.12916.martin.konold@erfrakon.de> X-Mailer: Mulberry/4.0.7b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on piper.mulberrymail.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Martin, --On November 21, 2006 2:03:12 PM +0100 Martin Konold wrote: > What confuses me is that the latest METADATA draft is dated from October > 19, 2006 and refers to LISTEXT as a prerequisit. On the other hand the > LISTEXT is expired and the most recent > draft-ietf-imapext-list-extensions-18 dated September 21, 2006 only > mentions the LIST-EXTENDED capability. METADATA references the current LIST-EXTENDED draft (the one in the rfc editor queue) but used the old capability name LISTEXT. I have fixed that in my working copy. I plan on pushing out a new version of that draft incorporating that change and others based on the feedback received last week. Once that is done I will request the IESG to last call it. -- Cyrus Daboo _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 21 10:59:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmY1l-0003v4-LD; Tue, 21 Nov 2006 10:59:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmY1k-0003u3-Hf for lemonade@ietf.org; Tue, 21 Nov 2006 10:59:16 -0500 Received: from moutng.kundenserver.de ([212.227.126.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmY1g-0002Eo-62 for lemonade@ietf.org; Tue, 21 Nov 2006 10:59:16 -0500 Received: from [84.160.156.59] (helo=noname) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1GmY1Z0W2N-0003Hv; Tue, 21 Nov 2006 16:59:06 +0100 From: Martin Konold Organization: erfrakon To: Cyrus Daboo Subject: Re: [lemonade] New member Martin Konold Date: Tue, 21 Nov 2006 16:59:01 +0100 User-Agent: KMail/1.9.5 References: <200611211403.12916.martin.konold@erfrakon.de> <5C4C9E0FE41BB01CA8931723@Cyrus-Daboo-G5.local> In-Reply-To: <5C4C9E0FE41BB01CA8931723@Cyrus-Daboo-G5.local> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611211659.02734.martin.konold@erfrakon.de> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:b04c3ed30b43fd5a3d557b6dbc75a710 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 Am Dienstag, 21. November 2006 15:56 schrieb Cyrus Daboo: Hi, > Once that is done I will request the IESG to last call it. Who has implemented METADATA sofar? (I plan to do it for Cyrus IMAP). Which clients can I use for testing? Yours, -- martin -- http://www.erfrakon.com/ Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 22 04:01:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmnyW-0003O9-2X; Wed, 22 Nov 2006 04:01:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmnyU-0003O0-QD for lemonade@ietf.org; Wed, 22 Nov 2006 04:00:58 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmnyE-0007W1-13 for lemonade@ietf.org; Wed, 22 Nov 2006 04:00:58 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J9400MQCJESJR@szxga02-in.huawei.com> for lemonade@ietf.org; Wed, 22 Nov 2006 16:54:29 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J94000XYJEQIT@szxga02-in.huawei.com> for lemonade@ietf.org; Wed, 22 Nov 2006 16:54:28 +0800 (CST) Received: from w48795 ([10.164.120.76]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J940086JJEOW5@szxml03-in.huawei.com> for lemonade@ietf.org; Wed, 22 Nov 2006 16:54:26 +0800 (CST) Date: Wed, 22 Nov 2006 16:54:23 +0800 From: Lingyan Wu Subject: Re: [Lemonade]About draft-gulbrandsen-imap-notify-01 To: Ben Last , Dave Cridland Message-id: <015101c70e13$cf354210$4c78a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-Priority: 3 X-MSMail-priority: Normal References: <00cf01c70899$0e8a9490$3878a40a@china.huawei.com> <00b501c70978$ed9d1a10$3878a40a@china.huawei.com> <010b01c709ff$21690670$3878a40a@china.huawei.com> <2ea801c70d60$fab536b0$4c78a40a@china.huawei.com> <4994.1164112254.935270@peirce.dave.cridland.net> X-Spam-Score: 0.6 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Lingyan Wu List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0173629423==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============0173629423== Content-type: multipart/alternative; boundary="Boundary_(ID_KfCxUB/Hchf2FWzXEOu+TA)" This is a multi-part message in MIME format. --Boundary_(ID_KfCxUB/Hchf2FWzXEOu+TA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT ----- Original Message ----- From: Dave Cridland To: Lingyan Wu Cc: Enhancements to Internet email to support diverse service enivronments Sent: Tuesday, November 21, 2006 8:30 PM Subject: Re: [Lemonade]About draft-gulbrandsen-imap-notify-01 On Tue Nov 21 11:34:17 2006, Lingyan Wu wrote: > Assuming only synchronize those which are modified while > connection, how to notify the client those modified in unselected > mailboxes? Is it appropriate through STATUS response? > > Yes, I believe so. The STATUS response can carry sufficient data to indicate whether synchronization is required, whether new messages have arrived, and whether messages have been deleted. [Lingyan] Yes, the STATUS response could indicate if there are some events (Message Addition and Deletion events, Message Flags events etc ) in the mailbox . I think when Message Flags events happen while connection , the server could send the events directly to the client to ask the client to update the flags of the corresponding emails so that the client could furthest keep the consistent flags. Thus although the client doesn't select the mailbox it could get the latest flags of the emails in that mailbox. The specifics of these events can then be fetched by selecting the mailbox and synchronizing - where QRESYNC is supported, this is at most two round-trips - one for synchronizing FLAG changes and EXPUNGE events, one for downloading new message data. If there are no new messages - and the client can detirmine this via the information in the SELECT (whether enhanced by QRESYNC or not) then the second round-trip is not needed. [Lingyan] Just for FLAG changes, the server could notify the client what FLAG changes happened while connection and the client updates the flags of emails in the client accordingly. Doesn't this more simple? I don't think this method could replace what you mentioned but just could provide an accessorial and simple function. Is the simple flow as follows right? C -->S: select mailboxA and do some operation S: a FLAG change happens in mailboxB C<-- S: send a STATUS response to tell the client some events have happened in mailboxB C<-->S: select mailboxB to synchronize FLAG changes C -->S: select mailboxA to continue the former operation The flow could be simplified to: C-->S: select mailboxA and do some operation S: a FLAG change happens in mailboxB C<--S: send the event directly through extended STATUS response >> And the cost of synchronizing those is that we also send updates >> for all messages which are NOT in the client's cache. > > What I wanted to say is, what should be synchronized are those > updates passing filters related with the client. > > But if a user is interested in the changes to a mailbox, the user will look at the mailbox. If the user is looking at a mailbox, it should be SELECTed. [Lingyan] Maybe as a user I want to keep the latest flags of emails in the client , so I think when I select a mailbox to do some operation it's appropriate for the server to take the chance to send FLAG changes in both selected and unselected mailboxes after receiving IDLE command. > If CONSTORE is not supportted, the server could send the tracked > changes to the client through FETCH and STATUS response to avoid > that "the client must SELECT each folder separately to receive the > changes for that folder". If CONDSTORE is not supported, then synchronization is going to be much more expensive. There's little that can be done to avoid that. > If CONSTORE is supportted, the server could send the changes since > some known moment (could be according to the HIGHESTMODSEQ catched > in client) or just send those which are modified while connection > just as what you said (If I misunderstand you, please correct me:)). > > And the client, with NOTIFY and QRESYNC, can not only know that such changes exist, but can obtain them as needed in one or two round-trip. This does two things. From the client perspective, it allows for a client to alter only the mailbox-level data in its cache, avoiding the need to open the message-level cache itself. On resynch, it can then write larger chunks of data at once, which is more efficient for almost any client, but certainly for PDAs and mobile handsets, for which writes are both slow and power-hungry. Ideally, the simplest method for handling this data is to have a single database which maintains mailbox level data, and a second database per-mailbox to handle message data. This means that the client only has two databases open at once, causing far fewer writes. From the server perspective, it's much the same - servers can optimize passing around HIGHESTMODSEQ, EXISTS, and possibly UIDNEXT changes much more easily that by passing around FETCH data. 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 --Boundary_(ID_KfCxUB/Hchf2FWzXEOu+TA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
 
----- Original Message -----
Sent: Tuesday, November 21, 2006 8:30 PM
Subject: Re: [Lemonade]About draft-gulbrandsen-imap-notify-01

On Tue Nov 21 11:34:17 2006, Lingyan Wu wrote:
> Assuming only synchronize those which are modified while
> connection, how to notify the client those modified in unselected
> mailboxes? Is it appropriate through STATUS response?
>
>
Yes, I believe so.

The STATUS response can carry sufficient data to indicate whether
synchronization is required, whether new messages have arrived, and
whether messages have been deleted.
[Lingyan] Yes, the STATUS response could indicate if there are some events (Message Addition and Deletion events, Message Flags events etc ) in the mailbox . 
I think when Message Flags events happen while connection , the server could send the events directly to the client to ask the client to update the flags of the corresponding emails so that the client could furthest keep the consistent flags. Thus although the client doesn't select the mailbox it could get the latest flags of the emails in that mailbox.

The specifics of these events can then be fetched by selecting the
mailbox and synchronizing - where QRESYNC is supported, this is at
most two round-trips - one for synchronizing FLAG changes and EXPUNGE
events, one for downloading new message data. If there are no new
messages - and the client can detirmine this via the information in
the SELECT (whether enhanced by QRESYNC or not) then the second
round-trip is not needed.

[Lingyan] Just for FLAG changes, the server could notify the client what FLAG changes happened while connection and the client updates the flags of emails in the client accordingly. Doesn't this more simple? I don't think this method could replace what you mentioned but just could provide an accessorial and simple function.
 
Is the simple flow as follows right?
C -->S: select mailboxA and do some operation
     S: a FLAG change happens in mailboxB
C<-- S: send a STATUS response to tell the client some events have happened in mailboxB
C<-->S: select mailboxB to synchronize FLAG changes
C -->S: select mailboxA to continue the former operation
 
The flow could be simplified to:
C-->S: select mailboxA and do some operation
    S: a FLAG change happens in mailboxB
C<--S: send the event directly through extended STATUS response

>> And the cost of synchronizing those is that we also send updates
>> for all messages which are NOT in the client's cache.
>
> What I wanted to say is, what should be synchronized are those
> updates passing filters related with the client.
>
>
But if a user is interested in the changes to a mailbox, the user
will look at the mailbox. If the user is looking at a mailbox, it
should be SELECTed.
[Lingyan] Maybe as a user I want to keep the latest flags of emails in the client , so I think when I select a mailbox to do some operation it's appropriate for the server to take the chance to send FLAG changes in both selected and unselected mailboxes after receiving IDLE command.
 
> If CONSTORE is not supportted, the server could send the tracked
> changes to the client through FETCH and STATUS response to avoid
> that "the client must SELECT each folder separately to receive the
> changes for that folder".

If CONDSTORE is not supported, then synchronization is going to be
much more expensive. There's little that can be done to avoid that.

> If CONSTORE is supportted, the server could send the changes since
> some known moment (could be according to the HIGHESTMODSEQ catched
> in client) or just send those which are modified while connection
> just as what you said (If I misunderstand you, please correct me:)).
>
>
And the client, with NOTIFY and QRESYNC, can not only know that such
changes exist, but can obtain them as needed in one or two round-trip.

This does two things. From the client perspective, it allows for a
client to alter only the mailbox-level data in its cache, avoiding
the need to open the message-level cache itself. On resynch, it can
then write larger chunks of data at once, which is more efficient for
almost any client, but certainly for PDAs and mobile handsets, for
which writes are both slow and power-hungry.

Ideally, the simplest method for handling this data is to have a
single database which maintains mailbox level data, and a second
database per-mailbox to handle message data. This means that the
client only has two databases open at once, causing far fewer writes.

 From the server perspective, it's much the same - servers can
optimize passing around HIGHESTMODSEQ, EXISTS, and possibly UIDNEXT
changes much more easily that by passing around FETCH data.

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
--Boundary_(ID_KfCxUB/Hchf2FWzXEOu+TA)-- --===============0173629423== 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 --===============0173629423==-- From lemonade-bounces@ietf.org Wed Nov 22 05:32:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmpOk-0003SP-HO; Wed, 22 Nov 2006 05:32:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmpOj-0003SK-5o for lemonade@ietf.org; Wed, 22 Nov 2006 05:32:09 -0500 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmpOh-0007k9-FX for lemonade@ietf.org; Wed, 22 Nov 2006 05:32:09 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.50) id 1GmpOX-00018Q-8l; Wed, 22 Nov 2006 10:31:57 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id A8505498005; Wed, 22 Nov 2006 10:44:43 +0000 (GMT) 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 11418-05; Wed, 22 Nov 2006 10:44:30 +0000 (GMT) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 3A9D7498004; Wed, 22 Nov 2006 10:44:30 +0000 (GMT) Date: Wed, 22 Nov 2006 10:31:42 +0000 Subject: Re: [Lemonade]About draft-gulbrandsen-imap-notify-01 References: <00cf01c70899$0e8a9490$3878a40a@china.huawei.com> <00b501c70978$ed9d1a10$3878a40a@china.huawei.com> <010b01c709ff$21690670$3878a40a@china.huawei.com> <2ea801c70d60$fab536b0$4c78a40a@china.huawei.com> <4994.1164112254.935270@peirce.dave.cridland.net> <015101c70e13$cf354210$4c78a40a@china.huawei.com> In-Reply-To: <015101c70e13$cf354210$4c78a40a@china.huawei.com> MIME-Version: 1.0 Message-Id: <4994.1164191503.684909@peirce.dave.cridland.net> From: Dave Cridland To: Lingyan Wu Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Heisenberg-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 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 Although I'm far from a fanatic on correct quoting, please consider configuring more traditional quoting at least for IETF lists, this style makes it very much harder to read and reply to. Clients which support format=flowed are freely available, and well worth it at that price. I find it difficult to distinguish which paragraphs you wrote from those you're replying to, and I have the advantage that you're replying to a message I wrote. On Wed Nov 22 08:54:23 2006, Lingyan Wu wrote: > [Lingyan] Yes, the STATUS response could indicate if there are > some events (Message Addition and Deletion events, Message Flags > events etc ) in the mailbox . I think when Message Flags events > happen while connection , the server could send the events directly > to the client to ask the client to update the flags of the > corresponding emails so that the client could furthest keep the > consistent flags. Thus although the client doesn't select the > mailbox it could get the latest flags of the emails in that > mailbox. > But that's what SELECT is for. You can turn this around - if a client knows it has all the latest flags for a mailbox, it need not select it. > [Lingyan] Just for FLAG changes, the server could notify the > client what FLAG changes happened while connection and the client > updates the flags of emails in the client accordingly. Doesn't this > more simple? I don't think this method could replace what you > mentioned but just could provide an accessorial and simple function. > > Is the simple flow as follows right? > C -->S: select mailboxA and do some operation > S: a FLAG change happens in mailboxB > C<-- S: send a STATUS response to tell the client some events > have happened in mailboxB > C<-->S: select mailboxB to synchronize FLAG changes C -->S: > select mailboxA to continue the former operation > > No, that's a poorly designed client - there's no need to react immediately to the STATUS by resynchronizing the mailbox. What the client ought to be doing is merely note that its cache for mailboxB is out of date, and therefore the next time the user requests operations on mailboxB, it needs to resynchronize. It might resynchronize without any direct need during a quiescent period, perhaps when the client has been idle for a second or two, perhaps, but resynchronizing merely because it can is definitely a poor design. The more interesting case is when the client wants to perform operations on mailboxB and there haven't been any events since the last time it selected it - in this case, it only needs to select mailboxB when it cannot service the request from the cache, and moreover need only perform a simple SELECT rather than a QRESYNC enhanced one (which is slightly smaller). In many ways, this is how I see NOTIFY being most interesting - it's removing the need to SELECT the mailbox at all, in some cases, and in others simplifies things. > >> And the cost of synchronizing those is that we also send > updates >> for all messages which are NOT in the client's cache. > > > What I wanted to say is, what should be synchronized are > those > updates passing filters related with the client. > > > But if a user is interested in the changes to a mailbox, > the user will look at the mailbox. If the user is looking at a > mailbox, it should be SELECTed. > [Lingyan] Maybe as a user I want to keep the latest flags of > emails in the client , so I think when I select a mailbox to do > some operation it's appropriate for the server to take the chance > to send FLAG changes in both selected and unselected mailboxes > after receiving IDLE command. > > But when you SELECT a mailbox, you get all the flag changes you want for that mailbox, and the server sends you updates. There's nothing stopping you from maintainig multiple connections for particularly critical mailboxes, of course, but if you're trying to get all the data all the time, you'd be best off running an SMTP server on the mobile. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 22 05:49:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmpfA-00013p-Hh; Wed, 22 Nov 2006 05:49:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmpf9-00013k-3N for lemonade@ietf.org; Wed, 22 Nov 2006 05:49:07 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmpf7-0002Xt-KY for lemonade@ietf.org; Wed, 22 Nov 2006 05:49:07 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 98BB24ACE2; Wed, 22 Nov 2006 11:49:02 +0100 (CET) Message-Id: Date: Wed, 22 Nov 2006 11:50:16 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [Lemonade]About draft-gulbrandsen-imap-notify-01 References: <00cf01c70899$0e8a9490$3878a40a@china.huawei.com> <00b501c70978$ed9d1a10$3878a40a@china.huawei.com> <010b01c709ff$21690670$3878a40a@china.huawei.com> <2ea801c70d60$fab536b0$4c78a40a@china.huawei.com> <4994.1164112254.935270@peirce.dave.cridland.net> <015101c70e13$cf354210$4c78a40a@china.huawei.com> <4994.1164191503.684909@peirce.dave.cridland.net> In-Reply-To: <4994.1164191503.684909@peirce.dave.cridland.net> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dave Cridland writes: > In many ways, this is how I see NOTIFY being most interesting - it's > removing the need to SELECT the mailbox at all, in some cases, and in > others simplifies things. Should NOTIFY send an immediate STATUS (UIDNEXT HIGHESTMODSEQ) the first time it's run? (The server has to know whether it's the first time, unfortunately.) C: a login dave acap S: OK yep, you know the password, you must be dave C: b notify (mailbox1 mailbox2) ... S: * STATUS mailbox1 (HIGHESTMODSEQ 3213 UIDNEXT 13) S: * STATUS mailbox2 (HIGHESTMODSEQ 421342314 UIDNEXT 243124) S: b OK Maybe this is worthless complexity. This is lemonade, so COMPRESS=DEFLATE is available, and this alternative is just a few bytes more expensive (five bytes, maybe? ten?): C: a login dave acap S: a OK yep, you know the password, you must be dave C: b notify (mailbox1 mailbox2) ... C: c status mailbox1 (uidnext highestmodseq) C: d status mailbox2 (uidnext highestmodseq) S: ... Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 22 05:56:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmpls-0003Qt-4I; Wed, 22 Nov 2006 05:56:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmplq-0003Qn-G6 for lemonade@ietf.org; Wed, 22 Nov 2006 05:56:02 -0500 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmplp-0003cP-0j for lemonade@ietf.org; Wed, 22 Nov 2006 05:56:02 -0500 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 kAMAgwG14776 for ; Wed, 22 Nov 2006 10:42:59 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Lemonade]About draft-gulbrandsen-imap-notify-01 Date: Wed, 22 Nov 2006 10:55:31 -0000 Message-ID: <22C8A0D5D5E095449AB509FE777B5F80032EBDC1@svr-exchange.avocado.emccsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Lemonade]About draft-gulbrandsen-imap-notify-01 Thread-Index: AccOJAOmn0HFvfC4Qfinss+8hFnnYgAADMEw From: "Ben Last" To: "Arnt Gulbrandsen" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org >From: Arnt Gulbrandsen [mailto:arnt@oryx.com]=20 >Should NOTIFY send an immediate STATUS (UIDNEXT HIGHESTMODSEQ) the first time it's run? >(The server has to know whether it's the first time, unfortunately.) > [ useful examples snipped ] I think that's an excellent idea; it allows the client to see, immediately after login, what the current modseq and uidnext of all mailboxes is, and that allows it to determine immediately whether anything has changed in those mailboxes since the last time it was synchronized. Loss of synchronization due to loss of network connection is, after all, inevitable in mobile. Thus I imagine that any client would want to know the status, so it's efficient to have it provided automatically. Regards Ben Ben Last R&D Manager EMCC Software Ltd _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 22 07:04:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmqqU-0002bT-NP; Wed, 22 Nov 2006 07:04:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmqqT-0002bN-Ka for lemonade@ietf.org; Wed, 22 Nov 2006 07:04:53 -0500 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmqqS-0000Sg-6f for lemonade@ietf.org; Wed, 22 Nov 2006 07:04:53 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.50) id 1GmqqQ-0002EX-Kp; Wed, 22 Nov 2006 12:04:50 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id A93D9498006; Wed, 22 Nov 2006 12:17:37 +0000 (GMT) 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 12387-08; Wed, 22 Nov 2006 12:17:17 +0000 (GMT) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 290DE498003; Wed, 22 Nov 2006 12:17:17 +0000 (GMT) Date: Wed, 22 Nov 2006 12:04:29 +0000 Subject: RE: [Lemonade]About draft-gulbrandsen-imap-notify-01 References: =?US-ASCII?Q?<22C8A0D5D5E095449AB509FE777B5F800?= =?US-ASCII?Q?2EBDC1@svr-exchange.avocado.emccsoft.com>?= In-Reply-To: =?US-ASCII?Q?<22C8A0D5D5E095449AB509FE777B5F80?= =?US-ASCII?Q?32EBDC1@svr-exchange.avocado.emccsoft.com>?= MIME-Version: 1.0 Message-Id: <4994.1164197070.005644@peirce.dave.cridland.net> From: Dave Cridland To: Ben Last Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Pythagoras-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed Nov 22 10:55:31 2006, Ben Last wrote: > >From: Arnt Gulbrandsen [mailto:arnt@oryx.com] >Should NOTIFY send > an immediate STATUS (UIDNEXT HIGHESTMODSEQ) the > first time it's run? > >(The server has to know whether it's the first time, > unfortunately.) > > > [ useful examples snipped ] > > I think that's an excellent idea; it allows the client to see, > immediately after login, what the current modseq and uidnext of all > mailboxes is, and that allows it to determine immediately whether > anything has changed in those mailboxes since the last time it was > synchronized. Loss of synchronization due to loss of network > connection > is, after all, inevitable in mobile. Thus I imagine that any client > would want to know the status, so it's efficient to have it provided > automatically. Yes, but it's also pipelinable, so as Arnt points out, the overhead of the client doing it is slight, and the complexity for the server is comparitively great, especially if we consider multiple NOTIFY commands (should the server issue STATUS for only those mailboxes previously not set to NOTIFY?). FWIW, using a fresh deflate stream, Arnt's example commands compressed to 37 octets when the client issued "A01 NOTIFY (mailbox1 mailbox2) ...\r\n", and 81 octets when the client issued "A01 NOTIFY (mailbox1 mailbox2) ...\r\nA02 STATUS mailbox1 (HIGHESTMODSEQ UIDNEXT)\r\nA03 STATUS mailbox2 (HIGHESTMODSEQ UIDNEXT)\r\n". This isn't terribly useful, since it's a fresh deflate stream, although it's using a Z_SYNC_FLUSH, but it might suggest that the overhead of the client issuing the STATUS commands explicitly is higher than Arnt suspected. Overall, I'm very much open-minded about the issue for now, and I think I'd prefer to gain some implementation experience first. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 22 07:13:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmqyY-0004rE-DD; Wed, 22 Nov 2006 07:13:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmqyW-0004r6-IZ for lemonade@ietf.org; Wed, 22 Nov 2006 07:13:12 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmqyV-0001Wy-02 for lemonade@ietf.org; Wed, 22 Nov 2006 07:13:12 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id DE04D4ACBB; Wed, 22 Nov 2006 13:13:09 +0100 (CET) Message-Id: Date: Wed, 22 Nov 2006 13:14:24 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [Lemonade]About draft-gulbrandsen-imap-notify-01 References: <4994.1164197070.005644@peirce.dave.cridland.net> In-Reply-To: <4994.1164197070.005644@peirce.dave.cridland.net> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dave Cridland writes: > On Wed Nov 22 10:55:31 2006, Ben Last wrote: >> >From: Arnt Gulbrandsen [mailto:arnt@oryx.com] >Should NOTIFY send an >> immediate STATUS (UIDNEXT HIGHESTMODSEQ) the >> first time it's run? >> >(The server has to know whether it's the first time, unfortunately.) >> >> > [ useful examples snipped ] >> >> I think that's an excellent idea; it allows the client to see, >> immediately after login, what the current modseq and uidnext of all >> mailboxes is, and that allows it to determine immediately whether >> anything has changed in those mailboxes since the last time it was >> synchronized. Loss of synchronization due to loss of network connection >> is, after all, inevitable in mobile. Thus I imagine that any client >> would want to know the status, so it's efficient to have it provided >> automatically. (What? I didn't see that message?) > Yes, but it's also pipelinable, so as Arnt points out, the overhead of > the client doing it is slight, and the complexity for the server is > comparitively great, especially if we consider multiple NOTIFY > commands (should the server issue STATUS for only those mailboxes > previously not set to NOTIFY?). *IF* this is a good idea, then the rule is simple: It applies only for the first NOTIFY command. Because the server's pre-NOTIFY default cannot be expressed using NOTIFY, the server has to keep track of whether a NOTIFY command has been issued before. Sending the STATUS responses should be less than ten lines of code conditioned by an existing variable. Or two existing variables. Any other rule would be much more complex and not much better. > FWIW, using a fresh deflate stream, Arnt's example commands compressed > to 37 octets when the client issued "A01 NOTIFY (mailbox1 mailbox2) > ...\r\n", and 81 octets when the client issued "A01 NOTIFY (mailbox1 > mailbox2) ...\r\nA02 STATUS mailbox1 (HIGHESTMODSEQ UIDNEXT)\r\nA03 > STATUS mailbox2 (HIGHESTMODSEQ UIDNEXT)\r\n". This isn't terribly > useful, since it's a fresh deflate stream, although it's using a > Z_SYNC_FLUSH, but it might suggest that the overhead of the client > issuing the STATUS commands explicitly is higher than Arnt suspected. I wonder why. > Overall, I'm very much open-minded about the issue for now, and I > think I'd prefer to gain some implementation experience first. Sounds good to me. Btw, I finished editing of -02 this morning and once Curtis, Alexey and I agree on the changes (that may require some more editing) I'll post it. Arnt typist _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 22 09:58:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmtYV-0004ll-Es; Wed, 22 Nov 2006 09:58:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmtYU-0004lW-JA for lemonade@ietf.org; Wed, 22 Nov 2006 09:58:30 -0500 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmtYS-000359-6I for lemonade@ietf.org; Wed, 22 Nov 2006 09:58:30 -0500 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 kAMEj9G02245 for ; Wed, 22 Nov 2006 14:45:09 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Lemonade]About draft-gulbrandsen-imap-notify-01 Date: Wed, 22 Nov 2006 14:57:39 -0000 Message-ID: <22C8A0D5D5E095449AB509FE777B5F80032EBFD1@svr-exchange.avocado.emccsoft.com> In-Reply-To: <4994.1164197070.005644@peirce.dave.cridland.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Lemonade]About draft-gulbrandsen-imap-notify-01 Thread-Index: AccOLmNcWxMztssHRwisi4g/Q0XIwAAFwbGw From: "Ben Last" To: "Dave Cridland" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org >From: Dave Cridland [mailto:dave@cridland.net]=20 >>On Wed Nov 22 10:55:31 2006, Ben Last wrote: > I think that's an excellent idea; it allows the client to see,=20 > immediately after login, what the current modseq and uidnext of all=20 > mailboxes is... >Yes, but it's also pipelinable, so as Arnt points out, the overhead of the client doing it is slight, >and the complexity for the server is comparitively great, especially if we >consider multiple NOTIFY >commands (should the server issue STATUS for only those mailboxes previously not set to NOTIFY?). Actually, I've always considered pipelining of commands to be a complexity in a client; we tend to avoid it because it makes the implementation of a state machine potentially much more complex. But yes, I ignored any implications for the server. That's the good part of doing client development :) Regards Ben Ben Last R&D Manager EMCC Software Ltd _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 22 12:36:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmw1Q-0005nO-Cu; Wed, 22 Nov 2006 12:36:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmw1O-0005mz-VX for lemonade@ietf.org; Wed, 22 Nov 2006 12:36:30 -0500 Received: from moutng.kundenserver.de ([212.227.126.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmw1K-0001Sb-GI for lemonade@ietf.org; Wed, 22 Nov 2006 12:36:30 -0500 Received: from [84.245.151.2] (helo=n800w.m.i2n) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1Gmw1H2TDo-0007Tb; Wed, 22 Nov 2006 18:36:25 +0100 From: Martin Konold Organization: erfrakon To: lemonade@ietf.org Date: Wed, 22 Nov 2006 18:36:20 +0100 User-Agent: KMail/1.9.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611221836.21718.martin.konold@erfrakon.de> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:b04c3ed30b43fd5a3d557b6dbc75a710 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: Arnt Gulbrandsen Subject: [lemonade] draft-gulbrandsen-imap-notify-01 use cases X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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, I try to understand the use cases and purpose of draft-gulbrandsen-imap-notify-01. Is it correct that the primary goals are mainly the two following points? 1. being able to restrict the amount of data IDLE [RFC2177] would send downstream by issueing the NOTIFY command with appropriate parameters 2. theses restrictions can be used during IDLE or always 3. allow for reducing the load on the server by avoid unnecessary notification messages To me this looks like it is mainly emphasizing on improving the downstream bandwidth usage while helping the server to avoid doing unnecessary work. Did I miss further goals/use cases? In addition I want to solve some further goals with IDLEPLUS. The general use-cases which IDLEPLUS tries to solve are: 1. improve the performance with high latency and asymmetric TCP/IP connections. A typical use case would be IMAP over an UMTS link with typically 384 k/Bit downstream but often only 64 k/Bit upstream. 2. avoid transfering upstream (C->S) the redundant data and therefore make use of server side configuration store (subscribe db and METADATA annotations if available) 3. allow to monitor a potentially high number of mailboxes while leveraging on the fact that generally most mailboxes are idle (*) 4. allow for efficient implementation on both server and client. (Actually I am currently working on an implementation for Cyrus Imapd) I can easily imagine to merge these two efforts. Especially I am more than willing to add support for being able to make the type of notifications configurable. This can be either done like in NOTIFY using parameters or preferably using annotations and leveraging upon the METADATA extension. After reading the recent minutes http://tools.ietf.org/wg/lemonade/minutes?item=minutes67.html I got the impression that actually the scope of NOTIFY shall be extended to allow monitoring multiple mailboxes in parallel. I guess that this change is in the pending -02 version of draft-gulbrandsen-imap-notify. On the other hand I am wondering if the use cases being addressed in IDLEPLUS can also be implemented in NOTIFY? Opinions welcome! (*) a typical use case is a CRM system with a subfolder for each customer. This can result easily into many thousand folders though most of the time nothing actually changes. http://www.erfrakon.de/konold/draft-konold-imap-idleplus-04.txt Yours, -- martin -- http://www.erfrakon.com/ Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 22 13:43:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmx3y-00070q-UD; Wed, 22 Nov 2006 13:43:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmx3x-0006zh-PG for lemonade@ietf.org; Wed, 22 Nov 2006 13:43:13 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmx3w-0002jY-8b for lemonade@ietf.org; Wed, 22 Nov 2006 13:43:13 -0500 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, 22 Nov 2006 18:43:11 +0000 Message-ID: <45649A21.1030404@isode.com> Date: Wed, 22 Nov 2006 18:42:41 +0000 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: Martin Konold Subject: Re: [lemonade] draft-gulbrandsen-imap-notify-01 use cases References: <200611221836.21718.martin.konold@erfrakon.de> In-Reply-To: <200611221836.21718.martin.konold@erfrakon.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: lemonade@ietf.org, Arnt Gulbrandsen X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Martin Konold wrote: >Hi, > >I try to understand the use cases and purpose of >draft-gulbrandsen-imap-notify-01. > > Hi Martin, >Is it correct that the primary goals are mainly the two following points? > >1. being able to restrict the amount of data IDLE [RFC2177] would send >downstream by issueing the NOTIFY command with appropriate parameters > >2. theses restrictions can be used during IDLE or always > >3. allow for reducing the load on the server by avoid unnecessary notification >messages > > This looks more or less correct. >To me this looks like it is mainly emphasizing on improving the downstream >bandwidth usage while helping the server to avoid doing unnecessary work. > >Did I miss further goals/use cases? > >In addition I want to solve some further goals with IDLEPLUS. The general >use-cases which IDLEPLUS tries to solve are: > >1. improve the performance with high latency and asymmetric TCP/IP >connections. A typical use case would be IMAP over an UMTS link with >typically 384 k/Bit downstream but often only 64 k/Bit upstream. > >2. avoid transfering upstream (C->S) the redundant data and therefore make use >of server side configuration store (subscribe db and METADATA annotations if >available) > There are several pieces of information specified in parameters to NOTIFY command: 1). List of events the client is interested in - I don't think this is going to be huge. 2). List of mailboxes the client is interested in - the client can use mailbox patterns to specify multiple mailboxes. I don't think this is going to be a big list, unless you hit some pathological case 3). What kind of information needs to be returned for new messages - I doubt this is going to be huge. 4). List of filters (search criteria). I've written draft-melnikov-imapext-filters-00.txt that allows them to be stored on the server. This will co-exist peacefully with NOTIFY. >3. allow to monitor a potentially high number of mailboxes while leveraging on >the fact that generally most mailboxes are idle (*) > > This is still possible with NOTIFY, see above. >4. allow for efficient implementation on both server and client. (Actually I >am currently working on an implementation for Cyrus Imapd) > > [Making NOTIFY difficult to implement for servers and/or clients was certainly a no goal ;-)] >I can easily imagine to merge these two efforts. > Your draft is not sufficient different ours, so this would make sense. >Especially I am more than >willing to add support for being able to make the type of notifications >configurable. This can be either done like in NOTIFY using parameters or >preferably using annotations and leveraging upon the METADATA extension. > As I mentioned above, I am not convinced that the effort is worth the gain, in this case. >After reading the recent minutes >http://tools.ietf.org/wg/lemonade/minutes?item=minutes67.html I got the >impression that actually the scope of NOTIFY shall be extended to allow >monitoring multiple mailboxes in parallel. I guess that this change is in the >pending -02 version of draft-gulbrandsen-imap-notify. > >On the other hand I am wondering if the use cases being addressed in IDLEPLUS >can also be implemented in NOTIFY? > >Opinions welcome! > >(*) a typical use case is a CRM system with a subfolder for each customer. >This can result easily into many thousand folders though most of the time >nothing actually changes. > >http://www.erfrakon.de/konold/draft-konold-imap-idleplus-04.txt > > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 22 14:01:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmxLb-0002RR-LJ; Wed, 22 Nov 2006 14:01:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmxLa-0002RM-8x for lemonade@ietf.org; Wed, 22 Nov 2006 14:01:26 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmxLY-0004r5-S2 for lemonade@ietf.org; Wed, 22 Nov 2006 14:01:26 -0500 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, 22 Nov 2006 19:01:24 +0000 Message-ID: <45649E65.4070608@isode.com> Date: Wed, 22 Nov 2006 19:00:53 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Arnt Gulbrandsen Subject: Re: [lemonade] draft-gulbrandsen-imap-notify-01 use cases References: <200611221836.21718.martin.konold@erfrakon.de> <45649A21.1030404@isode.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Arnt Gulbrandsen wrote: > Alexey Melnikov writes: > >> There are several pieces of information specified in parameters to >> NOTIFY command: >> 1). List of events the client is interested in - I don't think this >> is going to be huge. >> 2). List of mailboxes the client is interested in - the client can >> use mailbox patterns to specify multiple mailboxes. I don't think >> this is going to be a big list, unless you hit some pathological case >> 3). What kind of information needs to be returned for new messages - >> I doubt this is going to be huge. >> 4). List of filters (search criteria). I've written >> draft-melnikov-imapext-filters-00.txt that allows them to be stored >> on the server. This will co-exist peacefully with NOTIFY. > > Do you think anyone will send NOTIFY more than once during an IMAP > connection? Unlikely. > Assuming that it's sent once, shortly after connection establishment, > the only way to make it very large would seem to be sending a long > list of mailboxes. In that case, there's an o(size of mailbox names) > uplink cost and O(number of events*size of each event) downlink cost. > > We could store the mailbox list on the server, Yes, but I think the existing list of mailbox patterns is good enough (and compact enough). I surely hope the client is not going to list all user mailboxes when it can just use "*" or similar. We can create a new pattern for "all subscribed mailboxes", but because handling of subscribed mailboxes is already broken (inconsistent across clients), I doubt this is going to be very useful. But I can be convinced otherwise. > of course, but in that case, a well-connected desktop client and a > GPRS-connected mobile phone will tend to monitor the same set of > mailboxes. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 22 21:04:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn3x2-0001EY-VU; Wed, 22 Nov 2006 21:04:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn3x1-0001EF-TY for lemonade@ietf.org; Wed, 22 Nov 2006 21:04:31 -0500 Received: from consign.cs.umd.edu ([128.8.128.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gn3x1-00051a-Az for lemonade@ietf.org; Wed, 22 Nov 2006 21:04:31 -0500 Received: from delegate.pc.cs.umd.edu (exchange.cs.umd.edu [128.8.130.248]) by consign.cs.umd.edu (8.13.1/8.12.5) with ESMTP id kAN24Ti2005109 for ; Wed, 22 Nov 2006 21:04:29 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 22 Nov 2006 21:04:24 -0500 Message-ID: <5B211F0A44261848B86EC460096A555A1BACA8@delegate.pc.cs.umd.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Call for Papers: IEEE NetCri 07 Thread-Index: AccOo7K0UMzP6OP6TDSIGVKSngxLsw== From: "Elsharnouby, Tamer" To: X-CSD-MailScanner-Information: Please email staff@cs.umd.edu for more information X-CSD-MailScanner: Found to be clean X-CSD-MailScanner-SpamCheck: not spam, SpamAssassin (cached, score=-1.44, required 5, ALL_TRUSTED -1.44) X-CSD-MailScanner-From: sharno@cs.umd.edu X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Subject: [lemonade] Call for Papers: IEEE NetCri 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 *** Our Apologies if you received this multiple times = *** =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Call for Papers NetCri 07 The First International Workshop on=20 Research Challenges in Next Generation Networks for=20 First Responders and Critical Infrastructures http://www.cs.umd.edu/~sharno/NetCri07 In Conjunction with=20 IEEE IPCCC 2007, New Orleans, Louisiana, April 11-13 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D As advances in pervasive computing, wireless communication and sensor = networks continue, more opportunities are open to first responders and critical = infra- structures to benefit from these technologies. Providing first = responders with the best possible technology, infrastructure and services help save the = lives of the general public and the first responders as well. One of the main = challenges to the operations of first responders and critical = infrastructures is to deploy a communication network that is dependable, secure, and = rapidly deployable. In order to operate effectively, the deployed network = supports services such as location determination, audio and video communication, = and in site and remote sensing. Another key feature for first responders and = critical infrastructures networks is to support interactions among multiple = heterogen- eous networks.=20 =20 This workshop provides a forum for researchers, industry, and government = agencies to discuss the challenges facing the design, deployment and = operation- al issues for next generation network support for first responders and = critical infrastructure. The workshop will identify and define fundamental = concepts and=20 techniques, resolve conflicts between different approaches in the area, = and=20 provide a common ground for an advanced research and development agenda. = Topics of interest include, but are not limited to: - Smart environments (buildings, roads, vehicles, etc.)=20 - Fast roaming in heterogonous network environment - Localization and time synchronization=20 - Rapidly deployable and self configuring services and networks - Security, dependability, privacy, and performance trade-offs - QoS in heterogeneous wireless networks - Sensor and actuator networks for information gathering and real-time = control - Network and system support for augmented reality and visual = analytics - Simulation studies of first responders and critical infrastructures' = networks - Novel and adaptive communication protocols to support first = responders and critical infrastructure' operation - Resource management and allocation - Power control management - Admission, load and flow control - Performance analysis and experimentation of heterogeneous wireless = networks - Security techniques and methods for heterogeneous wireless networks - Interoperability among WLANs, Cellular, WSN and wired networks - Metrics and measurements on heterogeneous networks - Mobility models and traffic patterns in disaster areas - Cross-layer design - Testbeds Paper Submission Papers should describe original, previously unpublished work, not = currently=20 under review by another conference, workshop, or journal. Authors are = invited to submit a maximum of 6 pages papers including the abstract, figures = and=20 references. Papers should include the title, author(s), authors' = affiliation and an abstract. The formatting should be according to IEEE rules. = Papers=20 should be submitted in a PDF format using the EDAS submission system. Accepted papers will be accessible through the IEEE digital library and = are=20 included in the conference proceedings. Important Dates Submission deadline: November 30, 2006 Notification of acceptance: January 5, 2007 Camera ready version: January 26, 2007 Workshop Organizing Committee Program Co-Chairs Mohamed Eltoweissy, Virginia Tech, USA Moustafa Youssef, University of Maryland, USA=20 Publicity Co-Chairs Tamer Elsharnouby, Microsoft Corporation, USA James Joshi, University of Pittsburg, USA Technical Program Committee=20 Arup Acharya, IBM, USA Ashok Agrawala, University of Maryland, USA Jonathan Agre, Fujitsu Lab, USA Mustaque Ahamad, Georgia Tech, USA Nils Aschenbruck, University of Bonn, Germany Farag Azzedine, King Fahd University, Saudi Arabia Doreen Cheng, Samsung Research, USA Nagwa Elmakky, Alexandria University, Egypt Mohamed Gouda, University of Texas, USA Elena Guara, Coventry University, UK Wendi Heinzelman, University of Rochester, USA James Joshi, University of Pittsburgh, USA P. Krishnan, Avaya Labs, USA Scott Midkiff, Virginia Tech, USA Tamer Nadeem, Siemens Research, USA Dragos Niculescu, NEC Labs, USA Stephan Olariu, Old Dominion University, USA Krishna Sivalingam, University of Maryland at BC, USA Stephen D. Wolthusen, University of London, USA Mohamed Younis, University of Maryland at BC, USA Adel Youssef, Google, USA _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Nov 23 03:30:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn9yM-0005nE-Ps; Thu, 23 Nov 2006 03:30:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn9yL-0005n6-4M for lemonade@ietf.org; Thu, 23 Nov 2006 03:30:17 -0500 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gn9yJ-000348-KT for lemonade@ietf.org; Thu, 23 Nov 2006 03:30:17 -0500 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 kAN8HEG05358 for ; Thu, 23 Nov 2006 08:17:14 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] draft-gulbrandsen-imap-notify-01 Date: Thu, 23 Nov 2006 08:29:47 -0000 Message-ID: <22C8A0D5D5E095449AB509FE777B5F80032EC115@svr-exchange.avocado.emccsoft.com> In-Reply-To: <45649A21.1030404@isode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] draft-gulbrandsen-imap-notify-01 Thread-Index: AccOZi8hEHXOGFQrSXSKUq2V/9njkgAcRJ1g From: "Ben Last" To: , "Arnt Gulbrandsen" X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 Some overdue notes on the draft: sorry for the delay.=20 In 5.1, FlagChange & AnnotationChange: >Open issue: Which mailboxes does this cover? Those owned by the >user, those accessible to the user, and if the latter, then which >ACL right is needed? How about "all mailboxes for which the client may issue a successful SELECT"? In 5.3, ExpungeMessage: I don't see a huge client benefit in the UIDs of the neighbours being sent via unsolicited FETCH after the EXPUNGE. At best, it allows a client to establish that it is now out of sync with the server if the UID of the neighbour isn't that which is expected; that's really an edge case. >If the expunged message(s) is/are in another mailbox, the server >sends an unsolicited STATUS (EXISTS) response for the relevant >mailbox. If CONDSTORE is supported and enabled, HIGHESTMODSEQ should >be included in the STATUS response. Thus a STATUS (EXISTS) means "the number of messages in another mailbox has changed". Is it worth clarifying this for the reader? Much applause and votes for the CreateMailbox, DeleteMailbox and RenameMailbox notifications; I think it's important that the client can easily distinguish a Rename from a Create or Delete. Also, is it likely that clients will be coded to expect unsolicited LIST responses? Would it not be more appropriate to create a new response? I'd like an efficient way for the client to express interest in commonly used subsets of events, rather than just all or a full list. If it's reasonable to allow wildcards for selection of keywords, then renaming the events so that all mailbox event keywords start with "Mailbox" (ie, "MailboxCreate, MailboxDelete, MailboxRename"), all message event keyword start with "Message" (ie, "MessageNew, MessageExpunge, MessageFlagChange"), etc, then one might be able to express a notify command as in this example: NOTIFY (* (Mailbox* Message*)) ...which indicates that the client is not interested in quota events. I acknowledge this may be an inappropriate use of wildcards: if so, how about "MessageAll", "MailboxAll", etc, to imply all events of that class? The drawback with using "*" for all events is that if future revisions introduce new event classes beyond Message, Mailbox and Quota, a client will receive notifications of events that it may not be able to handle. Regards Ben Ben Last R&D Manager EMCC Software _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Nov 23 03:37:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnA5W-0001CM-Sm; Thu, 23 Nov 2006 03:37:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnA5V-00017g-L8 for lemonade@ietf.org; Thu, 23 Nov 2006 03:37:41 -0500 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnA5U-0004U4-8h for lemonade@ietf.org; Thu, 23 Nov 2006 03:37:41 -0500 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 kAN8OcG06057 for ; Thu, 23 Nov 2006 08:24:38 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] draft-gulbrandsen-imap-notify-01 use cases Date: Thu, 23 Nov 2006 08:37:11 -0000 Message-ID: <22C8A0D5D5E095449AB509FE777B5F80032EC11D@svr-exchange.avocado.emccsoft.com> In-Reply-To: <45649E65.4070608@isode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] draft-gulbrandsen-imap-notify-01 use cases Thread-Index: AccOaLNYPdg7pRa9RhywOIBAlV/2VgAcQeFg From: "Ben Last" To: "Alexey Melnikov" , "Arnt Gulbrandsen" X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org >From: Alexey Melnikov [mailto:alexey.melnikov@isode.com]=20 >Arnt Gulbrandsen wrote: >> Do you think anyone will send NOTIFY more than once during an IMAP=20 >> connection? >Unlikely. Unless, during a persistent connection, the user changes the set of mailboxes that the client is to synchronize. That would require re-issuing a NOTIFY. Ah: just occurred to me that when a client sees a new mailbox created, a reasonable behaviour would be to start synchronizing that new mailbox. Which would imply issuing a new NOTIFY to include it in the set of mailboxes for which events are expected. Along the same lines: if a mailbox is renamed such that its new name does not match a wildcard expression used in an intial NOTIFY, does the server continue to send notifications for that mailbox? Ie, is the wildcard matching done by the server at the time the NOTIFY is processed, or when events are generated? To be specific about that last point: consider I have the mailboxes "Arnt", "Alexey" and "Andrew" and issue: NOTIFY ("A*" *) The server issues notifications for all three mailboxes. I then rename "Andrew" to "Eric". Does the server continue to issue events for Eric? b Ben Last R&D Manager EMCC Software _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Nov 23 05:37:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnBxV-0004nW-Qi; Thu, 23 Nov 2006 05:37:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnBxU-0004ma-C9 for lemonade@ietf.org; Thu, 23 Nov 2006 05:37:32 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnBxQ-0005he-IG for lemonade@ietf.org; Thu, 23 Nov 2006 05:37:32 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 00FDF4AC7F; Thu, 23 Nov 2006 11:37:16 +0100 (CET) Message-Id: <705dmHm8YyXO0iuhs9tllA.md5@libertango.oryx.com> Date: Thu, 23 Nov 2006 11:38:36 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] draft-gulbrandsen-imap-notify-01 use cases References: <200611221836.21718.martin.konold@erfrakon.de> In-Reply-To: <200611221836.21718.martin.konold@erfrakon.de> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Arnt Gulbrandsen X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Martin Konold writes: > After reading the recent minutes > http://tools.ietf.org/wg/lemonade/minutes?item=minutes67.html I got the > impression that actually the scope of NOTIFY shall be extended to > allow monitoring multiple mailboxes in parallel. I guess that this > change is in the pending -02 version of > draft-gulbrandsen-imap-notify. I think that's already in -01. The syntax uses mbox-or-pat from LISTEXT, so you can use a list of mailboxes or a mailbox wildcard specification. Armt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Nov 23 05:40:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnBzw-0008Mc-9p; Thu, 23 Nov 2006 05:40:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnBzv-0008MR-RP for lemonade@ietf.org; Thu, 23 Nov 2006 05:40:03 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnBzu-0006FS-6Y for lemonade@ietf.org; Thu, 23 Nov 2006 05:40:03 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id E2CB14ACD9 for ; Thu, 23 Nov 2006 11:40:00 +0100 (CET) Message-Id: Date: Thu, 23 Nov 2006 11:41:19 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] draft-gulbrandsen-imap-notify-01 use cases References: <200611221836.21718.martin.konold@erfrakon.de> In-Reply-To: <200611221836.21718.martin.konold@erfrakon.de> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Arnt Gulbrandsen X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Martin Konold writes: > (*) a typical use case is a CRM system with a subfolder for each > customer. This can result easily into many thousand folders though > most of the time nothing actually changes. I thought about this, and I'd say that NOTIFY solves this use case very badly and IDLEPLUS has a race condition. Assume that there's exactly 1000 subfolders and fifty changes per day total, including two which happen at almost the same time, and that the RTT is one second, and that processing SELECT takes 0.250 seconds and FETCH 0.050. (The message interval should follow a Poisson distribution, right, so short intervals will occur every so often.) The NOTIFY command handles that nicely, just one wildcard and hardly any responses, but the client also has to send 1000 STATUS commands immediately after starting NOTIFY, so for a two-hour IMAP connection that's 1001 commands and 2006 responses in order to notify the client of 4 events. IDLEPLUS needs the same STATUS commands, so the total response count is effectively equal (I don't care abotu the DONE packet, it doesn't matter). The difference is that if a message arrives at 10:00:00.000 and another in another mailbox at 10:00:02.000, the second one is lost. At 10:00:00.000 the server sends an EXISTS to notify the client, which the client receives at 10:00.00.500, and it immediately sends DONE and SELECT, which the server accept at 10:00:01.000. Sometime around 10:00:01.250 the server is done processing select, and sometime around 10:00:01.750 the client receives the responses for the SELECT, and sends a FETCH for the message that arrived at 10:00:00.000. At 10:00:02:250 the server receives a FETCH, which completes at 10:00:02.300, and the client receives the FETCH response very shortly after 10:00:02.800, and immediately sends another IDLEPLUS. The server goes into IDLEPLUS mode very shortly after 10:00:03.300, and announces any messages that arrive after that time, but the message that arrived at 10:00:02.000 is not announced. If the RTT is smaller the problem is smaller. On ethernet it almost disappears. If the client is more primitive and doesn't pipeline, the problem is bigger. (IDLE doesn't have this race, it doesn't occur for the selected mailbox.) I can think of ways to solve this both for NOTIFY and IDLEPLUS. For NOTIFY I thought of a fairly pretty solution of sorts. It involves using the notification framework Ray spoke of and configuring it to e.g. "notify me of new messages in these 1000 mailboxes via IMAP/NOTIFY if I'm logged in, else send me an SMS". If that's done the 1000 STATUS commands aren't necessary, so NOTIFY works well. Just 5 responses for 4 events. The user gets a notification via NOTIFY if logged in, else via SMS. For IDLEPLUS that approach works less well - it would switch to SMS notifications for 2.3 seconds every time the client sends an IMAP command. Very unpredictable for the user. It would also be possible to give IDLEPLUS transaction/checkpoint ability, client identity and a notification spool, so the client could say "IDLEPLUS 1111111232" to identify itself, receive its spooled events and wait for more, and "NOOPPLUS 423142342" to tell the server that all events up to number 423142342 have been received. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Nov 23 05:49:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnC99-0004fT-8w; Thu, 23 Nov 2006 05:49:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnC98-0004fO-Dr for lemonade@ietf.org; Thu, 23 Nov 2006 05:49:34 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnC96-0008F7-SD for lemonade@ietf.org; Thu, 23 Nov 2006 05:49:34 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id F2F4D4ACDF; Thu, 23 Nov 2006 11:49:31 +0100 (CET) Message-Id: Date: Thu, 23 Nov 2006 11:50:51 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] draft-gulbrandsen-imap-notify-01 use cases References: <22C8A0D5D5E095449AB509FE777B5F80032EC11D@svr-exchange.avocado.emccsoft.com> In-Reply-To: <22C8A0D5D5E095449AB509FE777B5F80032EC11D@svr-exchange.avocado.emccsoft.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Ben Last writes: >> From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] Arnt >> Gulbrandsen wrote: >>> Do you think anyone will send NOTIFY more than once during an IMAP >>> connection? >> Unlikely. > > Unless, during a persistent connection, the user changes the set of > mailboxes that the client is to synchronize. IMO that case has to be handled correctly, but it's not a common case and does not warrant careful optimisation. My preference is to optimise for a single NOTIFY and make sure that if several are sent, the results is well-defined and useful. > ... > > The server issues notifications for all three mailboxes. I then rename > "Andrew" to "Eric". Does the server continue to issue events for > Eric? I ran across that this morning too, in a different context: If I ask for create/rename events for a* and a new mailbox is created, named "Andrew", or if "Eric" is renamed back to "Andrew", what happens? Obviously some corner cases need much careful definition than the -01 provides. The two issues you raise interact, too. Fsck. I'll go brew some espresso. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Nov 23 06:48:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnD3t-0007b0-Ee; Thu, 23 Nov 2006 06:48:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnD3r-0007au-KS for lemonade@ietf.org; Thu, 23 Nov 2006 06:48:11 -0500 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnD3p-0002Cj-4o for lemonade@ietf.org; Thu, 23 Nov 2006 06:48:11 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1GnD3h-00023D-Th; Thu, 23 Nov 2006 11:48:03 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id E6F2A498005; Thu, 23 Nov 2006 12:00:58 +0000 (GMT) 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 04540-08; Thu, 23 Nov 2006 12:00:49 +0000 (GMT) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id A5DFA498004; Thu, 23 Nov 2006 12:00:49 +0000 (GMT) Date: Thu, 23 Nov 2006 11:47:52 +0000 Subject: Re: [lemonade] draft-gulbrandsen-imap-notify-01 use cases References: <200611221836.21718.martin.konold@erfrakon.de> In-Reply-To: MIME-Version: 1.0 Message-Id: <4994.1164282472.445097@peirce.dave.cridland.net> From: Dave Cridland To: Arnt Gulbrandsen Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Rutherford-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: Enhancements to Internet email to support diverse service enivronments , Arnt Gulbrandsen X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu Nov 23 10:41:19 2006, Arnt Gulbrandsen wrote: > IDLEPLUS needs the same STATUS commands, so the total response > count is effectively equal (I don't care abotu the DONE packet, it > doesn't matter). The difference is that if a message arrives at > 10:00:00.000 and another in another mailbox at 10:00:02.000, the > second one is lost. At 10:00:00.000 the server sends an EXISTS to > notify the client, which the client receives at 10:00.00.500, and > it immediately sends DONE and SELECT, which the server accept at > 10:00:01.000. Sometime around 10:00:01.250 the server is done > processing select, and sometime around 10:00:01.750 the client > receives the responses for the SELECT, and sends a FETCH for the > message that arrived at 10:00:00.000. At 10:00:02:250 the server > receives a FETCH, which completes at 10:00:02.300, and the client > receives the FETCH response very shortly after 10:00:02.800, and > immediately sends another IDLEPLUS. The server goes into IDLEPLUS > mode very shortly after 10:00:03.300, and announces any messages > that arrive after that time, but the message that arrived at > 10:00:02.000 is not announced. Ah, I see - if a message arrives in a different mailbox when IDLEPLUS is not active, then yes, you lose data. This is why IDLEPLUS is designed for use in a different connection than that used for "real work". The problem then is that you have to decide whether IDLEPLUS gets notifications for mailboxes the other session has selected. If you do, then you have essentially doubled the bandwidth cost of notifications, since they'll get transmitted once on the mailbox connection and once on the IDLEPLUS connection. Moreover, you can get notified about events which haven't "happened" yet for the other session, which is perhaps even more confusing. So the client has to ignore notifications on the IDLEPLUS connection for selected mailboxes in other sessions anyway. But, if you don't send duplicate notifications, it's going to be very hard to decide whether you've received all the notifications for the mailbox as you select it. That's going to be painful. Moreover, you need to identify that the two sessions are from the same client, which currently we can't do. This duplication problem doesn't occur for NOTIFY, even if it's used in the same way, because the client isn't relying on the responses to keep it in synch, it's relying on the messages to tell it it's out of synch. Losing one, if the client thinks it's out of synch, makes no difference. Similarly, duplicating one makes no difference. It's only in the case where the client is using NOTIFY-via-IDLE within the same session *and* it misses a notification *and* it previously thought it was in synch *and* it can service any requests from the mailbox cache that it'll make a difference. > For IDLEPLUS that approach works less well - it would switch to SMS > notifications for 2.3 seconds every time the client sends an IMAP > command. Very unpredictable for the user. It would also be possible > to give IDLEPLUS transaction/checkpoint ability, client identity > and a notification spool, so the client could say "IDLEPLUS > 1111111232" to identify itself, receive its spooled events and wait > for more, and "NOOPPLUS 423142342" to tell the server that all > events up to number 423142342 have been received. ... and thus become even more like CLEARIDLE, as I recall. Losing synch isn't a major problem if regaining it is cheap, and it is per-mailbox. Right now, I'm somewhat more concerned with how to deal with regaining mailbox-level synch across large numbers of mailboxes at connection time. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Nov 23 07:21:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnDa8-0005y9-Uo; Thu, 23 Nov 2006 07:21:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnDa7-0005uU-Jb for lemonade@ietf.org; Thu, 23 Nov 2006 07:21:31 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnDa6-0007Cb-5e for lemonade@ietf.org; Thu, 23 Nov 2006 07:21:31 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 2C9924AC4B; Thu, 23 Nov 2006 13:21:29 +0100 (CET) Message-Id: <6/vZ9PN2A7sqQCWWG8LEPg.md5@libertango.oryx.com> Date: Thu, 23 Nov 2006 13:22:48 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] draft-gulbrandsen-imap-notify-01 use cases References: <200611221836.21718.martin.konold@erfrakon.de> <4994.1164282472.445097@peirce.dave.cridland.net> In-Reply-To: <4994.1164282472.445097@peirce.dave.cridland.net> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Arnt Gulbrandsen X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dave Cridland writes: > Losing synch isn't a major problem if regaining it is cheap, and it is > per-mailbox. Right now, I'm somewhat more concerned with how to deal > with regaining mailbox-level synch across large numbers of mailboxes > at connection time. You're assuming much local client storage and little bandwidth, as might the case for a modern laptop with a mobile phone card? If condstore's modseq is global, we could give notify a modseq argument and it would send immediate STATUS responses for each maillbox whose highestmodseq is larger... but that won't work if condstore "next modseq" variable is per-mailbox, which I believe 4551 allows. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Nov 23 08:59:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnF6Q-0002QO-S1; Thu, 23 Nov 2006 08:58:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnF6P-0002MK-LE for lemonade@ietf.org; Thu, 23 Nov 2006 08:58:57 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnF6O-0008A6-8z for lemonade@ietf.org; Thu, 23 Nov 2006 08:58:57 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 3038E4ACE9; Thu, 23 Nov 2006 14:58:51 +0100 (CET) Message-Id: Date: Thu, 23 Nov 2006 15:00:11 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] draft-gulbrandsen-imap-notify-01 References: <22C8A0D5D5E095449AB509FE777B5F80032EC115@svr-exchange.avocado.emccsoft.com> In-Reply-To: <22C8A0D5D5E095449AB509FE777B5F80032EC115@svr-exchange.avocado.emccsoft.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Ben Last writes: > Some overdue notes on the draft: sorry for the delay. I wish you'd sent that yesterday or tomorrow ;) I will pretend that you sent it tomorrow, so that I can get -02 published, and deal with your issues in -03. OK? Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Nov 23 10:26:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnGSh-0007Rq-FN; Thu, 23 Nov 2006 10:26:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnGSg-0007Rl-Ip for lemonade@ietf.org; Thu, 23 Nov 2006 10:26:02 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnGSf-00061x-4y for lemonade@ietf.org; Thu, 23 Nov 2006 10:26:02 -0500 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, 23 Nov 2006 15:25:49 +0000 Message-ID: <4565BD78.9010601@isode.com> Date: Thu, 23 Nov 2006 15:25:44 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Arnt Gulbrandsen Subject: Re: [lemonade] draft-gulbrandsen-imap-notify-01 use cases References: <22C8A0D5D5E095449AB509FE777B5F80032EC11D@svr-exchange.avocado.emccsoft.com> In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Arnt Gulbrandsen wrote: > Ben Last writes: > >>> From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] Arnt >>> Gulbrandsen wrote: >>> >>>> Do you think anyone will send NOTIFY more than once during an IMAP >>>> connection? >>> >>> Unlikely. >> >> Unless, during a persistent connection, the user changes the set of >> mailboxes that the client is to synchronize. > > IMO that case has to be handled correctly, but it's not a common case > and does not warrant careful optimisation. Exactly my thought. > My preference is to optimise for a single NOTIFY and make sure that if > several are sent, the results is well-defined and useful. Yes. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Nov 26 17:10:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoSCv-00015s-R4; Sun, 26 Nov 2006 17:10:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnCGI-0007aR-Qe for lemonade@ietf.org; Thu, 23 Nov 2006 05:56:58 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnCGH-0000p8-9g for lemonade@ietf.org; Thu, 23 Nov 2006 05:56:58 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 56D4C4AC4B; Thu, 23 Nov 2006 11:56:52 +0100 (CET) Message-Id: Date: Thu, 23 Nov 2006 11:58:11 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] draft-gulbrandsen-imap-notify-01 use cases References: <200611221836.21718.martin.konold@erfrakon.de> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-Mailman-Approved-At: Sun, 26 Nov 2006 17:10:40 -0500 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 Arnt Gulbrandsen writes: > IDLEPLUS needs the same STATUS commands, so the total response count > is effectively equal (I don't care abotu the DONE packet, it doesn't > matter). The difference is that if a message arrives at 10:00:00.000 > and another in another mailbox at 10:00:02.000, the second one is > lost. At 10:00:00.000 the server sends an EXISTS to notify the > client, which the client receives at 10:00.00.500, and it immediately > sends DONE and SELECT, which the server accept at 10:00:01.000. > Sometime around 10:00:01.250 the server is done processing select, > and sometime around 10:00:01.750 the client receives the responses > for the SELECT, and sends a FETCH for the message that arrived at > 10:00:00.000. At 10:00:02:250 the server receives a FETCH, which > completes at 10:00:02.300, and the client receives the FETCH response > very shortly after 10:00:02.800, and immediately sends another > IDLEPLUS. The server goes into IDLEPLUS mode very shortly after > 10:00:03.300, and announces any messages that arrive after that time, > but the message that arrived at 10:00:02.000 is not announced. For "very shortly after", please read "at", otherwise the transmission time of the FETCH response is partly accounted for twice. (0.050 seconds is reasonable only if the transmission time is included.) Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 27 06:36:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoemW-0008E3-3S; Mon, 27 Nov 2006 06:36:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoemU-0008CE-AZ for lemonade@ietf.org; Mon, 27 Nov 2006 06:36:14 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoemS-0002bW-U3 for lemonade@ietf.org; Mon, 27 Nov 2006 06:36:14 -0500 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, 27 Nov 2006 11:36:01 +0000 Message-ID: <4569DC81.5000807@isode.com> Date: Sun, 26 Nov 2006 18:27:13 +0000 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: Tony Finch 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: 7655788c23eb79e336f5f8ba8bce7906 Cc: lemonade@ietf.org Subject: [lemonade] SMTP AUTH and PIPELINING X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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: >Should the AUTH optimization be made mandatory? > Yes, RFC 4468 got approved and IESG didn't notice ;-). >I note that RFC 4468 fails >to say that it updates RFC 2554 despite the fact that it specifies a >change to AUTH's pipelining behaviour. > Which reminded me. I am updating RFC 2554, so I've added the following paragraph: When the AUTH command is used together with the [PIPELINING] extension, it is considered the last command in a pipelined group of commands. The only exception to this rule is when the AUTH command contains an initial response for a SASL mechanism that allows client to send data first and will complete in one round trip. Two examples of such SASL mechanisms are PLAIN [PLAIN] and EXTERNAL [SASL]. Does the new paragraph look alright? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 27 06:47:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goex7-0004S5-DJ; Mon, 27 Nov 2006 06:47:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goex5-0004Rd-O8 for lemonade@ietf.org; Mon, 27 Nov 2006 06:47:11 -0500 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Goex1-0004Ov-9v for lemonade@ietf.org; Mon, 27 Nov 2006 06:47:11 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.50) id 1Goews-00062w-Q6; Mon, 27 Nov 2006 11:46:59 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 3B5E4498005; Mon, 27 Nov 2006 12:00:36 +0000 (GMT) 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 25989-08-3; Mon, 27 Nov 2006 12:00:23 +0000 (GMT) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 9FE17498004; Mon, 27 Nov 2006 12:00:23 +0000 (GMT) Date: Mon, 27 Nov 2006 11:46:44 +0000 Subject: Re: [lemonade] SMTP AUTH and PIPELINING References: <4569DC81.5000807@isode.com> In-Reply-To: <4569DC81.5000807@isode.com> MIME-Version: 1.0 Message-Id: <8401.1164628006.024139@peirce.dave.cridland.net> From: Dave Cridland To: Alexey Melnikov Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Heisenberg-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Enhancements to Internet email to support diverse service enivronments , Tony Finch X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Sun Nov 26 18:27:13 2006, Alexey Melnikov wrote: > When the AUTH command is used together with the [PIPELINING] > extension, > it is considered the last command in a pipelined group of commands. > The only exception to this rule is when the AUTH command contains > an initial response for a SASL mechanism that allows client to send > data first and will complete in one round trip. Two examples of > such > SASL mechanisms are PLAIN [PLAIN] and EXTERNAL [SASL]. "and will definitely complete in one round trip", or "and is known to complete in one round-trip". DIGEST-MD5 *might* complete in one round-trip, but might not. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 27 08:07:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GogCf-0001J1-PZ; Mon, 27 Nov 2006 08:07:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GogCe-0001Ir-4N for lemonade@ietf.org; Mon, 27 Nov 2006 08:07:20 -0500 Received: from ppsw-2.csi.cam.ac.uk ([131.111.8.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GogCZ-0002Af-FE for lemonade@ietf.org; Mon, 27 Nov 2006 08:07:20 -0500 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]:47569) by ppsw-2.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.152]:25) with esmtpa (EXTERNAL:fanf2) id 1GogCO-0002lH-6z (Exim 4.63) (return-path ); Mon, 27 Nov 2006 13:07:04 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1GogCN-0003Al-Ah (Exim 4.54) (return-path ); Mon, 27 Nov 2006 13:07:03 +0000 Date: Mon, 27 Nov 2006 13:07:03 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Alexey Melnikov In-Reply-To: <4569DC81.5000807@isode.com> Message-ID: References: <4569DC81.5000807@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.2 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Tony Finch , lemonade@ietf.org Subject: [lemonade] Re: SMTP AUTH and PIPELINING X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Sun, 26 Nov 2006, Alexey Melnikov wrote: > > Which reminded me. I am updating RFC 2554, so I've added the following > paragraph: > > When the AUTH command is used together with the [PIPELINING] extension, > it is considered the last command in a pipelined group of commands. I would say "MUST be" rather than "is considered to be" since this is a requirement on the client. > The only exception to this rule is when the AUTH command contains > an initial response for a SASL mechanism that allows client to send > data first and will complete in one round trip. Two examples of such > SASL mechanisms are PLAIN [PLAIN] and EXTERNAL [SASL]. Otherwise that looks OK, with Dave's added "definitely". Tony. -- f.a.n.finch http://dotat.at/ HUMBER THAMES DOVER WIGHT: SOUTH OR SOUTHEAST 5 TO 7, OCCASIONALLY GALE 8. MODERATE OR ROUGH. OCCASIONAL RAIN OR SHOWERS. GOOD OCCASIONALLY MODERATE. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 27 08:48:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gogqm-0003Ce-HI; Mon, 27 Nov 2006 08:48:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GogpZ-0001F6-76 for lemonade@ietf.org; Mon, 27 Nov 2006 08:47:33 -0500 Received: from moutng.kundenserver.de ([212.227.126.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gogmt-0000bx-6a for lemonade@ietf.org; Mon, 27 Nov 2006 08:44:51 -0500 Received: from [84.160.204.178] (helo=noname) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1Gogmr1ygr-00007W; Mon, 27 Nov 2006 14:44:46 +0100 From: Martin Konold Organization: erfrakon To: lemonade@ietf.org Subject: Re: [lemonade] draft-gulbrandsen-imap-notify-01 use cases Date: Mon, 27 Nov 2006 14:44:38 +0100 User-Agent: KMail/1.9.5 References: <200611221836.21718.martin.konold@erfrakon.de> <4994.1164282472.445097@peirce.dave.cridland.net> In-Reply-To: <4994.1164282472.445097@peirce.dave.cridland.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611271444.39648.martin.konold@erfrakon.de> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:b04c3ed30b43fd5a3d557b6dbc75a710 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Am Donnerstag, 23. November 2006 12:47 schrieb Dave Cridland: Hi > The problem then is that you have to decide whether IDLEPLUS gets > notifications for mailboxes the other session has selected. If you > do, then you have essentially doubled the bandwidth cost of > notifications, since they'll get transmitted once on the mailbox > connection and once on the IDLEPLUS connection. IDLEPLUS emphasizes optimization for upload not download stream. The upload stream is the bottleneck in most modern high latency networks like ADSL and UMTS. > session, which is perhaps even more confusing. So the client has to > ignore notifications on the IDLEPLUS connection for selected > mailboxes in other sessions anyway. The client has to ignore the unsolicited notification on the non IDLEPLUS selection as these messages are unreliable anyway! This allows for simpler client implementation. The extra bandwidth can imho be neglected. Due to the fact that they are unreliable anyway the server might optimize them away anyway. Yours, -- martin -- http://www.erfrakon.com/ Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 27 08:51:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gogt5-00065e-AV; Mon, 27 Nov 2006 08:51:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gogt3-00065U-M3 for lemonade@ietf.org; Mon, 27 Nov 2006 08:51:09 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gogt2-000221-72 for lemonade@ietf.org; Mon, 27 Nov 2006 08:51:09 -0500 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, 27 Nov 2006 13:51:06 +0000 Message-ID: <456AED38.6030604@isode.com> Date: Mon, 27 Nov 2006 13:50:48 +0000 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: Tony Finch References: <4569DC81.5000807@isode.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: lemonade@ietf.org Subject: [lemonade] Re: SMTP AUTH and PIPELINING X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 Sun, 26 Nov 2006, Alexey Melnikov wrote: > > >>Which reminded me. I am updating RFC 2554, so I've added the following >>paragraph: >> >> When the AUTH command is used together with the [PIPELINING] extension, >> it is considered the last command in a pipelined group of commands. >> >> >I would say "MUST be" rather than "is considered to be" since this is a >requirement on the client. > > Done. Thanks. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 27 08:56:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gogy4-0000SB-HD; Mon, 27 Nov 2006 08:56:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gogy3-0000Rz-Lv for lemonade@ietf.org; Mon, 27 Nov 2006 08:56:19 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gogy2-0002eX-7W for lemonade@ietf.org; Mon, 27 Nov 2006 08:56:19 -0500 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, 27 Nov 2006 13:56:16 +0000 Message-ID: <456AEE77.5070307@isode.com> Date: Mon, 27 Nov 2006 13:56:07 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Dave Cridland Subject: Re: [lemonade] SMTP AUTH and PIPELINING References: <4569DC81.5000807@isode.com> <8401.1164628006.024139@peirce.dave.cridland.net> In-Reply-To: <8401.1164628006.024139@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: 7d33c50f3756db14428398e2bdedd581 Cc: Enhancements to Internet email to support diverse service enivronments , Tony Finch X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 Sun Nov 26 18:27:13 2006, Alexey Melnikov wrote: > >> When the AUTH command is used together with the [PIPELINING] extension, >> it is considered the last command in a pipelined group of commands. >> The only exception to this rule is when the AUTH command contains >> an initial response for a SASL mechanism that allows client to send >> data first and will complete in one round trip. Two examples of such >> SASL mechanisms are PLAIN [PLAIN] and EXTERNAL [SASL]. > > > "and will definitely complete in one round trip", or "and is known to > complete in one round-trip". I've used the latter. Thanks! > DIGEST-MD5 *might* complete in one round-trip, but might not. Right. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Nov 27 10:58:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gois9-0002Eg-U3; Mon, 27 Nov 2006 10:58:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goip8-0000jo-Ke; Mon, 27 Nov 2006 10:55:14 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Goika-00006m-Dj; Mon, 27 Nov 2006 10:50:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 2425D1759B; Mon, 27 Nov 2006 15:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Goik5-0007Na-Nl; Mon, 27 Nov 2006 10:50:01 -0500 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, 27 Nov 2006 10:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-compress-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 : The IMAP COMPRESS Extension Author(s) : A. Gulbrandsen Filename : draft-ietf-lemonade-compress-06.txt Pages : 10 Date : 2006-11-27 The COMPRESS extension allows an IMAP connection to be effectively and efficiently compressed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-compress-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-compress-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-compress-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: <2006-11-27093903.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-compress-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-compress-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-27093903.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --NextPart-- From lemonade-bounces@ietf.org Mon Nov 27 15:50:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GonR4-0004FZ-Iw; Mon, 27 Nov 2006 15:50:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GonQu-0003vf-4y; Mon, 27 Nov 2006 15:50:32 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GonQt-0004g3-Qi; Mon, 27 Nov 2006 15:50:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id B9DC92ACBC; Mon, 27 Nov 2006 20:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GonQP-0001FF-GP; Mon, 27 Nov 2006 15:50:01 -0500 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, 27 Nov 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-client-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 : IMAP4 Extensions for Quick Mailbox Resynchronization Author(s) : A. Melnikov, et al. Filename : draft-ietf-lemonade-reconnect-client-02.txt Pages : 25 Date : 2006-11-27 This document defines an IMAP4 extension, which gives an IMAP client the ability to quickly resynchronize any previously opened mailbox as part of the SELECT command, without the need for server-side state or additional client round-trips. This extension also introduces a new response that allows for a more compact representation for a list of expunged messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-reconnect-client-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-reconnect-client-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-reconnect-client-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-11-27101424.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-reconnect-client-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-reconnect-client-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-27101424.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --NextPart-- From lemonade-bounces@ietf.org Mon Nov 27 17:10:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoogF-0003Qg-Cb; Mon, 27 Nov 2006 17:10:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoogE-0003QV-5c for lemonade@ietf.org; Mon, 27 Nov 2006 17:10:26 -0500 Received: from smtp.andrew.cmu.edu ([128.2.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoogC-00006D-AO for lemonade@ietf.org; Mon, 27 Nov 2006 17:10:25 -0500 Received: from [192.168.137.22] (ntonawnd-cuda1-cable-bundle-68-69-73-26.kntnny.adelphia.net [68.69.73.26]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.6/8.13.6) with ESMTP id kARMAOa3020900 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 27 Nov 2006 17:10:25 -0500 Message-ID: <456B624E.9070406@andrew.cmu.edu> Date: Mon, 27 Nov 2006 17:10:22 -0500 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Thunderbird 1.5.0.7 (X11/20060913) MIME-Version: 1.0 To: Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] Re: I-D ACTION:draft-ietf-lemonade-compress-05.txt References: <5897.1160043366.572711@peirce.dave.cridland.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 128.2.10.81 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Randall Gellens wrote: > At 11:16 AM +0100 10/5/06, Dave Cridland wrote: > >> With SASL, the negotiation takes place above the compression layer, >> but the security layer (if any) happens below the compression. > > The wording I suggested tries to be careful to only talk about a SASL > security layer, not the SASL negotiation. If we want to make this more > explicit, we could add a one-sentence paragraph to this affect before > the text. > >> With TLS, I assume the negotiation happens below the compression >> layer, if any, not above. > > Do we want to have text recommending the order that clients issue > STARTTLS, AUTHENTICATE, and COMPRESS? I know we discussed this a while > back, with some difference of opinion as to if authentication should be > done before or after compression. If I recall correctly, doing > compression before authentication saves bandwidth, but doing it after > makes it easier to debug. > > Presumably, we would add new one-sentence paragraph along the lines of: > > "Clients making use of TLS, SASL authentication, and compression SHOULD > issue these commands in the following order: first STARTTLS, then > AUTHENTICATE, and finally COMPRESS." > > (Or swap COMPRESS and AUTHENTICATE if that is the way we want to go.) I notice that no such wording was added to -06 and I'm wondering why. Unless I'm reading -06 incorrectly, if we allow the COMPRESS command before STARTTLS, then we compress the TLS records during the TLS negotiation, but then once the negotiation is complete we stop compressing the whole TLS records and just compress the application data in the records. In order to have some uniformity, I'd suggest that we either state that the COMPRESS command MUST NOT be used prior to STARTTLS, or we change the ordering in how we process data such that the compression is the outermost layer rather than the innermost layer. My preference is the former since its easier to implement IMHO. Unless there is a *huge* benefit to compressing the SASL exchange, why not just enforce the order of the commands as STARTTLS, LOGIN/AUTHENTICATE, COMPRESS (note that 3501 already enforces STARTTLS before LOGIN/AUTHENTICATE) which would make COMPRESS a 'command-auth' rather than a 'command-any' in the ABNF. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Nov 28 15:50:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp9uW-0007TR-AT; Tue, 28 Nov 2006 15:50:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp9uS-0007R8-Bt; Tue, 28 Nov 2006 15:50:32 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gp9uS-0005U6-2m; Tue, 28 Nov 2006 15:50:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id E2AAD2AC65; Tue, 28 Nov 2006 20:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gp9tx-0001AR-Lj; Tue, 28 Nov 2006 15:50:01 -0500 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, 28 Nov 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-rfc2192bis-03.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to Support Diverse Service Environments Working Group of the IETF. Title : IMAP URL Scheme Author(s) : A. Melnikov, et al. Filename : draft-ietf-lemonade-rfc2192bis-03.txt Pages : 30 Date : 2006-11-28 IMAP [IMAP4] 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-rfc2192bis-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-rfc2192bis-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-rfc2192bis-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-11-28114755.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-rfc2192bis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-rfc2192bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-28114755.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --NextPart-- From lemonade-bounces@ietf.org Wed Nov 29 08:06:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpP8Y-0003wm-Kb; Wed, 29 Nov 2006 08:06:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpP8X-0003wM-Cz for lemonade@ietf.org; Wed, 29 Nov 2006 08:06:05 -0500 Received: from outbound.cantata.com ([208.236.123.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpP8T-00069h-3P for lemonade@ietf.org; Wed, 29 Nov 2006 08:06:05 -0500 Received: from ma02exchtmp01.Cantata.com ([10.128.18.41]) by outbound.Cantata.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Nov 2006 08:05:58 -0500 Received: from 10.129.49.155 ([10.129.49.155]) by ma02exchtmp01.Cantata.com ([10.128.18.41]) with Microsoft Exchange Server HTTP-DAV ; Wed, 29 Nov 2006 13:05:58 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Wed, 29 Nov 2006 08:05:40 -0500 From: Eric Burger To: IETF LEMONADE Message-ID: Thread-Topic: WGLC (agian) Reconnect Client Thread-Index: AccTtxGvUG95un+qEduDuwAWy5cvmw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 29 Nov 2006 13:05:58.0859 (UTC) FILETIME=[1CED11B0:01C713B7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [lemonade] WGLC (agian) Reconnect Client X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Because of the number of changes during the last WGLC, we will have another work group last call on Reconnect Client: or WGLC closes December 13, 2006 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 29 10:22:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpRGI-0003OR-Hv; Wed, 29 Nov 2006 10:22:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpRGA-0002oi-Vd for lemonade@ietf.org; Wed, 29 Nov 2006 10:22:07 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpRBN-00060o-TI for lemonade@ietf.org; Wed, 29 Nov 2006 10:17:12 -0500 Received: from prosecco.oryx.com (prosecco.oryx.com [195.30.37.38]) by kalyani.oryx.com (Postfix) with ESMTP id 17F9A4AC7A; Wed, 29 Nov 2006 16:16:53 +0100 (CET) Message-Id: Date: Wed, 29 Nov 2006 16:15:21 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Re: I-D ACTION:draft-ietf-lemonade-compress-05.txt References: <456B624E.9070406@andrew.cmu.edu> In-Reply-To: <456B624E.9070406@andrew.cmu.edu> Content-Type: text/plain; format=flowed MIME-Version: 1.0 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 Ken Murchison writes: > I notice that no such wording was added to -06 and I'm wondering why. Because I messed up. Edited both on my officebox and my laptop, and forgot to merge. A very simple operation, really, but I didn't do it. Mea culpa. Three documents suffered. You know two of them already, the third is NOTIFY, whose -02 revision omits the word 'messages' in a critical spot. But I like your suggestion better than the text I had typed: > Unless there is a *huge* benefit to compressing the SASL exchange, why > not just enforce the order of the commands as STARTTLS, > LOGIN/AUTHENTICATE, COMPRESS (note that 3501 already enforces > STARTTLS before LOGIN/AUTHENTICATE) which would make COMPRESS a > 'command-auth' rather than a 'command-any' in the ABNF. (I wasn't aware of the mandate in 3501.) The SASL exchange occurs just one per connection in the common case, so personally I don't care about compressing it. O(1) is O(1) is O(1). Besides AUTHENTICATE disturbs compression by using base64, so I doubt that it would be compressed very much. Could we do this? Switch to command-auth and done? Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 29 10:50:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpRi5-0001qc-5v; Wed, 29 Nov 2006 10:50:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpRhp-0001Qg-Ps for lemonade@ietf.org; Wed, 29 Nov 2006 10:50:41 -0500 Received: from smtp.andrew.cmu.edu ([128.2.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpRho-0004gW-Hj for lemonade@ietf.org; Wed, 29 Nov 2006 10:50:41 -0500 Received: from [192.168.137.22] (ntonawnd-cuda1-cable-bundle-68-69-73-26.kntnny.adelphia.net [68.69.73.26]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.6/8.13.6) with ESMTP id kATFodaW009471 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 29 Nov 2006 10:50:39 -0500 Message-ID: <456DAC4E.2060604@andrew.cmu.edu> Date: Wed, 29 Nov 2006 10:50:38 -0500 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Thunderbird 1.5.0.7 (X11/20060913) MIME-Version: 1.0 To: Arnt Gulbrandsen Subject: Re: [lemonade] Re: I-D ACTION:draft-ietf-lemonade-compress-05.txt References: <456B624E.9070406@andrew.cmu.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 128.2.10.81 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 Arnt Gulbrandsen wrote: > Ken Murchison writes: >> I notice that no such wording was added to -06 and I'm wondering why. > > Because I messed up. Edited both on my officebox and my laptop, and > forgot to merge. A very simple operation, really, but I didn't do it. > Mea culpa. Three documents suffered. You know two of them already, the > third is NOTIFY, whose -02 revision omits the word 'messages' in a > critical spot. > > But I like your suggestion better than the text I had typed: > >> Unless there is a *huge* benefit to compressing the SASL exchange, why >> not just enforce the order of the commands as STARTTLS, >> LOGIN/AUTHENTICATE, COMPRESS (note that 3501 already enforces STARTTLS >> before LOGIN/AUTHENTICATE) which would make COMPRESS a 'command-auth' >> rather than a 'command-any' in the ABNF. > > (I wasn't aware of the mandate in 3501.) Its not *real* explicit, but all 3 are command-nonauth, but only LOGIN and AUTHENTICATE move you to authenticated state. Therefore, STARTTLS can not be used after LOGIN/AUTHENTICATE. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 29 11:34:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpSNo-0008FY-Ty; Wed, 29 Nov 2006 11:34:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpSNm-0007ss-OM for lemonade@ietf.org; Wed, 29 Nov 2006 11:34:02 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpSNk-0004UZ-Bh for lemonade@ietf.org; Wed, 29 Nov 2006 11:34:02 -0500 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, 29 Nov 2006 16:33:59 +0000 Message-ID: <456DB66D.4010600@isode.com> Date: Wed, 29 Nov 2006 16:33:49 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Arnt Gulbrandsen Subject: Re: [lemonade] Re: I-D ACTION:draft-ietf-lemonade-compress-05.txt References: <456B624E.9070406@andrew.cmu.edu> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Arnt Gulbrandsen wrote: >> Unless there is a *huge* benefit to compressing the SASL exchange, >> why not just enforce the order of the commands as STARTTLS, >> LOGIN/AUTHENTICATE, COMPRESS (note that 3501 already enforces >> STARTTLS before LOGIN/AUTHENTICATE) which would make COMPRESS a >> 'command-auth' rather than a 'command-any' in the ABNF. > > (I wasn't aware of the mandate in 3501.) > > The SASL exchange occurs just one per connection in the common case, > so personally I don't care about compressing it. O(1) is O(1) is O(1). > Besides AUTHENTICATE disturbs compression by using base64, so I doubt > that it would be compressed very much. > > Could we do this? Switch to command-auth and done? I am fine with this change. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 29 15:12:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpVmx-0000Wx-29; Wed, 29 Nov 2006 15:12:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpVmw-0000Wq-5b for lemonade@ietf.org; Wed, 29 Nov 2006 15:12:14 -0500 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpVmu-0004To-Rx for lemonade@ietf.org; Wed, 29 Nov 2006 15:12:14 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.50) id 1GpVmt-0001CX-NQ; Wed, 29 Nov 2006 20:12:11 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id D1A96498005; Wed, 29 Nov 2006 20:26:12 +0000 (GMT) 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 26181-08; Wed, 29 Nov 2006 20:25:58 +0000 (GMT) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id B26EE498004; Wed, 29 Nov 2006 20:25:58 +0000 (GMT) Date: Wed, 29 Nov 2006 20:11:55 +0000 Subject: Re: [lemonade] Re: I-D ACTION:draft-ietf-lemonade-compress-05.txt References: <456B624E.9070406@andrew.cmu.edu> <456DB66D.4010600@isode.com> In-Reply-To: <456DB66D.4010600@isode.com> MIME-Version: 1.0 Message-Id: <21413.1164831117.372426@peirce.dave.cridland.net> From: Dave Cridland To: Alexey Melnikov Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Heisenberg-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed Nov 29 16:33:49 2006, Alexey Melnikov wrote: > Arnt Gulbrandsen wrote: > >>> Unless there is a *huge* benefit to compressing the SASL >>> exchange, why not just enforce the order of the commands as >>> STARTTLS, LOGIN/AUTHENTICATE, COMPRESS (note that 3501 already >>> enforces STARTTLS before LOGIN/AUTHENTICATE) which would make >>> COMPRESS a 'command-auth' rather than a 'command-any' in the ABNF. >> >> (I wasn't aware of the mandate in 3501.) >> >> The SASL exchange occurs just one per connection in the common >> case, so personally I don't care about compressing it. O(1) is >> O(1) is O(1). Besides AUTHENTICATE disturbs compression by using >> base64, so I doubt that it would be compressed very much. >> >> Could we do this? Switch to command-auth and done? > > I am fine with this change. I don't really see the need, and all my implementations handle, and expect, COMPRESS between TLS and SASL negotiations. (All of them also handle TLS, SASL, and COMPRESS simultaneously). I don't think the difficulty lies in the implementation, I think it lies in the specification. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 29 17:01:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpXUY-0005Ss-Sp; Wed, 29 Nov 2006 17:01:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpXUX-0005Sm-Ly for lemonade@ietf.org; Wed, 29 Nov 2006 17:01:21 -0500 Received: from smtp.andrew.cmu.edu ([128.2.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpXUV-0003hU-LT for lemonade@ietf.org; Wed, 29 Nov 2006 17:01:21 -0500 Received: from [192.168.137.22] (ntonawnd-cuda1-cable-bundle-68-69-73-26.kntnny.adelphia.net [68.69.73.26]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.6/8.13.6) with ESMTP id kATM1HS1012793 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 29 Nov 2006 17:01:18 -0500 Message-ID: <456E032C.70102@andrew.cmu.edu> Date: Wed, 29 Nov 2006 17:01:16 -0500 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Thunderbird 1.5.0.7 (X11/20060913) MIME-Version: 1.0 To: Dave Cridland Subject: Re: [lemonade] Re: I-D ACTION:draft-ietf-lemonade-compress-05.txt References: <456B624E.9070406@andrew.cmu.edu> <456DB66D.4010600@isode.com> <21413.1164831117.372426@peirce.dave.cridland.net> In-Reply-To: <21413.1164831117.372426@peirce.dave.cridland.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 128.2.10.81 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Enhancements to Internet email to support diverse service enivronments , Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dave Cridland wrote: > On Wed Nov 29 16:33:49 2006, Alexey Melnikov wrote: >> Arnt Gulbrandsen wrote: >> >>>> Unless there is a *huge* benefit to compressing the SASL exchange, >>>> why not just enforce the order of the commands as STARTTLS, >>>> LOGIN/AUTHENTICATE, COMPRESS (note that 3501 already enforces >>>> STARTTLS before LOGIN/AUTHENTICATE) which would make COMPRESS a >>>> 'command-auth' rather than a 'command-any' in the ABNF. >>> >>> (I wasn't aware of the mandate in 3501.) >>> >>> The SASL exchange occurs just one per connection in the common case, >>> so personally I don't care about compressing it. O(1) is O(1) is >>> O(1). Besides AUTHENTICATE disturbs compression by using base64, so I >>> doubt that it would be compressed very much. >>> >>> Could we do this? Switch to command-auth and done? >> >> I am fine with this change. > > I don't really see the need, and all my implementations handle, and > expect, COMPRESS between TLS and SASL negotiations. (All of them also > handle TLS, SASL, and COMPRESS simultaneously). Just to be clear, you support: STARTTLS AUTHENTICATE COMPRESS and STARTTLS COMPRESS AUTHENTICATE but do NOT support: COMPRESS STARTTLS AUTHENTICATE -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 29 17:37:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpY33-0006Vv-CD; Wed, 29 Nov 2006 17:37:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpY32-0006Vq-9s for lemonade@ietf.org; Wed, 29 Nov 2006 17:37:00 -0500 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpY2z-0008Jv-RG for lemonade@ietf.org; Wed, 29 Nov 2006 17:37:00 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1GpY2y-0005UR-JK; Wed, 29 Nov 2006 22:36:56 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id B0723498005; Wed, 29 Nov 2006 22:50:58 +0000 (GMT) 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 28322-10; Wed, 29 Nov 2006 22:50:54 +0000 (GMT) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 65C0E498003; Wed, 29 Nov 2006 22:50:54 +0000 (GMT) Date: Wed, 29 Nov 2006 22:36:51 +0000 Subject: Re: [lemonade] Re: I-D ACTION:draft-ietf-lemonade-compress-05.txt References: <456B624E.9070406@andrew.cmu.edu> <456DB66D.4010600@isode.com> <21413.1164831117.372426@peirce.dave.cridland.net> <456E032C.70102@andrew.cmu.edu> In-Reply-To: <456E032C.70102@andrew.cmu.edu> MIME-Version: 1.0 Message-Id: <21413.1164839812.042173@peirce.dave.cridland.net> From: Dave Cridland To: Ken Murchison Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Rutherford-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Enhancements to Internet email to support diverse service enivronments , Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed Nov 29 22:01:16 2006, Ken Murchison wrote: > Dave Cridland wrote: >> On Wed Nov 29 16:33:49 2006, Alexey Melnikov wrote: >>> Arnt Gulbrandsen wrote: >>> >>>>> Unless there is a *huge* benefit to compressing the SASL >>>>> exchange, why not just enforce the order of the commands as >>>>> STARTTLS, LOGIN/AUTHENTICATE, COMPRESS (note that 3501 already >>>>> enforces STARTTLS before LOGIN/AUTHENTICATE) which would make >>>>> COMPRESS a 'command-auth' rather than a 'command-any' in the >>>>> ABNF. >>>> >>>> (I wasn't aware of the mandate in 3501.) >>>> >>>> The SASL exchange occurs just one per connection in the common >>>> case, so personally I don't care about compressing it. O(1) is >>>> O(1) is O(1). Besides AUTHENTICATE disturbs compression by using >>>> base64, so I doubt that it would be compressed very much. >>>> >>>> Could we do this? Switch to command-auth and done? >>> >>> I am fine with this change. >> >> I don't really see the need, and all my implementations handle, >> and expect, COMPRESS between TLS and SASL negotiations. (All of >> them also handle TLS, SASL, and COMPRESS simultaneously). > > Just to be clear, you support: > > STARTTLS > AUTHENTICATE > COMPRESS > > and > > STARTTLS > COMPRESS > AUTHENTICATE > > but do NOT support: > > COMPRESS > STARTTLS > AUTHENTICATE No, that's supported too. My client doesn't do that, but it could do. It doesn't, primarily because that ordering doesn't make sense, since TLS might provide compression anyway, removing the need for the additional round-trip. (Assuming your TLS library bothers to tell you, of course). It would, however, be really difficult to support if TLS negotiation happened above the compression layer - the negotiation would be hard, but renegotiations would be exceedingly painful to deal with. That's why I mentioned this edge-case a while back - it's obvious what should happen, but it's difficult to put into words. What about: Independent of the ordering of the STARTTLS, COMPRESS, and AUTHENTICATE commands, the ordering of the resultant layers is always, from top to bottom: IMAP, COMPRESS, SASL, TLS, TCP. For all these commands, the layers exist after the command has successfully completed; in particular this means that SASL negotiation occurs in the IMAP layer, and therefore will be compressed by any COMPRESS layer present, then encrypted by any TLS layer present, and finally transmitted by TCP. TLS negotiation happens after the STARTTLS command, within the new TLS layer. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Nov 29 18:18:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpYhW-0000aZ-19; Wed, 29 Nov 2006 18:18:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpYhU-0000aJ-LE for lemonade@ietf.org; Wed, 29 Nov 2006 18:18:48 -0500 Received: from moutng.kundenserver.de ([212.227.126.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpYhO-000656-CS for lemonade@ietf.org; Wed, 29 Nov 2006 18:18:48 -0500 Received: from [84.160.200.38] (helo=noname) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1GpYhN2Y03-0005P1; Thu, 30 Nov 2006 00:18:41 +0100 From: Martin Konold Organization: erfrakon To: lemonade@ietf.org Subject: Re: [lemonade] Re: I-D ACTION:draft-ietf-lemonade-compress-05.txt Date: Thu, 30 Nov 2006 00:18:38 +0100 User-Agent: KMail/1.9.5 References: <456B624E.9070406@andrew.cmu.edu> <456E032C.70102@andrew.cmu.edu> <21413.1164839812.042173@peirce.dave.cridland.net> In-Reply-To: <21413.1164839812.042173@peirce.dave.cridland.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611300018.39319.martin.konold@erfrakon.de> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:b04c3ed30b43fd5a3d557b6dbc75a710 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Am Mittwoch, 29. November 2006 23:36 schrieb Dave Cridland: Hi, > > but do NOT support: > > > > COMPRESS > > STARTTLS > > AUTHENTICATE I propose not support COMPRESS before STARTTLS for security reasons. IMHO this would add an unnecessary extra attack vector without good reason. The server administrator should be able to enforce the certificate exchange as soon as possible in order to limit many potential attacks to authenticate users. (think about client certifcates) > AUTHENTICATE commands, the ordering of the resultant layers is > always, from top to bottom: IMAP, COMPRESS, SASL, TLS, TCP. I fully agree. Regards, -- martin -- http://www.erfrakon.com/ Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Nov 30 03:07:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpgwq-0006tr-JD; Thu, 30 Nov 2006 03:07:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpgwo-0006on-Ck for lemonade@ietf.org; Thu, 30 Nov 2006 03:07:10 -0500 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpgwm-00026F-UH for lemonade@ietf.org; Thu, 30 Nov 2006 03:07:10 -0500 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 kAU7rkG11994 for ; Thu, 30 Nov 2006 07:53:47 GMT 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] Re: I-D ACTION:draft-ietf-lemonade-compress-05.txt Date: Thu, 30 Nov 2006 08:06:21 -0000 Message-ID: <22C8A0D5D5E095449AB509FE777B5F80033B0D58@svr-exchange.avocado.emccsoft.com> In-Reply-To: <21413.1164839812.042173@peirce.dave.cridland.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Re: I-D ACTION:draft-ietf-lemonade-compress-05.txt Thread-Index: AccUBv0vH1jgWAY6R6+gra/jqOnemwATzYog From: "Ben Last" To: "Dave Cridland" , X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org >From: Dave Cridland [mailto:dave@cridland.net]=20 >What about: >Independent of the ordering of the STARTTLS, COMPRESS, and AUTHENTICATE commands, the ordering >of the resultant layers is always, from top to bottom: IMAP, COMPRESS, SASL, TLS, TCP. For all >these commands, the layers exist after the command has successfully completed; in particular >this means that SASL negotiation occurs in the IMAP layer, and therefore will be compressed by >any COMPRESS layer present, then encrypted by any TLS layer present, and finally transmitted >by TCP. TLS negotiation happens after the STARTTLS command, within the new TLS layer. Now that is very good; makes the ordering clear and also provides a model of how the protocols encapsulate each other. Fully agree. Regards Ben Ben Last R&D Manager EMCC Software Ltd _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade