From lemonade-bounces@ietf.org Wed Mar 01 01:40:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEL0I-0003t3-NX; Wed, 01 Mar 2006 01:40:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEL0H-0003sy-7U for lemonade@ietf.org; Wed, 01 Mar 2006 01:40:05 -0500 Received: from monkey.teamware.com ([62.61.83.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEL0F-0007YB-Pb for lemonade@ietf.org; Wed, 01 Mar 2006 01:40:05 -0500 Received: from intrepid (intrepid.teamw.com [10.142.128.11]) by monkey.teamware.com (8.13.1/8.13.1) with ESMTP id k216hcb9018936 for ; Wed, 1 Mar 2006 08:43:39 +0200 Received: from [10.142.130.127] ([10.142.130.127]) by intrepid with ESMTP id m318mai2; 1 Mar 2006 08:58:00 +0200 Message-ID: <440541B7.5030105@teamware.com> Date: Wed, 01 Mar 2006 08:39:51 +0200 From: Antony Bowesman Organization: Teamware Group User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] final future release question (I think) References: <027501c63cd2$26b7b450$6401a8c0@gawhitelaptop> <28755.1141179949.810563@peirce.dave.cridland.net> In-Reply-To: <28755.1141179949.810563@peirce.dave.cridland.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TWG-MailScanner-Information: Please contact the ISP for more information X-TWG-MailScanner: Found to be clean X-TWG-MailScanner-SpamCheck: not spam, SpamAssassin (score=0, required 5, autolearn=not spam) X-MailScanner-From: adb@teamware.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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: >> Consequently, my vote is against your proposal, and for HOLDFOR= and >> HOLDUNTIL= as previously discussed. Agreed Antony _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Mar 01 22:21:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEeNo-0004Io-RI; Wed, 01 Mar 2006 22:21:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEeNo-0004H0-0P for lemonade@ietf.org; Wed, 01 Mar 2006 22:21:40 -0500 Received: from ppsw-7.csi.cam.ac.uk ([131.111.8.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEeNj-0007Ea-IP for lemonade@ietf.org; Wed, 01 Mar 2006 22:21:39 -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-2.csi.cam.ac.uk ([131.111.8.54]:34306) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1FEeNV-0008Ty-Op (Exim 4.54) (return-path ); Thu, 02 Mar 2006 03:21:21 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1FEeNV-0000GD-LQ (Exim 4.53) (return-path ); Thu, 02 Mar 2006 03:21:21 +0000 Date: Thu, 2 Mar 2006 03:21:21 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] SMTP QUICKSTART In-Reply-To: Message-ID: References: <25269.1140724067.114807@invsysm1> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I've been doing some implementation experiments with OpenSSL. It's fairly easy to pipeline from both ends before the TLS startup, so you could do something like this: C --> S: QTLS\r\n TLS client hello C <-- S: 220 OK\r\r TLS server hello etc. The idea is to treat the QTLS command a bit like BDAT, i.e. it incorporates trailing binary data. If the SMTP handshaking goes wrong, the server could swallow the TLS client hello and they could resynchronize. The "going wrong" could occur if the client pipelines QHLO and QTLS into the same packet as its TCP SYN, and the server has unexpectedly changed. The recovery from this should be as simple as the client re-sending a corrected hello sequence, rather than a disconnection and reconnection. In the successful case, the start-up exchange will require the same number of round trips as TLS-on-connect. There are a few implementation complications: OpenSSL doesn't expose its client hello parsing code in a way that's convenient to use without also getting the server's response - though juggling BIO layers could probably deal with that. However it might be better to implement a purely syntactic check for the failure case, to avoid running a load of protocol logic that isn't going to be used. The end of the TLS handshake is less happy than the start - it's quite inconvenient to hook in to OpenSSL's negotiation code to piggy-back application data onto its final packets. There is a tiny bit of support for doing so at the client end after a session cache hit, but not at the server end, e.g. for a capability banner. I need to do more investigation to come up with a work-around or patch. Tony. -- f.a.n.finch http://dotat.at/ GERMAN BIGHT HUMBER THAMES: NORTHWEST 6 OR 7 DECREASING 4 OR 5, BECOMING VARIABLE 3 OR 4 IN NORTH GERMAN BIGHT. WINTRY SHOWERS. MODERATE OR GOOD. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Mar 02 04:52:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEkU7-0000ew-8P; Thu, 02 Mar 2006 04:52:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEkU5-0000br-Op for lemonade@ietf.org; Thu, 02 Mar 2006 04:52:33 -0500 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEkU5-0006Ql-Bo for lemonade@ietf.org; Thu, 02 Mar 2006 04:52:33 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.34) id 1FEkU2-00065F-4M; Thu, 02 Mar 2006 09:52:30 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id CAA8E498003; Thu, 2 Mar 2006 09:53:56 +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 05864-10; Thu, 2 Mar 2006 09:53:53 +0000 (GMT) Received: from JOHN (unknown [IPv6:2001:4bd0:2029:0:588c:6650:27f5:87b7]) by turner.dave.cridland.net (Postfix) with ESMTP id 113E7498002; Thu, 2 Mar 2006 09:53:52 +0000 (GMT) Date: Thu, 02 Mar 2006 09:54:16 +0000 Subject: Re: [lemonade] SMTP QUICKSTART References: <25269.1140724067.114807@invsysm1> In-Reply-To: MIME-Version: 1.0 Message-Id: <3732.1141293257.933000@JOHN> From: Dave Cridland To: 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-Rutherford-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu Mar 02 03:21:21 2006, Tony Finch wrote: > I've been doing some implementation experiments with OpenSSL. It's > fairly > easy to pipeline from both ends before the TLS startup, so you could > do something like this: > > C --> S: QTLS\r\n > TLS client hello > C <-- S: 220 OK\r\r > TLS server hello etc. > > Two things on this: First, I think that even if you can do this on OpenSSL, it's going to be really tricky to do on enough existing mobile platforms that it's not worth doing. It might be better to do: C --> S: QTLS\r\n C --> S: TLS Hello S --> C: TLS Hello This is rather weird - a SMTP command which has no response - but the specification informally proposed for QTLS suggests that it has no possible failure mode - it's 220 or sever the connection. By omitting it, then it's relatively easy to take advantage of it. Remember that pipelining has two features - not waiting for a response, and sending within the same packet - you don't have to use both features at the same time. > The idea is to treat the QTLS command a bit like BDAT, i.e. it > incorporates trailing binary data. If the SMTP handshaking goes > wrong, the > server could swallow the TLS client hello and they could > resynchronize. > The "going wrong" could occur if the client pipelines QHLO and QTLS > into > the same packet as its TCP SYN, and the server has unexpectedly > changed. > The recovery from this should be as simple as the client re-sending > a > corrected hello sequence, rather than a disconnection and > reconnection. In > the successful case, the start-up exchange will require the same > number of > round trips as TLS-on-connect. > > Okay, I think think isn't going in the right direction. I think the scenario of: C: TCP: SYN Data: None S: TCP: SYN+ACK Data: Banner with capabilities C: QTLS, TLS Hello etc gains you the same round-trips as SMTPS, and the same level of robustness as existing STARTTLS, but means the server has to have the tricky bits. Plus, I don't think that data in the SYN is a good idea, since it makes SYN based attacks very much harder to deal with. This does skew the overall protocol in favour of server operating systems that can be made to provide an API to sending data in SYN+ACK packets, of course, but that's simpler than dealing with every potential client operating system and TLS implementation. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Mar 02 08:02:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEnSD-0000Ve-2F; Thu, 02 Mar 2006 08:02:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEnSC-0000VZ-AT for lemonade@ietf.org; Thu, 02 Mar 2006 08:02:48 -0500 Received: from ppsw-7.csi.cam.ac.uk ([131.111.8.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEnS8-00050D-Si for lemonade@ietf.org; Thu, 02 Mar 2006 08:02:48 -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-2.csi.cam.ac.uk ([131.111.8.54]:34757) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1FEnRK-0007NZ-NC (Exim 4.54) (return-path ); Thu, 02 Mar 2006 13:01:54 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1FEnRK-0008Sf-5B (Exim 4.53) (return-path ); Thu, 02 Mar 2006 13:01:54 +0000 Date: Thu, 2 Mar 2006 13:01:54 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Dave Cridland Subject: Re: [lemonade] SMTP QUICKSTART In-Reply-To: <3732.1141293257.933000@JOHN> Message-ID: References: <25269.1140724067.114807@invsysm1> <3732.1141293257.933000@JOHN> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu, 2 Mar 2006, Dave Cridland wrote: > > First, I think that even if you can do this on OpenSSL, it's going to be > really tricky to do on enough existing mobile platforms that it's not worth > doing. It might be better to do: > > C --> S: QTLS\r\n > C --> S: TLS Hello > S --> C: TLS Hello > > This is rather weird - a SMTP command which has no response - but the > specification informally proposed for QTLS suggests that it has no possible > failure mode - it's 220 or sever the connection. There are about two failure modes. The main one occurs if the client didn't complete the SMTP negotiation correctly, because it spoke first. I have an updated draft in the works which has a much safer mechanism for allowing this. The second is if we use Chris's idea of including the server name in the QTLS command; the server has to be able to reject commands which specify an unknown server name. (However since this feature wouldn't be much use unless it was also supported by POP and IMAP, and since it can be added to any protocol that uses TLS via an RFC 3546 server name indication in the TLS client hello, it's probably not worth pursuing.) Similar problems can arise in servers which initialize their TLS layer lazily, at STARTTLS time instead of before listing capabilities. It might be easier to decouple the SMTP and TLS layers if (like BDAT) the client includes a byte count of the client hello in the QTLS command, so the TLS layer doesn't have to be invoked to reject the QTLS command. > Okay, I think think isn't going in the right direction. I think the scenario > of: > > C: TCP: SYN Data: None > S: TCP: SYN+ACK Data: Banner with capabilities > C: QTLS, TLS Hello > > etc gains you the same round-trips as SMTPS, and the same level of robustness > as existing STARTTLS, but means the server has to have the tricky bits. Plus, > I don't think that data in the SYN is a good idea, since it makes SYN based > attacks very much harder to deal with. Er, sorry, when I said SYN I meant the final ACK of the TCP handshake. Your suggestion is (a) not supported by any TCP stacks, and (b) vulnerable to being used as an attack traffic amplifier. I'm continuing to pursue a spec that allows the client to talk first because it has advantages both after the TCP handshake and after the TLS handshake. Tony. -- f.a.n.finch http://dotat.at/ RATTRAY HEAD TO BERWICK ON TWEED: NORTH OR NORTHWEST 4 OR 5, OCCASIONALLY 6 AT FIRST, THEN VEERING NORTH OR NORTHEAST, OCCASIONALLY 6 LATER IN NORTH WEATHER: SNOW SHOWERS. GOOD OCCASIONALLY POOR. MODERATE OR ROUGH _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Mar 02 11:42:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEqt7-0006Lr-5I; Thu, 02 Mar 2006 11:42:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEqt6-0006KL-8X for lemonade@ietf.org; Thu, 02 Mar 2006 11:42:48 -0500 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEqt5-0006BM-Q8 for lemonade@ietf.org; Thu, 02 Mar 2006 11:42:48 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1FEqt2-0005Rc-EV; Thu, 02 Mar 2006 16:42:44 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 79FC3498003; Thu, 2 Mar 2006 16:42:46 +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 06887-08; Thu, 2 Mar 2006 16:42: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 9EBD9498002; Thu, 2 Mar 2006 16:42:41 +0000 (GMT) Date: Thu, 02 Mar 2006 16:42:38 +0000 Subject: Re: [lemonade] SMTP QUICKSTART References: <25269.1140724067.114807@invsysm1> <3732.1141293257.933000@JOHN> In-Reply-To: MIME-Version: 1.0 Message-Id: <7911.1141317759.291780@peirce.dave.cridland.net> From: Dave Cridland To: 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: 6d95a152022472c7d6cdf886a0424dc6 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu Mar 2 13:01:54 2006, Tony Finch wrote: > On Thu, 2 Mar 2006, Dave Cridland wrote: > > First, I think that even if you can do this on OpenSSL, it's > going to be > > really tricky to do on enough existing mobile platforms that it's > not worth > > doing. It might be better to do: > > > > C --> S: QTLS\r\n > > C --> S: TLS Hello > > S --> C: TLS Hello > > > > This is rather weird - a SMTP command which has no response - but > the > > specification informally proposed for QTLS suggests that it has > no possible > > failure mode - it's 220 or sever the connection. > > There are about two failure modes. The main one occurs if the client > didn't complete the SMTP negotiation correctly, because it spoke > first. > I have an updated draft in the works which has a much safer > mechanism > for allowing this. > > Okay, but if the client gets the SMTP negotiation out of the way first, then it won't speak first. I'm personally very nervous about having clients assume things based on previous sessions, because breakage is going to happen, be difficult to test, etc. > The second is if we use Chris's idea of including the server name > in the > QTLS command; the server has to be able to reject commands which > specify > an unknown server name. (However since this feature wouldn't be > much use > unless it was also supported by POP and IMAP, and since it can be > added to > any protocol that uses TLS via an RFC 3546 server name indication > in the > TLS client hello, it's probably not worth pursuing.) Right, so this isn't a problem. > Similar problems can > arise in servers which initialize their TLS layer lazily, at > STARTTLS > time instead of before listing capabilities. > > Yes, but we can mandate that a server only advertises QTLS support if it has verified that the TLS layer is available and ready. In fact, without this, there's little point in QTLS over STARTTLS. > It might be easier to decouple the SMTP and TLS layers if (like > BDAT) the > client includes a byte count of the client hello in the QTLS > command, so > the TLS layer doesn't have to be invoked to reject the QTLS command. > > Nope. The APIs for TLS support on some platforms don't have any indication of how many octets the TLS hello is going to be, so this simply won't get used where it's needed most. > Er, sorry, when I said SYN I meant the final ACK of the TCP > handshake. Ah... Yes, then we're back to the client speaking before receiving the banner. > Your suggestion is (a) not supported by any TCP stacks Yours isn't supported by any TLS implementations. Something has to change somewhere, I'm proposing changing the TCP stacks on servers, and the servers, rather than the protocol. This is in part because for server implementors, the option of using an open source server OS is present, whereas client implementors won't have much success in persuading people to change the OS on their phone. > , and (b) vulnerable > to being used as an attack traffic amplifier. I understood that any real danager of this was heavily mitigated by the typical deployment of SYN flooding protection, and the use of firewalling to prevent the obviously bogus SYN+ACK packets aimed at broadcast or multicast addresses. In other words, this is no more a danger than DNS. > I'm continuing to pursue a > spec that allows the client to talk first because it has advantages > both > after the TCP handshake and after the TLS handshake. Right... The client always talks first after the TLS handshake in ESMTP, though. This might be because it needs to reissue EHLO (technically mandatory, although one can still be paranoid about downgrade attacks and yet elide the second EHLO), or because it authenticates. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Mar 02 16:38:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEvV1-0007Ry-P1; Thu, 02 Mar 2006 16:38:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEuvD-0004Qh-79; Thu, 02 Mar 2006 16:01:15 -0500 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEuvD-00014n-08; Thu, 02 Mar 2006 16:01:15 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k22Ko29W014813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Mar 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FEukM-0003SY-Ok; Thu, 02 Mar 2006 15:50:02 -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, 02 Mar 2006 15:50:02 -0500 X-Spam-Score: 0.3 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-compress-00.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. Title : COMPRESSION Author(s) : S. Maes, R. Cromwell Filename : draft-ietf-lemonade-compress-00.txt Pages : 7 Date : 2006-3-2 Lemonade investigates adding mobile optimizations for the next version of the Lemonade Profile. LZIP addresses this task and provides an extension to allow compression of the exchanged text and binary literals, typically message body parts. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-compress-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-compress-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-compress-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-2143643.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-compress-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-compress-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-2143643.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 Mar 02 17:03:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEuvV-0004gW-BH; Thu, 02 Mar 2006 16:01:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEukT-0006cU-GL; Thu, 02 Mar 2006 15:50:09 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEukT-0006sO-Dy; Thu, 02 Mar 2006 15:50:09 -0500 Received: from pine.neustar.com ([209.173.57.70]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FEukM-00017L-QF; Thu, 02 Mar 2006 15:50:09 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k22Ko2vP005683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Mar 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FEukM-0003QX-6I; Thu, 02 Mar 2006 15:50:02 -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, 02 Mar 2006 15:50:02 -0500 X-Spam-Score: -2.6 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-deployments-00.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. Title : Deployment Considerations for lemonade-compliant Mobile Email Author(s) : R. Gellens Filename : draft-ietf-lemonade-deployments-00.txt Pages : 7 Date : 2006-3-2 This document discusses deployment issues and describes implicit requirements for successful deployment of mobile email based on the IETF lemonade documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-deployments-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-deployments-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-deployments-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-2131500.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-deployments-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-deployments-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-2131500.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 Mar 02 18:15:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEx0o-00014k-AF; Thu, 02 Mar 2006 18:15:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEx0l-000135-Do; Thu, 02 Mar 2006 18:15:07 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEvwp-0007np-Th; Thu, 02 Mar 2006 17:06:59 -0500 Received: from pine.neustar.com ([209.173.57.70]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FEulI-00019V-VQ; Thu, 02 Mar 2006 15:51:04 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k22Ko2vP005705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Mar 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FEukM-0003SO-ND; Thu, 02 Mar 2006 15:50:02 -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, 02 Mar 2006 15:50:02 -0500 X-Spam-Score: -2.6 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-search-within-00.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. Title : WITHIN Search extension to the IMAP Protocol Author(s) : S. Maes, R. Cromwell Filename : draft-ietf-lemonade-search-within-00.txt Pages : 5 Date : 2006-3-2 WITHIN is an extension to [RFC3501] SEARCH which returns messages whose internal date is on or within a specified interval and differs from SINCE in that an interval in seconds is specified instead of a date. WITHIN is expected to be most useful for persistent searches in combination with mobile devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-search-within-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-search-within-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-search-within-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-2141928.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-search-within-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-search-within-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-2141928.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 Mar 02 18:21:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEx7P-0005Cs-FP; Thu, 02 Mar 2006 18:21:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEx7L-0004og-8R; Thu, 02 Mar 2006 18:21:55 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEvwA-0007kN-PT; Thu, 02 Mar 2006 17:06:18 -0500 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FEuog-0001VQ-Kb; Thu, 02 Mar 2006 15:54:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k22Ko20e023393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Mar 2006 20:50:03 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FEukM-0003SE-Lp; Thu, 02 Mar 2006 15:50:02 -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, 02 Mar 2006 15:50:02 -0500 X-Spam-Score: -2.6 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-00.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. Title : Persistent Virtual Folder extension to the IMAP Protocol Author(s) : S. Maes, et al. Filename : draft-ietf-lemonade-vfolder-00.txt Pages : 10 Date : 2006-3-2 Persistent Extensions to the IMAP Protocol (LPSEARCH) defines extension parameters to the [RFC3501] CREATE command to allow virtual mailboxes to be created which are views of other mailboxes narrowed by search criteria. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-vfolder-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-vfolder-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-vfolder-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-2141529.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-vfolder-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-vfolder-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-2141529.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 Mar 02 18:50:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FExYZ-0005ak-1o; Thu, 02 Mar 2006 18:50:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FExYY-0005aa-EX; Thu, 02 Mar 2006 18:50:02 -0500 Received: from [156.154.16.129] (helo=cypress.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FExYX-0005uc-Rp; Thu, 02 Mar 2006 18:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k22No10e025521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Mar 2006 23:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FExYX-0007EX-EY; Thu, 02 Mar 2006 18: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, 02 Mar 2006 18:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-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 : CONVERT Author(s) : S. Maes, R. Cromwell Filename : draft-ietf-lemonade-convert-02.txt Pages : 14 Date : 2006-3-2 CONVERT defines extensions to the IMAPv4 Rev1 protocol [RFC3501] for optimization in a mobile setting, aimed at allowing adaptation and transcoding of attachments as needed by the client. Conversion (adaptation, transcoding) may be requested by the client and performed by the server on a best effort basis or decided by the server based on its knowledge of the client capabilities, user or administrator preferences or its settings. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-convert-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-convert-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-convert-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-3-2150055.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-convert-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-convert-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-2150055.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 Mar 02 18:50:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FExZG-0007G2-Lv; Thu, 02 Mar 2006 18:50:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FExYa-0005du-Kc; Thu, 02 Mar 2006 18:50:04 -0500 Received: from [156.154.16.129] (helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FExYY-0005un-1I; Thu, 02 Mar 2006 18:50:04 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k22No1vP007718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Mar 2006 23:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FExYX-0007FF-Js; Thu, 02 Mar 2006 18: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, 02 Mar 2006 18:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-firewall-binding-00.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. Title : Lemonade bindings to cross firewalls and mobile network intermediaries Author(s) : S. Maes Filename : draft-ietf-lemonade-firewall-binding-00.txt Pages : 20 Date : 2006-3-2 As part of the LEMONADE work to define extensions to the IMAP and SMTP protocols that provide optimizations in a variety of settings, the this document describes an alternative, optional binding for IMAP and SMTP showing how HTTP can be used to transfer commands and responses. This binding is intended to facilitate the use of IMAP and SMTP in deployments involving a variety of intermediaries. Bindings to SOAP, REST and WebDAV are also provided. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-firewall-binding-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-firewall-binding-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-firewall-binding-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-2152112.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-firewall-binding-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-firewall-binding-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-2152112.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --NextPart-- From lemonade-bounces@ietf.org Fri Mar 03 18:20:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFJZt-0006Gm-Rz; Fri, 03 Mar 2006 18:20:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFJZr-0006Cr-Qh for lemonade@ietf.org; Fri, 03 Mar 2006 18:20:51 -0500 Received: from ppsw-9.csi.cam.ac.uk ([131.111.8.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFJZp-0002TU-Ct for lemonade@ietf.org; Fri, 03 Mar 2006 18:20:51 -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-2.csi.cam.ac.uk ([131.111.8.54]:34185) by ppsw-9.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1FFJZV-0003bp-VT (Exim 4.54) (return-path ); Fri, 03 Mar 2006 23:20:29 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1FFJZV-0002Lu-ND (Exim 4.53) (return-path ); Fri, 03 Mar 2006 23:20:29 +0000 Date: Fri, 3 Mar 2006 23:20:29 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] SMTP QUICKSTART In-Reply-To: <7911.1141317759.291780@peirce.dave.cridland.net> Message-ID: References: <25269.1140724067.114807@invsysm1> <3732.1141293257.933000@JOHN> <7911.1141317759.291780@peirce.dave.cridland.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.2 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I've finished writing the updated QUICKSTART spec. http://www-uxsup.csx.cam.ac.uk/~fanf2/hermes/doc/antiforgery/draft-fanf-smtp-quickstart.txt This version includes a basic subset which should be easy to implement, and which brings the MAIL command forward from the client's 9th packet to its 5th in typical use: C: TCP SYN S: SYN/ACK C: ACK S: SMTP C: QTLS TLS client hello S: server hello, certificate, etc. C: key exchange, change cipher, finish handshake S: change cipher, finish handshake C: QHLO AUTH PLAIN MAIL FROM:<...> RCPT TO:<...> ... S: 220 OK 235 OK 250 OK 250 OK ... Full QUICKSTART allows the client to pipeline commands before the server greeting and after the TLS handshake in a way that should be safe, albeit not so trivial to implement. If all goes well, the MAIL command appears in the client's 3rd packet, which I think is pretty good. Even Dave should be able to get a message out in two or three seconds :-) If the client has to recover from a cache miss it should be no slower than the basic form. C: TCP SYN S: SYN/ACK C: ACK SMTP QHLO STARTTLS TLS client hello S: SMTP 220 OK 220 OK TLS server hello, change cipher, finish handshake C: change cipher, finish handshake SMTP QHLO AUTH PLAIN MAIL FROM:<...> RCPT TO:<...> ... S: 220 OK 235 OK 250 OK 250 OK ... Tony. -- f.a.n.finch http://dotat.at/ WEST NORTHERN SECTION: IN NORTH, VARIABLE 3 OR 4. FAIR. GOOD. IN SOUTH, EAST OR SOUTHEAST 4 OR 5, OCCASIONALLY 6. MAINLY FAIR. GOOD. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Mar 03 21:34:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFMb2-0008Bo-1W; Fri, 03 Mar 2006 21:34:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFMb0-00089F-UU for lemonade@ietf.org; Fri, 03 Mar 2006 21:34:14 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFMaz-0006Fg-32 for lemonade@ietf.org; Fri, 03 Mar 2006 21:34:14 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k242Y9Ms011118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 3 Mar 2006 18:34:10 -0800 Received: from [129.46.172.15] (vpn-10-50-16-81.qualcomm.com [10.50.16.81]) by neophyte.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k242Y6hB003355 for ; Fri, 3 Mar 2006 18:34:07 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <43FC8731.3080505@teamware.com> <22667.1140657288.257701@peirce.dave.cridland.net> <21533.1140619429.225276@peirce.dave.cridland.net> <01LZ9CVRUSC000009C@mauve.mrochek.com> <01LZ8M8NO8S800009C@mauve.mrochek.com> <01LZ9FNBLMAS00009C@mauve.mrochek.com> References: <21533.1140619429.225276@peirce.dave.cridland.net> <01LZ9FNBLMAS00009C@mauve.mrochek.com> <01LZ8M8NO8S800009C@mauve.mrochek.com> <01LZ9CVRUSC000009C@mauve.mrochek.com> <43FC8731.3080505@teamware.com> <21533.1140619429.225276@peirce.dave.cridland.net> <22667.1140657288.257701@peirce.dave.cridland.net> <21533.1140619429.225276@peirce.dave.cridland.net> <21533.1140619429.225276@peirce.dave.cridland.net> <01LZ8M8NO8S800009C@mauve.mrochek.com> <01LZ9CVRUSC000009C@mauve.mrochek.com> <01LZ8M8NO8S800009C@mauve.mrochek.com> <21533.1140619429.225276@peirce.dave.cridland.net> <01LZ9FNBLMAS00009C@mauve.mrochek.com> <01LZ8M8NO8S800009C@mauve.mrochek.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Fri, 3 Mar 2006 18:33:49 -0800 To: lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] streamlined message submission Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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:09 PM -0800 2/21/06, Ned Freed wrote: > > > http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/draft-fanf-smtp-tls-on-connect.txt > > I have to say I agreed with the decision not to go with separate > ports and with > STARTTLS instead. And although this does reduce round trips significantly I'm > fairly unenthusiastic it, but less because I agreed with the prior > decision and > more because I predict there will be opposition to moving back to the smtps > approach from the security folks. And although we've supported smtps in our > product for a long time, I don't in practice see the large amounts > of lingering > use of it you do. One of the main arguments against alternate-port-TLS is what happens if/when we deploy something else that replaces TLS? Does each protocol then need three ports? I wonder if it would be worth trying an approach that connects on the standard port, but immediately tried to negotiate TLS, without waiting for the usual greeting and extension list? As long as existing servers send an error when they see the start of a TLS negotiation, it might be OK. > > > http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/draft-fanf-smtp-quickstart.txt > > This extension seems quite reasonable to me. I'm bothered by a few things: (1) would there be problems with clients connecting to servers and getting unexpected multi-line greetings? [Ned seems to think this would be fine, so maybe we don't worry here.] (2) this business of the client using something extended as its first command to signal to the server that it is fine seems fragile (3) the burden on the client of correctly caching the server's extensions at the right time doesn't seem to be clearly described: in one place it says the client uses its most recent cache, yet in another it says that the client can't use SMTP AUTH if the server didn't advertise it prior to TLS; the most recent cache is likely to be post-TLS. (4) why would a server advertise PIPELINING in the greeting yet not in an EHLO response? Or is there another reason the client can't assume PIPELINING if it sees it in the greeting yet issues an EHLO? If we do proceed with this, I'd suggest that it MUST NOT be used on port 25; it MUST be a port 587 mechanism only. This is because some servers have adopted anti-spam techniques that in some cases detect extra commands that are sent with the HELO/EHLO command (or otherwise look at client use of PIPELINING without having negotiated it). I'd suggest that, while logging of client IP address is useful, reverse DNS information may be misleading and is generally much less useful. They are certainly not equivalent. It is fairly trivial for someone to setup their own PTR entries for IP addresses they own, containing any host names they choose; even when no malice is intended, the reverse zone is the most likely to be misconfigured. > > > http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/draft-fanf-smtp-rcpthdr.txt > (0) How are malformed or unparseable To:/Cc:/Bcc: fields supposed to be > handled? There's no place to report such an error in the dialogue and > a DSN isn't designed to report such issues. > (1) How are problems with specific recipient addresses supposed to > be handled? If we do proceed with this draft, I'd suggest that malformed and unparseable address headers, as well as errors for a specific address, be handled by a new extended SMTP response code and including the bad address (or the entire header if it is bad) in square brackets in the text. This would have to be a response after end of data, of course. It's still a lot tricker for clients to get this right than an immediate error after the specific RCPT TO, but it's much, much, much better than accepting the message and generating a DSN. At 5:16 PM +0000 2/22/06, Tony Finch wrote: > On Wed, 22 Feb 2006, Dave Cridland wrote: > > > > > http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/draft-fanf-submission-streamlined.txt >> >> BURL doesn't allow clients to pipeline AUTH - that's just possible > > anyway with a server that supports PIPELINING. > > The BURL spec is the only document that gives permission to do it. This is something we could likely tighten up in profile-bis. > Pipelined QUIT is included in an example in RFC 2920. It shouldn't be a > problem if the client waits for all the server's responses. The client would pipeline QUIT and check the responses after the connection closes, right? I suppose we'd want an extension that said "if any RCPT is bad then please ignore any subsequent ones because I don't really want it sent even though it might seem so but that is just because I am pipelining everything". It would be the moral equivalent of the compiler flags to treat all warnings as errors. The client would include this new keyword on MAIL FROM (maybe ABORTONBADRCPT), the server would generate usual responses to every RCPT TO, then if any were bad, it would send a failure after end-of-data. > You can't reliably auto-detect plaintext SMTP (or IMAP) versus > TLS-on-connect on the same port, because there's a mismatch between who > talks first. If it was consistently the client that talked first then the > server could autodetect, but the SMTP or IMAP server banner prevents this. But the server can check before it sends the greeting to see if the client sent any data and if so if it is a TLS initiation, couldn't it? They way some servers now check if the client sent commands without waiting for the EHLO response? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Get your facts first, and then you can distort them as much as you please. --Mark Twain _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Mar 04 08:05:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFWRY-0002St-JV; Sat, 04 Mar 2006 08:05:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEGWJ-0007On-AZ; Tue, 28 Feb 2006 20:52:51 -0500 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEGWH-0005Tl-V9; Tue, 28 Feb 2006 20:52:51 -0500 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.8/8.12.8) with ESMTP id k211qnWV010908; Tue, 28 Feb 2006 17:52:49 -0800 Received: (from apache@localhost) by nit.isi.edu (8.12.8/8.12.8/Submit) id k211qnS0010907; Tue, 28 Feb 2006 17:52:49 -0800 Date: Tue, 28 Feb 2006 17:52:49 -0800 Message-Id: <200603010152.k211qnS0010907@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 X-Mailman-Approved-At: Sat, 04 Mar 2006 08:05:07 -0500 Cc: lemonade@ietf.org, rfc-editor@rfc-editor.org Subject: [lemonade] RFC 4416 on Goals for Internet Messaging to Support Diverse Service Environments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4416 Title: Goals for Internet Messaging to Support Diverse Service Environments Author: J. Wong, Ed. Status: Informational Date: February 2006 Mailbox: j.k.wong@sympatico.ca Pages: 43 Characters: 93676 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-lemonade-goals-05.txt URL: http://www.rfc-editor.org/rfc/rfc4416.txt This document is a history capturing the background, motivation and thinking during the LEMONADE definition and design process. The LEMONADE Working Group -- Internet email to support diverse service environments -- is chartered to provide enhancements to Internet mail to facilitate its use by more diverse clients. In particular, by clients on hosts not only operating in environments with high latency/bandwidth-limited unreliable links but also constrained to limited resources. The enhanced mail must be backwards compatible with existing Internet mail. The primary motivation for this effort is -- by making Internet mail protocols richer and more adaptable to varied media and environments -- to allow mobile handheld devices tetherless access to Internet mail using only IETF mail protocols. The requirements for these devices drive a discussion of the possible protocol enhancements needed to support multimedia messaging on limited-capability hosts in diverse service environments. A list of general principles to guide the design of the enhanced messaging protocols is documented. Finally, additional issues of providing seamless service between enhanced Internet mail and the existing separate mobile messaging infrastructure are briefly listed. This memo provides information for the Internet community. This document is a product of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Mar 05 04:19:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFpOM-0006RI-PT; Sun, 05 Mar 2006 04:19:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFpOL-0006Of-E5 for lemonade@ietf.org; Sun, 05 Mar 2006 04:19:05 -0500 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFpOG-0002DO-Su for lemonade@ietf.org; Sun, 05 Mar 2006 04:19:05 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1FFpOF-0005LK-H0 for lemonade@ietf.org; Sun, 05 Mar 2006 09:18:59 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id B2FC3498003 for ; Sun, 5 Mar 2006 09:19: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 22730-02 for ; Sun, 5 Mar 2006 09:19:19 +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 B9D4C498002 for ; Sun, 5 Mar 2006 09:19:17 +0000 (GMT) Date: Sun, 05 Mar 2006 09:18:47 +0000 Subject: Re: [lemonade] streamlined message submission References: <21533.1140619429.225276@peirce.dave.cridland.net> <01LZ9FNBLMAS00009C@mauve.mrochek.com> <01LZ8M8NO8S800009C@mauve.mrochek.com> <01LZ9CVRUSC000009C@mauve.mrochek.com> <43FC8731.3080505@teamware.com> <21533.1140619429.225276@peirce.dave.cridland.net> <22667.1140657288.257701@peirce.dave.cridland.net> <21533.1140619429.225276@peirce.dave.cridland.net> <21533.1140619429.225276@peirce.dave.cridland.net> <01LZ8M8NO8S800009C@mauve.mrochek.com> <01LZ9CVRUSC000009C@mauve.mrochek.com> <01LZ8M8NO8S800009C@mauve.mrochek.com> <21533.1140619429.225276@peirce.dave.cridland.net> <01LZ9FNBLMAS00009C@mauve.mrochek.com> <01LZ8M8NO8S800009C@mauve.mrochek.com> In-Reply-To: MIME-Version: 1.0 Message-Id: <14379.1141550327.734683@peirce.dave.cridland.net> From: Dave Cridland To: Enhancements to Internet email to support diverse service enivronments Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Pythagoras-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 Mar 4 02:33:49 2006, Randall Gellens wrote: > At 5:09 PM -0800 2/21/06, Ned Freed wrote: >> > >> http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/draft-fanf-smtp-rcpthdr.txt > > > >> (0) How are malformed or unparseable To:/Cc:/Bcc: fields supposed >> to be >> handled? There's no place to report such an error in the >> dialogue and >> a DSN isn't designed to report such issues. > >> (1) How are problems with specific recipient addresses supposed >> to be handled? > > If we do proceed with this draft, I'd suggest that malformed and > unparseable address headers, as well as errors for a specific > address, be handled by a new extended SMTP response code and > including the bad address (or the entire header if it is bad) in > square brackets in the text. This would have to be a response > after end of data, of course. > > It's still a lot tricker for clients to get this right than an > immediate error after the specific RCPT TO, but it's much, much, > much better than accepting the message and generating a DSN. > > Chris Newman briefly proposed doing it the other way around, that is, generating the headers from the envelope. I've written this up as http://dave.cridland.net/draft-cridland-esmtp-headergen-pre.txt with XML source at http://svn.dave.cridland.net/svn/ietf-drafts/draft-cridland-esmtp-headergen.xml (This is very rough thus far, just aimed at being a talking point. In particular, as I write this, I note I've not yet seperated out informative and normative references at all.) Given the availability of PIPELINING, this seems like a better and easier way to go. > The client would pipeline QUIT and check the responses after the > connection closes, right? I suppose we'd want an extension that > said "if any RCPT is bad then please ignore any subsequent ones > because I don't really want it sent even though it might seem so > but that is just because I am pipelining everything". It would be > the moral equivalent of the compiler flags to treat all warnings as > errors. The client would include this new keyword on MAIL FROM > (maybe ABORTONBADRCPT), the server would generate usual responses > to every RCPT TO, then if any were bad, it would send a failure > after end-of-data. > > It's actually saying "If any RCPT is bad then I'm going to waste a stackload of data transmission, and therefore cost and battery life". I think if you want this behaviour, you have to introduce a post-envelope sync point - ie, you send the envelope, and examine responses to decide whether you wish to continue. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Mar 05 10:15:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFuxX-0006E1-Pm; Sun, 05 Mar 2006 10:15:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFuxW-0006Dw-7w for lemonade@ietf.org; Sun, 05 Mar 2006 10:15:46 -0500 Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFuxU-0000UD-Rb for lemonade@ietf.org; Sun, 05 Mar 2006 10:15:46 -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-2.csi.cam.ac.uk ([131.111.8.54]:60444) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:fanf2) id 1FFuxO-0005Rw-1M (Exim 4.54) (return-path ); Sun, 05 Mar 2006 15:15:38 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1FFuxO-0001TW-C6 (Exim 4.53) (return-path ); Sun, 05 Mar 2006 15:15:38 +0000 Date: Sun, 5 Mar 2006 15:15:38 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Randall Gellens Subject: Re: [lemonade] streamlined message submission In-Reply-To: Message-ID: References: <21533.1140619429.225276@peirce.dave.cridland.net> <21533.1140619429.225276@peirce.dave.cridland.net> <01LZ8M8NO8S800009C@mauve.mrochek.com> <01LZ9CVRUSC000009C@mauve.mrochek.com> <01LZ8M8NO8S800009C@mauve.mrochek.com> <21533.1140619429.225276@peirce.dave.cridland.net> <01LZ9FNBLMAS00009C@mauve.mrochek.com> <01LZ8M8NO8S800009C@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Fri, 3 Mar 2006, Randall Gellens wrote: > > I wonder if it would be worth trying an approach that connects on the standard > port, but immediately tried to negotiate TLS, without waiting for the usual > greeting and extension list? As long as existing servers send an error when > they see the start of a TLS negotiation, it might be OK. I don't think the error handling would be particularly elegant - the client would probably have to drop the connection and re-try from the beginning, and the server will likely force it to do so. My latest QUICKSTART draft describes how to make STARTTLS as efficient (in terms of packet count if not byte count) as TLS-on-connect. > (2) this business of the client using something extended as its first > command to signal to the server that it is fine seems fragile > (3) the burden on the client of correctly caching the server's > extensions at the right time doesn't seem to be clearly described: [...] The latest QUICKSTART draft is much more robust. I think I have explained the cacheing better, though there's still some room for improvement. > If we do proceed with this, I'd suggest that it MUST NOT be used on port 25; > it MUST be a port 587 mechanism only. This is because some servers have > adopted anti-spam techniques that in some cases detect extra commands that are > sent with the HELO/EHLO command (or otherwise look at client use of PIPELINING > without having negotiated it). I've explained why I think this isn't such s problem as it might seem in the latest draft's security considerations section. The more robust signalling helps a lot. > I'd suggest that, while logging of client IP address is useful, reverse DNS > information may be misleading and is generally much less useful. I should have been clearer that I was assuming "paranoid" reverse DNS checking. Thanks for looking at the drafts. Tony. -- f.a.n.finch http://dotat.at/ SHANNON ROCKALL: NORTHWEST 4 OR 5 BECOMING VARIABLE 3 OR 4 THEN SOUTHEAST 5 TO 7. SHOWERS THEN RAIN. MAINLY GOOD. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Mar 05 20:12:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FG4G7-0001QQ-Uk; Sun, 05 Mar 2006 20:11:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FG4G6-0001Lr-WB for lemonade@ietf.org; Sun, 05 Mar 2006 20:11:35 -0500 Received: from rwcrmhc12.comcast.net ([216.148.227.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FG4G5-0000tK-Lc for lemonade@ietf.org; Sun, 05 Mar 2006 20:11:34 -0500 Received: from gawhitelaptop (c-67-162-191-81.hsd1.tx.comcast.net[67.162.191.81]) by comcast.net (rwcrmhc12) with SMTP id <20060306011131m12001egcae>; Mon, 6 Mar 2006 01:11:31 +0000 From: "Greg White" To: Subject: RE: [lemonade] final future release question (I think) Date: Sun, 5 Mar 2006 19:11:12 -0600 Message-ID: <000201c640ba$dc384dd0$6401a8c0@gawhitelaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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: mrc@ndcms.cac.washington.edu [mailto:mrc@ndcms.cac.washington.edu] = On Behalf Of Mark Crispin Sent: Tuesday, February 28, 2006 8:01 PM To: Greg White Cc: lemonade@ietf.org Subject: Re: [lemonade] final future release question (I think) > I have two objections to your proposal. > First, I see nothing in RFC 2822 that prevents a client from = specifying=20 > multiple parameters with the same name. Consequently, I think that = your=20 > concern against HOLDFOR=3D and HOLDUNTIL=3D is misplaced; a client can = just as > easily have HOLD=3Dfor; and HOLD=3Duntil; in the same command. Yeah, that occurred to me after I sent out the email. I looked in 2821, = and couldn't find anything either (did you mean 2821?). > Second, I think that your proposed HOLD=3Dfor;20 syntax is bizarre = (not to=20 > mention ugly). Is there any precedent for such use of semicolon in = SMTP?=20 > I'm not aware of any (I admit that I haven't been keeping careful = track).=20 > Where I have seen semi-colon used with parameters, it has been as a=20 > delimiter between parameters as in MIME. Since I haven't been keeping track either (precedent for use of = semi-colon), I did some investigating: I started by looking at all the SMTP extension documents I could find in = the RFC Editor, and split them into two groups: those that define MAIL/RCPT parms, and those that don't: Those that don't: AUTH CHUNKING CONNEG CONPERM ENHANCEDSTATUSCODES ETRN PIPELINING STARTTLS Those that do: 8BITMIME BINARYMIME CHECKPOINT DELIVERBY DSN MTRK NO-SOLICITING SIZE Further examination of the "those that do" list shows the following extensions employing syntax similar to the "bizarre, even ugly" syntax suggested in the FUTURERELEASE draft: 1) DELIVERBY - defines the BY parm for the MAIL cmd, uses semi-colon to separate subvalues 2) DSN - a) defines the NOTIFY parm for the RCPT cmd, uses comma to separate subvalues b) defines the ORCPT parm for the RCPT cmd, uses semi-colon to separate subvalues 3) MTRK - defines the MTRK parm for the MAIL cmd, uses colon to = separate subvalues 4) NO-SOLICITING - defines the SOLICIT parm for the MAIL cmd, uses = colon to separate subvalues So, half of all the SMTP extensions that define MAIL/RCPT cmd parms use = this syntax, and a quarter of all SMTP extensions (that I could find) use it. = In my mind, this is sufficient precedent for the use of semicolon (or other char, for that matter) to delimit subvalues. Furthermore, I'm not = offended, but "bizarre, even ugly" is a pretty strong denounciation of a string consisting of . I don't even think this is "complicated"; even if it is complicated, compliant = systems are already parsing similar strings. I know the ABNF is complicated, = but Randy has offered a solution for that. > Consequently, my vote is against your proposal, and for HOLDFOR=3D and = > HOLDUNTIL=3D as previously discussed. >From what I can tell, this discussion is about asethetics, and not = design. I do not think I have heard a compelling design reason for switching = from one to two parameters on the MAIL command. However, the only design = reason I had for using the current syntax was because I knew it had been used before. At this point, design-wise, the options look like "6 of one, = half a dozen of the other"... Does anyone out there have a compelling design argument for one side or = the other? I am not opposed to changing the document, but if we are down to = a "I just like this better" discussion, I would like to hear from more = than 3 people (thanks Mark, Dave, Antony). Or maybe 4 (I'm assuming Randy = hasn't changed his mind) > -- Mark -- Thanks, Greg 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 Sun Mar 05 20:28:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FG4Wp-0007Sf-DC; Sun, 05 Mar 2006 20:28:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FG4Wn-0007Sa-PA for lemonade@ietf.org; Sun, 05 Mar 2006 20:28:49 -0500 Received: from rwcrmhc13.comcast.net ([204.127.192.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FG4Wm-0001dT-Dk for lemonade@ietf.org; Sun, 05 Mar 2006 20:28:49 -0500 Received: from gawhitelaptop (c-67-162-191-81.hsd1.tx.comcast.net[67.162.191.81]) by comcast.net (rwcrmhc13) with SMTP id <20060306012847m13002hqtue>; Mon, 6 Mar 2006 01:28:47 +0000 From: "Greg White" To: Subject: FW: [lemonade] final future release question (I think) Date: Sun, 5 Mar 2006 19:28:22 -0600 Message-ID: <000301c640bd$4532edc0$6401a8c0@gawhitelaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I think I owe the list an apology for beating this horse into ground; I just now noticed Greg V. posted the syntax question 2/17; I should have jumped in there. I apologize for that. But, the same 3 people = responded that time (and also Anil, thanks), so I would still like to hear from = others before making the change... Thanks,=20 Greg -----Original Message----- From: Greg White [mailto:g.a.white@comcast.net]=20 Sent: Sunday, March 05, 2006 7:11 PM To: lemonade@ietf.org Subject: RE: [lemonade] final future release question (I think) -----Original Message----- From: mrc@ndcms.cac.washington.edu [mailto:mrc@ndcms.cac.washington.edu] = On Behalf Of Mark Crispin Sent: Tuesday, February 28, 2006 8:01 PM To: Greg White Cc: lemonade@ietf.org Subject: Re: [lemonade] final future release question (I think) > I have two objections to your proposal. > First, I see nothing in RFC 2822 that prevents a client from=20 > specifying > multiple parameters with the same name. Consequently, I think that = your=20 > concern against HOLDFOR=3D and HOLDUNTIL=3D is misplaced; a client can = just as > easily have HOLD=3Dfor; and HOLD=3Duntil; in the same command. Yeah, that occurred to me after I sent out the email. I looked in 2821, = and couldn't find anything either (did you mean 2821?). > Second, I think that your proposed HOLD=3Dfor;20 syntax is bizarre = (not=20 > to > mention ugly). Is there any precedent for such use of semicolon in = SMTP?=20 > I'm not aware of any (I admit that I haven't been keeping careful = track).=20 > Where I have seen semi-colon used with parameters, it has been as a=20 > delimiter between parameters as in MIME. Since I haven't been keeping track either (precedent for use of = semi-colon), I did some investigating: I started by looking at all the SMTP extension documents I could find in = the RFC Editor, and split them into two groups: those that define MAIL/RCPT parms, and those that don't: Those that don't: AUTH CHUNKING CONNEG CONPERM ENHANCEDSTATUSCODES ETRN PIPELINING STARTTLS Those that do: 8BITMIME BINARYMIME CHECKPOINT DELIVERBY DSN MTRK NO-SOLICITING SIZE Further examination of the "those that do" list shows the following extensions employing syntax similar to the "bizarre, even ugly" syntax suggested in the FUTURERELEASE draft: 1) DELIVERBY - defines the BY parm for the MAIL cmd, uses semi-colon to separate subvalues 2) DSN - a) defines the NOTIFY parm for the RCPT cmd, uses comma to separate subvalues b) defines the ORCPT parm for the RCPT cmd, uses semi-colon to separate subvalues 3) MTRK - defines the MTRK parm for the MAIL cmd, uses colon to = separate subvalues 4) NO-SOLICITING - defines the SOLICIT parm for the MAIL cmd, uses = colon to separate subvalues So, half of all the SMTP extensions that define MAIL/RCPT cmd parms use = this syntax, and a quarter of all SMTP extensions (that I could find) use it. = In my mind, this is sufficient precedent for the use of semicolon (or other char, for that matter) to delimit subvalues. Furthermore, I'm not = offended, but "bizarre, even ugly" is a pretty strong denounciation of a string consisting of . I don't even think this is "complicated"; even if it is complicated, compliant = systems are already parsing similar strings. I know the ABNF is complicated, = but Randy has offered a solution for that. > Consequently, my vote is against your proposal, and for HOLDFOR=3D and > HOLDUNTIL=3D as previously discussed. >From what I can tell, this discussion is about asethetics, and not=20 >design. I do not think I have heard a compelling design reason for switching = from one to two parameters on the MAIL command. However, the only design = reason I had for using the current syntax was because I knew it had been used before. At this point, design-wise, the options look like "6 of one, = half a dozen of the other"... Does anyone out there have a compelling design argument for one side or = the other? I am not opposed to changing the document, but if we are down to = a "I just like this better" discussion, I would like to hear from more = than 3 people (thanks Mark, Dave, Antony). Or maybe 4 (I'm assuming Randy = hasn't changed his mind) > -- Mark -- Thanks, Greg http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. = Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Mar 05 20:33:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FG4b1-0002ht-BC; Sun, 05 Mar 2006 20:33:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FG4b0-0002ek-EW for lemonade@ietf.org; Sun, 05 Mar 2006 20:33:10 -0500 Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FG4b0-0001q7-0a for lemonade@ietf.org; Sun, 05 Mar 2006 20:33:10 -0500 Received: from gawhitelaptop (c-67-162-191-81.hsd1.tx.comcast.net[67.162.191.81]) by comcast.net (rwcrmhc11) with SMTP id <20060306013309m11009vrqve>; Mon, 6 Mar 2006 01:33:09 +0000 From: "Greg White" To: Subject: FW: [lemonade] final future release question (I think) Date: Sun, 5 Mar 2006 19:32:45 -0600 Message-ID: <000401c640bd$e1dcac10$6401a8c0@gawhitelaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org oh yeah, one last thing: how about DURING as a new hold type? Greg -----Original Message----- From: Greg White [mailto:g.a.white@comcast.net]=20 Sent: Sunday, March 05, 2006 7:28 PM To: lemonade@ietf.org Subject: FW: [lemonade] final future release question (I think) I think I owe the list an apology for beating this horse into ground; I just now noticed Greg V. posted the syntax question 2/17; I should have jumped in there. I apologize for that. But, the same 3 people = responded that time (and also Anil, thanks), so I would still like to hear from = others before making the change... Thanks,=20 Greg -----Original Message----- From: Greg White [mailto:g.a.white@comcast.net]=20 Sent: Sunday, March 05, 2006 7:11 PM To: lemonade@ietf.org Subject: RE: [lemonade] final future release question (I think) -----Original Message----- From: mrc@ndcms.cac.washington.edu [mailto:mrc@ndcms.cac.washington.edu] = On Behalf Of Mark Crispin Sent: Tuesday, February 28, 2006 8:01 PM To: Greg White Cc: lemonade@ietf.org Subject: Re: [lemonade] final future release question (I think) > I have two objections to your proposal. > First, I see nothing in RFC 2822 that prevents a client from > specifying > multiple parameters with the same name. Consequently, I think that = your=20 > concern against HOLDFOR=3D and HOLDUNTIL=3D is misplaced; a client can = just as > easily have HOLD=3Dfor; and HOLD=3Duntil; in the same command. Yeah, that occurred to me after I sent out the email. I looked in 2821, = and couldn't find anything either (did you mean 2821?). > Second, I think that your proposed HOLD=3Dfor;20 syntax is bizarre = (not > to > mention ugly). Is there any precedent for such use of semicolon in = SMTP?=20 > I'm not aware of any (I admit that I haven't been keeping careful = track).=20 > Where I have seen semi-colon used with parameters, it has been as a=20 > delimiter between parameters as in MIME. Since I haven't been keeping track either (precedent for use of = semi-colon), I did some investigating: I started by looking at all the SMTP extension documents I could find in = the RFC Editor, and split them into two groups: those that define MAIL/RCPT parms, and those that don't: Those that don't: AUTH CHUNKING CONNEG CONPERM ENHANCEDSTATUSCODES ETRN PIPELINING STARTTLS Those that do: 8BITMIME BINARYMIME CHECKPOINT DELIVERBY DSN MTRK NO-SOLICITING SIZE Further examination of the "those that do" list shows the following extensions employing syntax similar to the "bizarre, even ugly" syntax suggested in the FUTURERELEASE draft: 1) DELIVERBY - defines the BY parm for the MAIL cmd, uses semi-colon to separate subvalues 2) DSN - a) defines the NOTIFY parm for the RCPT cmd, uses comma to separate subvalues b) defines the ORCPT parm for the RCPT cmd, uses semi-colon to separate subvalues 3) MTRK - defines the MTRK parm for the MAIL cmd, uses colon to = separate subvalues 4) NO-SOLICITING - defines the SOLICIT parm for the MAIL cmd, uses = colon to separate subvalues So, half of all the SMTP extensions that define MAIL/RCPT cmd parms use = this syntax, and a quarter of all SMTP extensions (that I could find) use it. = In my mind, this is sufficient precedent for the use of semicolon (or other char, for that matter) to delimit subvalues. Furthermore, I'm not = offended, but "bizarre, even ugly" is a pretty strong denounciation of a string consisting of . I don't even think this is "complicated"; even if it is complicated, compliant = systems are already parsing similar strings. I know the ABNF is complicated, = but Randy has offered a solution for that. > Consequently, my vote is against your proposal, and for HOLDFOR=3D and = > HOLDUNTIL=3D as previously discussed. >From what I can tell, this discussion is about asethetics, and not >design. I do not think I have heard a compelling design reason for switching = from one to two parameters on the MAIL command. However, the only design = reason I had for using the current syntax was because I knew it had been used before. At this point, design-wise, the options look like "6 of one, = half a dozen of the other"... Does anyone out there have a compelling design argument for one side or = the other? I am not opposed to changing the document, but if we are down to = a "I just like this better" discussion, I would like to hear from more = than 3 people (thanks Mark, Dave, Antony). Or maybe 4 (I'm assuming Randy = hasn't changed his mind) > -- Mark -- Thanks, Greg http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. = Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Mar 06 15:50:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGMfD-0003sG-50; Mon, 06 Mar 2006 15:50:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGMeZ-0001th-2k; Mon, 06 Mar 2006 15:50:03 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGMeY-0001M1-Gb; Mon, 06 Mar 2006 15:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k26Ko2BX024368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Mar 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FGMeY-00056G-3O; Mon, 06 Mar 2006 15:50:02 -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, 06 Mar 2006 15:50:02 -0500 X-Spam-Score: 0.3 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-notifications-01.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. Title : Lemonade notifications and filters Author(s) : S. Maes Filename : draft-ietf-lemonade-notifications-01.txt Pages : 19 Date : 2006-3-6 This document discusses how to provide notification and filtering mechanisms to IMAP [RFC3501] as part the Lemonade profile [LEMONADEPROFILEBIS]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-notifications-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-notifications-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-notifications-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-6110033.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-notifications-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-notifications-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-6110033.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 Mar 06 15:58:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGMn5-00069k-Nn; Mon, 06 Mar 2006 15:58:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGMee-00028q-TZ; Mon, 06 Mar 2006 15:50:09 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGMee-0001Nq-R9; Mon, 06 Mar 2006 15:50:08 -0500 Received: from [156.154.24.129] (helo=oak.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FGMeY-0002vA-Ln; Mon, 06 Mar 2006 15:50:08 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k26Ko2BX024369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Mar 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FGMeY-00056L-45; Mon, 06 Mar 2006 15:50:02 -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, 06 Mar 2006 15:50:02 -0500 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-01.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. Title : LEMONADE profile bis Author(s) : S. Maes Filename : draft-ietf-lemonade-profile-bis-01.txt Pages : 50 Date : 2006-3-6 This document describes LEMONADE profile bis. It contains pointers or mention to all the features that are normatively part of LEMONADE profile bis. This document describes a profile (a set of required extensions, restrictions and usage modes) of the IMAP and mail submission protocols. This profile allows clients (especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP and Submission to access and submit mail. This includes the ability to forward received mail without needing to download and upload the mail, to optimize submission and to efficiently resynchronize in case of loss of connectivity with the server. The Lemonade profile relies upon extensions to IMAP and Mail Submission protocols; specifically URLAUTH and CATENATE IMAP protocol ([18]) extensions and BURL extension to the SUBMIT protocol (SUBMIT). It provides also extensions to provide support for realizationz of OMA mobile email enabler (MEM) ([16] and [9]) using Internet Mail protocols defined by the IETF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-profile-bis-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-profile-bis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-profile-bis-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-6111207.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-profile-bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-profile-bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-6111207.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 Mar 06 17:49:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGOWT-0003GL-I2; Mon, 06 Mar 2006 17:49:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGOWR-0003GG-DX for lemonade@ietf.org; Mon, 06 Mar 2006 17:49:47 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGOWP-0004xk-IP for lemonade@ietf.org; Mon, 06 Mar 2006 17:49:47 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k26MneFT027378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 6 Mar 2006 14:49:41 -0800 Received: from [192.168.1.13] (loud.qualcomm.com [129.46.172.15]) by sabrina.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k26Mndeo019798; Mon, 6 Mar 2006 14:49:40 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <14379.1141550327.734683@peirce.dave.cridland.net> References: <21533.1140619429.225276@peirce.dave.cridland.net> <01LZ9FNBLMAS00009C@mauve.mrochek.com> <01LZ8M8NO8S800009C@mauve.mrochek.com> <01LZ9CVRUSC000009C@mauve.mrochek.com> <43FC8731.3080505@teamware.com> <21533.1140619429.225276@peirce.dave.cridland.net> <22667.1140657288.257701@peirce.dave.cridland.net> <21533.1140619429.225276@peirce.dave.cridland.net> <21533.1140619429.225276@peirce.dave.cridland.net> <01LZ8M8NO8S800009C@mauve.mrochek.com> <01LZ9CVRUSC000009C@mauve.mrochek.com> <01LZ8M8NO8S800009C@mauve.mrochek.com> <21533.1140619429.225276@peirce.dave.cridland.net> <01LZ9FNBLMAS00009C@mauve.mrochek.com> <01LZ8M8NO8S800009C@mauve.mrochek.com> <14379.1141550327.734683@peirce.dave.cridland.net> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Mon, 6 Mar 2006 14:43:52 -0800 To: Dave Cridland , From: Randall Gellens Subject: Re: [lemonade] streamlined message submission 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: f66b12316365a3fe519e75911daf28a8 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 9:18 AM +0000 3/5/06, Dave Cridland wrote: > On Sat Mar 4 02:33:49 2006, Randall Gellens wrote: >> At 5:09 PM -0800 2/21/06, Ned Freed wrote: >>> > >>> http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/draft-fanf-smtp-rcpthdr.txt >> >> >> >>> (0) How are malformed or unparseable To:/Cc:/Bcc: fields supposed to be >>> handled? There's no place to report such an error in the dialogue and >>> a DSN isn't designed to report such issues. >> >>> (1) How are problems with specific recipient addresses supposed >>> to be handled? >> >> If we do proceed with this draft, I'd suggest that malformed and >> unparseable address headers, as well as errors for a specific >> address, be handled by a new extended SMTP response code and >> including the bad address (or the entire header if it is bad) in >> square brackets in the text. This would have to be a response >> after end of data, of course. >> >> It's still a lot tricker for clients to get this right than an >> immediate error after the specific RCPT TO, but it's much, much, >> much better than accepting the message and generating a DSN. >> > Chris Newman briefly proposed doing it the other way around, that > is, generating the headers from the envelope. > > I've written this up as > http://dave.cridland.net/draft-cridland-esmtp-headergen-pre.txt > with XML source at > http://svn.dave.cridland.net/svn/ietf-drafts/draft-cridland-esmtp-headergen.xml > > (This is very rough thus far, just aimed at being a talking point. > In particular, as I write this, I note I've not yet seperated out > informative and normative references at all.) > > Given the availability of PIPELINING, this seems like a better and > easier way to go. I'd agree that this approach (generating headers from envelope) is better than the other way around, since the client can easily determine which address is bad, but I'd still question the value. It seems to me that saving round-trips is the key, that as 3G systems are deployed, total octet savings isn't as important, while latency and round-trips still are. I could easily be wrong, of course. But I'd like to see better explanations of why the added complexity is worth the octet savings. (By the way, I like that 'foo' is the username for 'Fred Oo' -- clever). > >> The client would pipeline QUIT and check the responses after the >> connection closes, right? I suppose we'd want an extension that >> said "if any RCPT is bad then please ignore any subsequent ones >> because I don't really want it sent even though it might seem so >> but that is just because I am pipelining everything". It would be >> the moral equivalent of the compiler flags to treat all warnings >> as errors. The client would include this new keyword on MAIL FROM >> (maybe ABORTONBADRCPT), the server would generate usual responses >> to every RCPT TO, then if any were bad, it would send a failure >> after end-of-data. >> > It's actually saying "If any RCPT is bad then I'm going to waste a > stackload of data transmission, and therefore cost and battery > life". I think if you want this behaviour, you have to introduce a > post-envelope sync point - ie, you send the envelope, and examine > responses to decide whether you wish to continue. I suppose it depends on if we want to optimize for the error case or the non-error case. If we expect at least one RCPT to fail, then we don't want to send the data until we know. But if we expect that all RCPTs will be fine, then we don't want to introduce a delay waiting for the server response if we can pipeline the entire transaction. The size of the message is also significant, of course. If we have a small message, then why have any delay? But if we have a large message, maybe it makes sense to wait. So perhaps there is use for such an extension plus client advice on how and when to use it. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- The reliability of machinery is inversely proportional to the number and significance of any persons watching it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Mar 06 18:40:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGPJh-0001pW-TM; Mon, 06 Mar 2006 18:40:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGPJg-0001pM-N7 for lemonade@ietf.org; Mon, 06 Mar 2006 18:40:40 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGPJf-0006oh-Ck for lemonade@ietf.org; Mon, 06 Mar 2006 18:40:40 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k26NeaMs002938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 6 Mar 2006 15:40:37 -0800 Received: from [192.168.1.13] (loud.qualcomm.com [129.46.172.15]) by magus.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k26NeVfP002513; Mon, 6 Mar 2006 15:40:35 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Mon, 6 Mar 2006 15:39:45 -0800 To: lemonade@ietf.org, ietf-smtp@imc.org From: Randall Gellens Subject: [lemonade] Re: PIPELINING, AUTH, and CHUNKING Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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:56 PM +0000 2/23/06, Tony Finch wrote: > For example, it's common to have dual-purpose MSA > and MX servers which operate in MSA mode after AUTH and MX mode otherwise. > If the client pipelines an AUTH and an intended submission, but the auth > fails, bad things will happen - recipients will be rejected that would > have been OK, an incomplete message will suffer an anti-spam penalty > instead of being fixed up, etc. Another reason to stop running dual-purpose servers on port 25, and restrict 25 to message relay, and use port 587 for message submission. It makes the client's intent much more clear. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- "Contrariwise," continued Tweedledee, "if it was so, it might be, and if it were so, it would be; but as it isn't, it ain't. That's logic!" _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Mar 06 18:40:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGPJi-0001pb-12; Mon, 06 Mar 2006 18:40:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGPJh-0001pR-8K for lemonade@ietf.org; Mon, 06 Mar 2006 18:40:41 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGPJg-0006oj-U2 for lemonade@ietf.org; Mon, 06 Mar 2006 18:40:41 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k26NecMs002941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 6 Mar 2006 15:40:39 -0800 Received: from [192.168.1.13] (loud.qualcomm.com [129.46.172.15]) by magus.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k26NeVfR002513; Mon, 6 Mar 2006 15:40:38 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Mon, 6 Mar 2006 15:40:13 -0800 To: lemonade@ietf.org, ietf-smtp@imc.org From: Randall Gellens Subject: [lemonade] Re: PIPELINING, AUTH, and CHUNKING 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: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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:56 PM +0000 2/23/06, Tony Finch wrote: > The BURL spec requires a sync point after the "LAST" BDAT or BURL command, > instead of after the message envelope. I think it would be better for BDAT > and BURL to not require any synchronization at all: if the client wants a > sync, it can use the NOOP command. Note that the main reason a sync point > is required after DATA is so that the client and server agree about > whether the next utterance from the client is a command or is message > data. This isn't a problem for BDAT because the command and data are sent > together, with a single response from the server for both. > > This would allow a client to pipeline multiple messages together, which > means you can move from using TCP in interactive mode to bulk data mode, > and therefore make the best use of the available bandwidth. For example, > consider a 1Mb/s link with a 100ms RTT. If the client sends a 5KB message, > this takes about 50ms to transmit, so by the time the server's replies > arrive the client will be one or two messages further on; if there was a > problem, the client can deal with it asynchronously, and it will have done > 50ms extra useful work. If the client sends a 20KB message, the server's > replies will start arriving part-way through message transmission, so if > there is a problem the client can usefully RSET it before the next chunk > to save time and bandwidth. > > I think it would be cool to allow this kind of high-bandwidth asynchronous > message transmission. It is also more friendly from the point of > congestion control than having multiple concurrent SMTP connections > perpetually in TCP slow start. Interesting. Both mobile and desktop clients often send multiple messages. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- "The meat is rotten, but the booze is holding out." --alleged computer translation of "The spirit is willing, but the flesh is weak." _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Mar 06 18:40:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGPJo-0001vI-6Q; Mon, 06 Mar 2006 18:40:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGPJm-0001ru-P7 for lemonade@ietf.org; Mon, 06 Mar 2006 18:40:46 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGPJm-0006oz-E7 for lemonade@ietf.org; Mon, 06 Mar 2006 18:40:46 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k26NehMs002956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 6 Mar 2006 15:40:44 -0800 Received: from [192.168.1.13] (loud.qualcomm.com [129.46.172.15]) by magus.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k26NeVfT002513; Mon, 6 Mar 2006 15:40:39 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Mon, 6 Mar 2006 15:40:23 -0800 To: lemonade@ietf.org, ietf-smtp@imc.org From: Randall Gellens Subject: [lemonade] Re: PIPELINING and failed recipients Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Chris Newman , Ned Freed X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 1:22 PM +0000 2/23/06, Tony Finch wrote: > I think both Ned and Dave mentioned the irritation that can arise from a > message and receiving a bounce for some of the recipients. (Note to self: > ietf-smtp@ietf.org is the wrong address). It's ietf-smtp@imc.org. > One advantage of a sync point > after the message envelope is that the client can decide not to proceed if > a subset of the recipients are rejected; this doesn't work if the envelope > and data are pipelined. (It is also limited by how strongly the server can > verify addresses.) What do you think of having a NOPARTFAIL parameter to > the MAIL command, which means that the client is asking the server to > reject the message data if any of the recipients are rejected - "no > partial failure". Perhaps "NOBADRCPT" or my earlier suggestion of "ABORTONBADRCPT". Maybe "ERRONBADRCPT"? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- When a man's best friend is his dog, that dog has a problem. --Edward Abbey _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Mar 06 18:45:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGPOT-0006zd-AV; Mon, 06 Mar 2006 18:45:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGPOS-0006zI-KP for lemonade@ietf.org; Mon, 06 Mar 2006 18:45:36 -0500 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGPOQ-0006sT-US for lemonade@ietf.org; Mon, 06 Mar 2006 18:45:36 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1FGPOP-0008MC-DJ; Mon, 06 Mar 2006 23:45:33 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id D0E05498003; Mon, 6 Mar 2006 23:46: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 32098-06; Mon, 6 Mar 2006 23:46:12 +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 13848498002; Mon, 6 Mar 2006 23:46:11 +0000 (GMT) Date: Mon, 06 Mar 2006 23:45:23 +0000 Subject: Re: [lemonade] streamlined message submission References: <21533.1140619429.225276@peirce.dave.cridland.net> <01LZ9FNBLMAS00009C@mauve.mrochek.com> <01LZ8M8NO8S800009C@mauve.mrochek.com> <01LZ9CVRUSC000009C@mauve.mrochek.com> <43FC8731.3080505@teamware.com> <21533.1140619429.225276@peirce.dave.cridland.net> <22667.1140657288.257701@peirce.dave.cridland.net> <21533.1140619429.225276@peirce.dave.cridland.net> <21533.1140619429.225276@peirce.dave.cridland.net> <01LZ8M8NO8S800009C@mauve.mrochek.com> <01LZ9CVRUSC000009C@mauve.mrochek.com> <01LZ8M8NO8S800009C@mauve.mrochek.com> <21533.1140619429.225276@peirce.dave.cridland.net> <01LZ9FNBLMAS00009C@mauve.mrochek.com> <01LZ8M8NO8S800009C@mauve.mrochek.com> <14379.1141550327.734683@peirce.dave.cridland.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <23144.1141688724.585729@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: 00e94c813bef7832af255170dca19e36 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Mon Mar 6 22:43:52 2006, Randall Gellens wrote: > At 9:18 AM +0000 3/5/06, Dave Cridland wrote: >> Chris Newman briefly proposed doing it the other way around, that >> is, generating the headers from the envelope. >> >> I've written this up as >> http://dave.cridland.net/draft-cridland-esmtp-headergen-pre.txt >> with XML source at >> http://svn.dave.cridland.net/svn/ietf-drafts/draft-cridland-esmtp-headergen.xml >> >> (This is very rough thus far, just aimed at being a talking >> point. In particular, as I write this, I note I've not yet >> seperated out informative and normative references at all.) >> >> Given the availability of PIPELINING, this seems like a better >> and easier way to go. > > I'd agree that this approach (generating headers from envelope) is > better than the other way around, since the client can easily > determine which address is bad, but I'd still question the value. > It seems to me that saving round-trips is the key, that as 3G > systems are deployed, total octet savings isn't as important, while > latency and round-trips still are. I could easily be wrong, of > course. But I'd like to see better explanations of why the added > complexity is worth the octet savings. > > Total octet count is primarily a battery problem, as I understand things, and also a layer 8 consideration. There's other issues that we can look at if the addressing header fields of the message are (largely) built from the envelope, however, such as revisiting the OMA's requirement for large recipient list manipulation. "Server-side" defined aliases and distribution lists might also be worth looking at. (Of course, I already have my aliases and lists defined server-side, so this makes good sense for me). > (By the way, I like that 'foo' is the username for 'Fred Oo' -- > clever). > > I didn't think it was as groundbreaking an achievement as Bob Ar, I was merely following a trend. :-) >> It's actually saying "If any RCPT is bad then I'm going to waste >> a stackload of data transmission, and therefore cost and battery >> life". I think if you want this behaviour, you have to introduce a >> post-envelope sync point - ie, you send the envelope, and examine >> responses to decide whether you wish to continue. > > I suppose it depends on if we want to optimize for the error case > or the non-error case. If we expect at least one RCPT to fail, > then we don't want to send the data until we know. But if we > expect that all RCPTs will be fine, then we don't want to introduce > a delay waiting for the server response if we can pipeline the > entire transaction. The size of the message is also significant, of > course. If we have a small message, then why have any delay? But > if we have a large message, maybe it makes sense to wait. > > So perhaps there is use for such an extension plus client advice on > how and when to use it. True. I think unfortunately it's a trade-off, and I can't see a way around that, which is fustrating. It's a good argument for assembling on the IMAP server and using BURL, over the alternative of assembling on the submit stream (and optionally using POSTADDRESS for FCC). Using a single BURL chunk means you're wasting less in the error case. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Mar 06 21:04:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGRYW-0001ZS-Ul; Mon, 06 Mar 2006 21:04:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGRYV-0001ZN-UW for lemonade@ietf.org; Mon, 06 Mar 2006 21:04:07 -0500 Received: from [209.55.107.55] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGRYT-0003PL-HY for lemonade@ietf.org; Mon, 06 Mar 2006 21:04:07 -0500 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LZQS78F2LC00AWN0@mauve.mrochek.com> for lemonade@ietf.org; Mon, 6 Mar 2006 18:04:03 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1141697043; h=Date: From:Subject:MIME-version:Content-type; b=qNwCbOQ+km4z5viA6CwDhNKeV BO1nJ3Q62PiVEqNt13ZaWf6dnYuJYZhEid0KBnSTDp5Y4JwMobADysYbCedNA== Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LZQIY3HFA800009C@mauve.mrochek.com>; Mon, 06 Mar 2006 18:04:01 -0800 (PST) To: Randall Gellens Message-id: <01LZQS77GJCW00009C@mauve.mrochek.com> Date: Mon, 06 Mar 2006 17:08:07 -0800 (PST) From: Ned Freed Subject: Re: [lemonade] streamlined message submission In-reply-to: "Your message dated Mon, 06 Mar 2006 14:43:52 -0800" MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <21533.1140619429.225276@peirce.dave.cridland.net> <01LZ9FNBLMAS00009C@mauve.mrochek.com> <01LZ8M8NO8S800009C@mauve.mrochek.com> <01LZ9CVRUSC000009C@mauve.mrochek.com> <43FC8731.3080505@teamware.com> <22667.1140657288.257701@peirce.dave.cridland.net> <14379.1141550327.734683@peirce.dave.cridland.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > > I've written this up as > > http://dave.cridland.net/draft-cridland-esmtp-headergen-pre.txt > > with XML source at > > http://svn.dave.cridland.net/svn/ietf-drafts/draft-cridland-esmtp-headergen.xml > > > > (This is very rough thus far, just aimed at being a talking point. > > In particular, as I write this, I note I've not yet seperated out > > informative and normative references at all.) First, I think FULLNAME/ENCNAME is neither necessary nor sufficient. We should stick to a single DISPLAYNAME argument and have it take whatever string is going to end up in the header, encoded as xtext. The insufficiency is that clients routinely need to generate headers containing multiple encoded words in a charset other than UTF-8. This proposal doesn't allow for this case. Second, you really should allow for the generation of bcc and resent-bcc as well as all the others. i do like limiting the set of headers to the sensible ones, however. > > Given the availability of PIPELINING, this seems like a better and > > easier way to go. > I'd agree that this approach (generating headers from envelope) is > better than the other way around, since the client can easily > determine which address is bad, but I'd still question the value. It > seems to me that saving round-trips is the key, that as 3G systems > are deployed, total octet savings isn't as important, while latency > and round-trips still are. I could easily be wrong, of course. But > I'd like to see better explanations of why the added complexity is > worth the octet savings. Full agreement on all points. If we have to do it this is the right way, however, I remain unconvinced that it is worth it. (And this is coming from someone whose SMTP server already has the capability to generate headers from envelope addresses - adding this is probably a few dozen liens of code at the very most.) Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Mar 07 04:09:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGYC1-0004Dq-HO; Tue, 07 Mar 2006 04:09:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGYBz-0004DO-Ac for lemonade@ietf.org; Tue, 07 Mar 2006 04:09:19 -0500 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGYBx-00026E-RE for lemonade@ietf.org; Tue, 07 Mar 2006 04:09:19 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1FGYBw-0005bL-0t; Tue, 07 Mar 2006 09:09:16 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id B35A6498003; Tue, 7 Mar 2006 09:10:05 +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 04976-10; Tue, 7 Mar 2006 09:10:00 +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 003F3498002; Tue, 7 Mar 2006 09:09:58 +0000 (GMT) Date: Tue, 07 Mar 2006 09:09:07 +0000 Subject: Re: [lemonade] streamlined message submission References: <21533.1140619429.225276@peirce.dave.cridland.net> <01LZ9FNBLMAS00009C@mauve.mrochek.com> <01LZ8M8NO8S800009C@mauve.mrochek.com> <01LZ9CVRUSC000009C@mauve.mrochek.com> <43FC8731.3080505@teamware.com> <22667.1140657288.257701@peirce.dave.cridland.net> <14379.1141550327.734683@peirce.dave.cridland.net> <01LZQS77GJCW00009C@mauve.mrochek.com> In-Reply-To: <01LZQS77GJCW00009C@mauve.mrochek.com> MIME-Version: 1.0 Message-Id: <23144.1141722548.499078@peirce.dave.cridland.net> From: Dave Cridland To: Ned Freed 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: cd26b070c2577ac175cd3a6d878c6248 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 Mar 7 01:08:07 2006, Ned Freed wrote: >> > I've written this up as >> > http://dave.cridland.net/draft-cridland-esmtp-headergen-pre.txt >> > with XML source at >> > >> http://svn.dave.cridland.net/svn/ietf-drafts/draft-cridland-esmtp-headergen.xml >> > >> > (This is very rough thus far, just aimed at being a talking >> point. >> > In particular, as I write this, I note I've not yet seperated out >> > informative and normative references at all.) > > First, I think FULLNAME/ENCNAME is neither necessary nor > sufficient. We should > stick to a single DISPLAYNAME argument and have it take whatever > string is > going to end up in the header, encoded as xtext. > > The insufficiency is that clients routinely need to generate > headers containing > multiple encoded words in a charset other than UTF-8. This proposal > doesn't > allow for this case. > > I was trying to push the RFC2047 encoding toward the server, to simplify the client, in the hope an IMAP extension might do the same for the decoding. The trouble is, the xtext encoding is pretty verbose, and I thought the double-encoding of RFC2047+xtext was just really ugly. FWIW, I'd be quite happy to push the display-name entirely onto the server, by telling it to go look it up, but therein lies a specification nightmare. I'll rework it as a single DISPLAYNAME argument. Is anyone interested in group syntax, by the way? > Second, you really should allow for the generation of bcc and > resent-bcc as > well as all the others. i do like limiting the set of headers to > the sensible > ones, however. > > I've never been sure why a submission client would specify a Bcc header, it's always seemed to me to be unsafe behaviour, given that the client cannot know how Bcc is treated by the submission server, so I deliberately missed out the Bcc and Resent-Bcc headers. This also saved me from writing anything more in the Security Considerations section. :-) > Full agreement on all points. If we have to do it this is the right > way, > however, I remain unconvinced that it is worth it. (And this is > coming from > someone whose SMTP server already has the capability to generate > headers from > envelope addresses - adding this is probably a few dozen liens of > code at the > very most.) I'll reiterate two points: 1) I wrote up this off-hand suggestion from Chris Newman primarily to start discussion. I haven't implemented this either, and the actual octet savings are very slim indeed, they're smaller than just omitting the addressing header fields. (Roughly equal to omitting the envelope, which is where all this started). 2) However, having a reasonable framework for generating addressing header fields from the envelope does provide us with a base to manipulate addresses and address lists at a single point in the ESMTP transaction, rather than twice. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Mar 07 09:07:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGcqJ-0006Fv-Ne; Tue, 07 Mar 2006 09:07:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGVVI-0007mv-8Z for lemonade@ietf.org; Tue, 07 Mar 2006 01:17:04 -0500 Received: from mail3.panix.com ([166.84.1.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGVVE-0002d5-0V for lemonade@ietf.org; Tue, 07 Mar 2006 01:17:04 -0500 Received: from mailspool2.panix.com (mailspool2.panix.com [166.84.1.79]) by mail3.panix.com (Postfix) with ESMTP id A61D913AA19; Tue, 7 Mar 2006 01:16:59 -0500 (EST) Received: from [192.168.1.11] (ool-45749fe3.dyn.optonline.net [69.116.159.227]) by mailspool2.panix.com (Postfix) with ESMTP id 8FDA0F53883; Tue, 7 Mar 2006 01:16:59 -0500 (EST) Mime-Version: 1.0 X-Sender: Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X 6.2.3 (MacOS 10.3) Date: Tue, 7 Mar 2006 00:28:08 -0500 To: ietf-smtp@imc.org From: "Robert A. Rosenberg" Subject: [lemonade] Re: PIPELINING and failed recipients Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.5 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-Mailman-Approved-At: Tue, 07 Mar 2006 09:07:13 -0500 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 15:40 -0800 on 03/06/2006, Randall Gellens wrote about [lemonade] Re: PIPELINING and failed recipients: > > One advantage of a sync point >> after the message envelope is that the client can decide not to proceed if >> a subset of the recipients are rejected; this doesn't work if the envelope >> and data are pipelined. (It is also limited by how strongly the server can >> verify addresses.) What do you think of having a NOPARTFAIL parameter to >> the MAIL command, which means that the client is asking the server to >> reject the message data if any of the recipients are rejected - "no > > partial failure". If I am sending a multi-addressed message, I would like the ability (even if pipelining) to get a response stating if each recipient was accepted or not, and have the MUA requeue the message with all the rejected addresses while allowing the message to get sent with the valid addresses. IOW: Leave it as "failed" as presently occurs if it can not get sent BUT remove the accepted addresses so the failed version only contains the rejected addresses. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Mar 08 19:02:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH8bf-0006cn-0e; Wed, 08 Mar 2006 19:02:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH8be-0006ci-Hg for lemonade@ietf.org; Wed, 08 Mar 2006 19:02:14 -0500 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH8bd-0001to-Bz for lemonade@ietf.org; Wed, 08 Mar 2006 19:02:14 -0500 X-IronPort-AV: i="4.02,177,1139202000"; d="scan'208"; a="29700486:sNHT27741348" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Mar 2006 19:02:11 -0500 Message-ID: <330A23D8336C0346B5C1A5BB196666470264A075@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: It's Official Thread-Index: AcZDDLc6SjHL5pkfRhmzR+1uRBO+dA== From: "Burger, Eric" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [lemonade] It's Official X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org LEMONADE Session 1 (2 hours) Monday, Afternoon Session II 1520-1720 Room Name: Miro ---------------------------------------------- LEMONADE Session 2 (2 hours) Wednesday, Morning Session I 0900-1130 Room Name: Miro ---------------------------------------------- _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Mar 08 21:31:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHAvf-0002hC-CJ; Wed, 08 Mar 2006 21:31:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHAve-0002eR-Ji for lemonade@ietf.org; Wed, 08 Mar 2006 21:31:02 -0500 Received: from smtp.andrew.cmu.edu ([128.2.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHAvd-0006uc-Dc for lemonade@ietf.org; Wed, 08 Mar 2006 21:31:02 -0500 Received: from [192.168.137.17] (69-171-17-197.kntnny.adelphia.net [69.171.17.197]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.4/8.13.4) with ESMTP id k292V0cN021875 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 8 Mar 2006 21:31:00 -0500 Message-ID: <440F9363.5000104@andrew.cmu.edu> Date: Wed, 08 Mar 2006 21:30:59 -0500 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-imapext@imc.org, lemonade@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [lemonade] BINARY & CATENATE X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org With the help of the good folks at Lucent I've been working on adding support for BINARY APPEND to Cyrus (to go along with its existing support for BINARY FETCH). I'm now wondering if I need to support BINARY (literal8) for CATENATE (TEXT parts)? I don't see any mention of BINARY or literal8 in the CATENATE draft. And what about CTE=binary in messages/parts fetched via URLs? -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Mar 09 14:31:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHQrb-0006JB-0Z; Thu, 09 Mar 2006 14:31:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHQra-0006Fm-8y for lemonade@ietf.org; Thu, 09 Mar 2006 14:31:54 -0500 Received: from 216-43-25-66.ip.mcleodusa.net ([216.43.25.66] helo=episteme-software.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHQrY-0004vw-Sm for lemonade@ietf.org; Thu, 09 Mar 2006 14:31:54 -0500 Received: from [129.46.77.116] (127.0.0.1) by episteme-software.com with ESMTP (EIMS X 3.3d15); Thu, 9 Mar 2006 13:31:51 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <440F9363.5000104@andrew.cmu.edu> References: <440F9363.5000104@andrew.cmu.edu> X-Mailer: Eudora [Macintosh version 7.0a12] Date: Thu, 9 Mar 2006 11:31:48 -0800 To: Ken Murchison From: Pete Resnick Subject: Re: [lemonade] BINARY & CATENATE Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ietf-imapext@imc.org, 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 3/8/06 at 9:30 PM -0500, Ken Murchison wrote: >I'm now wondering if I need to support BINARY (literal8) for >CATENATE (TEXT parts)? I don't see any mention of BINARY or >literal8 in the CATENATE draft. Damn! How did I miss that? I'd sure like you to add the support for it and we'll fix CATENATE the next time around. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Mar 09 15:06:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHROt-00083h-UT; Thu, 09 Mar 2006 15:06:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHROt-0007y2-0T for lemonade@ietf.org; Thu, 09 Mar 2006 15:06:19 -0500 Received: from smtp.andrew.cmu.edu ([128.2.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHROr-0005ub-Ma for lemonade@ietf.org; Thu, 09 Mar 2006 15:06:18 -0500 Received: from [192.168.137.17] (69-171-17-197.kntnny.adelphia.net [69.171.17.197]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.4/8.13.4) with ESMTP id k29K6GEp009110 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 9 Mar 2006 15:06:17 -0500 Message-ID: <44108AB8.30205@andrew.cmu.edu> Date: Thu, 09 Mar 2006 15:06:16 -0500 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete Resnick Subject: Re: [lemonade] BINARY & CATENATE References: <440F9363.5000104@andrew.cmu.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ietf-imapext@imc.org, 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 Pete Resnick wrote: > On 3/8/06 at 9:30 PM -0500, Ken Murchison wrote: > >> I'm now wondering if I need to support BINARY (literal8) for CATENATE >> (TEXT parts)? I don't see any mention of BINARY or literal8 in the >> CATENATE draft. > > > Damn! How did I miss that? > > I'd sure like you to add the support for it and we'll fix CATENATE the > next time around. Is this something that we should put on the agenda for one/both WG at the upcoming meetings? -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Mar 09 15:08:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHRRT-0002N4-4E; Thu, 09 Mar 2006 15:08:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHRRS-0002Mz-1k for lemonade@ietf.org; Thu, 09 Mar 2006 15:08:58 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHRRQ-00060H-K5 for lemonade@ietf.org; Thu, 09 Mar 2006 15:08:58 -0500 Received: from [172.16.1.198] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Thu, 9 Mar 2006 20:08:48 +0000 Message-ID: <44108B4F.6070000@isode.com> Date: Thu, 09 Mar 2006 20:08:47 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Ken Murchison Subject: Re: [lemonade] BINARY & CATENATE References: <440F9363.5000104@andrew.cmu.edu> <44108AB8.30205@andrew.cmu.edu> In-Reply-To: <44108AB8.30205@andrew.cmu.edu> 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-imapext@imc.org, 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 Ken Murchison wrote: > Pete Resnick wrote: > >> On 3/8/06 at 9:30 PM -0500, Ken Murchison wrote: >> >>> I'm now wondering if I need to support BINARY (literal8) for >>> CATENATE (TEXT parts)? I don't see any mention of BINARY or >>> literal8 in the CATENATE draft. >> >> Damn! How did I miss that? >> >> I'd sure like you to add the support for it and we'll fix CATENATE >> the next time around. > > Is this something that we should put on the agenda for one/both WG at > the upcoming meetings? We should address this in Lemonade Profile Phase 2. So discussing this in Lemonade seems appropriate. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Mar 09 16:19:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHSOp-00041R-NG; Thu, 09 Mar 2006 16:10:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHS5G-0000yZ-Li; Thu, 09 Mar 2006 15:50:06 -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 1FHS5G-0007Ej-JV; Thu, 09 Mar 2006 15:50:06 -0500 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=oak.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FHS5C-0005Qr-KU; Thu, 09 Mar 2006 15:50:06 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k29Ko2BX027046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Mar 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FHS5C-00006j-9N; Thu, 09 Mar 2006 15:50:02 -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, 09 Mar 2006 15:50:02 -0500 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-imap-sieve-01.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. Title : Support for Sieve in Internet Message Access Protocol (IMAP4) Author(s) : B. Leiba Filename : draft-ietf-lemonade-imap-sieve-01.txt Pages : 21 Date : 2006-3-9 Sieve defines an email filtering language that can, in principle, plug into any point in the processing of an email message. As defined in the base specification, it plugs into mail delivery. This document defines how Sieve can plug into points in the IMAP protocol where messages are created or changed, adding the option of user- defined or installation-defined filtering (or, with Sieve extensions, features such as notifications). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-imap-sieve-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-imap-sieve-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-imap-sieve-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-9115541.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-imap-sieve-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-imap-sieve-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-9115541.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 Mar 09 19:06:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHV9U-0005HQ-1E; Thu, 09 Mar 2006 19:06:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHV9S-0005H8-In for lemonade@ietf.org; Thu, 09 Mar 2006 19:06:38 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHV9R-00086U-8d for lemonade@ietf.org; Thu, 09 Mar 2006 19:06:38 -0500 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k2A06Y5n027774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 9 Mar 2006 16:06:35 -0800 Received: from [192.168.1.13] (loud.qualcomm.com [129.46.172.15]) by crowley.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k2A06XXa010684; Thu, 9 Mar 2006 16:06:33 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <000201c640ba$dc384dd0$6401a8c0@gawhitelaptop> References: <000201c640ba$dc384dd0$6401a8c0@gawhitelaptop> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Thu, 9 Mar 2006 16:06:29 -0800 To: "Greg White" , From: Randall Gellens Subject: RE: [lemonade] final future release question (I think) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 7:11 PM -0600 3/5/06, Greg White wrote: > Or maybe 4 (I'm assuming Randy hasn't > changed his mind) No, I haven't. :-) (I still prefer the HOLDFOR and HOLDUNTIL versions, just because I think they look better.) -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- And still I persist in wondering if folly must always be man's nemesis. --Edgar Pangborn _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Mar 09 19:17:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHVK3-0004O0-9M; Thu, 09 Mar 2006 19:17:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHVK2-0004Nv-A3 for lemonade@ietf.org; Thu, 09 Mar 2006 19:17:34 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHVK0-00007q-W9 for lemonade@ietf.org; Thu, 09 Mar 2006 19:17:34 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k2A0HS5n028847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 9 Mar 2006 16:17:29 -0800 Received: from [192.168.1.13] (loud.qualcomm.com [129.46.172.15]) by neophyte.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k2A0HNRR017310; Thu, 9 Mar 2006 16:17:26 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <23144.1141688724.585729@peirce.dave.cridland.net> References: <21533.1140619429.225276@peirce.dave.cridland.net> <01LZ9FNBLMAS00009C@mauve.mrochek.com> <01LZ8M8NO8S800009C@mauve.mrochek.com> <01LZ9CVRUSC000009C@mauve.mrochek.com> <43FC8731.3080505@teamware.com> <21533.1140619429.225276@peirce.dave.cridland.net> <22667.1140657288.257701@peirce.dave.cridland.net> <21533.1140619429.225276@peirce.dave.cridland.net> <21533.1140619429.225276@peirce.dave.cridland.net> <01LZ8M8NO8S800009C@mauve.mrochek.com> <01LZ9CVRUSC000009C@mauve.mrochek.com> <01LZ8M8NO8S800009C@mauve.mrochek.com> <21533.1140619429.225276@peirce.dave.cridland.net> <01LZ9FNBLMAS00009C@mauve.mrochek.com> <01LZ8M8NO8S800009C@mauve.mrochek.com> <14379.1141550327.734683@peirce.dave.cridland.net> <23144.1141688724.585729@peirce.dave.cridland.net> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Thu, 9 Mar 2006 16:11:39 -0800 To: Dave Cridland , Alexey Melnikov From: Randall Gellens Subject: Re: [lemonade] streamlined message submission Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 11:45 PM +0000 3/6/06, Dave Cridland wrote: > It's a good argument for assembling on the IMAP server and using > BURL, over the alternative of assembling on the submit stream (and > optionally using POSTADDRESS for FCC). Using a single BURL chunk > means you're wasting less in the error case. This is a good point and one that I think should be mentioned in profile-bis. It's an advantage of CATENATE that I hadn't considered. -- 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 Thu Mar 09 19:24:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHVQh-0007Je-7X; Thu, 09 Mar 2006 19:24:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHVQf-0007Fd-NN for lemonade@ietf.org; Thu, 09 Mar 2006 19:24:25 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHVQe-0000SI-CU for lemonade@ietf.org; Thu, 09 Mar 2006 19:24:25 -0500 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k2A0OM5n029384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 9 Mar 2006 16:24:22 -0800 Received: from [192.168.1.13] (loud.qualcomm.com [129.46.172.15]) by crowley.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k2A0OIZv015720; Thu, 9 Mar 2006 16:24:20 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Thu, 9 Mar 2006 16:22:00 -0800 To: "Robert A. Rosenberg" , ietf-smtp@imc.org From: Randall Gellens Subject: [lemonade] Re: PIPELINING and failed recipients Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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:28 AM -0500 3/7/06, Robert A. Rosenberg wrote: > At 15:40 -0800 on 03/06/2006, Randall Gellens wrote about > [lemonade] Re: PIPELINING and failed recipients: That attribution is misleading, since I was quoting a message from Tony Finch, I think. >> > One advantage of a sync point >>> after the message envelope is that the client can decide not to >>> proceed if >>> a subset of the recipients are rejected; this doesn't work if >>> the envelope >>> and data are pipelined. (It is also limited by how strongly the >>> server can >>> verify addresses.) What do you think of having a NOPARTFAIL parameter to >>> the MAIL command, which means that the client is asking the server to >>> reject the message data if any of the recipients are rejected - "no >> > partial failure". > > If I am sending a multi-addressed message, I would like the ability > (even if pipelining) to get a response stating if each recipient > was accepted or not, and have the MUA requeue the message with all > the rejected addresses while allowing the message to get sent with > the valid addresses. IOW: Leave it as "failed" as presently occurs > if it can not get sent BUT remove the accepted addresses so the > failed version only contains the rejected addresses. I am not sure what you are saying. Are you asking that clients be written to behave in a specific way regarding a message where some recipients are rejected by the submission server? Currently, clients can choose which behavior to support: immediate send to good recipients, or hold message in abeyance and alert user, who can either correct or delete the bad rejected recipients. No one has suggested anything that would force the client to choose one way or the other. An extension such as "NOBADRCPT" (or "ABORTONBADRCPT" or "ERRONBADRCPT") would allow the client to behave in either way. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- "SFPD Homicide: Our Day Begins when Yours End" --Slogan seen on back of San Francisco Police Jacket, as reported by Herb Cain in SF Chronicle _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Mar 10 16:14:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHot6-0002JP-TG; Fri, 10 Mar 2006 16:11:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHot5-0002JC-Qh for lemonade@ietf.org; Fri, 10 Mar 2006 16:11:03 -0500 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHot5-0007tX-FA for lemonade@ietf.org; Fri, 10 Mar 2006 16:11:03 -0500 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k2ALB2nl029779; Fri, 10 Mar 2006 15:11:02 -0600 (CST) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 10 Mar 2006 15:11:02 -0600 Message-ID: <54E40201497DF142B06B27255953F7971C72694D@il0015exch007u.ih.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: lemonade@ietf.org, ietf-smtp@imc.org Date: Fri, 10 Mar 2006 15:10:58 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C64487.1F5BDF8A" X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: Subject: [lemonade] FW: I-D ACTION:draft-vaudreuil-esmtp-binary3-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 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. ------_=_NextPart_000_01C64487.1F5BDF8A Content-Type: text/plain; charset="iso-8859-1" FYI. Greg V. -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Friday, March 10, 2006 3:50 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-vaudreuil-esmtp-binary3-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SMTP Service Extensions for Transmission of Large and Binary MIME Messages Author(s) : G. Vaudreuil Filename : draft-vaudreuil-esmtp-binary3-02.txt Pages : 12 Date : 2006-3-10 This memo defines two extensions to the SMTP service. The first extension enables a SMTP client and server to negotiate the use of an alternative to the DATA command, called "BDAT", for efficiently sending large MIME messages. The second extension takes advantage of the BDAT command to permit the negotiated sending of MIME messages that employ the binary transfer encoding. This document is intended to obsolete RFC 3030. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-vaudreuil-esmtp-binary3-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-vaudreuil-esmtp-binary3-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-vaudreuil-esmtp-binary3-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_000_01C64487.1F5BDF8A Content-Type: message/rfc822 To: Subject: Date: Fri, 10 Mar 2006 14:52:25 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C64487.1F5BDF8A" ------_=_NextPart_002_01C64487.1F5BDF8A Content-Type: text/plain ------_=_NextPart_002_01C64487.1F5BDF8A Content-Type: application/octet-stream; name="ATT47258" Content-Disposition: attachment; filename="ATT47258" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-10103022.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-vaudreuil-esmtp-binary3-02.txt ------_=_NextPart_002_01C64487.1F5BDF8A Content-Type: message/external-body; site="internet-drafts"; dir="draft-vaudreuil-esmtp-binary3-02.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C64487.1F5BDF8A-- ------_=_NextPart_000_01C64487.1F5BDF8A Content-Type: text/plain; name="ATT4725845.txt" Content-Disposition: attachment; filename="ATT4725845.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------_=_NextPart_000_01C64487.1F5BDF8A 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_000_01C64487.1F5BDF8A-- From lemonade-bounces@ietf.org Sun Mar 12 16:52:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIYUY-0007UM-W8; Sun, 12 Mar 2006 16:52:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHRvS-0006xi-Ua for lemonade@ietf.org; Thu, 09 Mar 2006 15:39:58 -0500 Received: from orthanc.ca ([209.89.70.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHRvR-00070j-Jx for lemonade@ietf.org; Thu, 09 Mar 2006 15:39:58 -0500 Received: from [10.8.9.61] (mx1.gmi-mr.com [216.32.20.2] (may be forged)) (authenticated bits=0) by orthanc.ca (8.13.4/8.13.4) with ESMTP id k29KdfSh021065; Thu, 9 Mar 2006 13:39:43 -0700 (MST) (envelope-from lyndon@orthanc.ca) Message-ID: <44109286.7030000@orthanc.ca> Date: Thu, 09 Mar 2006 12:39:34 -0800 From: Lyndon Nerenberg User-Agent: Thunderbird 1.5 (X11/20060201) MIME-Version: 1.0 To: Dave Cridland Subject: Re: [lemonade] BINARY & CATENATE References: <440F9363.5000104@andrew.cmu.edu> <12195.1141934644.865501@peirce.dave.cridland.net> In-Reply-To: <12195.1141934644.865501@peirce.dave.cridland.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on orthanc.ca X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-Mailman-Approved-At: Sun, 12 Mar 2006 16:52:45 -0500 Cc: Pete Resnick , ietf-imapext@imc.org, 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 > BINARY is on the cards for a revision, I think, perhaps it could be > added to that? Might be able to get it all sorted out quicker. I have started on the update, and plan to push a draft soon after the freeze is over. I'm not sure this can be fixed in the BINARY document, but work out what you need and I'll see what can be done. I won't be in Dallas, but I should be able to attend via Jabber (ugh). --lyndon _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Mar 12 16:52:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIYUY-0007U4-Rq; Sun, 12 Mar 2006 16:52:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHRMs-0001NO-D0 for lemonade@ietf.org; Thu, 09 Mar 2006 15:04:14 -0500 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHRMr-0005r1-40 for lemonade@ietf.org; Thu, 09 Mar 2006 15:04:14 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1FHRMo-0006Ua-R6; Thu, 09 Mar 2006 20:04:10 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id D1020498003; Thu, 9 Mar 2006 20:05: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 01465-06; Thu, 9 Mar 2006 20:05: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 4E4B8498002; Thu, 9 Mar 2006 20:05:20 +0000 (GMT) Date: Thu, 09 Mar 2006 20:04:04 +0000 Subject: Re: [lemonade] BINARY & CATENATE References: <440F9363.5000104@andrew.cmu.edu> In-Reply-To: MIME-Version: 1.0 Message-Id: <12195.1141934644.865501@peirce.dave.cridland.net> From: Dave Cridland To: Pete Resnick , Lyndon Nerenberg Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Heisenberg-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-Mailman-Approved-At: Sun, 12 Mar 2006 16:52:45 -0500 Cc: ietf-imapext@imc.org, diverse service enivronments , Enhancements X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu Mar 9 19:31:48 2006, Pete Resnick wrote: > On 3/8/06 at 9:30 PM -0500, Ken Murchison wrote: > >> I'm now wondering if I need to support BINARY (literal8) for >> CATENATE (TEXT parts)? I don't see any mention of BINARY or >> literal8 in the CATENATE draft. > > Damn! How did I miss that? > > I'd sure like you to add the support for it and we'll fix CATENATE > the next time around. BINARY is on the cards for a revision, I think, perhaps it could be added to that? Might be able to get it all sorted out quicker. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Mar 12 16:52:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIYUZ-0007UR-3n; Sun, 12 Mar 2006 16:52:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHZfl-0007pk-Fh for lemonade@ietf.org; Thu, 09 Mar 2006 23:56:17 -0500 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHZfk-0008G8-A2 for lemonade@ietf.org; Thu, 09 Mar 2006 23:56:17 -0500 Received: from gawhitelaptop (c-67-162-191-81.hsd1.tx.comcast.net[67.162.191.81]) by comcast.net (sccrmhc14) with SMTP id <20060310045615014000pc86e>; Fri, 10 Mar 2006 04:56:15 +0000 From: "Greg White" To: Date: Thu, 9 Mar 2006 22:55:58 -0600 Message-ID: <000001c643fe$eef92f60$6401a8c0@gawhitelaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-Mailman-Approved-At: Sun, 12 Mar 2006 16:52:45 -0500 Subject: [lemonade] New Future Release Draft X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org The FUTURERELEASE draft has been updated as requested on the list. I = did not get it submitted before the deadline, but I have posted it for those = who would like to look at it. Draft: http://home.comcast.net/~g.a.white/draft-ietf-lemonade-futuredelivery-04.= txt RFC Diffs: http://home.comcast.net/~g.a.white/rfcdiff.html Greg _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Mar 13 10:43:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIpCy-0002cd-Rj; Mon, 13 Mar 2006 10:43:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIpCx-0002a9-8T for lemonade@ietf.org; Mon, 13 Mar 2006 10:43:43 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIpCw-000296-LO for lemonade@ietf.org; Mon, 13 Mar 2006 10:43:43 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 00DD54AC1B; Mon, 13 Mar 2006 16:43:40 +0100 (CET) Message-Id: Date: Mon, 13 Mar 2006 16:54:58 +0100 From: Arnt Gulbrandsen To: stephane.maes@oracle.com, lemonade@ietf.org Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Subject: [lemonade] WITHIN draft review X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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, some thoughts on that. Small issues first, big at the end. First, let me say that I've needed an extension like this for some months, and the only reason I haven't written an extension like it myself is that I couldn't solve the problem I describe at the end. 1. There are some nits. Formatting problems. Lots of windows smartquotes and so on, while drafts should be in US-ASCII. The formal syntax is wrong, there should be an SP between "WITHIN" and number. 2. The name of the search-key is somewhat at odds with the way IMAP does things. Mostly, IMAP uses search keys called x and UNx. SEEN/UNSEEN, KEYWORD/UNKEYWORD, SENTSINCE/SENTBEFORE. This may or may not be a good idea, but it's existing practice. If this extension is to fit well into IMAP, then I suggest that it calls its search-keys like OLDER/YOUNGER, instead of NOT WITHIN/WITHIN. 3. Mostly, IMAP uses days for such things, and disregards timezones when comparing times. See the bottom part of RFC 3501 page 52, for example. WITHIN uses seconds, and does not mention timezones. 4. As far as I can see from the draft, WITHIN corresponds to SENTSINCE etc, not SINCE etc. That is, WITHIN cannot be used to search for all mail which has been received during the past two days. SEARCH NOT WITHIN 604800 seaches for all mail which is _dated_ more than a week ago. Not mail which was _received_ more than a week ago. I'm not sure which of the two is more desirable. It would be possible to have both by extending IMAP differently - using "-" nz-number as an alternative to time-date in SENTSINCE and friend. Instead of SEARCH NOT WITHIN 604800, the extension could say SEARCH SENTBEFORE -7 to find messages sent more than 7 days ago. Or it could say SEARCH SEARCH BEFORE -7 to search for mail which was received more than 7 days ago. 5. The big, big problem. WITHIN+VFOLDER are difficult to implement correctly and effciently. Take a search such as 'UNSEEN NOT WITHIN 86400', ie. a search for all unread messages older than one day. The UNSEEN bit of the search changes only when the mailbox' modsequence increases (or equivalent for servers which don't implement CONDSTORE). However, WITHIN changes potentially every second, even when nothing happens to the mailbox. So, in order to perform this search accurately, the server has to perform the search almost every time the client sends an IMAP command. If the mailbox is big, that's awfully expensive. There are two ways out of this, as far as I can see. One is to use day resolution for WITHIN. In that case, the server generally only has to reevaluate the search when the modsequence/uidnext changes, and once per day additionally. Not too bad. The other is to add special rules to say that, in effect, if WITHIN matches a message once in a mailbox session, it matches that message until the end of the session. In other words, WITHIN uses the time of the SELECT/EXAMINE as basis, not the current time. (I dislike this, for several reasons. Will elaborate on request, but this mail is long enough already.) Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Mar 13 12:28:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIqqX-0004u0-De; Mon, 13 Mar 2006 12:28:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIqqW-0004sc-By for lemonade@ietf.org; Mon, 13 Mar 2006 12:28:40 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIqqT-0005yb-Nv for lemonade@ietf.org; Mon, 13 Mar 2006 12:28:40 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 894754AC1B for ; Mon, 13 Mar 2006 18:28:36 +0100 (CET) Message-Id: Date: Mon, 13 Mar 2006 18:39:54 +0100 From: Arnt Gulbrandsen To: Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] compression References: <43725028.8060204@att.com> In-Reply-To: Content-Type: multipart/mixed; boundary=- MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --- Content-Type: text/plain; format=flowed Finally following up the short thread last autumn with some numbers, here's a short comparison of RFC 3749, draft-gulbrandsen-imap-deflate and draft-lemonade-lzip. RFC 3749 and imap-deflate are very similar in terms of compression. In general, RFC 3749 will win over imap-deflate by about 20 bytes, independently of the length of the IMAP connection. Two minutes or two hours, doesn't matter. The difference is because 3749 negotiates compression at a cost of just two bytes (one in the client hello, one in the server). For the IMAP conversation appended, here are the results comparing 3749/deflate with lzip. These numbers are approximate: I took some working code and hacked it to produce numbers instead of work. I accidentally mangled the line endings, so all the numbers are off by some small factor (1%?). The thread I used is just a few messages from lemonade. I just picked a random thread, and read a few messages using a fairly popular IMAP client, and played with the TCP connection until all passwords etc. were gone. There are four commands, each with 1-4 untagged and one tagged response. I have numbered them a1 to a4. Command a1 is compressed by all three to 42 bytes, much worse than its original 22. Its response is compressed to 70 bytes, from 123. The reason they do the same is that all three compressors use the same algorithm and do exactly the same work: Starting compression (which has overhead of about 20 bytes IIRC), learning that the compressed text contains ASCII, etc. Command a2 is compressed by lzip from 202 to 170 bytes, and by 3749/deflate to 138. The response is compressed by lzip from 3498 to 1016 bytes, and by 3749/deflate to 899. lzip does worse than the two others because it pays the startup cost again, while the two others already have trained their compressors to know that there's lots of printable ASCII, '* FETCH' occurs often, etc. Command a3 is compressed by lzip from 20 to 40 bytes (the same as the first command, really) and by 3749/deflate to 9 bytes. (Lzip pays the startup cost for the seventh time. The compressors in 3749/deflate have learnt from commands a1 and a2 approximately how an IMAP command looks, so they compress even a short command efficiently.) The response tells the same picture: 3749/deflate compresses the response from 2772 to 1112 bytes, lzip manages 1284. The difference here is mostly that 3749/deflate already knows that almost all bytes sent are ASCII words, while for lzip, the compressor has to learn it. There's also the usual 20-byte startup fee. Command a4 is 40 bytes again with lzip. With 3749/deflate it's 22. The response has an original size of 1078 characters. 3749/deflate compresses that to 280 characters. This result is so good becaus the response is pure text, and it's in the same thread as the a3 response. lzip doens't do so well: 559. Its compressor again has to learn everything from scratch, and it can't exploit the fact that threads frequently contain the same words and even sentences. Summing up: All three lose a bit on their first command, about 20 bytes. 3749/deflate win on the second and subsequent command. Lzip wins on the big command, loses on the two small commands. All three win on the responses, but 3749/deflate win much more, sometimes achieving results half the size of lzip's. I'll be happy to repeat this survey with a bigger corpus, if it's desirable. I don't see the point, myself. The numbers are clear enough already. Finally, I don't know whether the upstream comparison matters. I included the numbers because I thought they might matter for battery-powered devices where transmitting bytes to the server is expensive. Not my field. Downstream surely matters, and that's where 3749/gulbrandsen win by a large margin. Arnt --- Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; size=7767; filename=lemonade-thread >> a1 FETCH 1:* (FLAGS) << * 1 FETCH (FLAGS (\recent)) << * 2 FETCH (FLAGS (\recent)) << * 3 FETCH (FLAGS (\recent)) << * 4 FETCH (FLAGS (\recent)) << a1 OK done >> a2 FETCH 1:4 (UID FLAGS INTERNALDATE RFC822.SIZE BODY.PEEK[HEADER.FIELD= S (DATE FROM SUBJECT TO CC MESSAGE-ID REFERENCES CONTENT-TYPE CONTENT-DESCR= IPTION IN-REPLY-TO REPLY-TO LINES LIST-POST X-LABEL)]) << * 1 FETCH (UID 1 RFC822.SIZE 6039 FLAGS (\recent) INTERNALDATE "01-Jan-= 1970 00:00:00 +0000" BODY[HEADER.FIELDS (Date From Subject To Cc Message-Id= References Content-Type Content-Description In-Reply-To Reply-To Lines Lis= t-Post X-Label)] {473} << Message-Id: <54E40201497DF142B06B27255953F79705DADA36@il0015exch007u.ih= .lucent.com> << From: "Vaudreuil, Greg M (Greg)" << To: Mark Crispin , << Pete Resnick << Cc: lemonade@ietf.org << Subject: RE: [lemonade] Re: Point-of-order re IMAPEXT (Was: draft-royer= -le << monade-submit-00.txt) << Date: Tue, 17 Jun 2003 19:08:59 -0500 << Content-Type: text/plain; charset=3Diso-8859-1 << List-Post: << << ) << * 2 FETCH (UID 2 RFC822.SIZE 11136 FLAGS (\recent) INTERNALDATE "01-Jan= -1970 00:00:00 +0000" BODY[HEADER.FIELDS (Date From Subject To Cc Message-I= d References Content-Type Content-Description In-Reply-To Reply-To Lines Li= st-Post X-Label)] {671} << Message-Id: <3EEFB7A3.4050509@Royer.com> << Date: Tue, 17 Jun 2003 18:51:47 -0600 << From: Doug Royer << Reply-To: lemonade@ietf.org << To: lemonade@ietf.org << Subject: Re: [lemonade] Re: Point-of-order re IMAPEXT (Was: << draft-royer-lemonade-submit-00.txt) << References: <200306171156.HAA08281@ietf.org> << << << << Content-Type: multipart/signed; protocol=3D"application/x-pkcs7-signatu= re"; << micalg=3Dsha1; boundary=3D------------ms070409030502070300010903 << List-Post: << << ) << * 3 FETCH (UID 3 RFC822.SIZE 3857 FLAGS (\recent) INTERNALDATE "01-Jan-= 1970 00:00:00 +0000" BODY[HEADER.FIELDS (Date From Subject To Cc Message-Id= References Content-Type Content-Description In-Reply-To Reply-To Lines Lis= t-Post X-Label)] {494} << Date: Tue, 17 Jun 2003 19:44:08 -0600 << Subject: Re: [lemonade] Re: Point-of-order re IMAPEXT (Was: draft-royer= -le << monade-submit-00.txt) << Content-Type: text/plain; format=3Dflowed << Cc: lemonade@ietf.org << To: "Vaudreuil, Greg M (Greg)" << From: Lyndon Nerenberg << In-Reply-To: <54E40201497DF142B06B27255953F79705DADA36@il0015exch007u.i= h.lucent.com> << Message-Id: <5A1C3760-A12E-11D7-B9DC-000393D34A62@orthanc.ab.ca> << List-Post: << << ) << * 4 FETCH (UID 4 RFC822.SIZE 11003 FLAGS (\recent) INTERNALDATE "01-Jan= -1970 00:00:00 +0000" BODY[HEADER.FIELDS (Date From Subject To Cc Message-I= d References Content-Type Content-Description In-Reply-To Reply-To Lines Li= st-Post X-Label)] {671} << Message-Id: <3EF0C7CE.7020302@Royer.com> << Date: Wed, 18 Jun 2003 14:13:02 -0600 << From: Doug Royer << Reply-To: lemonade@ietf.org << To: lemonade@ietf.org << Subject: Re: [lemonade] Re: Point-of-order re IMAPEXT (Was: << draft-royer-lemonade-submit-00.txt) << References: <200306171156.HAA08281@ietf.org> << << << << Content-Type: multipart/signed; protocol=3D"application/x-pkcs7-signatu= re"; << micalg=3Dsha1; boundary=3D------------ms060208050706050606010300 << List-Post: << << ) << a2 OK done >> a3 FETCH 1 BODY[1] << * 1 FETCH (BODY[1] {2517} << << Lemonade is addressing the needs of "diverse endpoints", one of which, = =3D << and the most challenging of which, it mobile clients. There is also a = =3D << strong constituency for addressing the needs of the telephone user =3D << interface, one that has different demands in terms of low, predictable = =3D << latency, real-time streaming, and support for message context in sortin= g =3D << and counting messages. << << This is not a mobile-only working group. Forward without download is = =3D << just as important for a telephone user interface. << << Greg V. << << -----Original Message----- << From: Mark Crispin [mailto:MRC@CAC.Washington.EDU] << Sent: Tuesday, June 17, 2003 5:53 PM << To: Pete Resnick << Cc: lemonade@ietf.org << Subject: [lemonade] Re: Point-of-order re IMAPEXT (Was: << draft-royer-lemonade-submit-00.txt) << << << Well, Pete, I agree with you that "nothing belongs in IMAPEXT that isn't << already on the charter of IMAPEXT", and confess a backdoor motivation; << shove "submit as a general extension for all clients, not just mobile << clients" from LEMONADE (where extensions for non-mobile clients are << outside of charter) to IMAPEXT, which promptly tosses it as outside of = =3D << its << charter. << << > That a proposed solution is << > an IMAP extension is not a basis for saying it does not belong in << > LEMONADE. << << No, but...: << << The charter states that "Lemonade is tasked to provide a set of << enhancements and profiles of Internet email submission, transport, and << retrieval protocols to facilitate operation on platforms with constrain= ed << resources, or communications links with high latency or limited << bandwidth." << << The submit document explicitly states that it is to be used on others << platforms. What's more, the submit document does not address work item << (2) at all. << << Since the submit document covers platforms other than what is in the << charter, and because it does not address any of the work items of the << charter, I claim that it does not belong in LEMONADE. << << A possible fix to this document would be to remove all references to << non-mobile clients and to add the functionality for work item (2). << << -- Mark -- << << http://staff.washington.edu/mrc << Science does not emerge from voting, party politics, or public debate. << Si vis pacem, para bellum. << << _______________________________________________ << lemonade mailing list << lemonade@ietf.org << https://www1.ietf.org/mailman/listinfo/lemonade << << _______________________________________________ << lemonade mailing list << lemonade@ietf.org << https://www1.ietf.org/mailman/listinfo/lemonade << ) << a3 OK done >> a4 fetch 4 body[1] << * 4 FETCH (BODY[1] {959} << << << Mark Crispin wrote: << > Well, Pete, I agree with you that "nothing belongs in IMAPEXT that is= n't << > already on the charter of IMAPEXT", and confess a backdoor motivation; << > shove "submit as a general extension for all clients, not just mobile << > clients" from LEMONADE (where extensions for non-mobile clients are << > outside of charter) to IMAPEXT, which promptly tosses it as outside o= f its << > charter. << << Having re-read the charter, I see nothing in it that says that if << it is compatible with existing clients that it must be tossed. << And I see it as a plus that it is compatable. << << -- << << Doug Royer | http://INET-Consulting.com << -------------------------------|----------------------------- << Doug@Royer.com | Office: (208)612-INET << http://Royer.com/People/Doug | Fax: (866)594-8574 << | Cell: (208)520-4044 << << We Do Standards - You Need Standards << ) << a4 OK done --- 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 ----- From lemonade-bounces@ietf.org Tue Mar 14 00:49:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ2Oy-0007cD-A9; Tue, 14 Mar 2006 00:49:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ2Ow-0007c3-LK for lemonade@ietf.org; Tue, 14 Mar 2006 00:48:58 -0500 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ2Ov-0004sj-E9 for lemonade@ietf.org; Tue, 14 Mar 2006 00:48:58 -0500 X-IronPort-AV: i="4.02,189,1139202000"; d="scan'208"; a="29988445:sNHT37059128" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Mar 2006 00:50:40 -0500 Message-ID: <330A23D8336C0346B5C1A5BB19666647026A2F58@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Audio Streaming Thread-Index: AcZG7kHkWYUvK7PyQlSKGhbYiXVhgg== From: "Burger, Eric" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Subject: [lemonade] Audio Streaming X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org mp3 streaming information for IETF 65 is at: http://videolab.uoregon.edu/events/ietf/ _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Mar 14 00:49:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ2Oz-0007cP-ET; Tue, 14 Mar 2006 00:49:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ2Oy-0007c8-70 for lemonade@ietf.org; Tue, 14 Mar 2006 00:49:00 -0500 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ2Ox-0004sj-0r for lemonade@ietf.org; Tue, 14 Mar 2006 00:49:00 -0500 X-IronPort-AV: i="4.02,189,1139202000"; d="scan'208"; a="29988451:sNHT31176712" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Mar 2006 00:50:43 -0500 Message-ID: <330A23D8336C0346B5C1A5BB19666647026A2F5F@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Call for Implementations Thread-Index: AcZG/SuKxcDBr8HoRhqZP8rt7kz/oA== From: "Burger, Eric" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [lemonade] Call for Implementations X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 was planning on posting vendor implementations and (when the time is right) self-reported interoperability. A sample of what it would look like is at: http://flyingfox.snowshore.com/i-d/speechsc/MRCPv2-Plans.html Please send me logos and plans / availability of implementations and I'll post them.=20 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Mar 14 11:14:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJCAR-0008BE-PZ; Tue, 14 Mar 2006 11:14:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJCAQ-0008B9-PM for lemonade@ietf.org; Tue, 14 Mar 2006 11:14:38 -0500 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55] helo=zrtps0kn.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJCAP-00069n-Di for lemonade@ietf.org; Tue, 14 Mar 2006 11:14:38 -0500 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2EGEYh17810 for ; Tue, 14 Mar 2006 11:14:34 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 14 Mar 2006 11:14:20 -0500 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D08FD969B@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-lemonade-notify-s2s Thread-Index: AcZHglmfO5dNYu+JTUmZ3AbMej7gwA== From: "Glenn Parsons" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Subject: [lemonade] draft-ietf-lemonade-notify-s2s X-BeenThere: lemonade@ietf.org X-Mailman-Version: 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="===============0667766095==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============0667766095== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64782.5BB68675" This is a multi-part message in MIME format. ------_=_NextPart_001_01C64782.5BB68675 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, draft-ietf-lemonade-notify-s2s has been in IESG evaluation for some time, but it needs some revisions in order to be approved. The current author has confirmed that he is unable to continue as author. As announced previously, unless someone steps forward to take over this draft, it will be withdrawn after the upcoming Dallas IETF meeting. Cheers, Glenn. ------_=_NextPart_001_01C64782.5BB68675 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-ietf-lemonade-notify-s2s

Folks,

draft-ietf-lemonade-notify-s2s  has been in IESG evaluation for some time, but = it needs some revisions in order to be approved.

The current author has confirmed that = he is unable to continue as author.
As announced previously, unless = someone steps forward to take over this draft, it will be withdrawn = after the upcoming Dallas IETF meeting.

Cheers,
Glenn.

------_=_NextPart_001_01C64782.5BB68675-- --===============0667766095== 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 --===============0667766095==-- From lemonade-bounces@ietf.org Tue Mar 14 20:55:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJLEZ-0007kf-9P; Tue, 14 Mar 2006 20:55:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJLEX-0007hW-RP for lemonade@ietf.org; Tue, 14 Mar 2006 20:55:29 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJLEW-0005fX-84 for lemonade@ietf.org; Tue, 14 Mar 2006 20:55:29 -0500 Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k2F1tRQj027693 for ; Tue, 14 Mar 2006 18:55:27 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IW500A01BCGYB00@mail-amer.sun.com> (original mail from Anil.Srivastava@Sun.COM) for lemonade@ietf.org; Tue, 14 Mar 2006 18:55:27 -0700 (MST) Received: from NIKITA.sun.com ([129.150.23.78]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IW500DARC03VL10@mail-amer.sun.com>; Tue, 14 Mar 2006 18:55:27 -0700 (MST) Date: Tue, 14 Mar 2006 17:55:12 -0800 (Pacific Standard Time) From: Anil SRIVASTAVA Subject: Re: [lemonade] draft-ietf-lemonade-notify-s2s In-reply-to: <085091CB2CA14E4B8B163FFC37C84E9D08FD969B@zcarhxm0.corp.nortel.com> To: Glenn Parsons Message-id: Organization: Sun Microsystems [http://www.sun.com] MIME-version: 1.0 X-Mailer: Pine 4.64 (Windows XP) - Got Pine? [http://www.washington.edu/pine] Content-type: multipart/mixed; boundary="Boundary_(ID_mEwPRIJgu5YPL8/xL43EoQ)" Accept-Language: English; en X-Message-Class: normal X-Endorsement: Message brought to you by Sun Java Enterprise System Communication Suite 4 References: <085091CB2CA14E4B8B163FFC37C84E9D08FD969B@zcarhxm0.corp.nortel.com> X-Message-flag: Outlook: the best virus distribution system around X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Anil.Srivastava@Sun.COM List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --Boundary_(ID_mEwPRIJgu5YPL8/xL43EoQ) Content-type: TEXT/Plain; charset=US-ASCII Content-transfer-encoding: 7BIT Glen: I can take over the draft. I believe there is a natural link between this draft and the 'Internet Message Store Events' (http://www.ietf.org/internet-drafts/draft-newman-lemonade-msgevent-00.txt) draft. I can work with Chris, and others that the necessary revisions are made to get the document into the approval queue. Anil On 2006-03-14/11:14 [-0500], gparsons@nortel.com [Glenn Parsons] wrote: > Folks, > > draft-ietf-lemonade-notify-s2s > > has been in IESG evaluation for some time, but it needs some revisions > in order to be approved. The current author has confirmed that he is > unable to continue as author. As announced previously, unless someone > steps forward to take over this draft, it will be withdrawn after the > upcoming Dallas IETF meeting. > > Cheers, > Glenn. > > _______________ Anil SRIVASTAVA anil.srivastava@Sun.COM --Boundary_(ID_mEwPRIJgu5YPL8/xL43EoQ) Content-id: Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT Content-description: _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --Boundary_(ID_mEwPRIJgu5YPL8/xL43EoQ) 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 --Boundary_(ID_mEwPRIJgu5YPL8/xL43EoQ)-- From lemonade-bounces@ietf.org Tue Mar 14 23:46:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJNtt-0006Bb-FM; Tue, 14 Mar 2006 23:46:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJNts-0006BW-Kd for lemonade@ietf.org; Tue, 14 Mar 2006 23:46:20 -0500 Received: from ppsw-7.csi.cam.ac.uk ([131.111.8.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJNtp-0001tg-9z for lemonade@ietf.org; Tue, 14 Mar 2006 23:46: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-2.csi.cam.ac.uk ([131.111.8.54]:44929) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1FJNtf-0001rG-Md (Exim 4.54) (return-path ); Wed, 15 Mar 2006 04:46:07 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1FJNte-0000Jt-Vc (Exim 4.53) (return-path ); Wed, 15 Mar 2006 04:46:06 +0000 Date: Wed, 15 Mar 2006 04:46:06 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: lemonade@ietf.org, ietf-smtp@imc.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [lemonade] update to RFC 1845 checkpoint/restart X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org A few weeks ago I started a discussion on the lemonade list about efficient message transmission using a combination of PIPELINING and CHUNKING. I've since written a draft which addresses the increased risk of message duplication which can occur with fully-pipelined message transmission. The meat of it is a more pipelinable version of RFC 1845 checkpoint/restart. The gravy is a few sections of rationale... http://www-uxsup.csx.cam.ac.uk/~fanf2/hermes/doc/qsmtp/draft-fanf-smtp-replay.html Tony. -- f.a.n.finch http://dotat.at/ NITON: A DEPRESSION MOVING EAST INTO TRAFALGAR WILL GENERATE STRONG EASTERLY WINDS IN ALL AREAS DURING FRIDAY, PERHAPS GALE FORCE IN NORTH FITZROY, SOLE AND SHANNON. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Mar 15 03:55:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJRmZ-00077t-2n; Wed, 15 Mar 2006 03:55:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJRmX-000776-Hz for lemonade@ietf.org; Wed, 15 Mar 2006 03:55:01 -0500 Received: from rgminet01.oracle.com ([148.87.113.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJRmX-0000rX-7e for lemonade@ietf.org; Wed, 15 Mar 2006 03:55:01 -0500 Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k2F8sxwU025189; Wed, 15 Mar 2006 01:54:59 -0700 Received: from rgmsgw301.us.oracle.com (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2F8sxNs027075; Wed, 15 Mar 2006 01:54:59 -0700 Received: from us.oracle.com (dhcp-beijing-152-69-80-64.cn.oracle.com [152.69.80.64]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2F8stIG026923 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 15 Mar 2006 01:54:57 -0700 From: "Stephane H. Maes" To: "Anil.Srivastava@Sun.COM" , "Glenn Parsons" Subject: RE: [lemonade] draft-ietf-lemonade-notify-s2s Date: Wed, 15 Mar 2006 00:54:55 -0800 Message-ID: <20060315005455443.00000002684@smaes-lap3> In-Reply-To: X-Mailer: Oracle Connector for Outlook 10.1.2.0.3 71207 (11.0.8002) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: "lemonade@ietf.org" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "stephane.maes@oracle.com" List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Do we actually need such a req doc? = We now have the notification draft that will provide some of the specs. Sho= uld we combine both? Stephane = _____ Stephane H. Maes, PhD, Director of Architecture, Mobile, Voice, and Communications Platforms, Orac= le. Ph: +1-203-300-7786 (mobile/SMS); Fax / Office UM: +1-650-607-6296 e-mail: stephane.maes@oracle.com IM: shmaes (AIM/Y!/skype) or stephane_maes@hotmail.com (MSN Messenger) or s= tephane.maes@gmail.com (Google) = -----Original Message----- From: Anil SRIVASTAVA [mailto:Anil.Srivastava@Sun.COM] = Sent: Tuesday, March 14, 2006 5:55 PM To: Glenn Parsons Cc: lemonade@ietf.org Subject: Re: [lemonade] draft-ietf-lemonade-notify-s2s Glen: I can take over the draft. I believe there is a natural link between this = draft and the 'Internet Message Store Events' (http://www.ietf.org/internet-drafts/draft-newman-lemonade-msgevent-00.txt)= draft. I can work with Chris, and others that the necessary revisions are = made to get the document into the approval queue. Anil On 2006-03-14/11:14 [-0500], gparsons@nortel.com [Glenn Parsons] wrote: > Folks, > > draft-ietf-lemonade-notify-s2s > .txt> has been in IESG evaluation for some time, but it needs some = > revisions in order to be approved. The current author has confirmed = > that he is unable to continue as author. As announced previously, = > unless someone steps forward to take over this draft, it will be = > withdrawn after the upcoming Dallas IETF meeting. > > Cheers, > Glenn. > > _______________ Anil SRIVASTAVA anil.srivastava@Sun.COM _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Mar 15 10:11:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJXet-0002GG-4P; Wed, 15 Mar 2006 10:11:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJXer-0002E6-DH for lemonade@ietf.org; Wed, 15 Mar 2006 10:11:29 -0500 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJXep-00044O-Sl for lemonade@ietf.org; Wed, 15 Mar 2006 10:11:29 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1FJXem-0003RJ-8x; Wed, 15 Mar 2006 15:11:24 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id CD288498003; Wed, 15 Mar 2006 15:13:38 +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 30923-01; Wed, 15 Mar 2006 15:13:29 +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 07502498002; Wed, 15 Mar 2006 15:13:27 +0000 (GMT) Date: Wed, 15 Mar 2006 15:11:11 +0000 Subject: Re: [lemonade] update to RFC 1845 checkpoint/restart References: In-Reply-To: MIME-Version: 1.0 Message-Id: <12304.1142435472.095162@peirce.dave.cridland.net> From: Dave Cridland To: 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: 21c69d3cfc2dd19218717dbe1d974352 Cc: Enhancements to Internet email to support diverse service enivronments , ietf-smtp@imc.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 Mar 15 04:46:06 2006, Tony Finch wrote: > http://www-uxsup.csx.cam.ac.uk/~fanf2/hermes/doc/qsmtp/draft-fanf-smtp-replay.html Comments, in no particular order: 1) Why have a distinct response 255 instead of 355 ? A client's behaviour is likely to be the same, and semantically, there is no difference. 2) This specification is needlessly not compatible with RFC1845 on a number of points. I can't see why this needs to be so. 3) The DATA offset restriction (beginning of a line) is problematic because it forces a server to store the message one entire line in arrears, because of the multi-line termination of the data transmission with DATA. This is probably required, in order to gain compatibility with RFC1845, but it needs to be pointed out. 4) Section 9, first para, is an example of (2). 5) The syntax of REPLAY means that the syntax of txn-id is not accurate as given in section 6. A txn-id MUST NOT be "CLEAR", in particular. The syntax of REPLAY is, in my opinion, quite ugly as a result. 6) There's no mention here of BURL. a) An octet-offset provided by the server MUST NOT point into a BURL chunk. BURL chunks MUST be appended atomically. b) For BURL and BDAT commands, an additional parameter could be defined, which could then be send in lieu of, or in addition to, the octet-count by the server, thus providing for the (rare) case where a client cannot know the octet count of a BURL chunk without downloading it. 7) Your description of how to send no data with DATA is incorrect, it's actually DATA. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Mar 15 10:21:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJXoj-0008K1-Ce; Wed, 15 Mar 2006 10:21:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJXoi-0008Jw-5I for lemonade@ietf.org; Wed, 15 Mar 2006 10:21:40 -0500 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJXoh-0004NP-Sb for lemonade@ietf.org; Wed, 15 Mar 2006 10:21:40 -0500 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k2FFLcMO009463; Wed, 15 Mar 2006 09:21:38 -0600 (CST) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 15 Mar 2006 09:21:38 -0600 Message-ID: <54E40201497DF142B06B27255953F7971C8D3437@il0015exch007u.ih.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: Glenn Parsons Subject: RE: [lemonade] draft-ietf-lemonade-notify-s2s Date: Wed, 15 Mar 2006 09:21:36 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I would suggest that our thinking has evolved a bit on the S2S requirements, with the new NF interface more formally defined in recent meetings. At a minimum, I think the document should tie into the LEMONADE architecture with consistent terminology. I agree that folding this into the notifications draft may leverage the energy of an existing editor :-) Greg V. -----Original Message----- From: Stephane H. Maes [mailto:stephane.maes@oracle.com] Sent: Wednesday, March 15, 2006 3:55 AM To: Anil.Srivastava@Sun.COM; Glenn Parsons Cc: lemonade@ietf.org Subject: RE: [lemonade] draft-ietf-lemonade-notify-s2s Do we actually need such a req doc? We now have the notification draft that will provide some of the specs. Should we combine both? Stephane _____ Stephane H. Maes, PhD, Director of Architecture, Mobile, Voice, and Communications Platforms, Oracle. Ph: +1-203-300-7786 (mobile/SMS); Fax / Office UM: +1-650-607-6296 e-mail: stephane.maes@oracle.com IM: shmaes (AIM/Y!/skype) or stephane_maes@hotmail.com (MSN Messenger) or stephane.maes@gmail.com (Google) -----Original Message----- From: Anil SRIVASTAVA [mailto:Anil.Srivastava@Sun.COM] Sent: Tuesday, March 14, 2006 5:55 PM To: Glenn Parsons Cc: lemonade@ietf.org Subject: Re: [lemonade] draft-ietf-lemonade-notify-s2s Glen: I can take over the draft. I believe there is a natural link between this draft and the 'Internet Message Store Events' (http://www.ietf.org/internet-drafts/draft-newman-lemonade-msgevent-00.txt) draft. I can work with Chris, and others that the necessary revisions are made to get the document into the approval queue. Anil On 2006-03-14/11:14 [-0500], gparsons@nortel.com [Glenn Parsons] wrote: > Folks, > > draft-ietf-lemonade-notify-s2s > .txt> has been in IESG evaluation for some time, but it needs some > revisions in order to be approved. The current author has confirmed > that he is unable to continue as author. As announced previously, > unless someone steps forward to take over this draft, it will be > withdrawn after the upcoming Dallas IETF meeting. > > Cheers, > Glenn. > > _______________ Anil SRIVASTAVA anil.srivastava@Sun.COM _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Mar 15 10:37:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJY47-0001NY-5Y; Wed, 15 Mar 2006 10:37:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJY46-0001MA-E3 for lemonade@ietf.org; Wed, 15 Mar 2006 10:37:34 -0500 Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJY44-0005IU-WB for lemonade@ietf.org; Wed, 15 Mar 2006 10:37:34 -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-2.csi.cam.ac.uk ([131.111.8.54]:45075) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:fanf2) id 1FJY3y-00079N-0l (Exim 4.54) (return-path ); Wed, 15 Mar 2006 15:37:26 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1FJY3x-0001MZ-3f (Exim 4.53) (return-path ); Wed, 15 Mar 2006 15:37:25 +0000 Date: Wed, 15 Mar 2006 15:37:25 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Dave Cridland Subject: Re: [lemonade] update to RFC 1845 checkpoint/restart In-Reply-To: <12304.1142435472.095162@peirce.dave.cridland.net> Message-ID: References: <12304.1142435472.095162@peirce.dave.cridland.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: Enhancements to Internet email to support diverse service enivronments , ietf-smtp@imc.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 Mar 2006, Dave Cridland wrote: Thanks for your comments. > 1) Why have a distinct response 255 instead of 355 message>? A client's behaviour is likely to be the same, and > semantically, there is no difference. I vacillated a bit here - at one point the spec also had a 555 response instead of 355 0. You are probably right that 255 is also redundant. > 2) This specification is needlessly not compatible with RFC1845 on a > number of points. I can't see why this needs to be so. > > 4) Section 9, first para, is an example of (2). Hmm, yes, I suppose it might be possible (and desirable) to be backwards compatible. The REPLAY spec is currently weak in descibing the line between a retry and a replay. For example, the 555 response to MAIL would be better as a 455 that would cause the client to retry with a new transaction (i.e. a fresh ). The corresponding situation with an improved CHUNKING would be an unexpected 355 response. The problem here is what happens if the client has pipelined some data after the erroneous command? > 3) The DATA offset restriction (beginning of a line) is problematic because it > forces a server to store the message one entire line in arrears, because of > the multi-line termination of the data transmission with DATA. This is > probably required, in order to gain compatibility with RFC1845, but it needs > to be pointed out. I'm not sure it's necessary to be a line in arrears. You can store each line as you receive it, until you get a line containing just a dot. You only need a one-line window. > 5) The syntax of REPLAY means that the syntax of txn-id is not accurate as > given in section 6. A txn-id MUST NOT be "CLEAR", in particular. The syntax of > REPLAY is, in my opinion, quite ugly as a result. Perhaps it should be a separate command. I also considered making the transaction log clearing implicit, when the server sees a QUIT from the client. But what commend to use when the client wants to leave the connection idle waiting for new messages? EHLO? > 6) There's no mention here of BURL. > > a) An octet-offset provided by the server MUST NOT point into a BURL chunk. > BURL chunks MUST be appended atomically. Yes, that's a sound suggestion. > b) For BURL and BDAT commands, an additional parameter could be defined, which > could then be send in lieu of, or in addition to, the octet-count by the > server, thus providing for the (rare) case where a client cannot know the > octet count of a BURL chunk without downloading it. Perhaps a chunk count as well as an octet count? There would have to be an octet offset within the chunk, so that the chunk count and chunk offset together mean the same thing as the octet offset. I'll see if I can think of a good way of specifying it. I'm wary because its in danger of getting a bit complicated. > 7) Your description of how to send no data with DATA is incorrect, it's > actually DATA. That's two octets of data (a blank line), not zero :-) but I should mention the wait for 354. cf. the text about a "single dot" in RFC2920. Tony. -- f.a.n.finch http://dotat.at/ NITON: A DEPRESSION MOVING EAST INTO TRAFALGAR WILL GENERATE STRONG EASTERLY WINDS IN ALL AREAS DURING FRIDAY, PERHAPS GALE FORCE IN NORTH FITZROY, SOLE AND SHANNON. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Mar 15 11:01:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJYRh-0004hF-Nc; Wed, 15 Mar 2006 11:01:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJYRg-0004h9-Bc for lemonade@ietf.org; Wed, 15 Mar 2006 11:01:56 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJYRf-0006LV-PM for lemonade@ietf.org; Wed, 15 Mar 2006 11:01:56 -0500 Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k2FG1tuf021286 for ; Wed, 15 Mar 2006 09:01:55 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IW600101ETVY900@mail-amer.sun.com> (original mail from Anil.Srivastava@Sun.COM) for lemonade@ietf.org; Wed, 15 Mar 2006 09:01:55 -0700 (MST) Received: from NIKITA.sun.com ([129.150.23.78]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IW60040EF75IL20@mail-amer.sun.com>; Wed, 15 Mar 2006 09:01:54 -0700 (MST) Date: Wed, 15 Mar 2006 08:01:48 -0800 (Pacific Standard Time) From: Anil SRIVASTAVA Subject: RE: [lemonade] draft-ietf-lemonade-notify-s2s In-reply-to: <54E40201497DF142B06B27255953F7971C8D3437@il0015exch007u.ih.lucent.com> To: "Vaudreuil, Greg M (Greg)" Message-id: Organization: Sun Microsystems [http://www.sun.com] MIME-version: 1.0 X-Mailer: Pine 4.64 (Windows XP) - Got Pine? [http://www.washington.edu/pine] Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Accept-Language: English; en X-Message-Class: normal X-Endorsement: Message brought to you by Sun Java Enterprise System Communication Suite 4 References: <54E40201497DF142B06B27255953F7971C8D3437@il0015exch007u.ih.lucent.com> X-Message-flag: Outlook: the best virus distribution system around X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: lemonade@ietf.org, Glenn Parsons X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Anil.Srivastava@Sun.COM List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Since the goal is to have the requirements captured in a document and Stephane is willing to fold them into the current notification draft, that is good enough for me. Stephane: if you need help folding the two documents together you know where to reach me ;-). Anil On 2006-03-15/09:21 [-0600], gregv@lucent.com [Vaudreuil, Greg M (Greg)] wrote: > I would suggest that our thinking has evolved a bit on the S2S > requirements, with the new NF interface more formally defined in > recent meetings. At a minimum, I think the document should tie into > the LEMONADE architecture with consistent terminology. I agree that > folding this into the notifications draft may leverage the energy of > an existing editor :-) > > Greg V. > > -----Original Message----- > From: Stephane H. Maes [mailto:stephane.maes@oracle.com] > Sent: Wednesday, March 15, 2006 3:55 AM > To: Anil.Srivastava@Sun.COM; Glenn Parsons > Cc: lemonade@ietf.org > Subject: RE: [lemonade] draft-ietf-lemonade-notify-s2s > > > Do we actually need such a req doc? > > We now have the notification draft that will provide some of the > specs. Should we combine both? > > Stephane > > > _____ > Stephane H. Maes, PhD, > Director of Architecture, Mobile, Voice, and Communications Platforms, Oracle. > Ph: +1-203-300-7786 (mobile/SMS); Fax / Office UM: +1-650-607-6296 > e-mail: stephane.maes@oracle.com > IM: shmaes (AIM/Y!/skype) or stephane_maes@hotmail.com (MSN Messenger) or stephane.maes@gmail.com (Google) > > -----Original Message----- > From: Anil SRIVASTAVA [mailto:Anil.Srivastava@Sun.COM] > Sent: Tuesday, March 14, 2006 5:55 PM > To: Glenn Parsons > Cc: lemonade@ietf.org > Subject: Re: [lemonade] draft-ietf-lemonade-notify-s2s > > Glen: > > I can take over the draft. I believe there is a natural link between > this draft and the 'Internet Message Store Events' > (http://www.ietf.org/internet-drafts/draft-newman-lemonade-msgevent-00.txt) > draft. I can work with Chris, and others that the necessary revisions > are made to get the document into the approval queue. > > Anil > > On 2006-03-14/11:14 [-0500], gparsons@nortel.com [Glenn Parsons] wrote: > > > Folks, > > > > draft-ietf-lemonade-notify-s2s > > > .txt> has been in IESG evaluation for some time, but it needs some > > revisions in order to be approved. The current author has confirmed > > that he is unable to continue as author. As announced previously, > > unless someone steps forward to take over this draft, it will be > > withdrawn after the upcoming Dallas IETF meeting. > > > > Cheers, > > Glenn. > > > > > > _______________ > Anil SRIVASTAVA > anil.srivastava@Sun.COM > > > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade > _______________ Anil SRIVASTAVA anil.srivastava@Sun.COM _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Mar 15 11:46:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJZ8q-0001ls-VI; Wed, 15 Mar 2006 11:46:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJZ8p-0001li-IF for lemonade@ietf.org; Wed, 15 Mar 2006 11:46:31 -0500 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJZ8p-0007S9-4I for lemonade@ietf.org; Wed, 15 Mar 2006 11:46:31 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1FJZ8l-0002jJ-Ki; Wed, 15 Mar 2006 16:46:27 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id E33EF498003; Wed, 15 Mar 2006 16:48:42 +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 31226-08; Wed, 15 Mar 2006 16:48:31 +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 956AB498002; Wed, 15 Mar 2006 16:48:28 +0000 (GMT) Date: Wed, 15 Mar 2006 16:46:10 +0000 Subject: Re: [lemonade] update to RFC 1845 checkpoint/restart References: <12304.1142435472.095162@peirce.dave.cridland.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <12304.1142441172.994664@peirce.dave.cridland.net> From: Dave Cridland To: 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-Heisenberg-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: Enhancements to Internet email to support diverse service enivronments , ietf-smtp@imc.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 Mar 15 15:37:25 2006, Tony Finch wrote: > On Wed, 15 Mar 2006, Dave Cridland wrote: > > Thanks for your comments. > > Pleasure. RFC1845 has a lot to offer, I think. > The REPLAY spec is currently weak in descibing the line between a > retry > and a replay. For example, the 555 response to MAIL would be better > as a > 455 that would cause the client to retry with a new transaction > (i.e. a > fresh ). The corresponding situation with an improved > CHUNKING > would be an unexpected 355 response. The problem here is what > happens if > the client has pipelined some data after the erroneous command? > > I don't follow all of this. > > 5) The syntax of REPLAY means that the syntax of txn-id is not > accurate as > > given in section 6. A txn-id MUST NOT be "CLEAR", in particular. > The syntax of > > REPLAY is, in my opinion, quite ugly as a result. > > Perhaps it should be a separate command. I also considered making > the > transaction log clearing implicit, when the server sees a QUIT from > the > client. But what commend to use when the client wants to leave the > connection idle waiting for new messages? EHLO? > > No, because EHLO is already mandated as being a noisier RSET. I think a new command, or else changing the syntax of REPLAY. I have no preference as to which. > > 6) There's no mention here of BURL. > > > > a) An octet-offset provided by the server MUST NOT point into a > BURL chunk. > > BURL chunks MUST be appended atomically. > > Yes, that's a sound suggestion. > > It's by far the simplest. > > b) For BURL and BDAT commands, an additional parameter could be > defined, which > > could then be send in lieu of, or in addition to, the octet-count > by the > > server, thus providing for the (rare) case where a client cannot > know the > > octet count of a BURL chunk without downloading it. > > Perhaps a chunk count as well as an octet count? There would have > to be an > octet offset within the chunk, so that the chunk count and chunk > offset > together mean the same thing as the octet offset. I'll see if I can > think > of a good way of specifying it. I'm wary because its in danger of > getting > a bit complicated. > > Yes, that would be complicated. FWIW, I can only think of one case where the length of a resource is likely to be unknown, and that's the case where the client only has the URLAUTH URL. That said, the only case I can think of for that involves Alice granting Bob read access to a message via URLAUTH, and Bob using an ESMTP send with BURL in order to copy the message to his IMAP server in order to read it efficiently. That is a somewhat contrived use-case. I'd be happy to see the entire problem noted and subsequently ignored. > > 7) Your description of how to send no data with DATA is > incorrect, it's > > actually DATA. > > That's two octets of data (a blank line), not zero :-) but I should > mention the wait for 354. cf. the text about a "single dot" in > RFC2920. (This is "below") Ah, I sit corrected. I'd previously somehow misread RFC2821 section 4.1.1.4 para 2 as saying the exact opposite of what it does say. I have no idea how I misread that. This makes things much easier, and of course eliminates my point 3. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Mar 15 12:25:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJZkK-0004tO-Lj; Wed, 15 Mar 2006 12:25:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJZkJ-0004tJ-97 for lemonade@ietf.org; Wed, 15 Mar 2006 12:25:15 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJZkH-0000FZ-Tm for lemonade@ietf.org; Wed, 15 Mar 2006 12:25:15 -0500 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2FHPBC07907 for ; Wed, 15 Mar 2006 12:25:11 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 15 Mar 2006 12:24:38 -0500 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D08FDA61C@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft agenda Thread-Index: AcZIVVY+cT/CzrVLSK2gTkJxwppJ/w== From: "Glenn Parsons" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Subject: [lemonade] Draft agenda X-BeenThere: lemonade@ietf.org X-Mailman-Version: 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="===============1973917900==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============1973917900== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64855.58DE1582" This is a multi-part message in MIME format. ------_=_NextPart_001_01C64855.58DE1582 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, The draft agenda for next week is here: http://tools.ietf.org/wg/lemonade/agenda?item=3Dagenda65.html Let us know if you have any comments. Cheers, Glenn. PS. Here is a copy: =20 DRAFT DRAFT DRAFT DRAFT Lemonade Agenda =20 Monday, March 20, 2006 1520 - 1720, Miro Room =20 Document Status=20 Document issue discussion=20 draft-ietf-lemonade-profile-bis =20 draft-ietf-lemonade-notifications =20 draft-ietf-lemonade-convert =20 draft-ietf-lemonade-imap-sieve =20 draft-ietf-lemonade-compress =20 draft-ietf-lemonade-search-within =20 draft-ietf-lemonade-reconnect =20 draft-ietf-lemonade-vfolder =20 draft-ietf-lemonade-rfc2192bis =20 draft-ietf-lemonade-futuredelivery = =20 =20 =20 Wednesday, March 22, 2006 0900 - 1130, Miro Room =20 Document Status Document issue discussion draft-ietf-lemonade-deployments =20 draft-ietf-lemonade-firewall-binding = =20 Recharter discussion =20 =20 =20 ------_=_NextPart_001_01C64855.58DE1582 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft agenda

Folks,

The draft agenda for next week is = here:
http://tools.ietf.org/wg/lemonade/agenda?item=3Dagenda65.h= tml

Let us know if you have any = comments.

Cheers,
Glenn.

PS.  Here is a copy:

           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =          
          DRAFT DRAFT DRAFT = DRAFT
          Lemonade = Agenda
         
          Monday, March 20, = 2006
          1520 - 1720, Miro = Room
         
          Document = Status
          Document issue = discussion
           draft-ietf-lemonade-profile-bis
           = draft-ietf-lemonade-notifications
           <= U>draft-ietf-lemonade-convert
           = draft-ietf-lemonade-imap-sieve
           = = draft-ietf-lemonade-compress
           draft-ietf-lemonade-search-within
           = draft-ietf-lemonade-reconnect
           = <= U>draft-ietf-lemonade-vfolder
           = draft-ietf-lemonade-rfc2192bis
           draft-ietf-lemonade-futuredelivery
         
         
         
          Wednesday, March = 22, 2006
          0900 - 1130, Miro = Room
         
          Document = Status
          Document issue = discussion
           draft-ietf-lemonade-deployments  
           draft-ietf-lemonade-firewall-binding  
         
          Recharter = discussion 
         
         

------_=_NextPart_001_01C64855.58DE1582-- --===============1973917900== 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 --===============1973917900==-- From lemonade-bounces@ietf.org Wed Mar 15 14:52:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJc2k-0000uk-AK; Wed, 15 Mar 2006 14:52:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJc2j-0000uf-F4 for lemonade@ietf.org; Wed, 15 Mar 2006 14:52:25 -0500 Received: from ppsw-7.csi.cam.ac.uk ([131.111.8.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJc2i-0004xW-5L for lemonade@ietf.org; Wed, 15 Mar 2006 14:52:25 -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-2.csi.cam.ac.uk ([131.111.8.54]:47962) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1FJc2Y-0005sS-Nr (Exim 4.54) (return-path ); Wed, 15 Mar 2006 19:52:14 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1FJc2Y-0003dw-BE (Exim 4.53) (return-path ); Wed, 15 Mar 2006 19:52:14 +0000 Date: Wed, 15 Mar 2006 19:52:14 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Dave Cridland Subject: Re: [lemonade] update to RFC 1845 checkpoint/restart In-Reply-To: <12304.1142441172.994664@peirce.dave.cridland.net> Message-ID: References: <12304.1142435472.095162@peirce.dave.cridland.net> <12304.1142441172.994664@peirce.dave.cridland.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Enhancements to Internet email to support diverse service enivronments , ietf-smtp@imc.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 > > The REPLAY spec is currently weak in descibing the line between a retry > > and a replay. For example, the 555 response to MAIL would be better as a > > 455 that would cause the client to retry with a new transaction (i.e. a > > fresh ). The corresponding situation with an improved CHUNKING > > would be an unexpected 355 response. The problem here is what happens if > > the client has pipelined some data after the erroneous command? > > I don't follow all of this. I'm worried about transaction ID collisions, which I suppose are most likely to be caused by a client going insane (unless someone manages to successfully attack a client's txn-id generation algorithm). At the moment the replay spec makes this problem detectable by the 555 response to MAIL (though I plan to change this to 455). Checkpoint assumes this situation is OK since it looks to the server like a normal transaction restart. Tony. -- f.a.n.finch http://dotat.at/ SOLE LUNDY FASTNET SOUTH IRISH SEA: EAST 4 OR 5, OCCASIONALLY 6 LATER. SHOWERS, BECOMING WINTRY FOR A TIME. MODERATE OR GOOD, OCCASIONALLY POOR AT FIRST. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Mar 15 18:33:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJfV5-0002bX-H5; Wed, 15 Mar 2006 18:33:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJfV4-0002bN-AJ for lemonade@ietf.org; Wed, 15 Mar 2006 18:33:54 -0500 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJfV3-00045h-T8 for lemonade@ietf.org; Wed, 15 Mar 2006 18:33:54 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.34) id 1FJfV0-0003SP-9s; Wed, 15 Mar 2006 23:33:50 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 4A36A498003; Wed, 15 Mar 2006 23:36:08 +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 00544-02; Wed, 15 Mar 2006 23:35: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 48F45498002; Wed, 15 Mar 2006 23:35:55 +0000 (GMT) Date: Wed, 15 Mar 2006 23:33:36 +0000 Subject: Re: [lemonade] update to RFC 1845 checkpoint/restart References: <12304.1142435472.095162@peirce.dave.cridland.net> <12304.1142441172.994664@peirce.dave.cridland.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <12304.1142465616.742293@peirce.dave.cridland.net> From: Dave Cridland To: 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-Rutherford-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Enhancements to Internet email to support diverse service enivronments , ietf-smtp@imc.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 Mar 15 19:52:14 2006, Tony Finch wrote: > > > The REPLAY spec is currently weak in descibing the line between > a retry > > > and a replay. For example, the 555 response to MAIL would be > better as a > > > 455 that would cause the client to retry with a new transaction > (i.e. a > > > fresh ). The corresponding situation with an improved > CHUNKING > > > would be an unexpected 355 response. The problem here is what > happens if > > > the client has pipelined some data after the erroneous command? > > > > I don't follow all of this. > > I'm worried about transaction ID collisions, which I suppose are > most > likely to be caused by a client going insane (unless someone > manages to > successfully attack a client's txn-id generation algorithm). At the > moment > the replay spec makes this problem detectable by the 555 response > to MAIL > (though I plan to change this to 455). Checkpoint assumes this > situation > is OK since it looks to the server like a normal transaction > restart. > > Right, gotcha. You're saying that in the case where a transaction id collides, or, for some reason, the client thinks it's sending the transaction anew instead of resuming, then there's a problem here that 1845 missed because of the lack of pipelining. A solution is to state that use of TRANSID= denotes either resumption or new, and the client must wait for the response unless it knows what it will be in advance (by having previously issued a REPLAY command and examined the response). Then add an additional parameter which indicates to the server that the TRANSID is expected to be fresh, and if not, to reject this transaction. (Perhaps a TRANSID-NEW assertion parameter) This means that RFC1845bis (ie, this spec) clients use: MAIL FROM: TRANSID=xyz TRANSID-NEW for starting a new transaction, and do not need to synchronize, whereas RFC1845 clients don't use the additional parameter, but do synchronize. That handles the collision case, but the case where two clients simultaneously attempt to resume a TRANSID, is much more difficult to deal with. You could define REPLAY as an assertion that subsequent usage of this TRANSID in a MAIL command in this session is a resumption, which prevents accidental duplication, and then you merely have to deal with failing DATA, BDAT, and BURL commands if a TRANSID is resumed by another session. (And, one assumes noting this in logs or to the sender as a possible bug or security issue.) Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Mar 16 09:45:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJtjV-0006Vw-Cc; Thu, 16 Mar 2006 09:45:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJtjU-0006Vr-1k for lemonade@ietf.org; Thu, 16 Mar 2006 09:45:44 -0500 Received: from il-tlv-smtpgateway.comverse.com ([192.118.48.242] helo=il-tlv-smtpout2.icomverse.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJtjS-0004CR-2K for lemonade@ietf.org; Thu, 16 Mar 2006 09:45:44 -0500 Received: from il-tlv-bridge01.comverse.com (il-tlv-bridge01.comverse.com [10.115.242.136]) by il-tlv-smtpout2.icomverse.com (8.13.4/8.13.4) with ESMTP id k2GEjcWE021020 for ; Thu, 16 Mar 2006 16:45:38 +0200 Received: from il-tlv-mail01.comverse.com ([10.115.242.87]) by il-tlv-bridge01.comverse.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 16 Mar 2006 16:45:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 16 Mar 2006 16:45:34 +0200 Message-ID: <88E9D17A99A345439825C94B1DA393E31F8356@il-tlv-mail01.comverse.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-lemonade-vfolder Thread-Index: AcZJCEhhnEEvWxR4Qvqx8185j7X4TQ== From: "Weingarten Jerry" To: X-OriginalArrivalTime: 16 Mar 2006 14:45:38.0231 (UTC) FILETIME=[4A555470:01C64908] X-Spam-Score: 1.4 (+) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Subject: [lemonade] draft-ietf-lemonade-vfolder X-BeenThere: lemonade@ietf.org X-Mailman-Version: 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="===============1640667638==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============1640667638== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64908.4A1D5F2C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C64908.4A1D5F2C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I am confused by the Formal syntax (section 5) and the examples in section 6 - The syntax seems to refer to a literal string "LVFOLDER" whereas the examples use a string "LPSEARCH" is there a connection between the two? Also the first example in section 6 uses as the psearch string - (INBOX HEADER "Sender" "lemonade-bounces") what header field is this searching or is it searching the entire message header for either of the two strings? What is the meaning of multiple search strings - is it "OR" or "AND"? Thanx, Yaacov (Jerry) Weingarten Comverse - Standards=20 phone: +972-3-645 2392 mobile: +972-52-854 2392 email: jerry.weingarten@comverse.com ------_=_NextPart_001_01C64908.4A1D5F2C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-ietf-lemonade-vfolder

Hi,

I am confused by the Formal syntax (section 5) and the examples in = section 6 -

The syntax seems to refer to a literal string "LVFOLDER" = whereas the examples use a string "LPSEARCH" is there a = connection between the two?

Also the first example in section 6 uses as the psearch string - = (INBOX HEADER "Sender" "lemonade-bounces") what = header field is this searching or is it searching the entire message = header  for either of the two strings?  What is the meaning of = multiple search strings - is it "OR" or = "AND"?

Thanx,

Yaacov (Jerry) Weingarten

Comverse - Standards

phone: +972-3-645 2392

mobile: +972-52-854 2392

email: = jerry.weingarten@comverse.com

------_=_NextPart_001_01C64908.4A1D5F2C-- --===============1640667638== 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 --===============1640667638==-- From lemonade-bounces@ietf.org Thu Mar 16 16:42:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK0F1-0003Uv-3S; Thu, 16 Mar 2006 16:42:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK0Ez-0003Uq-Fq for lemonade@ietf.org; Thu, 16 Mar 2006 16:42:41 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK0Ex-00024L-14 for lemonade@ietf.org; Thu, 16 Mar 2006 16:42:41 -0500 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2GLgaT03743 for ; Thu, 16 Mar 2006 16:42:36 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 16 Mar 2006 16:42:30 -0500 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D090B4E3A@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LEMONADE in Beijing Thread-Index: AcZJQocVBgfgnPO5TCiDFMAn7ffcSA== From: "Glenn Parsons" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Subject: [lemonade] LEMONADE in Beijing X-BeenThere: lemonade@ietf.org X-Mailman-Version: 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="===============1304597011==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============1304597011== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64942.88B70FA3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C64942.88B70FA3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, This is a quite belated summary of our impressive progress at the LEMONADE interim meeting in Beijing, China. Thanks again to China Mobile for hosting this event. It was an excellent meeting with wonderful hospitality. Let me know if you have any comments on the results or my summary.=20 Cheers,=20 Glenn LEMONADE Beijing - January 24-25=20 =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=20 OMA liaison=20 - concern from OMA on who has control and what IETF will provide - consensus that LEMONADE will provide the profile - after review of liaison as well as revised OMA AD, identified specific additional questions on: notification encryption, a finite list of STI parameters, message recall issues, use of managed SIEVE - finalize liaison wording on mailing list Compression - TLS codec is GZIP, but compression of everything is not desirable so this is MAY - using selective ZIP compression is more appropriate, so this is MUST - consensus to document in a WG draft Firewall traversal=20 - four possible bindings proposed: tunnel, REST, SOAP & WebDav -- but this appears to be a lot of work - timeouts are an issue that can be solved by using tunnel approach, but SOAP is the simplest proposal - consensus to move forward with several non-standards track WG draft documents: - Firewall deployment considerations (BCP)=20 - Firewall binding options (Informational)=20 - Network timeouts (Informational)=20 Notifications - consensus that the proposal is the basis for a WG draft describing VF, NF & DF - still need to decide on filter management - consensus to also make message event a WG draft Filters - IMAP SIEVE will be amended to use managed SIEVE -- but there are still some concerns with the use of SIEVE scripts for filtering... - consensus to move managed SIEVE to WG for last call - consensus to make VFOLDER a WG draft, but move SEARCH to a separate WG document Reconnect - we need a new draft before the next meeting - and we need some implementation experience feedback... LEMONADE profile-bis=20 - includes deferred items from profile as well as the rest of the WG items based on OMA RD/AD input - include security/encryption? Defer decision until review of proposals - still need proposals if we are to contemplate including them: binary append, partials, proxies - consensus to merge figs 3&4 immediately and publish as WG document, have 01 ready for IETF 65 Expected before IETF 65, revised WG drafts on:=20 Profile-bis=20 Notifications=20 Message event=20 Content transformation (CONVERT)=20 Filters (IMAP SIEVE & manage SIEVE)=20 Quick reconnect=20 2192bis=20 And new 00 WG drafts on:=20 VFOLDER=20 SEARCH modification Content transformation (the streaming one)=20 Compression=20 Firewall deployment considerations (BCP)=20 Firewall binding options (Informational)=20 ------_=_NextPart_001_01C64942.88B70FA3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable LEMONADE in Beijing

Folks,

This is a quite belated summary of our = impressive progress at the LEMONADE interim meeting in Beijing, = China.
Thanks again to China Mobile for = hosting this event. It was an excellent meeting with wonderful = hospitality.
Let me know if you have any comments = on the results or my summary.
Cheers,
Glenn


LEMONADE Beijing - January 24-25
=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
OMA liaison
- concern from OMA on who has control and what IETF will provide
- consensus that LEMONADE will provide the profile
- after review of liaison as well as revised OMA AD, identified specific = additional questions on:  notification encryption, a finite list of = STI parameters, message recall issues, use of managed SIEVE
- finalize liaison wording on mailing list
Compression
- TLS codec is GZIP, but compression of everything is not desirable so = this is MAY
- using selective ZIP compression is more appropriate, so this is = MUST
- consensus to document in a WG draft
Firewall traversal
- four possible bindings proposed:  tunnel, REST, SOAP & WebDav = -- but this appears to be a lot of work
- timeouts are an issue that can be solved by using tunnel approach, but = SOAP is the simplest proposal
- consensus to move forward with several non-standards track WG draft = documents:
        - Firewall deployment = considerations (BCP)
        - Firewall binding options = (Informational)
        - Network timeouts = (Informational)
Notifications
- consensus that the proposal is the basis for a WG draft describing VF, = NF & DF
- still need to decide on filter management
- consensus to also make message event a WG draft
Filters
- IMAP SIEVE will be amended to use managed SIEVE -- but there are still = some concerns with the use of SIEVE scripts for filtering...
- consensus to move managed SIEVE to WG for last call
- consensus to make VFOLDER a WG draft, but move SEARCH to a separate WG = document
Reconnect
- we need a new draft before the next meeting
- and we need some implementation experience feedback...
LEMONADE profile-bis
- includes deferred items from profile as well as the rest of the WG = items based on OMA RD/AD input
- include security/encryption?  Defer decision until review of = proposals
- still need proposals if we are to contemplate including them:  = binary append, partials, proxies
- consensus to merge figs 3&4 immediately and publish as WG = document, have 01 ready for IETF 65
Expected before IETF 65, revised WG = drafts on:
        Profile-bis
        Notifications
        Message event
        Content transformation = (CONVERT)
        Filters (IMAP SIEVE & = manage SIEVE)
        Quick reconnect
        2192bis
And new 00 WG drafts on:
        VFOLDER
        SEARCH modification
        Content transformation (the = streaming one)
        Compression
        Firewall deployment = considerations (BCP)
        Firewall binding options = (Informational)

------_=_NextPart_001_01C64942.88B70FA3-- --===============1304597011== 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 --===============1304597011==-- From lemonade-bounces@ietf.org Thu Mar 16 18:16:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK1hg-0000xU-Lx; Thu, 16 Mar 2006 18:16:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK1hf-0000xP-Dg for lemonade@ietf.org; Thu, 16 Mar 2006 18:16:23 -0500 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FK1hf-0006ZV-3l for lemonade@ietf.org; Thu, 16 Mar 2006 18:16:23 -0500 X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-4.tower-121.messagelabs.com!1142550982!7821166!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 25204 invoked from network); 16 Mar 2006 23:16:22 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-4.tower-121.messagelabs.com with SMTP; 16 Mar 2006 23:16:22 -0000 Received: from [135.70.155.147] (unknown[135.70.155.147](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20060316231621gw100100pse> (Authid: tony); Thu, 16 Mar 2006 23:16:22 +0000 Message-ID: <4419F1C5.9020700@att.com> Date: Thu, 16 Mar 2006 18:16:21 -0500 From: Tony Hansen User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] compression References: <43725028.8060204@att.com> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Given the choice between draft-ietf-lemonade-compress-00.txt and draft-gulbrandsen-imap-deflate-02.txt, I think that the latter, draft-gulbrandsen-imap-deflate-02.txt, is a *better* choice to go forward with as a solution for compression of the IMAP stream. As I've said before, I think that Arnt's method is much simpler. And as his measurements indicate, it also provides superior performance. I'd like to nominate draft-gulbrandsen-imap-deflate-02.txt to *replace* draft-ietf-lemonade-compress-00.txt as the group's compression mechanism of choice. Tony Hansen tony@att.com Arnt Gulbrandsen wrote: > Finally following up the short thread last autumn with some numbers, > here's a short comparison of RFC 3749, draft-gulbrandsen-imap-deflate > and draft-lemonade-lzip. > > RFC 3749 and imap-deflate are very similar in terms of compression. In > general, RFC 3749 will win over imap-deflate by about 20 bytes, > independently of the length of the IMAP connection. Two minutes or two > hours, doesn't matter. The difference is because 3749 negotiates > compression at a cost of just two bytes (one in the client hello, one in > the server). > > For the IMAP conversation appended, here are the results comparing > 3749/deflate with lzip. These numbers are approximate: I took some > working code and hacked it to produce numbers instead of work. I > accidentally mangled the line endings, so all the numbers are off by > some small factor (1%?). > > The thread I used is just a few messages from lemonade. I just picked a > random thread, and read a few messages using a fairly popular IMAP > client, and played with the TCP connection until all passwords etc. were > gone. > > There are four commands, each with 1-4 untagged and one tagged response. > I have numbered them a1 to a4. > > Command a1 is compressed by all three to 42 bytes, much worse than its > original 22. Its response is compressed to 70 bytes, from 123. The > reason they do the same is that all three compressors use the same > algorithm and do exactly the same work: Starting compression (which has > overhead of about 20 bytes IIRC), learning that the compressed text > contains ASCII, etc. > > Command a2 is compressed by lzip from 202 to 170 bytes, and by > 3749/deflate to 138. The response is compressed by lzip from 3498 to > 1016 bytes, and by 3749/deflate to 899. lzip does worse than the two > others because it pays the startup cost again, while the two others > already have trained their compressors to know that there's lots of > printable ASCII, '* FETCH' occurs often, etc. > > Command a3 is compressed by lzip from 20 to 40 bytes (the same as the > first command, really) and by 3749/deflate to 9 bytes. (Lzip pays the > startup cost for the seventh time. The compressors in 3749/deflate have > learnt from commands a1 and a2 approximately how an IMAP command looks, > so they compress even a short command efficiently.) The response tells > the same picture: 3749/deflate compresses the response from 2772 to 1112 > bytes, lzip manages 1284. The difference here is mostly that > 3749/deflate already knows that almost all bytes sent are ASCII words, > while for lzip, the compressor has to learn it. There's also the usual > 20-byte startup fee. > > Command a4 is 40 bytes again with lzip. With 3749/deflate it's 22. The > response has an original size of 1078 characters. 3749/deflate > compresses that to 280 characters. This result is so good becaus the > response is pure text, and it's in the same thread as the a3 response. > lzip doens't do so well: 559. Its compressor again has to learn > everything from scratch, and it can't exploit the fact that threads > frequently contain the same words and even sentences. > > Summing up: All three lose a bit on their first command, about 20 bytes. > 3749/deflate win on the second and subsequent command. Lzip wins on the > big command, loses on the two small commands. All three win on the > responses, but 3749/deflate win much more, sometimes achieving results > half the size of lzip's. > > I'll be happy to repeat this survey with a bigger corpus, if it's > desirable. I don't see the point, myself. The numbers are clear enough > already. > > Finally, I don't know whether the upstream comparison matters. I > included the numbers because I thought they might matter for > battery-powered devices where transmitting bytes to the server is > expensive. Not my field. Downstream surely matters, and that's where > 3749/gulbrandsen win by a large margin. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Mar 16 20:54:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK4Ao-0000vc-N1; Thu, 16 Mar 2006 20:54:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK4Am-0000vX-Sj for lemonade@ietf.org; Thu, 16 Mar 2006 20:54:36 -0500 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK4Al-00035M-JG for lemonade@ietf.org; Thu, 16 Mar 2006 20:54:36 -0500 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M04QGGQK0000007A@mauve.mrochek.com> for lemonade@ietf.org; Thu, 16 Mar 2006 17:54:32 -0800 (PST) To: Tony Hansen Message-id: <01M04QRWUFKC00007A@mauve.mrochek.com> Date: Thu, 16 Mar 2006 17:50:48 -0800 (PST) From: Ned Freed Subject: Re: [lemonade] compression In-reply-to: "Your message dated Thu, 16 Mar 2006 18:16:21 -0500" <4419F1C5.9020700@att.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=ISO-8859-1 References: <43725028.8060204@att.com> <4419F1C5.9020700@att.com> 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 > Given the choice between draft-ietf-lemonade-compress-00.txt and > draft-gulbrandsen-imap-deflate-02.txt, I think that the latter, > draft-gulbrandsen-imap-deflate-02.txt, is a *better* choice to go > forward with as a solution for compression of the IMAP stream. I agree 100%. IMO the choices are between draft-gulbrandsen-imap-deflate-02.txt and using TLS-layer compression (sorry, don't remember the RFC number). Either one of these would be acceptable IMO. > As I've said before, I think that Arnt's method is much simpler. And as > his measurements indicate, it also provides superior performance. SImpler and superior compression are hard to argue with. I note that there are probably ways to make the compression work better in draft-ietf-lemonade-compress-00.txt (by saving compression state between commands) but this increases the complexity even more. > I'd like to nominate draft-gulbrandsen-imap-deflate-02.txt to *replace* > draft-ietf-lemonade-compress-00.txt as the group's compression mechanism > of choice. +1 Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Mar 16 21:01:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK4Hv-0002Ew-6R; Thu, 16 Mar 2006 21:01:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK4Ht-0002Er-82 for lemonade@ietf.org; Thu, 16 Mar 2006 21:01:57 -0500 Received: from rgminet01.oracle.com ([148.87.113.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK4Hq-0003UI-C5 for lemonade@ietf.org; Thu, 16 Mar 2006 21:01:57 -0500 Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k2H21rlI010481 for ; Thu, 16 Mar 2006 19:01:53 -0700 Received: from rgmsgw300.us.oracle.com (localhost [127.0.0.1]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2H21qZ5004064 for ; Thu, 16 Mar 2006 19:01:52 -0700 Received: from us.oracle.com (dhcp-apac-jp-csvpn-gw9-141-144-144-198.vpn.oracle.com [141.144.144.198]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2H21nSs004045 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 16 Mar 2006 19:01:51 -0700 From: "Stephane H. Maes" To: "Enhancements to Internet email to support diverse service enivronments" Subject: RE: [lemonade] compression Date: Thu, 16 Mar 2006 18:02:06 -0800 Message-ID: <20060316180206588.00000004288@smaes-lap3> In-Reply-To: <4419F1C5.9020700@att.com> X-Mailer: Oracle Connector for Outlook 10.1.2.0.3 71207 (11.0.8010) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "stephane.maes@oracle.com" List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org The comparison on compression seems to be a bit outdated as it seems based = on old LZIP spec. Following the agreements from Beijing, we aren't even com= pressing commands anymore, so the TLS comparison is apples to oranges. We are only compressing body parts, as such, TLS might win for compressing = command syntax, but the one test that wasn't checked is TLS compressing an = already compressed part... Also attachment compression is essential. It is not clear if the test looke= d at that. IETF mailing lists do not really provide attachment use cases...= . :) So I don't think that it is a clear cut or that the numbers + argument belo= w motivate yet supperiority of ne method over another. At least more evalua= tions are needed. Note I have no problem switching method if it turns out m= ore efficient. = Thanks Stephane _____ Stephane H. Maes, PhD, Director of Architecture, Mobile, Voice, and Communications Platforms, Orac= le. Ph: +1-203-300-7786 (mobile/SMS); Fax / Office UM: +1-650-607-6296 e-mail: stephane.maes@oracle.com IM: shmaes (AIM/Y!/skype) or stephane_maes@hotmail.com (MSN Messenger) or s= tephane.maes@gmail.com (Google) = -----Original Message----- From: Tony Hansen [mailto:tony@att.com] = Sent: Thursday, March 16, 2006 3:16 PM To: Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] compression Given the choice between draft-ietf-lemonade-compress-00.txt and draft-gulb= randsen-imap-deflate-02.txt, I think that the latter, draft-gulbrandsen-ima= p-deflate-02.txt, is a *better* choice to go forward with as a solution for= compression of the IMAP stream. As I've said before, I think that Arnt's method is much simpler. And as his= measurements indicate, it also provides superior performance. I'd like to nominate draft-gulbrandsen-imap-deflate-02.txt to *replace* dra= ft-ietf-lemonade-compress-00.txt as the group's compression mechanism of ch= oice. Tony Hansen tony@att.com Arnt Gulbrandsen wrote: > Finally following up the short thread last autumn with some numbers, = > here's a short comparison of RFC 3749, draft-gulbrandsen-imap-deflate = > and draft-lemonade-lzip. > > RFC 3749 and imap-deflate are very similar in terms of compression. In = > general, RFC 3749 will win over imap-deflate by about 20 bytes, = > independently of the length of the IMAP connection. Two minutes or two = > hours, doesn't matter. The difference is because 3749 negotiates = > compression at a cost of just two bytes (one in the client hello, one = > in the server). > > For the IMAP conversation appended, here are the results comparing = > 3749/deflate with lzip. These numbers are approximate: I took some = > working code and hacked it to produce numbers instead of work. I = > accidentally mangled the line endings, so all the numbers are off by = > some small factor (1%?). > > The thread I used is just a few messages from lemonade. I just picked = > a random thread, and read a few messages using a fairly popular IMAP = > client, and played with the TCP connection until all passwords etc. = > were gone. > > There are four commands, each with 1-4 untagged and one tagged response. > I have numbered them a1 to a4. > > Command a1 is compressed by all three to 42 bytes, much worse than its = > original 22. Its response is compressed to 70 bytes, from 123. The = > reason they do the same is that all three compressors use the same = > algorithm and do exactly the same work: Starting compression (which = > has overhead of about 20 bytes IIRC), learning that the compressed = > text contains ASCII, etc. > > Command a2 is compressed by lzip from 202 to 170 bytes, and by = > 3749/deflate to 138. The response is compressed by lzip from 3498 to > 1016 bytes, and by 3749/deflate to 899. lzip does worse than the two = > others because it pays the startup cost again, while the two others = > already have trained their compressors to know that there's lots of = > printable ASCII, '* FETCH' occurs often, etc. > > Command a3 is compressed by lzip from 20 to 40 bytes (the same as the = > first command, really) and by 3749/deflate to 9 bytes. (Lzip pays the = > startup cost for the seventh time. The compressors in 3749/deflate = > have learnt from commands a1 and a2 approximately how an IMAP command = > looks, so they compress even a short command efficiently.) The = > response tells the same picture: 3749/deflate compresses the response = > from 2772 to 1112 bytes, lzip manages 1284. The difference here is = > mostly that 3749/deflate already knows that almost all bytes sent are = > ASCII words, while for lzip, the compressor has to learn it. There's = > also the usual 20-byte startup fee. > > Command a4 is 40 bytes again with lzip. With 3749/deflate it's 22. The = > response has an original size of 1078 characters. 3749/deflate = > compresses that to 280 characters. This result is so good becaus the = > response is pure text, and it's in the same thread as the a3 response. > lzip doens't do so well: 559. Its compressor again has to learn = > everything from scratch, and it can't exploit the fact that threads = > frequently contain the same words and even sentences. > > Summing up: All three lose a bit on their first command, about 20 bytes. > 3749/deflate win on the second and subsequent command. Lzip wins on = > the big command, loses on the two small commands. All three win on the = > responses, but 3749/deflate win much more, sometimes achieving results = > half the size of lzip's. > > I'll be happy to repeat this survey with a bigger corpus, if it's = > desirable. I don't see the point, myself. The numbers are clear enough = > already. > > Finally, I don't know whether the upstream comparison matters. I = > included the numbers because I thought they might matter for = > battery-powered devices where transmitting bytes to the server is = > expensive. Not my field. Downstream surely matters, and that's where = > 3749/gulbrandsen win by a large margin. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Mar 17 05:03:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKBo2-00053X-Id; Fri, 17 Mar 2006 05:03:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKBo0-0004mx-DD for lemonade@ietf.org; Fri, 17 Mar 2006 05:03:36 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKBnz-0000ep-0v for lemonade@ietf.org; Fri, 17 Mar 2006 05:03:36 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 30B7B4AC22 for ; Fri, 17 Mar 2006 11:03:33 +0100 (CET) Message-Id: Date: Fri, 17 Mar 2006 11:15:08 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] compression References: <20060316180206588.00000004288@smaes-lap3> In-Reply-To: <20060316180206588.00000004288@smaes-lap3> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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 Oh, I didn't realize that lzip was dead. The new one looks considerably better in terms of protocol quality, but I fear it's even worse in terms of compression. I'll do a comparison later today, perhaps tomorrow. I'll just tack another message with a big attachment onto the four-message thread I posted earlier, using different big attachments. Some PDFs, a word file or two, a zip file, etc. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Mar 17 06:22:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKD27-0002AU-Sa; Fri, 17 Mar 2006 06:22:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKD26-00029H-M8 for lemonade@ietf.org; Fri, 17 Mar 2006 06:22:14 -0500 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKD25-0002u3-9Q for lemonade@ietf.org; Fri, 17 Mar 2006 06:22:14 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.34) id 1FKD23-0006R2-Ku; Fri, 17 Mar 2006 11:22:11 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 16B7B498003; Fri, 17 Mar 2006 11:24: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 10436-05; Fri, 17 Mar 2006 11:24:41 +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 23437498002; Fri, 17 Mar 2006 11:24:40 +0000 (GMT) Date: Fri, 17 Mar 2006 11:22:05 +0000 Subject: Re: [lemonade] compression References: <20060316180206588.00000004288@smaes-lap3> In-Reply-To: MIME-Version: 1.0 Message-Id: <15775.1142594526.256081@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: 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 Fri Mar 17 10:15:08 2006, Arnt Gulbrandsen wrote: > I'll do a comparison later today, perhaps tomorrow. I'll just tack > another message with a big attachment onto the four-message thread > I posted earlier, using different big attachments. Some PDFs, a > word file or two, a zip file, etc. Whilst I'm basically in favour of stream compression based methods (TLS, COMPRESS=DEFLATE, etc), I feel I ought to note two advantages of LZIP-like mechanisms: a) They're free to use alternate compression algorithms which don't make sense for streaming data, or are relatively expensive, since they're operating on a-priori known immutable data. So an LZIP-a-like could be made to use a Burrows-Wheeler Transform, or an Arithmetic Coding with prearranged model presets, or any number of other relatively expensive algorithms. b) For data that is not compressed by whichever algorithm is used, the mechanism could return BINARY fetch items instead of LZIP fetch items, thus avoiding both the expanding data problem, and the wasteful decompression on the client. However, streaming compression has other advantages: 1) It's highly reapplicable, whether in TLS or as a distinct command, between IMAP, ESMTP, and even ACAP for the wishful thinkers amongst us. 2) It applies to the general protocol babble, as well. This might even entirely outweigh the expanding data problem. 3) It applies to what the client sends, which in the typical mobile phone environment has the benefit of increasing battery life, as I understand things. 4) Where compression is possible, it's likely they'll achieve higher compression due to the algorithm's model, dictionary, etc being primed already for the majority of cases. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Mar 17 09:55:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKGMb-0003ZR-Fc; Fri, 17 Mar 2006 09:55:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKGMa-0003ZM-TI for lemonade@ietf.org; Fri, 17 Mar 2006 09:55:36 -0500 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKGMa-00016C-I7 for lemonade@ietf.org; Fri, 17 Mar 2006 09:55:36 -0500 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M04QGGQK0000007A@mauve.mrochek.com> for lemonade@ietf.org; Fri, 17 Mar 2006 06:55:32 -0800 (PST) To: Dave Cridland Message-id: <01M05I26ZJ2Y00007A@mauve.mrochek.com> Date: Fri, 17 Mar 2006 06:49:33 -0800 (PST) From: Ned Freed Subject: Re: [lemonade] compression In-reply-to: "Your message dated Fri, 17 Mar 2006 11:22:05 +0000" <15775.1142594526.256081@peirce.dave.cridland.net> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <20060316180206588.00000004288@smaes-lap3> <15775.1142594526.256081@peirce.dave.cridland.net> X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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 Fri Mar 17 10:15:08 2006, Arnt Gulbrandsen wrote: > > I'll do a comparison later today, perhaps tomorrow. I'll just tack > > another message with a big attachment onto the four-message thread > > I posted earlier, using different big attachments. Some PDFs, a > > word file or two, a zip file, etc. > Whilst I'm basically in favour of stream compression based methods > (TLS, COMPRESS=DEFLATE, etc), I feel I ought to note two advantages > of LZIP-like mechanisms: > a) They're free to use alternate compression algorithms which don't > make sense for streaming data, or are relatively expensive, since > they're operating on a-priori known immutable data. So an LZIP-a-like > could be made to use a Burrows-Wheeler Transform, or an Arithmetic > Coding with prearranged model presets, or any number of other > relatively expensive algorithms. Nothing prevents alternate compression schemes from being used in TLS. In fact you should be able to switch compressions on the fly by renegotiating. This is actually better than LZIP-like schemes because it could be initiated by the server, which is in a better position to know what compression would be best for a particular message. But this is all theoretical and IMO likely to stay that way.. I doubt very much that anyone will actually do such things - the added complexity is just not worth it. > b) For data that is not compressed by whichever algorithm is used, > the mechanism could return BINARY fetch items instead of LZIP fetch > items, thus avoiding both the expanding data problem, and the > wasteful decompression on the client. The expansion problem should be insignificant if the compression format is well designed. > However, streaming compression has other advantages: > 1) It's highly reapplicable, whether in TLS or as a distinct command, > between IMAP, ESMTP, and even ACAP for the wishful thinkers amongst > us. Yep. > 2) It applies to the general protocol babble, as well. This might > even entirely outweigh the expanding data problem. Right again. It is pretty common to deal with large numbers of small messages. > 3) It applies to what the client sends, which in the typical mobile > phone environment has the benefit of increasing battery life, as I > understand things. Actually, with TLS-level compression at least you should be able to control whether or not it applies to what the client sends. > 4) Where compression is possible, it's likely they'll achieve higher > compression due to the algorithm's model, dictionary, etc being > primed already for the majority of cases. Agreed. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Mar 17 11:23:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKHjt-0003Xg-8r; Fri, 17 Mar 2006 11:23:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKHjs-0003Xb-Ap for lemonade@ietf.org; Fri, 17 Mar 2006 11:23:44 -0500 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKHjr-0004Sz-T6 for lemonade@ietf.org; Fri, 17 Mar 2006 11:23:44 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1FKHjp-0006YP-RB; Fri, 17 Mar 2006 16:23:41 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 6F419498003; Fri, 17 Mar 2006 16:26:17 +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 11382-01; Fri, 17 Mar 2006 16:26: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 3579F498002; Fri, 17 Mar 2006 16:26:08 +0000 (GMT) Date: Fri, 17 Mar 2006 16:23:31 +0000 Subject: Re: [lemonade] compression References: <20060316180206588.00000004288@smaes-lap3> <15775.1142594526.256081@peirce.dave.cridland.net> <01M05I26ZJ2Y00007A@mauve.mrochek.com> In-Reply-To: <01M05I26ZJ2Y00007A@mauve.mrochek.com> MIME-Version: 1.0 Message-Id: <17579.1142612612.210287@peirce.dave.cridland.net> From: Dave Cridland To: Ned Freed 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: 00e94c813bef7832af255170dca19e36 Cc: email to support diverse service enivronments , Arnt Gulbrandsen , Enhancements X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Fri Mar 17 14:49:33 2006, Ned Freed wrote: >> a) They're free to use alternate compression algorithms which don't >> make sense for streaming data, or are relatively expensive, since >> they're operating on a-priori known immutable data. So an >> LZIP-a-like >> could be made to use a Burrows-Wheeler Transform, or an Arithmetic >> Coding with prearranged model presets, or any number of other >> relatively expensive algorithms. > > Nothing prevents alternate compression schemes from being used in > TLS. > In fact you should be able to switch compressions on the fly by > renegotiating. This is actually better than LZIP-like schemes > because it > could be initiated by the server, which is in a better position to > know what compression would be best for a particular message. > > But this is all theoretical and IMO likely to stay that way.. I > doubt very much > that anyone will actually do such things - the added complexity is > just not > worth it. > > Wouldn't the compression renegotiation involve an extra round-trip? And in any case, there's obvious mechanisms which are LZIP-like, but involve the server selecting a compression algorithm. HTTP already has this kind of mechanism. I think this stands in favour of LZIP-like mechanisms, to be honest. An uber-compression scheme could, of course, be defined for TLS which could not only switch algorithms by a unilateral symbol injection to the stream, but switch between models (or dictionaries, etc), thus allowing the data character to change when reading attachments and messages without degrading the model used for the IMAP protocol elements themselves. This is probably equally blue-sky, though. >> b) For data that is not compressed by whichever algorithm is used, >> the mechanism could return BINARY fetch items instead of LZIP fetch >> items, thus avoiding both the expanding data problem, and the >> wasteful decompression on the client. > > The expansion problem should be insignificant if the compression > format is well > designed. > > True, although again it's less if the entire attachment can be compressed in advance, and can be made to be zero with LZIP-like mechanisms. (Okay, BINARY is two octets longer than LZIP, and the theoretical minimum for a compression algorithm expansion in worst case is one octet, assuming an integer number of octets). In any case, Deflate is good enough that it compresses most things, including JFIF files off digital cameras, etc. Gzipping a 146,525 octet gzip as a quick test gave me an increase of 55 octets, which is comfortably low. (I would hope that's the file header plus one symbol per compressed block, less any compressibility of the original file header and trailer.) >> 2) It applies to the general protocol babble, as well. This might >> even entirely outweigh the expanding data problem. > > Right again. It is pretty common to deal with large numbers of > small messages. > > Yes, although I'm really thinking in terms of compressing away common strings such as "\r\n* ", for instance. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Mar 17 11:50:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKIA4-0000pH-Ih; Fri, 17 Mar 2006 11:50:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKIA3-0000pC-Lh for lemonade@ietf.org; Fri, 17 Mar 2006 11:50:47 -0500 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKIA3-0005D9-6X for lemonade@ietf.org; Fri, 17 Mar 2006 11:50:47 -0500 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M04QGGQK0000007A@mauve.mrochek.com> for lemonade@ietf.org; Fri, 17 Mar 2006 08:50:44 -0800 (PST) To: Dave Cridland Message-id: <01M05M30RBSY00007A@mauve.mrochek.com> Date: Fri, 17 Mar 2006 08:43:10 -0800 (PST) From: Ned Freed Subject: Re: [lemonade] compression In-reply-to: "Your message dated Fri, 17 Mar 2006 16:23:31 +0000" <17579.1142612612.210287@peirce.dave.cridland.net> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <20060316180206588.00000004288@smaes-lap3> <15775.1142594526.256081@peirce.dave.cridland.net> <01M05I26ZJ2Y00007A@mauve.mrochek.com> <17579.1142612612.210287@peirce.dave.cridland.net> X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: Enhancements to Internet email to support diverse service enivronments , Arnt Gulbrandsen , Ned Freed X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > On Fri Mar 17 14:49:33 2006, Ned Freed wrote: > >> a) They're free to use alternate compression algorithms which don't > >> make sense for streaming data, or are relatively expensive, since > >> they're operating on a-priori known immutable data. So an > >> LZIP-a-like > >> could be made to use a Burrows-Wheeler Transform, or an Arithmetic > >> Coding with prearranged model presets, or any number of other > >> relatively expensive algorithms. > > > > Nothing prevents alternate compression schemes from being used in > > TLS. > > In fact you should be able to switch compressions on the fly by > > renegotiating. This is actually better than LZIP-like schemes > > because it > > could be initiated by the server, which is in a better position to > > know what compression would be best for a particular message. > > > > But this is all theoretical and IMO likely to stay that way.. I > > doubt very much > > that anyone will actually do such things - the added complexity is > > just not > > worth it. > > > > > Wouldn't the compression renegotiation involve an extra round-trip? Perhaps - I don't know enough about the protocol specifics in TLS to say. But if choice of compression really matters to this extent, I doubt if the extra round trip is going to matter that much. > And in any case, there's obvious mechanisms which are LZIP-like, but > involve the server selecting a compression algorithm. HTTP already > has this kind of mechanism. I think this stands in favour of > LZIP-like mechanisms, to be honest. I disagree, but I also think this entire thing is so far out there it is irrelevant. > An uber-compression scheme could, of course, be defined for TLS which > could not only switch algorithms by a unilateral symbol injection to > the stream, but switch between models (or dictionaries, etc), thus > allowing the data character to change when reading attachments and > messages without degrading the model used for the IMAP protocol > elements themselves. This is probably equally blue-sky, though. Actually, I'd say it is less blue-sky than expecting either clients or servers to analyze data and change compression on the fly. Pushing all the complexity into the compression engine has some really attractive properties. But as long as we're compression-method-agile (and any of these schemes can be designed this way) any work in this space can be deferred. > >> b) For data that is not compressed by whichever algorithm is used, > >> the mechanism could return BINARY fetch items instead of LZIP fetch > >> items, thus avoiding both the expanding data problem, and the > >> wasteful decompression on the client. > > > > The expansion problem should be insignificant if the compression > > format is well > > designed. > > > > > True, although again it's less if the entire attachment can be > compressed in advance, and can be made to be zero with LZIP-like > mechanisms. (Okay, BINARY is two octets longer than LZIP, and the > theoretical minimum for a compression algorithm expansion in worst > case is one octet, assuming an integer number of octets). > In any case, Deflate is good enough that it compresses most things, > including JFIF files off digital cameras, etc. Gzipping a 146,525 > octet gzip as a quick test gave me an increase of 55 octets, which is > comfortably low. (I would hope that's the file header plus one symbol > per compressed block, less any compressibility of the original file > header and trailer.) Yes, I think that's more or less how it plays out. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Mar 18 07:50:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKatK-000598-3S; Sat, 18 Mar 2006 07:50:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKaXO-0001Yo-2O for lemonade@ietf.org; Sat, 18 Mar 2006 07:28:06 -0500 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKaXN-00084p-GG for lemonade@ietf.org; Sat, 18 Mar 2006 07:28:06 -0500 X-IronPort-AV: i="4.03,106,1141621200"; d="scan'208,217"; a="30217708:sNHT52536536" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Re: [lemonade] compression Date: Sat, 18 Mar 2006 07:29:42 -0500 Message-ID: <330A23D8336C0346B5C1A5BB196666470231C1E5@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] compression Thread-Index: AcZJ+IKLfpGTl/vNTZ+9kXiMnqt5CAAjx8GZ From: "Burger, Eric" To: "Ned Freed" , "Dave Cridland" X-Spam-Score: 0.5 (/) X-Scan-Signature: cbb41f2dbf0f142369614756642005e3 X-Mailman-Approved-At: Sat, 18 Mar 2006 07:50:44 -0500 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: , Content-Type: multipart/mixed; boundary="===============1763175697==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============1763175697== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64A87.A1DFD9E4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C64A87.A1DFD9E4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Arnt did an excellent job collecting actual data on the value of = transport layer compression and application layer compression. The counter argument I hear (and I'm hard of hearing, so I may be wrong) = is that transport layer compression might, under certain circumstances, = use more MIPS. It would be really helpful if someone could get _data_ on CPU use. Besides being useful data to help solve this problem, this data could = result in a conference or journal paper (hint). If anyone is interested = in glory, contact me off-line. -----Original Message----- From: Ned Freed [mailto:ned.freed@mrochek.com] Sent: Fri Mar 17 14:25:11 2006 To: Dave Cridland Cc: Enhancements to Internet email to support diverse service = enivronments; Arnt Gulbrandsen; Ned Freed Subject: Re: [lemonade] compression > On Fri Mar 17 14:49:33 2006, Ned Freed wrote: > >> a) They're free to use alternate compression algorithms which don't > >> make sense for streaming data, or are relatively expensive, since > >> they're operating on a-priori known immutable data. So an > >> LZIP-a-like > >> could be made to use a Burrows-Wheeler Transform, or an Arithmetic > >> Coding with prearranged model presets, or any number of other > >> relatively expensive algorithms. > > > > Nothing prevents alternate compression schemes from being used in > > TLS. > > In fact you should be able to switch compressions on the fly by > > renegotiating. This is actually better than LZIP-like schemes > > because it > > could be initiated by the server, which is in a better position to > > know what compression would be best for a particular message. > > > > But this is all theoretical and IMO likely to stay that way.. I > > doubt very much > > that anyone will actually do such things - the added complexity is > > just not > > worth it. > > > > > Wouldn't the compression renegotiation involve an extra round-trip? Perhaps - I don't know enough about the protocol specifics in TLS to = say. But if choice of compression really matters to this extent, I doubt if the = extra round trip is going to matter that much. > And in any case, there's obvious mechanisms which are LZIP-like, but > involve the server selecting a compression algorithm. HTTP already > has this kind of mechanism. I think this stands in favour of > LZIP-like mechanisms, to be honest. I disagree, but I also think this entire thing is so far out there it is irrelevant. > An uber-compression scheme could, of course, be defined for TLS which > could not only switch algorithms by a unilateral symbol injection to > the stream, but switch between models (or dictionaries, etc), thus > allowing the data character to change when reading attachments and > messages without degrading the model used for the IMAP protocol > elements themselves. This is probably equally blue-sky, though. Actually, I'd say it is less blue-sky than expecting either clients or = servers to analyze data and change compression on the fly. Pushing all the = complexity into the compression engine has some really attractive properties. But = as long as we're compression-method-agile (and any of these schemes can be = designed this way) any work in this space can be deferred. > >> b) For data that is not compressed by whichever algorithm is used, > >> the mechanism could return BINARY fetch items instead of LZIP fetch > >> items, thus avoiding both the expanding data problem, and the > >> wasteful decompression on the client. > > > > The expansion problem should be insignificant if the compression > > format is well > > designed. > > > > > True, although again it's less if the entire attachment can be > compressed in advance, and can be made to be zero with LZIP-like > mechanisms. (Okay, BINARY is two octets longer than LZIP, and the > theoretical minimum for a compression algorithm expansion in worst > case is one octet, assuming an integer number of octets). > In any case, Deflate is good enough that it compresses most things, > including JFIF files off digital cameras, etc. Gzipping a 146,525 > octet gzip as a quick test gave me an increase of 55 octets, which is > comfortably low. (I would hope that's the file header plus one symbol > per compressed block, less any compressibility of the original file > header and trailer.) Yes, I think that's more or less how it plays out. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade ------_=_NextPart_001_01C64A87.A1DFD9E4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [lemonade] compression

Arnt did an excellent job collecting actual data on = the value of transport layer compression and application layer = compression.

The counter argument I hear (and I'm hard of hearing, so I may be wrong) = is that transport layer compression might, under certain circumstances, = use more MIPS.

It would be really helpful if someone could get _data_ on CPU use.

Besides being useful data to help solve this problem, this data could = result in a conference or journal paper (hint). If anyone is interested = in glory, contact me off-line.



 -----Original Message-----
From:   Ned Freed [mailto:ned.freed@mrochek.com] Sent:   Fri Mar 17 14:25:11 2006
To:     Dave Cridland
Cc:     Enhancements to Internet email to support = diverse service enivronments; Arnt Gulbrandsen; Ned Freed
Subject:        Re: [lemonade] = compression

> On Fri Mar 17 14:49:33 2006, Ned Freed wrote:
> >> a) They're free to use alternate compression algorithms = which don't
> >> make sense for streaming data, or are relatively = expensive, since
> >> they're operating on a-priori known immutable data. So = an
> >> LZIP-a-like
> >> could be made to use a Burrows-Wheeler Transform, or an = Arithmetic
> >> Coding with prearranged model presets, or any number of = other
> >> relatively expensive algorithms.
> >
> > Nothing prevents alternate compression schemes from being used = in
> > TLS.
> > In fact you should be able to switch compressions on the fly = by
> > renegotiating. This is actually better than LZIP-like = schemes
> > because it
> > could be initiated by the server, which is in a better = position to
> > know what compression would be best for a particular = message.
> >
> > But this is all theoretical and IMO likely to stay that way.. = I
> > doubt very much
> > that anyone will actually do such things - the added = complexity is
> > just not
> > worth it.
> >
> >
> Wouldn't the compression renegotiation involve an extra = round-trip?

Perhaps - I don't know enough about the protocol specifics in TLS to = say. But
if choice of compression really matters to this extent, I doubt if the = extra
round trip is going to matter that much.

> And in any case, there's obvious mechanisms which are LZIP-like, = but
> involve the server selecting a compression algorithm. HTTP = already
> has this kind of mechanism. I think this stands in favour of
> LZIP-like mechanisms, to be honest.

I disagree, but I also think this entire thing is so far out there it = is
irrelevant.

> An uber-compression scheme could, of course, be defined for TLS = which
> could not only switch algorithms by a unilateral symbol injection = to
> the stream, but switch between models (or dictionaries, etc), = thus
> allowing the data character to change when reading attachments = and
> messages without degrading the model used for the IMAP protocol
> elements themselves. This is probably equally blue-sky, though.

Actually, I'd say it is less blue-sky than expecting either clients or = servers
to analyze data and change compression on the fly. Pushing all the = complexity
into the compression engine has some really attractive properties. But = as long
as we're compression-method-agile (and any of these schemes can be = designed
this way) any work in this space can be deferred.

> >> b) For data that is not compressed by whichever algorithm = is used,
> >> the mechanism could return BINARY fetch items instead of = LZIP fetch
> >> items, thus avoiding both the expanding data problem, and = the
> >> wasteful decompression on the client.
> >
> > The expansion problem should be insignificant if the = compression
> > format is well
> > designed.
> >
> >

> True, although again it's less if the entire attachment can be
> compressed in advance, and can be made to be zero with = LZIP-like
> mechanisms. (Okay, BINARY is two octets longer than LZIP, and = the
> theoretical minimum for a compression algorithm expansion in = worst
> case is one octet, assuming an integer number of octets).

> In any case, Deflate is good enough that it compresses most = things,
> including JFIF files off digital cameras, etc. Gzipping a = 146,525
> octet gzip as a quick test gave me an increase of 55 octets, which = is
> comfortably low. (I would hope that's the file header plus one = symbol
> per compressed block, less any compressibility of the original = file
> header and trailer.)

Yes, I think that's more or less how it plays out.

        =         =         =         Ned

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

------_=_NextPart_001_01C64A87.A1DFD9E4-- --===============1763175697== 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 --===============1763175697==-- From lemonade-bounces@ietf.org Sat Mar 18 15:52:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKiPv-0007KD-Lo; Sat, 18 Mar 2006 15:52:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKiPu-0007K8-Bb for lemonade@ietf.org; Sat, 18 Mar 2006 15:52:54 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKiPs-0007Cq-SR for lemonade@ietf.org; Sat, 18 Mar 2006 15:52:54 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 1DE744AC1C for ; Sat, 18 Mar 2006 21:52:51 +0100 (CET) Message-Id: Date: Sat, 18 Mar 2006 22:04:33 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] compression References: <330A23D8336C0346B5C1A5BB196666470231C1E5@ATLANTIS.Brooktrout.com> In-Reply-To: <330A23D8336C0346B5C1A5BB196666470231C1E5@ATLANTIS.Brooktrout.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Eric Burger writes: > Arnt did an excellent job collecting actual data on the value of > transport layer compression and application layer compression. > > The counter argument I hear (and I'm hard of hearing, so I may be > wrong) is that transport layer compression might, under certain > circumstances, use more MIPS. > > It would be really helpful if someone could get _data_ on CPU use. I can provide that as a side effect of the further comparison work I'm doing (and which I'll post about - the results are surprising). My timings won't be very very accurate, though. The charge has some validity, btw. In certain circumstances, which should be odd and unusual but I find myself affected. Consider compress=deflate and the almost entirely equivalent RFC3749 TLS feature. With c=d, the IMAP server author can do some measurements, and find out that zlib in its lightest-weight mode provides 97% of the achievable benefit (I am not making this up). However, if compression is being done by the TLS implementation, _and_ the TLS implementation doesn't provide any API to adjust the compression settings, then the IMAP server can't do this. Then the IMAP server is bound to spend as much CPU on compression as the TLS author saw fit. > Besides being useful data to help solve this problem, this data could > result in a conference or journal paper (hint). If anyone is > interested in glory, contact me off-line. Not me. I speak in public only when there's no escape ;) Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Mar 18 17:19:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKjlZ-0002Db-JN; Sat, 18 Mar 2006 17:19:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKjlY-0002DW-Vn for lemonade@ietf.org; Sat, 18 Mar 2006 17:19:20 -0500 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKjlY-0001YQ-Ji for lemonade@ietf.org; Sat, 18 Mar 2006 17:19:20 -0500 X-IronPort-AV: i="4.03,107,1141621200"; d="scan'208,217"; a="30238701:sNHT52422504" X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 X-OriginalArrivalTime: 15 Mar 2006 04:29:26.0004 (UTC) FILETIME=[0AC17340:01C647E9] X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,192,1139202000"; d="scan'208"; a="30039051:sNHT24340324" X-BeenThere: wgchairs@ietf.org X-Mailman-Version: 2.1.5 X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 x-pp-smtpvs: 1 x-pp-fromip: 204.176.205.23 Content-class: urn:content-classes:message Date: Sat, 18 Mar 2006 17:21:12 -0500 Message-ID: <330A23D8336C0346B5C1A5BB196666470231C1FF@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Jabber service for IETF meetings Thread-Index: AcZH6QtldRNwQ98qQ+yB9S2guOz8sgC8Tibk From: "Burger, Eric" To: "IETF LEMONADE" X-Spam-Score: 0.1 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Subject: [lemonade] FW: Jabber service for IETF meetings X-BeenThere: lemonade@ietf.org 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="===============1365729063==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============1365729063== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64ADA.43F1D492" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C64ADA.43F1D492 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 TmV3IGhvbWUgZm9yIEphYmJlci4gIFRoaXMgaXMgdGhlIHRleHQgY2hhdCAvIGxvZyBhcHBwbGlj YXRpb24gd2Ugd2lsbCB1c2UgZm9yIElFVEYgNjUuDQoNCiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogCUlFVEYgU2VjcmV0YXJpYXQgW21haWx0bzppZXRmLXNlY3JldGFyaWF0QGll dGYub3JnXQ0KU2VudDoJVHVlIE1hciAxNCAyMzoyOToyNiAyMDA2DQpUbzoJV29ya2luZyBHcm91 cCBDaGFpcnMNClN1YmplY3Q6CUphYmJlciBzZXJ2aWNlIGZvciBJRVRGIG1lZXRpbmdzIA0KDQpE ZWFyIElFVEYgV0cgQ2hhaXJzLA0KDQpUaGUgU2VjcmV0YXJpYXQgaXMgcGxlYXNlZCB0byBhbm5v dW5jZSBhIG5ldyBJbnN0YW50IE1lc3NhZ2luZyBzZXJ2aWNlLiAgVGhpcw0Kc2VydmljZSB3aWxs IHByb3ZpZGUgamFiYmVyIGNoYXQgcm9vbXMgdG8gYWxsIElFVEYgd29ya2luZyBncm91cHMgZm9y IHRoZWlyIHRleHQNCmNvbmZlcmVuY2luZyBhdCBJRVRGIDY1IGFuZCBmdXR1cmUgbWVldGluZ3Mu DQoNClRoZSBuZXcgamFiYmVyIHNlcnZlciBpcyBsb2NhdGVkIGF0IGphYmJlci5pZXRmLm9yZyBh bmQgaXMgY3VycmVudGx5DQphY2Nlc3NpYmxlLiAgRm9yIHRob3NlIHdobyBhcmUgaW50ZXJlc3Rl ZCwgcGxlYXNlIHZpc2l0IHRoZSBhYm92ZSBsb2NhdGlvbiB0bw0Kam9pbiBhbnkgb2YgdGhlIGF2 YWlsYWJsZSBjaGF0IHJvb21zLg0KDQpPdmVyIHRoZSBuZXh0IGZldyBkYXlzLCBwbGVhc2UgdGFr ZSB0aGUgdGltZSB0byB0ZXN0IHRoaXMgbmV3IHNlcnZpY2UgYW5kDQpwcm92aWRlIHVzIHdpdGgg YWxsIHF1ZXN0aW9ucywgY29tbWVudHMsIGFuZCBzdWdnZXN0aW9ucy4gIFlvdXIgZmVlZGJhY2sg aXMga2V5DQp0byBvdXIgc3VjY2VzcyENCg0KUGxlYXNlIG5vdGU6DQoNCkFsbCB0cmFmZmljIHdp dGhpbiB0aGUgZGVmaW5lZCByb29tcyAoZXhjZXB0ICJub2MiKSBpcyBiZWluZyBsb2dnZWQgYW5k IHVwZGF0ZWQNCmV2ZXJ5IDUgbWludXRlcyB0byB0aGUgaWV0Zi5vcmcgd2Vic2l0ZS4NCg0KVG8g dmlldyB0aGUgbG9nIGRpcmVjdG9yaWVzLCBwb2ludCB5b3VyIGJyb3dzZXIgdG8NCmh0dHA6Ly93 d3cuaWV0Zi5vcmcvbWVldGluZ3MvaWV0Zi1sb2dzLy4NCg0KSWYgeW91IGNsaWNrIG9uIGEgcm9v bSBkaXJlY3RvcnksIHlvdSB3aWxsIHNlZSBvbmUgb3IgbW9yZSBmaWxlcyBuYW1lZA0KIllZWVkt TU0tREQuaHRtbCIsIGUuZy4gMjAwNi0wMy0xNC5odG1sLiAgSWYgeW91IGNsaWNrIG9uIG9uZSBv ZiB0aG9zZSBmaWxlcywNCnlvdSB3aWxsIHNlZSBhbGwgbG9nZ2VkIHRyYWZmaWMgZm9yIHRoYXQg ZGF5Lg0KIA0KUGxlYXNlIHZpc2l0IHRoZSBJRVRGIFRleHQgQ29uZmVyZW5jaW5nIFdlYiBwYWdl DQooaHR0cDovL3d3dy5pZXRmLm9yZy9tZWV0aW5ncy90ZXh0X2NvbmYuaHRtbCkgZm9yIG1vcmUg aW5mb3JtYXRpb24uDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0Lg0KDQo= ------_=_NextPart_001_01C64ADA.43F1D492 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PVVURi04Ij4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMg RXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNi41Ljc2MzguMSI+DQo8VElUTEU+Rlc6IEphYmJlciBz ZXJ2aWNlIGZvciBJRVRGIG1lZXRpbmdzIDwvVElUTEU+DQo8L0hFQUQ+DQo8Qk9EWT4NCjwhLS0g Q29udmVydGVkIGZyb20gdGV4dC9wbGFpbiBmb3JtYXQgLS0+DQoNCjxQPjxGT05UIFNJWkU9Mj5O ZXcgaG9tZSBmb3IgSmFiYmVyLiZuYnNwOyBUaGlzIGlzIHRoZSB0ZXh0IGNoYXQgLyBsb2cgYXBw cGxpY2F0aW9uIHdlIHdpbGwgdXNlIGZvciBJRVRGIDY1LjxCUj4NCjxCUj4NCiZuYnNwOy0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tPEJSPg0KRnJvbTogJm5ic3A7IElFVEYgU2VjcmV0YXJpYXQg WzxBIEhSRUY9Im1haWx0bzppZXRmLXNlY3JldGFyaWF0QGlldGYub3JnIj5tYWlsdG86aWV0Zi1z ZWNyZXRhcmlhdEBpZXRmLm9yZzwvQT5dPEJSPg0KU2VudDombmJzcDsmbmJzcDsgVHVlIE1hciAx NCAyMzoyOToyNiAyMDA2PEJSPg0KVG86Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFdvcmtpbmcg R3JvdXAgQ2hhaXJzPEJSPg0KU3ViamVjdDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgSmFiYmVyIHNlcnZpY2UgZm9yIElFVEYgbWVldGluZ3M8QlI+DQo8QlI+DQpE ZWFyIElFVEYgV0cgQ2hhaXJzLDxCUj4NCjxCUj4NClRoZSBTZWNyZXRhcmlhdCBpcyBwbGVhc2Vk IHRvIGFubm91bmNlIGEgbmV3IEluc3RhbnQgTWVzc2FnaW5nIHNlcnZpY2UuJm5ic3A7IFRoaXM8 QlI+DQpzZXJ2aWNlIHdpbGwgcHJvdmlkZSBqYWJiZXIgY2hhdCByb29tcyB0byBhbGwgSUVURiB3 b3JraW5nIGdyb3VwcyBmb3IgdGhlaXIgdGV4dDxCUj4NCmNvbmZlcmVuY2luZyBhdCBJRVRGIDY1 IGFuZCBmdXR1cmUgbWVldGluZ3MuPEJSPg0KPEJSPg0KVGhlIG5ldyBqYWJiZXIgc2VydmVyIGlz IGxvY2F0ZWQgYXQgamFiYmVyLmlldGYub3JnIGFuZCBpcyBjdXJyZW50bHk8QlI+DQphY2Nlc3Np YmxlLiZuYnNwOyBGb3IgdGhvc2Ugd2hvIGFyZSBpbnRlcmVzdGVkLCBwbGVhc2UgdmlzaXQgdGhl IGFib3ZlIGxvY2F0aW9uIHRvPEJSPg0Kam9pbiBhbnkgb2YgdGhlIGF2YWlsYWJsZSBjaGF0IHJv b21zLjxCUj4NCjxCUj4NCk92ZXIgdGhlIG5leHQgZmV3IGRheXMsIHBsZWFzZSB0YWtlIHRoZSB0 aW1lIHRvIHRlc3QgdGhpcyBuZXcgc2VydmljZSBhbmQ8QlI+DQpwcm92aWRlIHVzIHdpdGggYWxs IHF1ZXN0aW9ucywgY29tbWVudHMsIGFuZCBzdWdnZXN0aW9ucy4mbmJzcDsgWW91ciBmZWVkYmFj ayBpcyBrZXk8QlI+DQp0byBvdXIgc3VjY2VzcyE8QlI+DQo8QlI+DQpQbGVhc2Ugbm90ZTo8QlI+ DQo8QlI+DQpBbGwgdHJhZmZpYyB3aXRoaW4gdGhlIGRlZmluZWQgcm9vbXMgKGV4Y2VwdCAmcXVv dDtub2MmcXVvdDspIGlzIGJlaW5nIGxvZ2dlZCBhbmQgdXBkYXRlZDxCUj4NCmV2ZXJ5IDUgbWlu dXRlcyB0byB0aGUgaWV0Zi5vcmcgd2Vic2l0ZS48QlI+DQo8QlI+DQpUbyB2aWV3IHRoZSBsb2cg ZGlyZWN0b3JpZXMsIHBvaW50IHlvdXIgYnJvd3NlciB0bzxCUj4NCjxBIEhSRUY9Imh0dHA6Ly93 d3cuaWV0Zi5vcmcvbWVldGluZ3MvaWV0Zi1sb2dzLyI+aHR0cDovL3d3dy5pZXRmLm9yZy9tZWV0 aW5ncy9pZXRmLWxvZ3MvPC9BPi48QlI+DQo8QlI+DQpJZiB5b3UgY2xpY2sgb24gYSByb29tIGRp cmVjdG9yeSwgeW91IHdpbGwgc2VlIG9uZSBvciBtb3JlIGZpbGVzIG5hbWVkPEJSPg0KJnF1b3Q7 WVlZWS1NTS1ERC5odG1sJnF1b3Q7LCBlLmcuIDIwMDYtMDMtMTQuaHRtbC4mbmJzcDsgSWYgeW91 IGNsaWNrIG9uIG9uZSBvZiB0aG9zZSBmaWxlcyw8QlI+DQp5b3Ugd2lsbCBzZWUgYWxsIGxvZ2dl ZCB0cmFmZmljIGZvciB0aGF0IGRheS48QlI+DQo8QlI+DQpQbGVhc2UgdmlzaXQgdGhlIElFVEYg VGV4dCBDb25mZXJlbmNpbmcgV2ViIHBhZ2U8QlI+DQooPEEgSFJFRj0iaHR0cDovL3d3dy5pZXRm Lm9yZy9tZWV0aW5ncy90ZXh0X2NvbmYuaHRtbCI+aHR0cDovL3d3dy5pZXRmLm9yZy9tZWV0aW5n cy90ZXh0X2NvbmYuaHRtbDwvQT4pIGZvciBtb3JlIGluZm9ybWF0aW9uLjxCUj4NCjxCUj4NClRo ZSBJRVRGIFNlY3JldGFyaWF0LjxCUj4NCjxCUj4NCjwvRk9OVD4NCjwvUD4NCg0KPC9CT0RZPg0K PC9IVE1MPg== ------_=_NextPart_001_01C64ADA.43F1D492-- --===============1365729063== 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 --===============1365729063==-- From lemonade-bounces@ietf.org Sun Mar 19 16:40:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL5dR-0003Qf-On; Sun, 19 Mar 2006 16:40:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL5dQ-0003Qa-Fz for lemonade@ietf.org; Sun, 19 Mar 2006 16:40:24 -0500 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL5dQ-0003Pm-1q for lemonade@ietf.org; Sun, 19 Mar 2006 16:40:24 -0500 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M08KW9C6IO000078@mauve.mrochek.com> for lemonade@ietf.org; Sun, 19 Mar 2006 13:40:22 -0800 (PST) To: Arnt Gulbrandsen Message-id: <01M08ORTJGOI000078@mauve.mrochek.com> Date: Sun, 19 Mar 2006 13:04:40 -0800 (PST) From: Ned Freed Subject: Re: [lemonade] compression In-reply-to: "Your message dated Sat, 18 Mar 2006 22:04:33 +0100" MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <330A23D8336C0346B5C1A5BB196666470231C1E5@ATLANTIS.Brooktrout.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > Eric Burger writes: > > Arnt did an excellent job collecting actual data on the value of > > transport layer compression and application layer compression. > > > > The counter argument I hear (and I'm hard of hearing, so I may be > > wrong) is that transport layer compression might, under certain > > circumstances, use more MIPS. > > > > It would be really helpful if someone could get _data_ on CPU use. The real problem is you can make CPU data say pretty much anything you want it to say. In the extreme case you can have the server send nothing but uncompressed blocks. You won't have any compression but the CPU load (on both ends) will be so low as to be immeasureable. More generally, it would be entirely feasible for a server to note that a binary download of some specific media type is unlikely to benefit from compression and to signal the compressor to enter passthrough mode, thus avoiding CPU usage on both the server and client. THis could even be done on a learning basis, or it could be precomputed as messages are inserted. There are all sorts of possible and more to the point, plausible, designs. THe key difference in the various proposals is who gets to control what. The LZIP proposal puts the control largely in the hands of the client and also dramatically limits the extent to which compression can be used and how effective it can be. I view all of these aspects of the design as extremely poor choices - the client is far less in a position to know when compression will or will not be useful than the server is. One approach that might be interesting would be for the client to give some indication to the server as to how it wants compression used. One client might say "decompression is expensive for me so please use passthrough unless there are major benefits". Another might say "bandwidth is my concern, compress whenever there is benefit". These sorts of controls could easily be included in the c=d proposal. But given that CPU statistics are almost certainly going to be done on an all-or-nothing basis, and this doesn't have to be (and probably shouldn't be) how a real implementation would work, I view any such data as a red herring, regardless of the results it shows. (I would also expect any test that involves downloading of a large object undergoing compression to show no significant differences between the various proposals - and if it doesn't the tests are highly suspect absent a good explanation for the difference.) > I can provide that as a side effect of the further comparison work I'm > doing (and which I'll post about - the results are surprising). My > timings won't be very very accurate, though. > The charge has some validity, btw. In certain circumstances, which > should be odd and unusual but I find myself affected. > Consider compress=deflate and the almost entirely equivalent RFC3749 TLS > feature. With c=d, the IMAP server author can do some measurements, and > find out that zlib in its lightest-weight mode provides 97% of the > achievable benefit (I am not making this up). However, if compression > is being done by the TLS implementation, _and_ the TLS implementation > doesn't provide any API to adjust the compression settings, then the > IMAP server can't do this. Then the IMAP server is bound to spend as > much CPU on compression as the TLS author saw fit. This is a very good point that should be considered when deciding between TLS-player compression and c=d. It is especially important given the relatively small number of TLS implementations servers are likely to use. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Mar 19 21:10:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL9qc-0004tg-Nk; Sun, 19 Mar 2006 21:10:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL9qc-0004tb-B2 for lemonade@ietf.org; Sun, 19 Mar 2006 21:10:18 -0500 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL9qb-0004sR-4Z for lemonade@ietf.org; Sun, 19 Mar 2006 21:10:18 -0500 X-IronPort-AV: i="4.03,109,1141621200"; d="scan'208"; a="30276820:sNHT36563768" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 19 Mar 2006 21:10:12 -0500 Message-ID: <330A23D8336C0346B5C1A5BB196666470276AA78@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft Statii Thread-Index: AcZLw2vgeI3yFlFKSJCbsTAeSC5jaA== From: "Burger, Eric" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [lemonade] Draft Statii X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org So we don't spend time in the meeting: Published: draft-ietf-lemonade-mms-mapping-06 RFC 4356 draft-ietf-lemonade-goals-05 RFC 4416 RFC-Editor's Queue: draft-ietf-lemonade-profile-07 RFC Ed Queue draft-ietf-lemonade-burl-04 RFC Ed Queue =20 draft-ietf-lemonade-catenate-05 RFC Ed Queue draft-ietf-lemonade-urlauth-08 RFC Ed Queue IESG Processing: draft-ietf-lemonade-notify-s2s-00 Revised ID Needed Fold into Notifications _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Mar 19 22:43:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLBIb-0001R6-UQ; Sun, 19 Mar 2006 22:43:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLBIb-0001Qy-B4 for lemonade@ietf.org; Sun, 19 Mar 2006 22:43:17 -0500 Received: from agminet01.oracle.com ([141.146.126.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLBIa-0007Cn-Tf for lemonade@ietf.org; Sun, 19 Mar 2006 22:43:17 -0500 Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2K3hESY029468 for ; Sun, 19 Mar 2006 21:43:14 -0600 Received: from rgmsgw300.us.oracle.com (localhost [127.0.0.1]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2K3hEf1018470 for ; Sun, 19 Mar 2006 20:43:14 -0700 Received: from us.oracle.com (dhcp-amer-rmdc-csvpn-gw5-141-144-104-78.vpn.oracle.com [141.144.104.78]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2K3hDwa018462 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 19 Mar 2006 20:43:13 -0700 From: "Stephane H. Maes" To: "lemonade@ietf.org" Subject: RE: [lemonade] compression Date: Sun, 19 Mar 2006 19:43:18 -0800 Message-ID: <20060319194318805.00000005420@smaes-lap3> In-Reply-To: <01M08ORTJGOI000078@mauve.mrochek.com> X-Mailer: Oracle Connector for Outlook 10.1.2.0.3 71207 (11.0.8010) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Spam-Score: 0.5 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "stephane.maes@oracle.com" List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org It seems that a premise is that the server should decide. Interesting diffe= rent point of view from other cases. I actually believe that the client should be able to decide when it decides= to download something if it wants it have it compressed and how. It needs = to be able to selectively select when to compresst. = Indeed, selective compression provides significant gains (e.g. attachemnt t= o compress). In addition, factors outside the protocol consideration or the server knowl= edge come into play (like battery state (i.e. is it ok to spend energy deco= mpressing versus getting more data but not having to decompress, user decis= ion (cost vs battery life etc...). Eventually as was discussed in Beijing, TSL compression is not yet easy to = support or expected to be supported on most mobile phones. So my view is that 1) we need to allow application level selective compress= ion 2) we need to let the client decide 3) it is useful in terms of bandwid= th and in terms of battery life to offer this option 40 ... I have no problem also allowing TLS compression, but in Beijing, the WG rat= her decided against it... Stephane _____ Stephane H. Maes, PhD, Director of Architecture, Mobile, Voice, and Communications Platforms, Orac= le. Ph: +1-203-300-7786 (mobile/SMS); Fax / Office UM: +1-650-607-6296 e-mail: stephane.maes@oracle.com IM: shmaes (AIM/Y!/skype) or stephane_maes@hotmail.com (MSN Messenger) or s= tephane.maes@gmail.com (Google) = -----Original Message----- From: Ned Freed [mailto:ned.freed@mrochek.com] = Sent: Sunday, March 19, 2006 1:05 PM To: Arnt Gulbrandsen Cc: lemonade@ietf.org Subject: Re: [lemonade] compression > Eric Burger writes: > > Arnt did an excellent job collecting actual data on the value of = > > transport layer compression and application layer compression. > > > > The counter argument I hear (and I'm hard of hearing, so I may be > > wrong) is that transport layer compression might, under certain = > > circumstances, use more MIPS. > > > > It would be really helpful if someone could get _data_ on CPU use. The real problem is you can make CPU data say pretty much anything you want= it to say. In the extreme case you can have the server send nothing but un= compressed blocks. You won't have any compression but the CPU load (on both= ends) will be so low as to be immeasureable. More generally, it would be entirely feasible for a server to note that a b= inary download of some specific media type is unlikely to benefit from comp= ression and to signal the compressor to enter passthrough mode, thus avoidi= ng CPU usage on both the server and client. THis could even be done on a le= arning basis, or it could be precomputed as messages are inserted. There ar= e all sorts of possible and more to the point, plausible, designs. THe key difference in the various proposals is who gets to control what. Th= e LZIP proposal puts the control largely in the hands of the client and als= o dramatically limits the extent to which compression can be used and how e= ffective it can be. I view all of these aspects of the design as extremely = poor choices - the client is far less in a position to know when compressio= n will or will not be useful than the server is. One approach that might be interesting would be for the client to give some= indication to the server as to how it wants compression used. One client m= ight say "decompression is expensive for me so please use passthrough unles= s there are major benefits". Another might say "bandwidth is my concern, co= mpress whenever there is benefit". These sorts of controls could easily be = included in the c=3Dd proposal. But given that CPU statistics are almost certainly going to be done on an a= ll-or-nothing basis, and this doesn't have to be (and probably shouldn't be= ) how a real implementation would work, I view any such data as a red herri= ng, regardless of the results it shows. (I would also expect any test that = involves downloading of a large object undergoing compression to show no si= gnificant differences between the various proposals - and if it doesn't the= tests are highly suspect absent a good explanation for the difference.) > I can provide that as a side effect of the further comparison work I'm = > doing (and which I'll post about - the results are surprising). My = > timings won't be very very accurate, though. > The charge has some validity, btw. In certain circumstances, which = > should be odd and unusual but I find myself affected. > Consider compress=3Ddeflate and the almost entirely equivalent RFC3749 = > TLS feature. With c=3Dd, the IMAP server author can do some = > measurements, and find out that zlib in its lightest-weight mode = > provides 97% of the achievable benefit (I am not making this up). = > However, if compression is being done by the TLS implementation, _and_ = > the TLS implementation doesn't provide any API to adjust the = > compression settings, then the IMAP server can't do this. Then the = > IMAP server is bound to spend as much CPU on compression as the TLS autho= r saw fit. This is a very good point that should be considered when deciding between T= LS-player compression and c=3Dd. It is especially important given the relat= ively small number of TLS implementations servers are likely to use. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Mar 20 00:37:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLD4n-0002R6-K2; Mon, 20 Mar 2006 00:37:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLD4m-0002Oe-DX for lemonade@ietf.org; Mon, 20 Mar 2006 00:37:08 -0500 Received: from webmail.chinamobile.com ([211.136.27.4] helo=cmccmta) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLD4e-0002cY-5z for lemonade@ietf.org; Mon, 20 Mar 2006 00:37:08 -0500 Received: from fanxiaohui ([10.1.5.34]) by mail.chinamobile.com (Lotus Domino Release 5.0.12HF438) with SMTP id 2006032013450863:5405 ; Mon, 20 Mar 2006 13:45:08 +0800 Date: Mon, 20 Mar 2006 13:35:01 +0800 From: "Xiaohui Fan" To: "stephane.maes@oracle.com" , "lemonade@ietf.org" Subject: Re: RE: [lemonade] compression Organization: cmcc X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 5.0.12HF438 | October 15, 2003) at 2006-03-20 01:45:08 PM, Serialize by Router on cmccmta/servers/cmcc(Release 5.0.6a |January 17, 2001) at 2006-03-20 01:29:43 PM, Serialize complete at 2006-03-20 01:29:43 PM Message-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 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="===============0294614577==" Errors-To: lemonade-bounces@ietf.org --===============0294614577== Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" QWN0dWFsbHkgdGhlcmUgYXJlIHZlcnkgZmV3IGhhbmRzZXRzIHN1cHBvcnRpbmcgVExTIGluIHRo ZSBtYXJrZXQuIFNvbWUgdGVybWluYWxzIHN1cHBvcnQgU1NMIGJ1dCBkb25vdCBpbXBsZW1lbnQg Y29tcHJlc3Npb24gbWVjaGFuaXNtLg0KDQpBbmQgSSBiZWxpZXZlIGl0IGlzIG5vdCBuZWNlc3Nh cnkgdG8gY29tcHJlc3MgY29tbWFuZHMuIFNvbWUgY29tbWFuZHMgYXJlIHZlcnkgc2hvcnQgYW5k IHRoZSBjb21wcmVzc2lvbiBjYW5ub3QgaGF2ZSANCm9idmlvdXMgZW5oYW5jZW1lbnQgb24gaXQs IHdoaWxlIG9uIHRoZSBvdGhlciBzaWRlLCB0aGUgY29tcHJlc3Npb24gY29tcHV0aW5nIG9uIGVh Y2ggY29tbWFuZCB3aWxsIGluY3JlYXNlIHRoZSBjb3N0DQpvZiBiYXR0ZXJ5LiANCg0KU28gb2Jq ZWN0IGNvbXByZXNzaW9uIGlzIG1vcmUgcmVhbGlzdGljIGFuZCBlY29ub21pYyBvbiBtb2JpbGUg cGhvbmVzLg0KDQo9PT09PT09IDIwMDYtMDMtMjAgMTE6NDM6MTggeW91IHdyb3RlIGluIGVtYWls o7o9PT09PT09DQoNCj5JdCBzZWVtcyB0aGF0IGEgcHJlbWlzZSBpcyB0aGF0IHRoZSBzZXJ2ZXIg c2hvdWxkIGRlY2lkZS4gSW50ZXJlc3RpbmcgZGlmZmVyZW50IHBvaW50IG9mIHZpZXcgZnJvbSBv dGhlciBjYXNlcy4NCj4NCj5JIGFjdHVhbGx5IGJlbGlldmUgdGhhdCB0aGUgY2xpZW50IHNob3Vs ZCBiZSBhYmxlIHRvIGRlY2lkZSB3aGVuIGl0IGRlY2lkZXMgdG8gZG93bmxvYWQgc29tZXRoaW5n IGlmIGl0IHdhbnRzIGl0IGhhdmUgaXQgY29tcHJlc3NlZCBhbmQgaG93LiBJdCBuZWVkcyB0byBi ZSBhYmxlIHRvIHNlbGVjdGl2ZWx5IHNlbGVjdCB3aGVuIHRvIGNvbXByZXNzdC4gDQo+DQo+SW5k ZWVkLCBzZWxlY3RpdmUgY29tcHJlc3Npb24gcHJvdmlkZXMgc2lnbmlmaWNhbnQgZ2FpbnMgKGUu Zy4gYXR0YWNoZW1udCB0byBjb21wcmVzcykuDQo+DQo+SW4gYWRkaXRpb24sIGZhY3RvcnMgb3V0 c2lkZSB0aGUgcHJvdG9jb2wgY29uc2lkZXJhdGlvbiBvciB0aGUgc2VydmVyIGtub3dsZWRnZSBj b21lIGludG8gcGxheSAobGlrZSBiYXR0ZXJ5IHN0YXRlIChpLmUuIGlzIGl0IG9rIHRvIHNwZW5k IGVuZXJneSBkZWNvbXByZXNzaW5nIHZlcnN1cyBnZXR0aW5nIG1vcmUgZGF0YSBidXQgbm90IGhh dmluZyB0byBkZWNvbXByZXNzLCB1c2VyIGRlY2lzaW9uIChjb3N0IHZzIGJhdHRlcnkgbGlmZSBl dGMuLi4pLg0KPg0KPkV2ZW50dWFsbHkgYXMgd2FzIGRpc2N1c3NlZCBpbiBCZWlqaW5nLCBUU0wg Y29tcHJlc3Npb24gaXMgbm90IHlldCBlYXN5IHRvIHN1cHBvcnQgb3IgZXhwZWN0ZWQgdG8gYmUg c3VwcG9ydGVkIG9uIG1vc3QgbW9iaWxlIHBob25lcy4NCj4NCj5TbyBteSB2aWV3IGlzIHRoYXQg MSkgd2UgbmVlZCB0byBhbGxvdyBhcHBsaWNhdGlvbiBsZXZlbCBzZWxlY3RpdmUgY29tcHJlc3Np b24gMikgd2UgbmVlZCB0byBsZXQgdGhlIGNsaWVudCBkZWNpZGUgMykgaXQgaXMgdXNlZnVsIGlu IHRlcm1zIG9mIGJhbmR3aWR0aCBhbmQgaW4gdGVybXMgb2YgYmF0dGVyeSBsaWZlIHRvIG9mZmVy IHRoaXMgb3B0aW9uIDQwIC4uLg0KPg0KPkkgaGF2ZSBubyBwcm9ibGVtIGFsc28gYWxsb3dpbmcg VExTIGNvbXByZXNzaW9uLCBidXQgaW4gQmVpamluZywgdGhlIFdHIHJhdGhlciBkZWNpZGVkIGFn YWluc3QgaXQuLi4NCj4NCj5TdGVwaGFuZQ0KPg0KPl9fX19fDQo+U3RlcGhhbmUgSC4gTWFlcywg UGhELA0KPkRpcmVjdG9yIG9mIEFyY2hpdGVjdHVyZSwgTW9iaWxlLCBWb2ljZSwgYW5kIENvbW11 bmljYXRpb25zIFBsYXRmb3JtcywgT3JhY2xlLg0KPlBoOiArMS0yMDMtMzAwLTc3ODYgKG1vYmls ZS9TTVMpOyBGYXggLyBPZmZpY2UgVU06ICsxLTY1MC02MDctNjI5Ng0KPmUtbWFpbDogc3RlcGhh bmUubWFlc0BvcmFjbGUuY29tDQo+SU06IHNobWFlcyAoQUlNL1khL3NreXBlKSBvciBzdGVwaGFu ZV9tYWVzQGhvdG1haWwuY29tIChNU04gTWVzc2VuZ2VyKSBvciBzdGVwaGFuZS5tYWVzQGdtYWls LmNvbSAoR29vZ2xlKQ0KPiANCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IE5l ZCBGcmVlZCBbbWFpbHRvOm5lZC5mcmVlZEBtcm9jaGVrLmNvbV0gDQo+U2VudDogU3VuZGF5LCBN YXJjaCAxOSwgMjAwNiAxOjA1IFBNDQo+VG86IEFybnQgR3VsYnJhbmRzZW4NCj5DYzogbGVtb25h ZGVAaWV0Zi5vcmcNCj5TdWJqZWN0OiBSZTogW2xlbW9uYWRlXSBjb21wcmVzc2lvbg0KPg0KPj4g RXJpYyBCdXJnZXIgd3JpdGVzOg0KPj4gPiBBcm50IGRpZCBhbiBleGNlbGxlbnQgam9iIGNvbGxl Y3RpbmcgYWN0dWFsIGRhdGEgb24gdGhlIHZhbHVlIG9mIA0KPj4gPiB0cmFuc3BvcnQgbGF5ZXIg Y29tcHJlc3Npb24gYW5kIGFwcGxpY2F0aW9uIGxheWVyIGNvbXByZXNzaW9uLg0KPj4gPg0KPj4g PiBUaGUgY291bnRlciBhcmd1bWVudCBJIGhlYXIgKGFuZCBJJ20gaGFyZCBvZiBoZWFyaW5nLCBz byBJIG1heSBiZQ0KPj4gPiB3cm9uZykgaXMgdGhhdCB0cmFuc3BvcnQgbGF5ZXIgY29tcHJlc3Np b24gbWlnaHQsIHVuZGVyIGNlcnRhaW4gDQo+PiA+IGNpcmN1bXN0YW5jZXMsIHVzZSBtb3JlIE1J UFMuDQo+PiA+DQo+PiA+IEl0IHdvdWxkIGJlIHJlYWxseSBoZWxwZnVsIGlmIHNvbWVvbmUgY291 bGQgZ2V0IF9kYXRhXyBvbiBDUFUgdXNlLg0KPg0KPlRoZSByZWFsIHByb2JsZW0gaXMgeW91IGNh biBtYWtlIENQVSBkYXRhIHNheSBwcmV0dHkgbXVjaCBhbnl0aGluZyB5b3Ugd2FudCBpdCB0byBz YXkuIEluIHRoZSBleHRyZW1lIGNhc2UgeW91IGNhbiBoYXZlIHRoZSBzZXJ2ZXIgc2VuZCBub3Ro aW5nIGJ1dCB1bmNvbXByZXNzZWQgYmxvY2tzLiBZb3Ugd29uJ3QgaGF2ZSBhbnkgY29tcHJlc3Np b24gYnV0IHRoZSBDUFUgbG9hZCAob24gYm90aA0KPmVuZHMpIHdpbGwgYmUgc28gbG93IGFzIHRv IGJlIGltbWVhc3VyZWFibGUuDQo+DQo+TW9yZSBnZW5lcmFsbHksIGl0IHdvdWxkIGJlIGVudGly ZWx5IGZlYXNpYmxlIGZvciBhIHNlcnZlciB0byBub3RlIHRoYXQgYSBiaW5hcnkgZG93bmxvYWQg b2Ygc29tZSBzcGVjaWZpYyBtZWRpYSB0eXBlIGlzIHVubGlrZWx5IHRvIGJlbmVmaXQgZnJvbSBj b21wcmVzc2lvbiBhbmQgdG8gc2lnbmFsIHRoZSBjb21wcmVzc29yIHRvIGVudGVyIHBhc3N0aHJv dWdoIG1vZGUsIHRodXMgYXZvaWRpbmcgQ1BVIHVzYWdlIG9uIGJvdGggdGhlIHNlcnZlciBhbmQg Y2xpZW50LiBUSGlzIGNvdWxkIGV2ZW4gYmUgZG9uZSBvbiBhIGxlYXJuaW5nIGJhc2lzLCBvciBp dCBjb3VsZCBiZSBwcmVjb21wdXRlZCBhcyBtZXNzYWdlcyBhcmUgaW5zZXJ0ZWQuIFRoZXJlIGFy ZSBhbGwgc29ydHMgb2YgcG9zc2libGUgYW5kIG1vcmUgdG8gdGhlIHBvaW50LCBwbGF1c2libGUs IGRlc2lnbnMuDQo+DQo+VEhlIGtleSBkaWZmZXJlbmNlIGluIHRoZSB2YXJpb3VzIHByb3Bvc2Fs cyBpcyB3aG8gZ2V0cyB0byBjb250cm9sIHdoYXQuIFRoZSBMWklQIHByb3Bvc2FsIHB1dHMgdGhl IGNvbnRyb2wgbGFyZ2VseSBpbiB0aGUgaGFuZHMgb2YgdGhlIGNsaWVudCBhbmQgYWxzbyBkcmFt YXRpY2FsbHkgbGltaXRzIHRoZSBleHRlbnQgdG8gd2hpY2ggY29tcHJlc3Npb24gY2FuIGJlIHVz ZWQgYW5kIGhvdyBlZmZlY3RpdmUgaXQgY2FuIGJlLiBJIHZpZXcgYWxsIG9mIHRoZXNlIGFzcGVj dHMgb2YgdGhlIGRlc2lnbiBhcyBleHRyZW1lbHkgcG9vciBjaG9pY2VzIC0gdGhlIGNsaWVudCBp cyBmYXIgbGVzcyBpbiBhIHBvc2l0aW9uIHRvIGtub3cgd2hlbiBjb21wcmVzc2lvbiB3aWxsIG9y IHdpbGwgbm90IGJlIHVzZWZ1bCB0aGFuIHRoZSBzZXJ2ZXIgaXMuDQo+DQo+T25lIGFwcHJvYWNo IHRoYXQgbWlnaHQgYmUgaW50ZXJlc3Rpbmcgd291bGQgYmUgZm9yIHRoZSBjbGllbnQgdG8gZ2l2 ZSBzb21lIGluZGljYXRpb24gdG8gdGhlIHNlcnZlciBhcyB0byBob3cgaXQgd2FudHMgY29tcHJl c3Npb24gdXNlZC4gT25lIGNsaWVudCBtaWdodCBzYXkgImRlY29tcHJlc3Npb24gaXMgZXhwZW5z aXZlIGZvciBtZSBzbyBwbGVhc2UgdXNlIHBhc3N0aHJvdWdoIHVubGVzcyB0aGVyZSBhcmUgbWFq b3IgYmVuZWZpdHMiLiBBbm90aGVyIG1pZ2h0IHNheSAiYmFuZHdpZHRoIGlzIG15IGNvbmNlcm4s IGNvbXByZXNzIHdoZW5ldmVyIHRoZXJlIGlzIGJlbmVmaXQiLiBUaGVzZSBzb3J0cyBvZiBjb250 cm9scyBjb3VsZCBlYXNpbHkgYmUgaW5jbHVkZWQgaW4gdGhlIGM9ZCBwcm9wb3NhbC4NCj4NCj5C dXQgZ2l2ZW4gdGhhdCBDUFUgc3RhdGlzdGljcyBhcmUgYWxtb3N0IGNlcnRhaW5seSBnb2luZyB0 byBiZSBkb25lIG9uIGFuIGFsbC1vci1ub3RoaW5nIGJhc2lzLCBhbmQgdGhpcyBkb2Vzbid0IGhh dmUgdG8gYmUgKGFuZCBwcm9iYWJseSBzaG91bGRuJ3QgYmUpIGhvdyBhIHJlYWwgaW1wbGVtZW50 YXRpb24gd291bGQgd29yaywgSSB2aWV3IGFueSBzdWNoIGRhdGEgYXMgYSByZWQgaGVycmluZywg cmVnYXJkbGVzcyBvZiB0aGUgcmVzdWx0cyBpdCBzaG93cy4gKEkgd291bGQgYWxzbyBleHBlY3Qg YW55IHRlc3QgdGhhdCBpbnZvbHZlcyBkb3dubG9hZGluZyBvZiBhIGxhcmdlIG9iamVjdCB1bmRl cmdvaW5nIGNvbXByZXNzaW9uIHRvIHNob3cgbm8gc2lnbmlmaWNhbnQgZGlmZmVyZW5jZXMgYmV0 d2VlbiB0aGUgdmFyaW91cyBwcm9wb3NhbHMgLSBhbmQgaWYgaXQgZG9lc24ndCB0aGUgdGVzdHMg YXJlIGhpZ2hseSBzdXNwZWN0IGFic2VudCBhIGdvb2QgZXhwbGFuYXRpb24gZm9yIHRoZSBkaWZm ZXJlbmNlLikNCj4NCj4+IEkgY2FuIHByb3ZpZGUgdGhhdCBhcyBhIHNpZGUgZWZmZWN0IG9mIHRo ZSBmdXJ0aGVyIGNvbXBhcmlzb24gd29yayBJJ20gDQo+PiBkb2luZyAoYW5kIHdoaWNoIEknbGwg cG9zdCBhYm91dCAtIHRoZSByZXN1bHRzIGFyZSBzdXJwcmlzaW5nKS4gTXkgDQo+PiB0aW1pbmdz IHdvbid0IGJlIHZlcnkgdmVyeSBhY2N1cmF0ZSwgdGhvdWdoLg0KPg0KPj4gVGhlIGNoYXJnZSBo YXMgc29tZSB2YWxpZGl0eSwgYnR3LiBJbiBjZXJ0YWluIGNpcmN1bXN0YW5jZXMsIHdoaWNoIA0K Pj4gc2hvdWxkIGJlIG9kZCBhbmQgdW51c3VhbCBidXQgSSBmaW5kIG15c2VsZiBhZmZlY3RlZC4N Cj4NCj4+IENvbnNpZGVyIGNvbXByZXNzPWRlZmxhdGUgYW5kIHRoZSBhbG1vc3QgZW50aXJlbHkg ZXF1aXZhbGVudCBSRkMzNzQ5IA0KPj4gVExTIGZlYXR1cmUuIFdpdGggYz1kLCB0aGUgSU1BUCBz ZXJ2ZXIgYXV0aG9yIGNhbiBkbyBzb21lIA0KPj4gbWVhc3VyZW1lbnRzLCBhbmQgZmluZCBvdXQg dGhhdCB6bGliIGluIGl0cyBsaWdodGVzdC13ZWlnaHQgbW9kZSANCj4+IHByb3ZpZGVzIDk3JSBv ZiB0aGUgYWNoaWV2YWJsZSBiZW5lZml0IChJIGFtIG5vdCBtYWtpbmcgdGhpcyB1cCkuIA0KPj4g SG93ZXZlciwgaWYgY29tcHJlc3Npb24gaXMgYmVpbmcgZG9uZSBieSB0aGUgVExTIGltcGxlbWVu dGF0aW9uLCBfYW5kXyANCj4+IHRoZSBUTFMgaW1wbGVtZW50YXRpb24gZG9lc24ndCBwcm92aWRl IGFueSBBUEkgdG8gYWRqdXN0IHRoZSANCj4+IGNvbXByZXNzaW9uIHNldHRpbmdzLCB0aGVuIHRo ZSBJTUFQIHNlcnZlciBjYW4ndCBkbyB0aGlzLiBUaGVuIHRoZSANCj4+IElNQVAgc2VydmVyIGlz IGJvdW5kIHRvIHNwZW5kIGFzIG11Y2ggQ1BVIG9uIGNvbXByZXNzaW9uIGFzIHRoZSBUTFMgYXV0 aG9yIHNhdyBmaXQuDQo+DQo+VGhpcyBpcyBhIHZlcnkgZ29vZCBwb2ludCB0aGF0IHNob3VsZCBi ZSBjb25zaWRlcmVkIHdoZW4gZGVjaWRpbmcgYmV0d2VlbiBUTFMtcGxheWVyIGNvbXByZXNzaW9u IGFuZCBjPWQuIEl0IGlzIGVzcGVjaWFsbHkgaW1wb3J0YW50IGdpdmVuIHRoZSByZWxhdGl2ZWx5 IHNtYWxsIG51bWJlciBvZiBUTFMgaW1wbGVtZW50YXRpb25zIHNlcnZlcnMgYXJlIGxpa2VseSB0 byB1c2UuDQo+DQo+CQkJCU5lZA0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+bGVtb25hZGUgbWFpbGluZyBsaXN0DQo+bGVtb25hZGVAaWV0Zi5v cmcNCj5odHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sZW1vbmFkZQ0KPg0K Pg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+bGVt b25hZGUgbWFpbGluZyBsaXN0DQo+bGVtb25hZGVAaWV0Zi5vcmcNCj5odHRwczovL3d3dzEuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sZW1vbmFkZQ0KDQo9ID0gPSA9ID0gPSA9ID0gPSA9ID0g PSA9ID0gPSA9ID0gPSA9ID0NCqGhoaGhoaGhoaGhoaGhoaENCgkJCQkgDQpCZXN0IFJlZ2FyZHMg CQkJCQ0KDQpGYW4gWGlhb2h1aQ0KDQpQcm9kdWN0IERldmVsb3BtZW50IERpdmlzaW9uIA0KUiZE IENFTlRFUg0KQ0hJTkEgTU9CSUxFIENPTU1VTklDQVRJT05TIENPUlBPUkFUSU9OIChDTUNDKQ0K QUREOiA1M0EsIFhpYmlhbm1lbm5laSBBdmUuLFh1YW53dSBEaXN0cmljdCxCZWlqaW5nLDEwMDA1 MyBDaGluYQ0KVEVMOis4NiAxMCA2NjAwNjY4OCBFWFQgMzEzNw0KRkFYOis4NiAxMCA2MzYwMDM0 MA0KRS1tYWlsOiBmYW54aWFvaHVpQGNoaW5hbW9iaWxlLmNvbQ0K --===============0294614577== 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 --===============0294614577==-- From lemonade-bounces@ietf.org Mon Mar 20 01:00:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLDRO-0007Gs-F5; Mon, 20 Mar 2006 01:00:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLDRM-0007Gn-DS for lemonade@ietf.org; Mon, 20 Mar 2006 01:00:28 -0500 Received: from zproxy.gmail.com ([64.233.162.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLDRM-0003Pe-05 for lemonade@ietf.org; Mon, 20 Mar 2006 01:00:28 -0500 Received: by zproxy.gmail.com with SMTP id f1so983008nzc for ; Sun, 19 Mar 2006 22:00:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=Q2Ri8tP2LnlsIseZbFEPxgEnd9vlPLqAUz4kuCeu2dWmVhiWVETltPNqp6T8/x9LCFV/v2irNKd9xOn/6jWleiwd6RUFc+pJUxKrTt9M+ObPHbDBbbn5uvPs3Rvx8KzecBeQ1pcGAwOXozL83yH4pTs7bbCl3CRPoFm6+o9tYq4= Received: by 10.65.133.20 with SMTP id k20mr129555qbn; Sun, 19 Mar 2006 22:00:27 -0800 (PST) Received: by 10.65.126.18 with HTTP; Sun, 19 Mar 2006 22:00:27 -0800 (PST) Message-ID: <23794f40603192200l54ff46bcq29deda1ecfea489f@mail.gmail.com> Date: Sun, 19 Mar 2006 22:00:27 -0800 From: "Alexey Melnikov" To: lemonade@ietf.org, "Stephane Maes" MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 Cc: Subject: [lemonade] Comments on VFOLDER draft X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0170617194==" Errors-To: lemonade-bounces@ietf.org --===============0170617194== Content-Type: multipart/alternative; boundary="----=_Part_9423_13723766.1142834427400" ------=_Part_9423_13723766.1142834427400 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I've already commented on IMAPEXT list that some text should be borrowed from Arnt's VIEW draft, as he seemed to to address some edge cases that VFOLDER currently doesn't. Arnt's draft also adds a LIST-EXTENDED extension= , so that VIEW-aware clients can distinguish views from real mailboxes. I think this might be handy for specialized clients. Detailed comments on draft-ietf-lemonade-vfolder-00 are below: In section 1, 2nd paragraph, second sentence: >The search criteria specify the backing mailbox, as well as a subset IMAP SEARCH ... I don't think that "search criteria" can "specify the backing mailbox". At least the SEARCH search criteria doesn't. Suggest some rewording. Also "subset of IMAP" Paragraph 3 in the same section: >UIDs are preserved, and as well as the UIDVALIDITY value. I am not sure why this restriction is required. Why enforcing it useful? Paragraph 5: >From the client's perspective, whether or not a mailbox is a vfolder is no= t visible, Suggest to use "virtual folder" here. >and for all intents and purposes, it appears as any other mailbox name. >This includes the ability for a new virtual folder to be created by using virtual folder >as a backing mailbox The last sentence is insufficient. I've suggested that the new search criteria was ANDed with the one from the virtual backing folder, however once this was done the real mailbox is considered to be the backing one (i.= e. changed to the backing virtual folder don't affect the new view). Other options are possible. Last paragraph is missing reference to ANNOTATE. In section 2: First paragraph, second sentence: use of LPSEARCH as a term after the LVFOLDER capability seems awkward. Did you mean LVFOLDER? In section 3: Description of NO response should include the two new cases described in this section: no backing mailbox and invalid search criteria. The text in this section is vague when saying that "an error in one of the SEARCH argument values" causes NO response. Invalid search syntax can also cause the BAD response. In section 5: I suggest adding a comment for "psearch" non-terminal saying that search keywords referring to mutable state are not allowed. In section 6: The example that causes the BADBACKING response code is using INBOX as the backing mailbox name, not the IMBOX. In section 7: In first paragraph: > Modifications to mutable state (flags, annotations) have no effect on whether >or not messages are included virtual folders, "included in virtual ..." > nor do they generate events. I am not sure what does "generate events" mean in this context. And I am no= t sure why this requirement is needed. >If a backing mailbox is deleted, then all vfolders attached to that backin= g mailbox >as deleted as well. typo: are deleted as well What about RENAME of the backing mailbox? >Changes to UIDVALIDITY, UIDNEXT, and other underlying properties of Why UIDNEXT change in the backing mailbox should always affect vfolders? If a new message is added to the backing mailbox which doesn't show up in a vfolder, there is no need to change the vfolder's UIDNEXT. >the backing mailbox are reflected in all attached vfolders. The section called "IANA Considerations" has nothing to do with IANA, as IANA has no registry for reserved IMAP mailbox names. I also don't like the requirement to restrict allowed vfolder names: everything except INBOX is an implementation/deployment detail. Section "References" should become "Normative References". Please replace reference to RFC 2234 with RFC 4234. Please delete [P-IMAP] - it is not referenced, at least certainly not in a normative manner. Delete appendix A, this is a separate document now. Regards, Alexey ------=_Part_9423_13723766.1142834427400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I've already commented on IMAPEXT list that some text should be borrowed from Arnt's VIEW draft, as he seemed to to address some edge cases that VFOLDER currently doesn't. Arnt's draft also adds a LIST-EXTENDED extension, so that VIEW-aware clients can distinguish views from real mailboxes. I think this might be handy for specialized clie= nts.

Detailed comments on draft-ietf-lemonade-vfolder-00 are below:

In section 1, 2nd paragraph, second sentence:

>The search criteria specify the backing mailbox, as well as a subset IM= AP SEARCH ...

I don't think that "search criteria" can "specify the backin= g mailbox". At least the SEARCH search criteria doesn't. Suggest some rewording.

Also "subset of IMAP"


Paragraph 3 in the same section:
>UIDs are preserved, and as well as the UIDVALIDITY value.

I am not sure why this restriction is required. Why enforcing it useful?

Paragraph 5:
>From the client's perspective, whether or not a mailbox is a vfolder is= not visible,

Suggest to use "virtual folder" here.

>and for all intents and purposes, it appears as any other mailbox name.=
>This includes the ability for a new virtual folder to be created by usi= ng virtual folder
>as a backing mailbox

The last sentence is insufficient. I've suggested that the new search criteria was ANDed with the one from the virtual backing folder, however once this was done the real mailbox is considered to be the backing one (i.e. changed to the backing virtual folder don't affect the new view). Other options are possible.


Last paragraph is missing reference to ANNOTATE.


In section 2:

First paragraph, second sentence: use of LPSEARCH as a term after the LVFOL= DER capability seems awkward. Did you mean LVFOLDER?

In section 3:

Description of NO response should include the two new cases described in this section: no backing mailbox and invalid search criteria.

The text in this section is vague when saying that "an error in one of the SEARCH argument values" causes NO response. Invalid search syntax can also cause the BAD response.

In section 5:
 I suggest adding a comment for "psearch" non-terminal sayin= g that search keywords referring to mutable state are not allowed.

In section 6:
 The example that causes the BADBACKING response code is using INBOX a= s the backing mailbox name, not the IMBOX.

In section 7:
 In first paragraph:
>  Modifications to mutable state (flags, annotations) have no effe= ct on whether
>or not messages are included virtual folders,

"included in virtual ..."

> nor do they generate events.

I am not sure what does "generate events" mean in this context. A= nd I am not sure why this requirement is needed.

>If a backing mailbox is deleted, then all vfolders attached to that bac= king mailbox
>as deleted as well.

typo: are deleted as well

What about RENAME of the backing mailbox?

>Changes to UIDVALIDITY, UIDNEXT, and other underlying properties of

Why UIDNEXT change in the backing mailbox should always affect vfolders? If a new message is added to the backing mailbox which doesn't show up in a vfolder, there is no need to change the vfolder's UIDNEXT.

>the backing mailbox are reflected in all attached vfolders.


The section called "IANA Considerations" has nothing to do with I= ANA, as IANA has no registry for reserved IMAP mailbox names.
I also don't like the requirement to restrict allowed vfolder names: everything except INBOX is an implementation/deployment detail.

Section "References" should become "Normative References&quo= t;. Please replace reference to RFC 2234 with RFC 4234. Please delete [P-IMAP] - it is not referenced, at least certainly not in a normative manner.

Delete appendix A, this is a separate document now.


Regards,
Alexey

------=_Part_9423_13723766.1142834427400-- --===============0170617194== 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 --===============0170617194==-- From lemonade-bounces@ietf.org Mon Mar 20 01:02:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLDSr-00006g-4T; Mon, 20 Mar 2006 01:02:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLDSq-00005g-1S for lemonade@ietf.org; Mon, 20 Mar 2006 01:02:00 -0500 Received: from rgminet01.oracle.com ([148.87.113.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLDSp-0003T5-EC for lemonade@ietf.org; Mon, 20 Mar 2006 01:02:00 -0500 Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k2K61v3J018894; Sun, 19 Mar 2006 23:01:57 -0700 Received: from rgmsgw300.us.oracle.com (localhost [127.0.0.1]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2K61vdH005651; Sun, 19 Mar 2006 23:01:57 -0700 Received: from us.oracle.com (dhcp-amer-rmdc-csvpn-gw6-141-144-112-21.vpn.oracle.com [141.144.112.21]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2K61uBg005642 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 19 Mar 2006 23:01:56 -0700 From: "Stephane H. Maes" To: "Alexey Melnikov" , "lemonade@ietf.org" Date: Sun, 19 Mar 2006 22:02:01 -0800 Message-ID: <20060319220201012.00000005420@smaes-lap3> In-Reply-To: <23794f40603192200l54ff46bcq29deda1ecfea489f@mail.gmail.com> X-Mailer: Oracle Connector for Outlook 10.1.2.0.3 71207 (11.0.8010) X-Accept-Language: en-us, en MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Spam-Score: 0.5 (/) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 Cc: Subject: [lemonade] RE: Comments on VFOLDER draft X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "stephane.maes@oracle.com" List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2055684966==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format --===============2055684966== Content-Type: multipart/alternative; boundary=-------a13e4399a13e4399 This is a multi-part message in MIME format ---------a13e4399a13e4399 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Alexey, Thanks Iwill make sure not to drop any of these next time. I real= ize I missed some you made already in the last update. Stephane = _____ Stephane H. Maes, PhD, Director of Architecture, Mobile, Voice, and C= ommunications Platforms, Oracle. Ph: +1-203-300-7786 (mobile/SMS); Fax / Of= fice UM: +1-650-607-6296 e-mail: stephane.maes@oracle.com IM: shmaes (AIM/Y= !/skype) or stephane_maes@hotmail.com (MSN Messenger) or stephane.maes@gmai= l.com (Google) = From: Alexey Melnikov [mailto:aamelnikov@gmail.com] Sent: Sunday, March 19= , 2006 10:00 PM To: lemonade@ietf.org; Stephane Maes Subject: Comments on V= FOLDER draft I've already commented on IMAPEXT list that some text should b= e borrowed from Arnt's VIEW draft, as he seemed to to address some edge cas= es that VFOLDER currently doesn't. Arnt's draft also adds a LIST-EXTENDED e= xtension, so that VIEW-aware clients can distinguish views from real mailbo= xes. I think this might be handy for specialized clients. Detailed comments= on draft-ietf-lemonade-vfolder-00 are below: In section 1, 2nd paragraph, = second sentence: >The search criteria specify the backing mailbox, as well = as a subset IMAP SEARCH ... I don't think that "search criteria" can "speci= fy the backing mailbox". At least the SEARCH search criteria doesn't. Sugge= st some rewording. Also "subset of IMAP" Paragraph 3 in the same section: >= UIDs are preserved, and as well as the UIDVALIDITY value. I am not sure why= this restriction is required. Why enforcing it useful? Paragraph 5: >From = the client's perspective, whether or not a mailbox is a vfolder is not visi= ble, Suggest to use "virtual folder" here. >and for all intents and purpose= s, it appears as any other mailbox name. >This includes the ability for a n= ew virtual folder to be created by using virtual folder >as a backing mailb= ox The last sentence is insufficient. I've suggested that the new search cr= iteria was ANDed with the one from the virtual backing folder, however once= this was done the real mailbox is considered to be the backing one (i.e. c= hanged to the backing virtual folder don't affect the new view). Other opti= ons are possible. Last paragraph is missing reference to ANNOTATE. In secti= on 2: First paragraph, second sentence: use of LPSEARCH as a term after the= LVFOLDER capability seems awkward. Did you mean LVFOLDER? In section 3: De= scription of NO response should include the two new cases described in this= section: no backing mailbox and invalid search criteria. The text in this = section is vague when saying that "an error in one of the SEARCH argument v= alues" causes NO response. Invalid search syntax can also cause the BAD res= ponse. In section 5:I suggest adding a comment for "psearch" non-terminal s= aying that search keywords referring to mutable state are not allowed. In s= ection 6:The example that causes the BADBACKING response code is using INBO= X as the backing mailbox name, not the IMBOX. In section 7:In first paragra= ph: > Modifications to mutable state (flags, annotations) have no effect on= whether >or not messages are included virtual folders, "included in virtua= l ..." > nor do they generate events. I am not sure what does "generate eve= nts" mean in this context. And I am not sure why this requirement is needed= . >If a backing mailbox is deleted, then all vfolders attached to that back= ing mailbox >as deleted as well. typo: are deleted as well What about RENAM= E of the backing mailbox? >Changes to UIDVALIDITY, UIDNEXT, and other under= lying properties of Why UIDNEXT change in the backing mailbox should always= affect vfolders? If a new message is added to the backing mailbox which do= esn't show up in a vfolder, there is no need to change the vfolder's UIDNEX= T. >the backing mailbox are reflected in all attached vfolders. The section= called "IANA Considerations" has nothing to do with IANA, as IANA has no r= egistry for reserved IMAP mailbox names. I also don't like the requirement = to restrict allowed vfolder names: everything except INBOX is an implementa= tion/deployment detail. Section "References" should become "Normative Refer= ences". Please replace reference to RFC 2234 with RFC 4234. Please delete [= P-IMAP] - it is not referenced, at least certainly not in a normative manne= r. Delete appendix A, this is a separate document now. Regards, Alexey ---------a13e4399a13e4399 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable
Alexey,
 
Thanks
 
Iwill make sure not to drop any of these next time= . I = realize I missed some you made already in the last update.
 
Stephane
 

_____
Stephane H. Maes, PhD,
Director of Architectu= re, = Mobile, Voice, and Communications Platforms, Oracle.
Ph: +1-203-300-7786= = (mobile/SMS); Fax / Office UM: +1-650-607-6296
e-mail: = stephane.maes@oracle.com
IM: shmaes (AIM/Y!/skype) or = stephane_maes@hotmail.com (MSN Messenger) or stephane.maes@gmail.com = (Google)
 

 

From: Alexey Melnikov = [mailto:aamelnikov@gmail.com]
Sent: Sunday, March 19, 2006 10:00= = PM
To: lemonade@ietf.org; Stephane Maes
Subject: Commen= ts on = VFOLDER draft

I've already commented on IMAPEXT list that some text should be = = borrowed from Arnt's VIEW draft, as he seemed to to address some edge cases= that = VFOLDER currently doesn't. Arnt's draft also adds a LIST-EXTENDED extension= , so = that VIEW-aware clients can distinguish views from real mailboxes. I think = this = might be handy for specialized clients.

Detailed comments on = draft-ietf-lemonade-vfolder-00 are below:

In section 1, 2nd paragrap= h, = second sentence:

>The search criteria specify the backing mailbox= , as = well as a subset IMAP SEARCH ...

I don't think that "search criteria= " can = "specify the backing mailbox". At least the SEARCH search criteria doesn't.= = Suggest some rewording.

Also "subset of IMAP"


Paragraph 3= in = the same section:
>UIDs are preserved, and as well as the UIDVALIDITY= = value.

I am not sure why this restriction is required. Why enforcing= it = useful?


Paragraph 5:
>From the client's perspective, wheth= er or = not a mailbox is a vfolder is not visible,

Suggest to use "virtual = folder" here.

>and for all intents and purposes, it appears as an= y = other mailbox name.
>This includes the ability for a new virtual fold= er to = be created by using virtual folder
>as a backing mailbox

The l= ast = sentence is insufficient. I've suggested that the new search criteria was A= NDed = with the one from the virtual backing folder, however once this was done th= e = real mailbox is considered to be the backing one (i.e. changed to the backi= ng = virtual folder don't affect the new view). Other options are = possible.


Last paragraph is missing reference to = ANNOTATE.


In section 2:

First paragraph, second sentence:= use = of LPSEARCH as a term after the LVFOLDER capability seems awkward. Did you = mean = LVFOLDER?

In section 3:

Description of NO response should inc= lude = the two new cases described in this section: no backing mailbox and invalid= = search criteria.

The text in this section is vague when saying that = "an = error in one of the SEARCH argument values" causes NO response. Invalid sea= rch = syntax can also cause the BAD response.

In section 5:
 I sug= gest = adding a comment for "psearch" non-terminal saying that search keywords = referring to mutable state are not allowed.

In section 6:
 T= he = example that causes the BADBACKING response code is using INBOX as the back= ing = mailbox name, not the IMBOX.

In section 7:
 In first = paragraph:
>  Modifications to mutable state (flags, annotations= ) = have no effect on whether
>or not messages are included virtual = folders,

"included in virtual ..."

> nor do they generate = = events.

I am not sure what does "generate events" mean in this conte= xt. = And I am not sure why this requirement is needed.

>If a backing = mailbox is deleted, then all vfolders attached to that backing mailbox
&= gt;as = deleted as well.

typo: are deleted as well

What about RENAME = of = the backing mailbox?

>Changes to UIDVALIDITY, UIDNEXT, and other = = underlying properties of

Why UIDNEXT change in the backing mailbox s= hould = always affect vfolders? If a new message is added to the backing mailbox wh= ich = doesn't show up in a vfolder, there is no need to change the vfolder's = UIDNEXT.

>the backing mailbox are reflected in all attached = vfolders.


The section called "IANA Considerations" has nothing t= o do = with IANA, as IANA has no registry for reserved IMAP mailbox names.
I al= so = don't like the requirement to restrict allowed vfolder names: everything ex= cept = INBOX is an implementation/deployment detail.

Section "References" s= hould = become "Normative References". Please replace reference to RFC 2234 with RF= C = 4234. Please delete [P-IMAP] - it is not referenced, at least certainly not= in a = normative manner.

Delete appendix A, this is a separate document = now.


Regards,
Alexey

---------a13e4399a13e4399-- --===============2055684966== 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 --===============2055684966==-- From lemonade-bounces@ietf.org Mon Mar 20 11:49:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLNZh-0003h7-PJ; Mon, 20 Mar 2006 11:49:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLNZg-0003gx-Db for lemonade@ietf.org; Mon, 20 Mar 2006 11:49:44 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLNZf-0001C0-3R for lemonade@ietf.org; Mon, 20 Mar 2006 11:49:44 -0500 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2KGneN22431 for ; Mon, 20 Mar 2006 11:49:40 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 20 Mar 2006 11:49:34 -0500 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D091F4B60@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda slides Thread-Index: AcZMPkRkfa7pF0JlQEKo3GPRJqCwSw== From: "Glenn Parsons" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Subject: [lemonade] Agenda slides X-BeenThere: lemonade@ietf.org X-Mailman-Version: 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="===============0516067493==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============0516067493== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64C3E.44CD9FCB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C64C3E.44CD9FCB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, An updated agenda .. Including the chairs slides (as soon as they are converted to PDF :-) are available here... http://tools.ietf.org/wg/lemonade/agenda And hopefully before the meeting on the supplemental site... Glenn. ------_=_NextPart_001_01C64C3E.44CD9FCB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agenda slides

Folks,

An updated agenda .. Including the = chairs slides (as soon as they are converted to PDF :-) are available = here…

http://tools.ietf.org/wg/lemonade/agenda

And hopefully before the meeting on the = supplemental site…

Glenn.


------_=_NextPart_001_01C64C3E.44CD9FCB-- --===============0516067493== 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 --===============0516067493==-- From lemonade-bounces@ietf.org Mon Mar 20 14:08:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLPjr-0003Qs-7J; Mon, 20 Mar 2006 14:08:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLPjq-0003Qn-75 for lemonade@ietf.org; Mon, 20 Mar 2006 14:08:22 -0500 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLPjm-0006gQ-Vi for lemonade@ietf.org; Mon, 20 Mar 2006 14:08:22 -0500 X-IronPort-AV: i="4.03,111,1141621200"; d="scan'208"; a="30312083:sNHT27346600" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Mar 2006 14:08:14 -0500 Message-ID: <330A23D8336C0346B5C1A5BB196666470276B0BA@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Slides Thread-Index: AcZMUaNxcA/Cf7jIRhSG1PGtEprAuA== From: "Burger, Eric" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [lemonade] Slides X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org The slides and agenda for the meeting are posted to the IETF meeting materials site. https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=3D6= 5 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Mar 20 17:14:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLSe8-0004rz-8V; Mon, 20 Mar 2006 17:14:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLSe7-0004ru-5N for lemonade@ietf.org; Mon, 20 Mar 2006 17:14:39 -0500 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLSe3-0006My-QB for lemonade@ietf.org; Mon, 20 Mar 2006 17:14:39 -0500 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M0A2Q9ZV5C00007A@mauve.mrochek.com> for lemonade@ietf.org; Mon, 20 Mar 2006 14:14:34 -0800 (PST) To: Stephane H Maes Message-id: <01M0A49JZ3AO00007A@mauve.mrochek.com> Date: Mon, 20 Mar 2006 14:07:34 -0800 (PST) From: Ned Freed Subject: RE: [lemonade] compression In-reply-to: "Your message dated Sun, 19 Mar 2006 19:43:18 -0800" <20060319194318805.00000005420@smaes-lap3> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <01M08ORTJGOI000078@mauve.mrochek.com> <20060319194318805.00000005420@smaes-lap3> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: lemonadeietforg X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > It seems that a premise is that the server should decide. No, the argument is that the server is in a better position to decide. > Interesting different point of view from other cases. > I actually believe that the client should be able to decide when it decides > to download something if it wants it have it compressed and how. It needs to be > able to selectively select when to compresst. You're a long way from making a case for this. > Indeed, selective compression provides significant gains (e.g. attachemnt to > compress). It may offer some CPU gain. I doubt it offers much besides that. > In addition, factors outside the protocol consideration or the server > knowledge come into play (like battery state (i.e. is it ok to spend energy > decompressing versus getting more data but not having to decompress, user > decision (cost vs battery life etc...). If decompression is problematic why enable compression in the first place? > Eventually as was discussed in Beijing, TSL compression is not yet easy to > support or expected to be supported on most mobile phones. Even if true - there are other very compelling reasons for getting TLS support in place - this says nothing about the c=d proposal. > So my view is that 1) we need to allow application level selective > compression 2) we need to let the client decide 3) it is useful in terms of >bandwidth and in terms of battery life to offer this option 40 ... I think all of these points have been refuted. > I have no problem also allowing TLS compression, but in Beijing, the WG > rather decided against it... Excuse ME, but the WG decided no such thing. IETF decisions are made on the list, not at meetings, and especially not at interim meetings. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Mar 20 17:39:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLT22-0000NI-Ku; Mon, 20 Mar 2006 17:39:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLT21-0000ND-Dq for lemonade@ietf.org; Mon, 20 Mar 2006 17:39:21 -0500 Received: from igw2.watson.ibm.com ([129.34.20.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLT20-0007LG-5c for lemonade@ietf.org; Mon, 20 Mar 2006 17:39:21 -0500 Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [129.34.20.40]) by igw2.watson.ibm.com (8.12.11/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id k2KMdYNW013323 for ; Mon, 20 Mar 2006 17:39:35 -0500 Received: from sp1n294en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id k2KMdIx278022 for ; Mon, 20 Mar 2006 17:39:18 -0500 Received: from mars (mars.watson.ibm.com [9.2.40.64]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id k2KMdIG257978 for ; Mon, 20 Mar 2006 17:39:18 -0500 Received: from sig-9-65-82-49.mts.ibm.com ([9.65.82.49]) by mars.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1142894358.2903; Mon, 20 Mar 2006 17:39:18 -0400 Date: Mon, 20 Mar 2006 17:39:17 -0500 From: Barry Leiba To: lemonade@ietf.org Message-ID: <5F8F0998845D2176E2CBFEC8@saturn.watson.ibm.com> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [lemonade] VFolder and IMAP extended LIST command X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Cyrus brought up a question of whether it could be damaging (or resource-wasting, or user-confusing) to have vfolders appear as "regular" folders in a normal IMAP LIST. This could cause unaware clients to download messages multiple times, to present duplicate (and confusing) views/folders to users, and so on. One way to address this -- probably the best way, as the discussion came to -- is to return vfolders only when requested explicitly, by an extended LIST command (as defined in the list extensions draft from the imapext group). Eric and Greg aren't sure that's the right thing. I'll let them state their concerns here, but at least one balance is resources on a "fat client" versus extra bytes sent and received by a mobile client (the command and the response are each longer for extended LIST than for a regular LIST). This post is to start a discussion on this. Barry -- Barry Leiba, Pervasive Computing Technology (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Mar 20 17:43:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLT61-0001TE-Qa; Mon, 20 Mar 2006 17:43:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLT61-0001T9-IV for lemonade@ietf.org; Mon, 20 Mar 2006 17:43:29 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLT60-0007TC-7o for lemonade@ietf.org; Mon, 20 Mar 2006 17:43:29 -0500 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k2KMhKex024724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 20 Mar 2006 14:43:21 -0800 Received: from [192.168.1.13] (vpn-10-50-0-108.qualcomm.com [10.50.0.108]) by crowley.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k2KMhGjZ006960; Mon, 20 Mar 2006 14:43:18 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <88E9D17A99A345439825C94B1DA393E31F8356@il-tlv-mail01.comverse.com> References: <88E9D17A99A345439825C94B1DA393E31F8356@il-tlv-mail01.comverse.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Mon, 20 Mar 2006 14:42:49 -0800 To: "Weingarten Jerry" , From: Randall Gellens Subject: Re: [lemonade] draft-ietf-lemonade-vfolder Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 1.1 (+) X-Scan-Signature: 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 4:45 PM +0200 3/16/06, Weingarten Jerry wrote: > Also the first example in section 6 uses as the psearch string - > (INBOX HEADER "Sender" "lemonade-bounces") what header field is > this searching or is it searching the entire message header for > either of the two strings? What is the meaning of multiple search > strings - is it "OR" or "AND"? Hi Jerry, This is in RFC 3501, the IMAP specification. HEADER is a search key that looks for the second string in the header whose name is the first string. Note that it does a case-insensitive substring match. Per RFC 3501, if multiple keys are entered the match is on all of them (AND). -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Premature optimization is the root of all evil --C. A. R. Hoare _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Mar 20 17:59:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLTLx-0003SC-8G; Mon, 20 Mar 2006 17:59:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLTLn-00039B-Rd for lemonade@ietf.org; Mon, 20 Mar 2006 17:59:47 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLTFj-0007h4-5p for lemonade@ietf.org; Mon, 20 Mar 2006 17:53:32 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id BB0B24AC1F; Mon, 20 Mar 2006 23:53:29 +0100 (CET) Message-Id: Date: Tue, 21 Mar 2006 00:05:21 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] VFolder and IMAP extended LIST command References: <5F8F0998845D2176E2CBFEC8@saturn.watson.ibm.com> In-Reply-To: <5F8F0998845D2176E2CBFEC8@saturn.watson.ibm.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Barry Leiba X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Barry Leiba writes: > Cyrus brought up a question of whether it could be damaging (or > resource-wasting, or user-confusing) to have vfolders appear as > "regular" folders in a normal IMAP LIST. In my experience, this doesn't happen. People don't do that. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Mar 20 18:24:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLTja-0000qo-Sh; Mon, 20 Mar 2006 18:24:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLTjZ-0000qh-Sg for lemonade@ietf.org; Mon, 20 Mar 2006 18:24:21 -0500 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLTjY-0001Ep-JF for lemonade@ietf.org; Mon, 20 Mar 2006 18:24:21 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1FLTjU-0007Kl-Hv; Mon, 20 Mar 2006 23:24:16 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id A6789498003; Mon, 20 Mar 2006 23:27: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 04943-01; Mon, 20 Mar 2006 23:27:22 +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 0A5D0498002; Mon, 20 Mar 2006 23:27:20 +0000 (GMT) Date: Mon, 20 Mar 2006 23:24:09 +0000 Subject: Re: [lemonade] VFolder and IMAP extended LIST command References: <5F8F0998845D2176E2CBFEC8@saturn.watson.ibm.com> In-Reply-To: MIME-Version: 1.0 Message-Id: <898.1142897050.251792@peirce.dave.cridland.net> From: Dave Cridland To: Arnt Gulbrandsen Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Pythagoras-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: support diverse service enivronments , Barry Leiba , Enhancements X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Mon Mar 20 23:05:21 2006, Arnt Gulbrandsen wrote: > Barry Leiba writes: >> Cyrus brought up a question of whether it could be damaging (or >> resource-wasting, or user-confusing) to have vfolders appear as >> "regular" folders in a normal IMAP LIST. > > In my experience, this doesn't happen. People don't do that. The discussion was really relating to the specific issue that some desktop clients sync all message data in all visible folders, but it mutated to cover the more interesting case of whether mobile clients seeing the same message in multiple folders could be made to know it was the same message. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Mar 20 19:06:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLUON-0001qt-64; Mon, 20 Mar 2006 19:06:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLUOM-0001qh-40 for lemonade@ietf.org; Mon, 20 Mar 2006 19:06:30 -0500 Received: from orthanc.ca ([209.89.70.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLUOK-000318-Fs for lemonade@ietf.org; Mon, 20 Mar 2006 19:06:30 -0500 Received: from [10.8.9.61] ([66.119.182.37]) (authenticated bits=0) by orthanc.ca (8.13.4/8.13.4) with ESMTP id k2L06Nnb041408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Mar 2006 17:06:24 -0700 (MST) (envelope-from lyndon@orthanc.ca) Message-ID: <441F437A.7090808@orthanc.ca> Date: Mon, 20 Mar 2006 16:06:18 -0800 From: Lyndon Nerenberg User-Agent: Thunderbird 1.5 (X11/20060201) MIME-Version: 1.0 To: ietf-imapext@imc.org, lemonade@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on orthanc.ca X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Subject: [lemonade] Splitting Binary X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 food for thought before Wednesdays sessions ... Most (all?) of the issues with Binary seem to be with the append side. I think fetch can be cleaned up with a grammar fix to clarify literal+ interactions, and text explicitly calling out that you can only binary fetch terminals. The big issue I have is with servers that don't support the append side, or do, but only on a subset of mailboxes. I just don't see a clean way for the server to advertise the append-side capability. I'm mulling the idea of splitting the current 'binary' into two new capabilities: 'bfetch' and 'bappend'. This would solve the problem for those servers that can't or won't implement the append side. It still doesn't handle the case where some mailboxes can handle bappend, but others can't. My feeling here is that since the server now has the option of punting on bappend, if it *does* advertise the capability it *must* deal with it on *all* mailboxes. Since bappend is an optimization for the client, I feel it's incumbent on the server to do whatever is necessary to actually optimize things for the client. Requiring the client to probe for validity is a non-starter in my books. And it was always my intent in binary that servers would go out of the way to make bappend work everywhere if it worked at all; the new behaviour would make that a requirement. I realize this is out of scope for both the WGs, but if we're starting anew there's a better chance of being able to tailor things to meet some of the requirements the Lemonade folks have been talking about. --lyndon _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Mar 20 19:37:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLUsp-0004pU-CZ; Mon, 20 Mar 2006 19:37:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLUsn-0004o3-PG for lemonade@ietf.org; Mon, 20 Mar 2006 19:37:57 -0500 Received: from out4.smtp.messagingengine.com ([66.111.4.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLUsm-0004VT-G5 for lemonade@ietf.org; Mon, 20 Mar 2006 19:37:57 -0500 Received: from frontend1.internal (mysql-sessions.internal [10.202.2.149]) by frontend1.messagingengine.com (Postfix) with ESMTP id E3F44D41746; Mon, 20 Mar 2006 19:37:54 -0500 (EST) Received: from frontend3.messagingengine.com ([10.202.2.152]) by frontend1.internal (MEProxy); Mon, 20 Mar 2006 19:37:54 -0500 X-Sasl-enc: 9fCNYnWqlVLzy0SgGIkdpLVViMoSpyjOTIiASt1MpSwo 1142901468 Received: from dhcp-wireless-131-69.ietf65.org (DHCP-Wireless-131-69.ietf65.org [130.129.131.69]) by www.fastmail.fm (Postfix) with ESMTP id EA89C74D; Mon, 20 Mar 2006 19:37:46 -0500 (EST) Date: Mon, 20 Mar 2006 18:37:52 -0600 From: Cyrus Daboo To: Lyndon Nerenberg , ietf-imapext@imc.org, lemonade@ietf.org Message-ID: <7BE23F3289CF7AC50D5DB896@dhcp-wireless-131-69.ietf65.org> In-Reply-To: <441F437A.7090808@orthanc.ca> References: <441F437A.7090808@orthanc.ca> X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [lemonade] Re: Splitting Binary X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 Lyndon, --On March 20, 2006 4:06:18 PM -0800 Lyndon Nerenberg wrote: > The big issue I have is with servers that don't support the append side, > or do, but only on a subset of mailboxes. I just don't see a clean way > for the server to advertise the append-side capability. Of course per-mailbox capabilities could be advertised via ANNOTATEMORE. That is something that we could formalize: e.g. for an extension that may be offered on a per-mailbox bases, a server that advertises 'FOOBAR' in the CAPABILITY response always supports the foobar extension on all mailboxes. Whereas if the server advertises 'OPTIONAL-FOOBAR' then it only supports foobar on a per-mailbox basis. In that case a new /capability annotation on mailboxes supporting foobar would list 'FOOBAR' as one of the capabilities - or its part of LISTEXT. This use of the 'OPTIONAL-' capability prefix can be used as a generalized way to handle cases like this. I don't know whether there is a benefit to separating these two cases like this... -- Cyrus Daboo _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Mar 20 20:11:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLVPi-0007vv-SR; Mon, 20 Mar 2006 20:11:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLVPh-0007vT-KC for lemonade@ietf.org; Mon, 20 Mar 2006 20:11:57 -0500 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLVPg-00065O-CI for lemonade@ietf.org; Mon, 20 Mar 2006 20:11:57 -0500 X-IronPort-AV: i="4.03,112,1141621200"; d="scan'208"; a="30325039:sNHT40857724" 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] VFolder and IMAP extended LIST command Date: Mon, 20 Mar 2006 20:11:53 -0500 Message-ID: <330A23D8336C0346B5C1A5BB19666647027B039A@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] VFolder and IMAP extended LIST command Thread-Index: AcZMdbi7M7i5GXMnRTaBSQ8eBnME9AADf2Pw From: "Burger, Eric" To: "Barry Leiba" X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 By the end of the meeting, I was convinced of why we cannot just ignore the problem. My question for the list is: "Do we need a mechanism to uniquely identify messages, so I don't have to fetch or store copies of something I already have?" In the meeting, we offered IMAP URL's. Other alternatives are GOID (Global Object ID [figment of my imagination]), a good hash, an opaque token, etc. Fundamental question: is this important? -----Original Message----- From: Dave Cridland [mailto:dave@cridland.net]=20 Sent: Monday, March 20, 2006 6:24 PM To: Arnt Gulbrandsen Cc: support diverse service enivronments; Barry Leiba; Enhancements Subject: Re: [lemonade] VFolder and IMAP extended LIST command On Mon Mar 20 23:05:21 2006, Arnt Gulbrandsen wrote: > Barry Leiba writes: >> Cyrus brought up a question of whether it could be damaging (or=20 >> resource-wasting, or user-confusing) to have vfolders appear as=20 >> "regular" folders in a normal IMAP LIST. >=20 > In my experience, this doesn't happen. People don't do that. The discussion was really relating to the specific issue that some=20 desktop clients sync all message data in all visible folders, but it=20 mutated to cover the more interesting case of whether mobile clients=20 seeing the same message in multiple folders could be made to know it=20 was the same message. Dave. --=20 You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Mar 20 23:49:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLYof-0003Lw-FU; Mon, 20 Mar 2006 23:49:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLYoe-0003Jz-2z for lemonade@ietf.org; Mon, 20 Mar 2006 23:49:56 -0500 Received: from orthanc.ca ([209.89.70.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLYoc-0004gh-NQ for lemonade@ietf.org; Mon, 20 Mar 2006 23:49:56 -0500 Received: from [192.168.15.2] (d154-5-28-131.bchsia.telus.net [154.5.28.131]) (authenticated bits=0) by orthanc.ca (8.13.4/8.13.4) with ESMTP id k2L4nm4J045693; Mon, 20 Mar 2006 21:49:49 -0700 (MST) (envelope-from lyndon@orthanc.ca) In-Reply-To: <7BE23F3289CF7AC50D5DB896@dhcp-wireless-131-69.ietf65.org> References: <441F437A.7090808@orthanc.ca> <7BE23F3289CF7AC50D5DB896@dhcp-wireless-131-69.ietf65.org> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lyndon Nerenberg Date: Mon, 20 Mar 2006 20:49:46 -0800 To: Cyrus Daboo X-Mailer: Apple Mail (2.746.3) X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on orthanc.ca X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: ietf-imapext@imc.org, lemonade@ietf.org Subject: [lemonade] Re: Splitting Binary X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > Of course per-mailbox capabilities could be advertised via > ANNOTATEMORE. That is something that we could formalize: But what do you do when the server doesn't support annotatemore? The problem is still there. --lyndon _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Mar 21 03:45:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLcUW-0004pz-SH; Tue, 21 Mar 2006 03:45:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLcUV-0004pu-Lb for lemonade@ietf.org; Tue, 21 Mar 2006 03:45:23 -0500 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLcUU-0004cV-8m for lemonade@ietf.org; Tue, 21 Mar 2006 03:45:23 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.34) id 1FLcUS-0006cI-Oc; Tue, 21 Mar 2006 08:45:20 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id E697D498003; Tue, 21 Mar 2006 08:48:33 +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 07174-07; Tue, 21 Mar 2006 08:48: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 AD0B1498002; Tue, 21 Mar 2006 08:48:28 +0000 (GMT) Date: Tue, 21 Mar 2006 08:45:14 +0000 Subject: Re: [lemonade] Splitting Binary References: <441F437A.7090808@orthanc.ca> In-Reply-To: <441F437A.7090808@orthanc.ca> MIME-Version: 1.0 Message-Id: <898.1142930714.941366@peirce.dave.cridland.net> From: Dave Cridland To: Lyndon Nerenberg Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Rutherford-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue Mar 21 00:06:18 2006, Lyndon Nerenberg wrote: > Most (all?) of the issues with Binary seem to be with the append > side. I think fetch can be cleaned up with a grammar fix to clarify > literal+ interactions, and text explicitly calling out that you can > only binary fetch terminals. > > Although issuing a BINARY fetch for a non-terminal is obviously a SHOULD NOT, I don't think it's a MUST NOT, and semantics must be defined. (It's equivalent to a BODY fetch, because the CTE is always an identity one). My reasoning here is that although it's pointless to do a BINARY fetch on a non-terminal directly, some extensions have been proposed that internally perform a binary fetch before performing some other operation. LZIP and LCONVERT are defined like that, I believe. > The big issue I have is with servers that don't support the append > side, or do, but only on a subset of mailboxes. I just don't see a > clean way for the server to advertise the append-side capability. > > I'm mulling the idea of splitting the current 'binary' into two new > capabilities: 'bfetch' and 'bappend'. Or you could make it BINARY (binary fetch supported, may support binary append on some mailboxes) and BAPPEND (binary append supported [including CATENATE?] on all mailboxes). I can't see the case where a server supports upload but not download. For per-mailbox capabilities, I'll just point at Cyrus's message - I've said before we need some standard mechanism for discovering per-mailbox capabilities. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Mar 21 04:01:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLckM-0004vc-NQ; Tue, 21 Mar 2006 04:01:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLckL-0004vX-Th for lemonade@ietf.org; Tue, 21 Mar 2006 04:01:45 -0500 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLckK-0005MT-GM for lemonade@ietf.org; Tue, 21 Mar 2006 04:01:45 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1FLckI-0004H9-8S; Tue, 21 Mar 2006 09:01:42 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 91B2D498003; Tue, 21 Mar 2006 09:04:55 +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 07413-02; Tue, 21 Mar 2006 09:04:47 +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 78881498002; Tue, 21 Mar 2006 09:04:45 +0000 (GMT) Date: Tue, 21 Mar 2006 09:01:31 +0000 Subject: RE: [lemonade] VFolder and IMAP extended LIST command References: <330A23D8336C0346B5C1A5BB19666647027B039A@ATLANTIS.Brooktrout.com> In-Reply-To: <330A23D8336C0346B5C1A5BB19666647027B039A@ATLANTIS.Brooktrout.com> MIME-Version: 1.0 Message-Id: <898.1142931691.608463@peirce.dave.cridland.net> From: Dave Cridland To: "Burger\, Eric" Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Pythagoras-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Enhancements to Internet email to support diverse service enivronments , Barry Leiba X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 Mar 21 01:11:53 2006, Burger, Eric wrote: > By the end of the meeting, I was convinced of why we cannot just > ignore > the problem. My question for the list is: "Do we need a mechanism > to > uniquely identify messages, so I don't have to fetch or store > copies of > something I already have?" > > In the meeting, we offered IMAP URL's. Other alternatives are GOID > (Global Object ID [figment of my imagination]), a good hash, an > opaque > token, etc. > > Fundamental question: is this important? > > Yes. On a high-level overview, a mechanism like this means that clients can detirmine not only the same message appearing in multiple views, but the same message having been moved between mailboxes "out of sight" of the client. But if you solve the problem by some form of identifier tied to the message then we get the interesting case where, given the GOID, we could add facilities to relocate the message - so we could use them as path components in IMAP URLs, perhaps. Going further, ANNOTATE can be replaced by some kind of dedicated metadata store (like, say, WebDAV if you're trendy, or ACAP if you're not) which itself points to the message via these identifiers. In principle, message-id fields could be used, but I don't know what the likelyhood of duplicate message-ids is in the wild. If we can use them to solve the problem in the majority of cases, that would have my vote. I was going to look into this (and content-id clashing, too) at some point, so I'll try to do this before Wednesday if there's interest. To summarise, solving this problem correctly can quite easily yield gains in other areas. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Mar 21 04:54:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLdZT-0007Dh-GY; Tue, 21 Mar 2006 04:54:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLdZS-0007DN-8C for lemonade@ietf.org; Tue, 21 Mar 2006 04:54:34 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLdJt-00075e-Cb for lemonade@ietf.org; Tue, 21 Mar 2006 04:38:30 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id E6E434AC1B; Tue, 21 Mar 2006 10:38:25 +0100 (CET) Message-Id: Date: Tue, 21 Mar 2006 10:50:19 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] VFolder and IMAP extended LIST command References: <5F8F0998845D2176E2CBFEC8@saturn.watson.ibm.com> <898.1142897050.251792@peirce.dave.cridland.net> In-Reply-To: <898.1142897050.251792@peirce.dave.cridland.net> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Barry Leiba X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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: > The discussion was really relating to the specific issue that some > desktop clients sync all message data in all visible folders, ... If that's common, I suspect mrc could say something interesting about it. His server reports a vast number of mailboxes - every file in my home directory or its subdirectories is reported as a mail message. 8421 "mailboxes" containing hundreds of thousand of "messages". Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Mar 21 04:55:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLdZt-0007LB-Jg; Tue, 21 Mar 2006 04:55:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLdZ1-00079a-9D for lemonade@ietf.org; Tue, 21 Mar 2006 04:54:07 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLdLi-0007Cm-Vm for lemonade@ietf.org; Tue, 21 Mar 2006 04:40:24 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 0F81E4AC1B; Tue, 21 Mar 2006 10:40:22 +0100 (CET) Message-Id: Date: Tue, 21 Mar 2006 10:52:16 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] VFolder and IMAP extended LIST command References: <330A23D8336C0346B5C1A5BB19666647027B039A@ATLANTIS.Brooktrout.com> In-Reply-To: <330A23D8336C0346B5C1A5BB19666647027B039A@ATLANTIS.Brooktrout.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Barry Leiba , Eric Burger X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Eric Burger writes: > By the end of the meeting, I was convinced of why we cannot just > ignore the problem. My question for the list is: "Do we need a > mechanism to uniquely identify messages, so I don't have to fetch or > store copies of something I already have?" > > In the meeting, we offered IMAP URL's. Other alternatives are GOID > (Global Object ID [figment of my imagination]), a good hash, an > opaque token, etc. > > Fundamental question: is this important? I think not. But if it can be done easily and without mandatory bandwidth cost, it may be worthwhile. I'd favour a hash as a FETCH item. "UID FETCH 1234567 SHA256". Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Mar 21 05:05:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLdkS-0004ov-61; Tue, 21 Mar 2006 05:05:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLdkQ-0004oe-Nf for lemonade@ietf.org; Tue, 21 Mar 2006 05:05:54 -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 1FLdTR-0007LD-3j for lemonade@ietf.org; Tue, 21 Mar 2006 04:48:21 -0500 Received: from smtp-out.sendmail.com ([209.246.26.45]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FLdDm-0007uC-2i for lemonade@ietf.org; Tue, 21 Mar 2006 04:32:11 -0500 Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.8beta/Switch-3.1.7) with ESMTP id k2L9Vtgr011745 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 21 Mar 2006 01:31:55 -0800 X-DKIM: Sendmail DKIM Filter v0.2.1 foon.sendmail.com k2L9Vtgr011745 DKIM-Signature: a=rsa-sha1; c=nowsp/nowsp; d=sendmail.com; s=tls.dkim; t=1142933516; h=X-DomainKeys:DomainKey-Signature:Received: Message-Id:To:Cc:From:Subject:In-reply-to:References:Date:Sender; b=Z RzRCyJ6MkeR5G9cVCAx4TVHhUJ7VHOV5IFR4t/IEh4k941Kf626tapXoUamnxSgnH+f 2lLHEssrAIbTJCxVj8IyPVB9YUb1ogclGzXfMvJtiqfQfTQOB3wtHP6dRD7X6xd0Rwj STA3S872YhZObLA0RI3LXLlWWKP1QJJLVGM8= X-DomainKeys: Sendmail DomainKeys Filter v0.3.2 foon.sendmail.com k2L9Vtgr011745 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=received:message-id:to:cc:from:subject:in-reply-to: references:date:sender; b=jNVeR8F+XZaMhKUbvlRueAlirJ4GgftHarE6QLg5vWx7CdZZLZMzATXONF+j7rE/y qkL8+5jU7N8Zi0V7yA4hblkL0drXU/tWRQ9vhxCXfVoXF0zkOFLY1Ud5YOcaN8nUr9J DAsCOjdD0cuRFRbnTjzr0+QHvlZPreyWvaMUKdo= Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.13.3/8.13.3) with ESMTP id k2L9Vt8J009971; Tue, 21 Mar 2006 01:31:55 -0800 (PST) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200603210931.k2L9Vt8J009971@lab.smi.sendmail.com> To: Dave Cridland From: Philip Guenther Subject: Re: [lemonade] VFolder and IMAP extended LIST command In-reply-to: <898.1142931691.608463@peirce.dave.cridland.net> References: <330A23D8336C0346B5C1A5BB19666647027B039A@ATLANTIS.Brooktrout.com> <898.1142931691.608463@peirce.dave.cridland.net> Date: Tue, 21 Mar 2006 01:31:55 -0800 X-Spam-Score: -0.4 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dave Cridland writes: ... >But if you solve the problem by some form of identifier tied to the >message then we get the interesting case where, given the GOID, we >could add facilities to relocate the message - so we could use them >as path components in IMAP URLs, perhaps. > >Going further, ANNOTATE can be replaced by some kind of dedicated >metadata store (like, say, WebDAV if you're trendy, or ACAP if you're >not) which itself points to the message via these identifiers. A protocol exists where containers hold mappings from name to unique ID, which may appear in multiple containers, and all actual data access is by unique ID. It's called NFS. (Or at least NFSv2 and v3 are like that. I haven't followed NFSv4.) >In principle, message-id fields could be used, but I don't know what >the likelyhood of duplicate message-ids is in the wild. The major problem with message-ids can be seen with this very message. You will receive two copies of this message, one direct and one via the list. They have different headers, at a minimum, and I believe the latter will have its body altered as well. Philip Guenther _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Mar 21 05:50:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLeRl-0000O5-3L; Tue, 21 Mar 2006 05:50:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLeRj-0000Nf-Ew for lemonade@ietf.org; Tue, 21 Mar 2006 05:50:39 -0500 Received: from smtp-out.sendmail.com ([209.246.26.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLeRi-0001pe-2j for lemonade@ietf.org; Tue, 21 Mar 2006 05:50:39 -0500 Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.8beta/Switch-3.1.7) with ESMTP id k2LAoZF9028516 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Tue, 21 Mar 2006 02:50:36 -0800 X-DKIM: Sendmail DKIM Filter v0.2.1 foon.sendmail.com k2LAoZF9028516 DKIM-Signature: a=rsa-sha1; c=nowsp/nowsp; d=sendmail.com; s=tls.dkim; t=1142938236; h=X-DomainKeys:DomainKey-Signature:Received: Message-Id:From:To:Subject:In-reply-to:References:Date:Sender; b=tH Ysj0f60kSu5bKtPZmNDvBdzKAaSSKDjEgwdSawKh0aps6T8I6Ekxszw67Gh8F8Srwne +WlKxMspVhUtZGP5FEBHLjdyu0zuDtob+qL2tELZxRRK+xb42RKri+gu2Psh7UEOMY1 v9mvFpal+c/GVPrz1Ya5iN+pjJ3NGTsFwNc= X-DomainKeys: Sendmail DomainKeys Filter v0.3.2 foon.sendmail.com k2LAoZF9028516 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=received:message-id:from:to:subject:in-reply-to:references:date:sender; b=ix3LKLXLccPNXn8L6MiLLbJki3l4B00LCd8PHZlxDpJh7UZlHEmXghvF/VJiFt8oW fEjdFTb0sv/DwptMUjQHforvExxaV6bbbtg6IVuv5hqozKOK+KmivCuf3773B5wG+67 zbgkRdnwq09xdeyHUxnat7xecbaV5C0a2hYAwjI= Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.13.3/8.13.3) with ESMTP id k2LAoZEu015529 for ; Tue, 21 Mar 2006 02:50:35 -0800 (PST) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200603211050.k2LAoZEu015529@lab.smi.sendmail.com> From: Philip Guenther To: Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] VFolder and IMAP extended LIST command In-reply-to: <200603210931.k2L9Vt8J009971@lab.smi.sendmail.com> References: <330A23D8336C0346B5C1A5BB19666647027B039A@ATLANTIS.Brooktrout.com> <898.1142931691.608463@peirce.dave.cridland.net> <200603210931.k2L9Vt8J009971@lab.smi.sendmail.com> Date: Tue, 21 Mar 2006 02:50:35 -0800 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Philip Guenther wrote: >A protocol exists where containers hold mappings from name to unique >ID, which may appear in multiple containers, and all actual data >access is by unique ID. It's called NFS. Sorry, I was too opaque by stopping there. I think there are number of parallels and/or warnings we can take from the file-sharing world when considering server-unique IDs for message. To blather some... NFSv[23] use opaque binary blobs as file-handles. Simply put, they are they are returned by directory lookup operations and then passed to most other operations include 'read' and 'write'. (That's an oversimplification; read the RFC or /usr/include/rpcsvc/nfs_prot.x on a UNIX box for the details.) In NFS, access rights are enforced on each object. This mean that just having a file-handle isn't enough: your authenticated ID must be authorized to access the object. This is what lets the access control work in the face of multiple access-paths for a given file-handle. This contrasts to IMAP, where the only standardized access-control is at the level of mailboxes, not messages. Whether you can access a given message _is_ dependent on the access-path. So, for a server to decide whether a request for message with GOID=142857 should be permitted, it has to track the reverse mapping of which mailboxes that message appears in and have an efficient way of tracking the union of rights. That's a _large_ constraint on server implementations. Making the IDs persistent has its own problems. As a protocol, NFS does not guarantee persistence of file-handles past unmount or across server restarts. That contrasts with AppleTalk Filing Protocol (AFP), which has always(?) supported persistent IDs and used them for various things. The result of that decision has been to make basically impossible implementing a portable and _correct_ AFP server that shares files from an existing filesystem. Some fairly good implementations exist, but I believe the all fudge the persistence aspect in some way. Again, supporting the particular requirement (persistent IDs) places a large constraint on the backend. Anyway, I've now swung from too succinct to blathering. My point is that this is heading into parts of the design space that are both (partially) mapped and treacherous. Philip Guenther _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Mar 21 05:52:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLeTq-0003I2-Mz; Tue, 21 Mar 2006 05:52:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLeTp-0003Hx-1K for lemonade@ietf.org; Tue, 21 Mar 2006 05:52:49 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLeTn-0001uj-L2 for lemonade@ietf.org; Tue, 21 Mar 2006 05:52:49 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id A70424AC1B; Tue, 21 Mar 2006 11:52:46 +0100 (CET) Message-Id: Date: Tue, 21 Mar 2006 12:04:41 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Splitting Binary References: <441F437A.7090808@orthanc.ca> <898.1142930714.941366@peirce.dave.cridland.net> In-Reply-To: <898.1142930714.941366@peirce.dave.cridland.net> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Lyndon Nerenberg X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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: > For per-mailbox capabilities, I'll just point at Cyrus's message - > I've said before we need some standard mechanism for discovering > per-mailbox capabilities. RFC 3348 uses LIST for the purpose, and I don't see significant drawbacks to that approach. We now have LISTEXT. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Mar 21 07:28:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLfyI-0006vL-Vd; Tue, 21 Mar 2006 07:28:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLfyH-0006uq-Mz for lemonade@ietf.org; Tue, 21 Mar 2006 07:28:21 -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 1FLeYQ-00022O-Dg for lemonade@ietf.org; Tue, 21 Mar 2006 05:57:34 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FLeJU-0008KH-9U for lemonade@ietf.org; Tue, 21 Mar 2006 05:42:10 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 827034AC1F; Tue, 21 Mar 2006 11:42:06 +0100 (CET) Message-Id: Date: Tue, 21 Mar 2006 11:54:00 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] VFolder and IMAP extended LIST command References: <330A23D8336C0346B5C1A5BB19666647027B039A@ATLANTIS.Brooktrout.com> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Barry Leiba , Eric Burger X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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: > I think not. But if it can be done easily and without mandatory > bandwidth cost, it may be worthwhile. I'd favour a hash as a FETCH > item. "UID FETCH 1234567 SHA256". I should elaborate. While implementing VIEW last autumn, we did some math, and couldn't see justification for this kind of download avoidance. There are many situations where it could help. Mailbox renames is a big one. But these situations just don't happen that often. If an IMAP URL is used, then the URL may easily be 100 characters. Let's say it is, it's such a nice round number, and that the average message (body[header.fields(from to cc subject date)] body[1]) is 5000 bytes. Then fetching the URL in addition brings the total to 5100 bytes. In other words, a 2% extra cost, so the URL has to save more than 2% of message downloads in order to carry its own load. In my opinion, it should save substantially more, or else noone will implement it. A hash is shorter. MD5 takes 20 bytes or so including syntax overhead, so it would pay for its traffic if it eliminates 0.4% of message downloads. Still not a clear win. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Mar 21 08:27:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLgts-0003Cz-0U; Tue, 21 Mar 2006 08:27:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLgtq-0003Cu-Bt for lemonade@ietf.org; Tue, 21 Mar 2006 08:27:50 -0500 Received: from out4.smtp.messagingengine.com ([66.111.4.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLgtp-0007mS-2u for lemonade@ietf.org; Tue, 21 Mar 2006 08:27:50 -0500 Received: from imap6.internal (imap6.internal [10.202.2.137]) by frontend1.messagingengine.com (Postfix) with ESMTP id 097ABD41CDC; Tue, 21 Mar 2006 08:27:47 -0500 (EST) Received: from frontend3.messagingengine.com ([10.202.2.152]) by imap6.internal (MEProxy); Tue, 21 Mar 2006 08:27:39 -0500 X-Sasl-enc: 5vDUr6wPVGSb75VOZOQcDIDlf0zhp9EnVEOKMG2OKKwI 1142947316 Received: from [172.20.101.119] (unknown [12.5.79.2]) by www.fastmail.fm (Postfix) with ESMTP id 565FF8CA; Tue, 21 Mar 2006 08:21:54 -0500 (EST) Date: Tue, 21 Mar 2006 07:22:01 -0600 From: Cyrus Daboo To: Lyndon Nerenberg Message-ID: In-Reply-To: References: <441F437A.7090808@orthanc.ca> <7BE23F3289CF7AC50D5DB896@dhcp-wireless-131-69.ietf65.org> X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ietf-imapext@imc.org, lemonade@ietf.org Subject: [lemonade] Re: Splitting Binary X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 Lyndon, --On March 20, 2006 8:49:46 PM -0800 Lyndon Nerenberg wrote: >> Of course per-mailbox capabilities could be advertised via >> ANNOTATEMORE. That is something that we could formalize: > > But what do you do when the server doesn't support annotatemore? The > problem is still there. At that point the client has to fall back to a 'try it and be prepared for it fail' behaviour. At least it will know to expect that if 'OPTIONAL-FOOBAR' is advertised. -- Cyrus Daboo _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Mar 21 09:05:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLhUR-0005YH-LU; Tue, 21 Mar 2006 09:05:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLhUQ-0005Y3-Aj for lemonade@ietf.org; Tue, 21 Mar 2006 09:05:38 -0500 Received: from mxout7.cac.washington.edu ([140.142.32.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLhUP-0000YQ-0A for lemonade@ietf.org; Tue, 21 Mar 2006 09:05:38 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout7.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k2LE5Ywq012753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Mar 2006 06:05:34 -0800 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW06.03) with ESMTP id k2LE5Wtq017324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Mar 2006 06:05:33 -0800 Date: Tue, 21 Mar 2006 06:05:32 -0800 (PST) From: Mark Crispin To: Dave Cridland Subject: Re: [lemonade] Splitting Binary In-Reply-To: <898.1142930714.941366@peirce.dave.cridland.net> Message-ID: References: <441F437A.7090808@orthanc.ca> <898.1142930714.941366@peirce.dave.cridland.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__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: b19722fc8d3865b147c75ae2495625f2 Cc: Enhancements to Internet email to support diverse service enivronments , Lyndon Nerenberg X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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, 21 Mar 2006, Dave Cridland wrote: > Although issuing a BINARY fetch for a non-terminal is obviously a SHOULD NOT, > I don't think it's a MUST NOT, and semantics must be defined. (It's > equivalent to a BODY fetch, because the CTE is always an identity one). My > reasoning here is that although it's pointless to do a BINARY fetch on a > non-terminal directly, some extensions have been proposed that internally > perform a binary fetch before performing some other operation. LZIP and > LCONVERT are defined like that, I believe. I think that this is asking for trouble. The addition of pointless capabilities causes certain individuals to assume, notwithstanding text in the specification to the contrary, that there is a point; what's more, they will infer the point. We don't want to go there on non-terminal fetches. I very reluctantly agreed to relax the restriction on a multipart fetch because there was a point to it (S/MIME handling) but I really don't want to go further down that slippery slope. The problem with adding text to the specification is that people don't read the specification. Just now, I am dealing with someone who doesn't have a clue as to what a literal is, yet is writing a server and asking "why is Outlook not working right" questions. The more that we add unnecessary facilities (and bloat the specification as a result), the less that people will read the specification. -- 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 Mar 21 11:05:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjM4-0002DZ-67; Tue, 21 Mar 2006 11:05:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjM3-0002DU-M5 for lemonade@ietf.org; Tue, 21 Mar 2006 11:05:07 -0500 Received: from agminet01.oracle.com ([141.146.126.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLjM1-0005Wo-BY for lemonade@ietf.org; Tue, 21 Mar 2006 11:05:07 -0500 Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2LG541j014624 for ; Tue, 21 Mar 2006 10:05:04 -0600 Received: from rgmsgw300.us.oracle.com (localhost [127.0.0.1]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2LG53q3011235 for ; Tue, 21 Mar 2006 09:05:04 -0700 Received: from us.oracle.com (dhcp-amer-rmdc-csvpn-gw6-141-144-112-34.vpn.oracle.com [141.144.112.34]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2LG51hq011220 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 21 Mar 2006 09:05:03 -0700 From: "Stephane H. Maes" To: "lemonade@ietf.org" Subject: [Lemonade] pointer to EMN Date: Tue, 21 Mar 2006 08:04:59 -0800 Message-ID: <20060321080459577.00000003536@smaes-lap3> X-Mailer: Oracle Connector for Outlook 10.1.2.0.3 71207 (11.0.8010) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Spam-Score: 0.5 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "stephane.maes@oracle.com" List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Per my action item, MN I slocated at http://www.openmobilealliance.org/rele= ase_program/docs/CopyrightClick.asp?pck=3DEmailNot&file=3DV1_0-20040731-C/O= MA-Push-EMN-v1_0-20040614-C.pdf Stephane _____ Stephane H. Maes, PhD, Director of Architecture, Mobile, Voice, and Communications Platforms, Orac= le. Ph: +1-203-300-7786 (mobile/SMS); Fax / Office UM: +1-650-607-6296 e-mail: stephane.maes@oracle.com IM: shmaes (AIM/Y!/skype) or stephane_maes@hotmail.com (MSN Messenger) or s= tephane.maes@gmail.com (Google) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Mar 21 11:46:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLk0J-0001Z1-Vw; Tue, 21 Mar 2006 11:46:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLk0I-0001Yf-OE for lemonade@ietf.org; Tue, 21 Mar 2006 11:46:42 -0500 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLk0I-0007Cx-EB for lemonade@ietf.org; Tue, 21 Mar 2006 11:46:42 -0500 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k2LGkffT011065 for ; Tue, 21 Mar 2006 10:46:41 -0600 (CST) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 21 Mar 2006 10:46:41 -0600 Message-ID: <54E40201497DF142B06B27255953F7971CB28902@il0015exch007u.ih.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: Enhancements to Internet email to support diverse service enivronments Subject: RE: [lemonade] VFolder and IMAP extended LIST command Date: Tue, 21 Mar 2006 10:46:39 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org In the London joint meeting with OMA, we discussed the requirement to support client-to-client sync. I don't know where in the past few meeting this has gone, if anywhere. However, it seems to play here as well. To restate by example, Imagine that my laptop with a thick client has cached most messsages from the server, including vitual views. My diverses mobile device connects via bluetooth to my laptop and interacts with my email store to grab a copy of the messages received while sitting in this meeting. When I closes the laptop and "go mobile", the mobile client connects via the more expensive and slower pipe to get new messages. Besides being another case where the "desktop" client has a copy of all the vfolders, does this also require the GUID? Greg V. -----Original Message----- From: Philip Guenther [mailto:guenther+lemonade@sendmail.com] Sent: Tuesday, March 21, 2006 5:51 AM To: Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] VFolder and IMAP extended LIST command Philip Guenther wrote: >A protocol exists where containers hold mappings from name to unique >ID, which may appear in multiple containers, and all actual data >access is by unique ID. It's called NFS. Sorry, I was too opaque by stopping there. I think there are number of parallels and/or warnings we can take from the file-sharing world when considering server-unique IDs for message. To blather some... NFSv[23] use opaque binary blobs as file-handles. Simply put, they are they are returned by directory lookup operations and then passed to most other operations include 'read' and 'write'. (That's an oversimplification; read the RFC or /usr/include/rpcsvc/nfs_prot.x on a UNIX box for the details.) In NFS, access rights are enforced on each object. This mean that just having a file-handle isn't enough: your authenticated ID must be authorized to access the object. This is what lets the access control work in the face of multiple access-paths for a given file-handle. This contrasts to IMAP, where the only standardized access-control is at the level of mailboxes, not messages. Whether you can access a given message _is_ dependent on the access-path. So, for a server to decide whether a request for message with GOID=142857 should be permitted, it has to track the reverse mapping of which mailboxes that message appears in and have an efficient way of tracking the union of rights. That's a _large_ constraint on server implementations. Making the IDs persistent has its own problems. As a protocol, NFS does not guarantee persistence of file-handles past unmount or across server restarts. That contrasts with AppleTalk Filing Protocol (AFP), which has always(?) supported persistent IDs and used them for various things. The result of that decision has been to make basically impossible implementing a portable and _correct_ AFP server that shares files from an existing filesystem. Some fairly good implementations exist, but I believe the all fudge the persistence aspect in some way. Again, supporting the particular requirement (persistent IDs) places a large constraint on the backend. Anyway, I've now swung from too succinct to blathering. My point is that this is heading into parts of the design space that are both (partially) mapped and treacherous. Philip Guenther _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Mar 21 14:59:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLn13-0000nP-S2; Tue, 21 Mar 2006 14:59:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLn12-0000nK-4t for lemonade@ietf.org; Tue, 21 Mar 2006 14:59:40 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLn10-0006WD-Oq for lemonade@ietf.org; Tue, 21 Mar 2006 14:59:40 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 99B4C4AC28; Tue, 21 Mar 2006 20:59:35 +0100 (CET) Message-Id: Date: Tue, 21 Mar 2006 21:11:32 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] VFolder and IMAP extended LIST command References: <54E40201497DF142B06B27255953F7971CB28902@il0015exch007u.ih.lucent.com> In-Reply-To: <54E40201497DF142B06B27255953F7971CB28902@il0015exch007u.ih.lucent.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: gregv@lucent.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 The easiest way to do this (which even works perfectly with plain IMAP servers) is if both clients record the UIDVALIDITY of each mailbox and the UID of each message. Then it all works. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Mar 21 17:17:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLpAS-0002ed-8a; Tue, 21 Mar 2006 17:17:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLpAQ-0002eC-Pq for lemonade@ietf.org; Tue, 21 Mar 2006 17:17:30 -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 1FLoID-0003TT-5o for lemonade@ietf.org; Tue, 21 Mar 2006 16:21:29 -0500 Received: from smtp-out.sendmail.com ([209.246.26.45]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FLoA4-0004gl-Q7 for lemonade@ietf.org; Tue, 21 Mar 2006 16:13:07 -0500 Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.8beta/Switch-3.1.7) with ESMTP id k2LLD26Y015187 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Tue, 21 Mar 2006 13:13:02 -0800 X-DKIM: Sendmail DKIM Filter v0.2.1 foon.sendmail.com k2LLD26Y015187 DKIM-Signature: a=rsa-sha1; c=nowsp/nowsp; d=sendmail.com; s=tls.dkim; t=1142975583; h=X-DomainKeys:DomainKey-Signature:Received: Message-Id:To:From:Subject:Date:Sender; b=Gmc2vAI7rj4W6Uo3xcHR8zz50 Fn4+2W/TTWXCDbHtMjFJYBnXrWCU9YxXvvtc3KrYottxit23Hfx7HvFyQyF0ScIHDdY FKoIrorcAyG1Vb97LsxtA8mkQoX3DxE/CegxnOyjvJJazWXrqvkix314yof/19AxNlK F9YPz9U8ZBYE= X-DomainKeys: Sendmail DomainKeys Filter v0.3.2 foon.sendmail.com k2LLD26Y015187 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=received:message-id:to:from:subject:date:sender; b=qXxduLzx91WMuQ5jVDDJTEwayLqGwrCJHjSZ9BqfjBTDPVHsNaTenDRLW6oX9D8nT 5TW2Z9N2UaMDUUV7houzD8H2zFrRO8IBdxUc3D4l46OupZ7Y1t6XAbGBwsgiVlM8XbM 9WcEm9vVoaKukH/3i/R2JmUAkfd76ng+WJkX55Y= Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.13.3/8.13.3) with ESMTP id k2LLD2pa061505 for ; Tue, 21 Mar 2006 13:13:02 -0800 (PST) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200603212113.k2LLD2pa061505@lab.smi.sendmail.com> To: Lemonade WG From: Philip Guenther Date: Tue, 21 Mar 2006 13:13:02 -0800 X-Spam-Score: -1.5 (-) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [lemonade] other lemonade-vfolder-00 comments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Requiring the VFOLDER to have the same UIDVALIDITY as the underlying folder is a non-starter: it breaks IMAP's guarantee that a change in immutable message data implies a change in at least one of { mailbox name, UIDVALIDITY, UID } and thereby breaks caching. It also breaks the requirement that the UIDVALIDITY for a given mailbox name never get smaller. I think it's also guaranteed that for a given mailbox name and UIDVALIDITY, messages cannot be inserted before the previously advertised UIDNEXT. That would mean that the UIDVALIDITY must change if the criteria of the vfolder is changed to include message that previously were not included. I don't understand the goal of the last sentence of section one. Whether a search criteria is immutable is not just dependent on what properties it considers. In particular, the WITHIN criteria in this doc is *NOT* immutable, even though it doesn't examine any mutable message properties. (It involves a mutable *non-message* property: the current time!) That's a major reason for it being difficult to implement. Please turn off "smart quotes" and just use ascii ' and " Philip Guenther _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Mar 22 04:01:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLzDn-0006gi-81; Wed, 22 Mar 2006 04:01:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLzDm-0006gd-P4 for lemonade@ietf.org; Wed, 22 Mar 2006 04:01:38 -0500 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLzDj-000655-Ev for lemonade@ietf.org; Wed, 22 Mar 2006 04:01:38 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1FLzDh-0006Pa-KB; Wed, 22 Mar 2006 09:01:33 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 512DE498003; Wed, 22 Mar 2006 09:04:57 +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 13260-02; Wed, 22 Mar 2006 09:04:53 +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 EC6FF498002; Wed, 22 Mar 2006 09:04:50 +0000 (GMT) Date: Wed, 22 Mar 2006 09:01:26 +0000 Subject: Re: [lemonade] Splitting Binary References: <441F437A.7090808@orthanc.ca> <898.1142930714.941366@peirce.dave.cridland.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <3374.1143018086.847797@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-Heisenberg-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: support diverse service enivronments , Lyndon Nerenberg , Enhancements X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue Mar 21 14:05:32 2006, Mark Crispin wrote: > We don't want to go there on non-terminal fetches. I very > reluctantly agreed to relax the restriction on a multipart fetch > because there was a point to it (S/MIME handling) but I really > don't want to go further down that slippery slope. I'm not proposing we encourage it in any way, what I'm really angling for is that if another specification builds on BINARY internally, as LZIP and LCONVERT presently do, that these edge cases are better off being documented clearly, otherwise we run the risk of two specifications inadvertantly clashing when they require some kind of behaviour at the point. I'm even okay with the behaviour not being available directly, as long as the nature of what a non-terminal looks like after transformation with BINARY is fully specified. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Mar 22 14:09:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM8iC-0007CL-2A; Wed, 22 Mar 2006 14:09:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM8iB-0007CG-79 for lemonade@ietf.org; Wed, 22 Mar 2006 14:09:39 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM8i9-0005ni-U8 for lemonade@ietf.org; Wed, 22 Mar 2006 14:09:39 -0500 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k2MJ9ZpF025033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 22 Mar 2006 11:09:36 -0800 Received: from [204.96.115.196] (vpn-10-50-0-90.qualcomm.com [10.50.0.90]) by crowley.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k2MJ9V6b021478 for ; Wed, 22 Mar 2006 11:09:33 -0800 (PST) Mime-Version: 1.0 Message-Id: X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Wed, 22 Mar 2006 11:07:15 -0800 To: lemonade@ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [lemonade] Profile-Bis: Explicitly Require Submission/587 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I think profile-bis should explicitly state that servers MUST support [message submission] on port 587. Also, Lemonade clients MUST use port 587 by default. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- There are two ways of constructing a software design: One way is to make is so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies." --C. A. R. Hoare _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Mar 22 14:18:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM8qd-0005cv-Fc; Wed, 22 Mar 2006 14:18:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM8qb-0005cg-Hn for lemonade@ietf.org; Wed, 22 Mar 2006 14:18:21 -0500 Received: from mail126.messagelabs.com ([216.82.250.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FM8qa-00069r-7U for lemonade@ietf.org; Wed, 22 Mar 2006 14:18:21 -0500 X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-11.tower-126.messagelabs.com!1143055098!9572961!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 9553 invoked from network); 22 Mar 2006 19:18:18 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-11.tower-126.messagelabs.com with SMTP; 22 Mar 2006 19:18:18 -0000 Received: from [135.70.105.114] (unknown[135.70.105.114](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20060322191817gw1001000ne> (Authid: tony); Wed, 22 Mar 2006 19:18:17 +0000 Message-ID: <4421A2F8.9040806@att.com> Date: Wed, 22 Mar 2006 14:18:16 -0500 From: Tony Hansen User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 CC: lemonade@ietf.org Subject: Re: [lemonade] Profile-Bis: Explicitly Require Submission/587 References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org +2 Randall Gellens wrote: > I think profile-bis should explicitly state that servers MUST support > [message submission] on port 587. Also, Lemonade clients MUST use port > 587 by default. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Mar 22 15:18:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM9n5-00062f-IY; Wed, 22 Mar 2006 15:18:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM9n4-00062a-2X for lemonade@ietf.org; Wed, 22 Mar 2006 15:18:46 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57] helo=zcars04f.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM9n3-0000GC-LY for lemonade@ietf.org; Wed, 22 Mar 2006 15:18:46 -0500 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2MKIhT11732 for ; Wed, 22 Mar 2006 15:18:43 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 22 Mar 2006 15:18:30 -0500 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D092BBF11@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft liaison to OMA Thread-Index: AcZN7clPcjieqXrQR3iTnvpCGb1hSw== From: "Glenn Parsons" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Subject: [lemonade] Draft liaison to OMA X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0298752846==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============0298752846== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64DED.C735F6AD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C64DED.C735F6AD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, As discussed in the meeting today, the draft liaison to OMA is below. Note we will also include a presentation on profile-bis, the draft of which was presented during the meeting today as well: http://www3.ietf.org/proceedings/06mar/slides/lemonade-5.ppt Please provide your comments on both of these by COB Friday March 24th so that we can send this as a liaison to OMA in time for their meeting. Cheers, Glenn. From: IETF LEMONADE Working Group To: OMA MWG MEM Sub Working Group Title: Regarding the LEMONADE Profile=09 Response contact: lemonade@ietf.org Purpose: For Information The LEMONADE working group (WG) would like to thank the OMA Mobile Email Sub Working Group for your latest liaison. We appreciate your response to the questions that we had asked in our previous liaison. We have a specific comment based on your feedback on subsetting the OMA STI parameters for content transformation. For the IMAP CONVERT protocol we propose to specify that HTML to text conversion is the only 'mandatory to implement' in clients and servers. We need a small set to ensure interoperability across a wide variety of devices. The CONVERT protocol can support all STI parameters as optional, and the protocol will support a graceful error condition if a client asks a server for a conversion that is not supported. We would encourage the OMA to further subset the full list of STI parameters to make it realistic for the OMA mobile enabler. As a result, we propose that LEMONADE would not specify the STI list decided by OMA MEM, but that this would be included in the OMA MEM TS. As we have indicated before, the LEMONADE WG is working on a set of extensions to IMAP and ESMTP to support mobile email. This set will be succinctly described in the LEMONADE profile (draft-ietf-lemonade-profile-bis). We understand that the OMA TS will normatively reference the LEMONADE profile for the MEM protocol. In order to help you understand this protocol better, we have attached a presentation to update OMA MEM on the content of the LEMONADE profile.=20 Up-to-date information on LEMONADE Internet-Drafts and RFCs can always be found at http://www.ietf.org/html.charters/lemonade-charter.html with more detail tracked on the supplemental site. Finally, as information, the next meetings of the IETF LEMONADE WG are: * May 31 - IETF LEMONADE 65.5 interim meeting - TBD * Jul 10-14 - IETF 66 plenary - Montreal ------_=_NextPart_001_01C64DED.C735F6AD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft liaison to OMA

Folks,

As discussed in the meeting today, the = draft liaison to OMA is below.

Note we will also include a = presentation on profile-bis, the draft of which was presented during the = meeting today as well:

= http://www3.ietf.org/proceedings/06mar/slides/lemonade-5.p= pt

Please provide your comments on both of = these by COB Friday March 24th so that we can send this as a liaison to = OMA in time for their meeting.

Cheers,
Glenn.



From: IETF LEMONADE Working = Group
To: OMA MWG MEM Sub Working = Group
Title: Regarding the LEMONADE = Profile  
Response contact:  = lemonade@ietf.org
Purpose:  For = Information


The LEMONADE working group (WG) = would like to thank the OMA Mobile Email Sub Working Group for your = latest liaison.

We appreciate your response to = the questions that we had asked in our previous liaison.  We have a = specific comment based on your feedback on subsetting the OMA STI = parameters for content transformation.  For the IMAP CONVERT = protocol we propose to specify that HTML to text conversion is the only = ‘mandatory to implement’ in clients and servers.  We = need a small set to ensure interoperability across a wide variety of = devices.  The CONVERT protocol can support all STI parameters as = optional, and the protocol will support a graceful error condition if a = client asks a server for a conversion that is not supported.  We = would encourage the OMA to further subset the full list of STI = parameters to make it realistic for the OMA mobile enabler.  As a = result, we propose that LEMONADE would not specify the STI list decided = by OMA MEM, but that this would be included in the OMA MEM = TS.

As we have indicated before, the = LEMONADE WG is working on a set of extensions to IMAP and ESMTP to = support mobile email.  This set will be succinctly described in the = LEMONADE profile (draft-ietf-lemonade-profile-bis).  We understand = that the OMA TS will normatively reference the LEMONADE profile for the = MEM protocol.  In order to help you understand this protocol = better, we have attached a presentation to update OMA MEM on the content = of the LEMONADE profile.

Up-to-date information on = LEMONADE Internet-Drafts and RFCs can always be found at http://www.ietf.org/html.charters/lemonade-charter.html with more detail tracked on the = supplemental site.

Finally, as information, the next = meetings of the IETF LEMONADE WG are:

  • May 31 – IETF LEMONADE = 65.5 interim meeting - TBD
  • Jul 10-14 – IETF 66 = plenary - Montreal

------_=_NextPart_001_01C64DED.C735F6AD-- --===============0298752846== 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 --===============0298752846==-- From lemonade-bounces@ietf.org Wed Mar 22 21:52:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMFvt-0007x5-Ie; Wed, 22 Mar 2006 21:52:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMFvs-0007wm-Dh for lemonade@ietf.org; Wed, 22 Mar 2006 21:52:16 -0500 Received: from rwcrmhc13.comcast.net ([216.148.227.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMFvq-0001MK-4O for lemonade@ietf.org; Wed, 22 Mar 2006 21:52:16 -0500 Received: from gawhitelaptop (c-67-162-191-81.hsd1.tx.comcast.net[67.162.191.81]) by comcast.net (rwcrmhc13) with SMTP id <20060323025213m13005r5t9e>; Thu, 23 Mar 2006 02:52:13 +0000 From: "Greg White" To: Date: Wed, 22 Mar 2006 20:52:02 -0600 Message-ID: <00b901c64e24$c376cd90$6401a8c0@gawhitelaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Subject: [lemonade] Future Release a WG item or ind. submission X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi, I just read the jabber logs from today's Lemonade meeting. Clip re: the status of Future Release as a WG item: [11:51:24] slide #32: futuer delivery [11:51:41] --- jr111 has joined [11:51:55] Chris said he user case was interesting but shouldn't = be a wg item [11:52:01] s/he/his/ [11:52:51] ned: this doc is really not in charter; should = have been in vpim; individual contrib so ok I'm not sure I understand what Tony's version of what Ned said means, = but I will point the group to http://www1.ietf.org/mail-archive/web/lemonade/current/msg00568.html , = which contains the minutes for the Interim Meeting in Richardson, TX in June = 2004. At this meeting, it was voted that the document would be a WG item. = Because of this, I changed the name of the draft from draft-vaudreuil-futuredelivery-02.txt to draft-ietf-lemonade-futuredelivery-00.txt at the end of June 2004. This change has been noted in the change log at the end of the draft since = June 2004. So, folks, what is the state of the draft? Thanks, Greg W _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Mar 23 01:38:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMJT0-0007uv-Cf; Thu, 23 Mar 2006 01:38:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMJSz-0007up-HS for lemonade@ietf.org; Thu, 23 Mar 2006 01:38:41 -0500 Received: from mail124.messagelabs.com ([85.158.136.19]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FMJSx-0001sO-To for lemonade@ietf.org; Thu, 23 Mar 2006 01:38:41 -0500 X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-12.tower-124.messagelabs.com!1143095917!8250668!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 23346 invoked from network); 23 Mar 2006 06:38:38 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-12.tower-124.messagelabs.com with SMTP; 23 Mar 2006 06:38:38 -0000 Received: from [135.70.44.84] (unknown[135.70.44.84](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20060323063836gw1001005pe> (Authid: tony); Thu, 23 Mar 2006 06:38:37 +0000 Message-ID: <4422426A.4030603@att.com> Date: Thu, 23 Mar 2006 01:38:34 -0500 From: Tony Hansen User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: lemonade@ietf.org Subject: Re: [lemonade] Future Release a WG item or ind. submission References: <00b901c64e24$c376cd90$6401a8c0@gawhitelaptop> In-Reply-To: <00b901c64e24$c376cd90$6401a8c0@gawhitelaptop> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org time warp reference to something else? You've got me. Tony Hansen tony@att.com Greg White wrote: > Hi, > > I just read the jabber logs from today's Lemonade meeting. Clip re: the > status of Future Release as a WG item: > > [11:51:24] slide #32: futuer delivery > [11:51:41] --- jr111 has joined > [11:51:55] Chris said he user case was interesting but shouldn't be > a wg item > [11:52:01] s/he/his/ > [11:52:51] ned: this doc is really not in charter; should have > been in vpim; individual contrib so ok > > > I'm not sure I understand what Tony's version of what Ned said means, > but I will point the group to > http://www1.ietf.org/mail-archive/web/lemonade/current/msg00568.html > , which contains the minutes for the Interim Meeting in Richardson, > TX in June 2004. At this meeting, it was voted that the document > would be a WG item. Because of this, I changed the name of the draft > from draft-vaudreuil-futuredelivery-02.txt to > draft-ietf-lemonade-futuredelivery-00.txt at the end of June 2004. > This change has been noted in the change log at the end of the draft > since June 2004. > > So, folks, what is the state of the draft? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Mar 23 08:46:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMQ9N-0004YJ-Mx; Thu, 23 Mar 2006 08:46:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM5PF-0005xB-Cv for lemonade@ietf.org; Wed, 22 Mar 2006 10:37:53 -0500 Received: from bes.cs.utk.edu ([160.36.56.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM5PE-00043o-6f for lemonade@ietf.org; Wed, 22 Mar 2006 10:37:53 -0500 Received: from localhost (bes [127.0.0.1]) by bes.cs.utk.edu (Postfix) with ESMTP id C6A6B273B7 for ; Wed, 22 Mar 2006 10:37:51 -0500 (EST) Received: from bes.cs.utk.edu ([127.0.0.1]) by localhost (bes [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10032-08; Wed, 22 Mar 2006 10:37:50 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by bes.cs.utk.edu (Postfix) with ESMTP id 0CFD1273AE; Wed, 22 Mar 2006 10:37:49 -0500 (EST) Message-ID: <44216F4C.3000601@cs.utk.edu> Date: Wed, 22 Mar 2006 10:37:48 -0500 From: Keith Moore User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: lemonade@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-Mailman-Approved-At: Thu, 23 Mar 2006 08:46:53 -0500 Subject: [lemonade] on MTI conversions X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org listening to the discussion on conversions, I question the need for an MTI conversion set. since conversion is an optional feature, I don't see how failure to implement any particular conversion results in degraded interoperability of the protocol. however I do see the need to demonstrate interoperability of the conversion feature so that it can advance along the standards track. so for these purposes I would propose that there be an informal implementor agreement to implement two or three trivial conversions (that require parameters) for the purpose of interop testing. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Mar 23 18:51:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMZaB-0003Hw-A0; Thu, 23 Mar 2006 18:51:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMZZA-0000zz-6q; Thu, 23 Mar 2006 18:50:08 -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 1FMZZA-0004xm-3C; Thu, 23 Mar 2006 18:50:08 -0500 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=oak.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FMZZ4-0007Gh-FX; Thu, 23 Mar 2006 18:50:07 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k2NNo2BX005423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Mar 2006 23:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FMZZ4-0001EP-3U; Thu, 23 Mar 2006 18:50:02 -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, 23 Mar 2006 18:50:02 -0500 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-futuredelivery-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 : SMTP Submission Service Extension for Future Message Release Author(s) : G. White, G. Vaudreuil Filename : draft-ietf-lemonade-futuredelivery-04.txt Pages : 12 Date : 2006-3-23 This memo defines an extension to the SMTP submission protocol for a client to indicate a future time for the message to be released for delivery. This extension permits a client to use server-based storage for a message that should be held in queue until an appointed time in the future. This is useful for clients which do not have local storage or are otherwise unable to release a message for delivery at an appointed time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-futuredelivery-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-futuredelivery-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-futuredelivery-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-3-23165353.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-futuredelivery-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-futuredelivery-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-23165353.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 Mar 23 19:01:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMZkB-0005h0-2o; Thu, 23 Mar 2006 19:01:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMZZw-0002nP-Ph for lemonade@ietf.org; Thu, 23 Mar 2006 18:50:56 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMZZw-00055E-4e for lemonade@ietf.org; Thu, 23 Mar 2006 18:50:56 -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 k2NNorIu004933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 23 Mar 2006 15:50:54 -0800 Received: from [204.96.115.196] (vpn-10-50-0-97.qualcomm.com [10.50.0.97]) by neophyte.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k2NNop6J017570; Thu, 23 Mar 2006 15:50:53 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D092BBF11@zcarhxm0.corp.nortel.com> References: <085091CB2CA14E4B8B163FFC37C84E9D092BBF11@zcarhxm0.corp.nortel.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Thu, 23 Mar 2006 15:50:49 -0800 To: "Glenn Parsons" , From: Randall Gellens Subject: Re: [lemonade] Draft liaison to OMA Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 3:18 PM -0500 3/22/06, Glenn Parsons wrote: > Note we will also include a presentation on profile-bis, the draft > of which was presented during the meeting today as well: > > > http://www3.ietf.org/proceedings/06mar/slides/lemonade-5.ppt > > Please provide your comments on both of these by COB Friday March > 24th so that we can send this as a liaison to OMA in time for their > meeting. I like slides 7 and 8, showing two deployment choices (proprietary world and IETF world), but I'd suggest one more slide (new slide 9), which would be the same as slide 8, except that the IMAP store and the submit server are both lemonade-enabled and hence there is no need for boxes in front. I'd go so far as to call this slide "IETF World", and rename slide 8 something like "IETF World (pre-lemonade)". On slide 9 (MUST implement), maybe replace "ESMTP" with "SMTP/Submit" and add "Message Submission (port 587)". Maybe this is too low-level, so I won't mind if you prefer to leave it out. On slide 10, please delete "push". We don't use that term anymore, since it has misleading connotations and people think it means something very different from what it does. I'd suggest deleting the whole line "The Pull Trio", and maybe the whole slide. Do we still need this slide? This is a long-settled issue and is part of the approved Profile document. On Slide 11, please change "Phase bis" to "Profile Update". We don't actually have phases, so we don't want to say "phase bis", and the term "bis" is not universally understood to mean what we mean here, which is an update. Also on Slide 11, by "All of Profile", do we mean "All of original Profile" or "All of updated Profile"? Also on Slide 11, do we want to mention TLS compression? I thought it was an open issue. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Power corrupts; Powerpoint corrupts absolutely. --Vint Cert _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Mar 23 23:01:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMdUJ-0005Pi-EN; Thu, 23 Mar 2006 23:01:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMdUI-0005PU-GL for lemonade@ietf.org; Thu, 23 Mar 2006 23:01:22 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMdUE-0002BH-1M for lemonade@ietf.org; Thu, 23 Mar 2006 23:01:22 -0500 Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k2O41HQj003925 for ; Thu, 23 Mar 2006 21:01:17 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IWM00K013FPGQ00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for lemonade@ietf.org; Thu, 23 Mar 2006 21:01:17 -0700 (MST) Received: from dhcp-wireless-128-202.ietf65.org ([129.150.21.10]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IWM003JK5U1ST10@mail-amer.sun.com>; Thu, 23 Mar 2006 21:01:17 -0700 (MST) Date: Thu, 23 Mar 2006 22:03:19 -0600 From: Chris Newman Subject: Re: [lemonade] Future Release a WG item or ind. submission In-reply-to: <00b901c64e24$c376cd90$6401a8c0@gawhitelaptop> To: Greg White , lemonade@ietf.org Message-id: <6BB7A015EDB2592F27C60C6B@107.114.96.204.in-addr.arpa> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <00b901c64e24$c376cd90$6401a8c0@gawhitelaptop> X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org The jabber log was slightly out of order. The discussion was about the object-based encryption proposal. - Chris Greg White wrote on 3/22/06 20:52 -0600: > Hi, > > I just read the jabber logs from today's Lemonade meeting. Clip re: the > status of Future Release as a WG item: > > [11:51:24] slide #32: futuer delivery > [11:51:41] --- jr111 has joined > [11:51:55] Chris said he user case was interesting but shouldn't be > a wg item > [11:52:01] s/he/his/ > [11:52:51] ned: this doc is really not in charter; should have > been in vpim; individual contrib so ok > > > I'm not sure I understand what Tony's version of what Ned said means, but I > will point the group to > http://www1.ietf.org/mail-archive/web/lemonade/current/msg00568.html , which > contains the minutes for the Interim Meeting in Richardson, TX in June 2004. > At this meeting, it was voted that the document would be a WG item. Because > of this, I changed the name of the draft from > draft-vaudreuil-futuredelivery-02.txt to > draft-ietf-lemonade-futuredelivery-00.txt at the end of June 2004. This > change has been noted in the change log at the end of the draft since June > 2004. > > So, folks, what is the state of the draft? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Mar 24 01:50:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMg8E-0005O5-0R; Fri, 24 Mar 2006 01:50:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMg8D-0005O0-F6 for lemonade@ietf.org; Fri, 24 Mar 2006 01:50:45 -0500 Received: from mail126.messagelabs.com ([216.82.250.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FMg88-0008My-Ty for lemonade@ietf.org; Fri, 24 Mar 2006 01:50:45 -0500 X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-9.tower-126.messagelabs.com!1143183038!10164228!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 18734 invoked from network); 24 Mar 2006 06:50:38 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-9.tower-126.messagelabs.com with SMTP; 24 Mar 2006 06:50:38 -0000 Received: from [135.70.71.237] (unknown[135.70.71.237](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20060324065037gw100100gpe> (Authid: tony); Fri, 24 Mar 2006 06:50:37 +0000 Message-ID: <442396BA.3070405@att.com> Date: Fri, 24 Mar 2006 01:50:34 -0500 From: Tony Hansen User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Chris Newman Subject: Re: [lemonade] Future Release a WG item or ind. submission References: <00b901c64e24$c376cd90$6401a8c0@gawhitelaptop> <6BB7A015EDB2592F27C60C6B@107.114.96.204.in-addr.arpa> In-Reply-To: <6BB7A015EDB2592F27C60C6B@107.114.96.204.in-addr.arpa> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Sometimes we'll move on to the next slide, but then additional comments will continue to be made on the previous topic. The log doesn't always capture those flip flop situations. Tony Hansen tony@att.com Chris Newman wrote: > The jabber log was slightly out of order. The discussion was about the > object-based encryption proposal. > > - Chris > > Greg White wrote on 3/22/06 20:52 -0600: > >> Hi, >> >> I just read the jabber logs from today's Lemonade meeting. Clip re: the >> status of Future Release as a WG item: >> >> [11:51:24] slide #32: futuer delivery >> [11:51:41] --- jr111 has joined >> [11:51:55] Chris said he user case was interesting but >> shouldn't be >> a wg item >> [11:52:01] s/he/his/ >> [11:52:51] ned: this doc is really not in charter; should >> have >> been in vpim; individual contrib so ok >> >> >> I'm not sure I understand what Tony's version of what Ned said means, >> but I >> will point the group to >> http://www1.ietf.org/mail-archive/web/lemonade/current/msg00568.html , >> which >> contains the minutes for the Interim Meeting in Richardson, TX in June >> 2004. >> At this meeting, it was voted that the document would be a WG item. >> Because >> of this, I changed the name of the draft from >> draft-vaudreuil-futuredelivery-02.txt to >> draft-ietf-lemonade-futuredelivery-00.txt at the end of June 2004. This >> change has been noted in the change log at the end of the draft since >> June >> 2004. >> >> So, folks, what is the state of the draft? > > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Mar 24 09:08:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMmyF-0003Rg-Kg; Fri, 24 Mar 2006 09:08:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMmyE-0003RI-B3 for lemonade@ietf.org; Fri, 24 Mar 2006 09:08:54 -0500 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMmyE-0000rB-1p for lemonade@ietf.org; Fri, 24 Mar 2006 09:08:54 -0500 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k2OE8qFI005939; Fri, 24 Mar 2006 08:08:52 -0600 (CST) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 24 Mar 2006 08:08:52 -0600 Message-ID: <54E40201497DF142B06B27255953F7971CD3EEF5@il0015exch007u.ih.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: Tony Hansen Subject: RE: [lemonade] Future Release a WG item or ind. submission Date: Fri, 24 Mar 2006 08:08:51 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Ned asserted that the document was not part of the charter. I incorrectly agreed, forgetting that we had debated this point and accepted the document as a WG item when we last met in greater Dallas almost two years ago. So, there was discussion in the meeting about whether this was or was not a WG item. It is fair to say the discussion was confused. The current document is the result of incorporating comments received during WG last call. This is document is a WG work item and is now ready for IETF last-call (once the ID clears the publishing queue). Greg V. -----Original Message----- From: Tony Hansen [mailto:tony@att.com] Sent: Friday, March 24, 2006 1:51 AM To: Chris Newman Cc: lemonade@ietf.org Subject: Re: [lemonade] Future Release a WG item or ind. submission Sometimes we'll move on to the next slide, but then additional comments will continue to be made on the previous topic. The log doesn't always capture those flip flop situations. Tony Hansen tony@att.com Chris Newman wrote: > The jabber log was slightly out of order. The discussion was about the > object-based encryption proposal. > > - Chris > > Greg White wrote on 3/22/06 20:52 -0600: > >> Hi, >> >> I just read the jabber logs from today's Lemonade meeting. Clip re: the >> status of Future Release as a WG item: >> >> [11:51:24] slide #32: futuer delivery >> [11:51:41] --- jr111 has joined >> [11:51:55] Chris said he user case was interesting but >> shouldn't be >> a wg item >> [11:52:01] s/he/his/ >> [11:52:51] ned: this doc is really not in charter; should >> have >> been in vpim; individual contrib so ok >> >> >> I'm not sure I understand what Tony's version of what Ned said means, >> but I >> will point the group to >> http://www1.ietf.org/mail-archive/web/lemonade/current/msg00568.html , >> which >> contains the minutes for the Interim Meeting in Richardson, TX in June >> 2004. >> At this meeting, it was voted that the document would be a WG item. >> Because >> of this, I changed the name of the draft from >> draft-vaudreuil-futuredelivery-02.txt to >> draft-ietf-lemonade-futuredelivery-00.txt at the end of June 2004. This >> change has been noted in the change log at the end of the draft since >> June >> 2004. >> >> So, folks, what is the state of the draft? > > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Mar 24 10:33:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMoIR-0008Tp-5x; Fri, 24 Mar 2006 10:33:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMoIQ-0008Nb-3J for lemonade@ietf.org; Fri, 24 Mar 2006 10:33:50 -0500 Received: from rgminet01.oracle.com ([148.87.113.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMoIP-0004ir-PK for lemonade@ietf.org; Fri, 24 Mar 2006 10:33:50 -0500 Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k2OFXldt029487 for ; Fri, 24 Mar 2006 08:33:48 -0700 Received: from rgmsgw300.us.oracle.com (localhost [127.0.0.1]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2OFXlGF006312 for ; Fri, 24 Mar 2006 08:33:47 -0700 Received: from us.oracle.com (dhcp-4op5-4op6-west-144-25-174-12.us.oracle.com [144.25.174.12]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2OFXlkO006306 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 24 Mar 2006 08:33:47 -0700 From: "Stephane H. Maes" To: "lemonade@ietf.org" Subject: RE: [lemonade] Future Release a WG item or ind. submission Date: Fri, 24 Mar 2006 07:33:48 -0800 Message-ID: <20060324073348062.00000001692@smaes-lap3> In-Reply-To: <6BB7A015EDB2592F27C60C6B@107.114.96.204.in-addr.arpa> X-Mailer: Oracle Connector for Outlook 10.1.2.0.3 71207 (11.0.8010) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Spam-Score: 0.5 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "stephane.maes@oracle.com" List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hmm I don't recall a statement that object level encryption would not be wi= thin the charter. This was stated about future delivery... Stephane = _____ Stephane H. Maes, PhD, Director of Architecture, Mobile, Voice, and Communications Platforms, Orac= le. Ph: +1-203-300-7786 (mobile/SMS); Fax / Office UM: +1-650-607-6296 e-mail: stephane.maes@oracle.com IM: shmaes (AIM/Y!/skype) or stephane_maes@hotmail.com (MSN Messenger) or s= tephane.maes@gmail.com (Google) = -----Original Message----- From: Chris Newman [mailto:Chris.Newman@Sun.COM] = Sent: Thursday, March 23, 2006 8:03 PM To: Greg White; lemonade@ietf.org Subject: Re: [lemonade] Future Release a WG item or ind. submission The jabber log was slightly out of order. The discussion was about the obj= ect-based encryption proposal. - Chris Greg White wrote on 3/22/06 20:52 -0600: > Hi, > > I just read the jabber logs from today's Lemonade meeting. Clip re: = > the status of Future Release as a WG item: > > [11:51:24] slide #32: futuer delivery [11:51:41] --- = > jr111 has joined [11:51:55] Chris said he user case was = > interesting but shouldn't be a wg item [11:52:01] s/he/his/ = > [11:52:51] ned: this doc is really not in charter; should = > have been in vpim; individual contrib so ok > > > I'm not sure I understand what Tony's version of what Ned said means, = > but I will point the group to = > http://www1.ietf.org/mail-archive/web/lemonade/current/msg00568.html , = > which contains the minutes for the Interim Meeting in Richardson, TX in J= une 2004. > At this meeting, it was voted that the document would be a WG item. = > Because of this, I changed the name of the draft from = > draft-vaudreuil-futuredelivery-02.txt to = > draft-ietf-lemonade-futuredelivery-00.txt at the end of June 2004. = > This change has been noted in the change log at the end of the draft = > since June 2004. > > So, folks, what is the state of the draft? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Mar 24 10:49:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMoXb-0000CD-VJ; Fri, 24 Mar 2006 10:49:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMoXa-0000BP-Ps for lemonade@ietf.org; Fri, 24 Mar 2006 10:49:30 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57] helo=zcars04f.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMoXZ-0005Oo-He for lemonade@ietf.org; Fri, 24 Mar 2006 10:49:30 -0500 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2OFnQ329357 for ; Fri, 24 Mar 2006 10:49:26 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 24 Mar 2006 10:49:17 -0500 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D0932589C@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed interim - May 31 & June 1 Thread-Index: AcZPWoJR3YteYe+3TWOG3ry4zlxA5w== From: "Glenn Parsons" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Subject: [lemonade] Proposed interim - May 31 & June 1 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2110778012==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============2110778012== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64F5A.86C2479A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C64F5A.86C2479A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, On reviewing various calendars -- we'd like to propose a LEMONADE interim on May 31 & June 1. How are these dates with folks? In the absence of the plethora of offers as we had last time, I will offer to host on the Nortel campus in Ottawa. Cheers, Glenn. ------_=_NextPart_001_01C64F5A.86C2479A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Proposed interim - May 31 & June 1

Folks,

On reviewing various calendars -- we'd = like to propose a LEMONADE interim on May 31 & June 1.

How are these dates with folks?

In the absence of the plethora of = offers as we had last time, I will offer to host on the Nortel campus in = Ottawa.

Cheers,
Glenn.

------_=_NextPart_001_01C64F5A.86C2479A-- --===============2110778012== 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 --===============2110778012==-- From lemonade-bounces@ietf.org Fri Mar 24 12:41:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMqHz-0005m7-Fi; Fri, 24 Mar 2006 12:41:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMqHz-0005m2-4H for lemonade@ietf.org; Fri, 24 Mar 2006 12:41:31 -0500 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMqHx-0003lD-LT for lemonade@ietf.org; Fri, 24 Mar 2006 12:41:30 -0500 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M0FENUS5R4000078@mauve.mrochek.com> for lemonade@ietf.org; Fri, 24 Mar 2006 09:41:27 -0800 (PST) To: Vaudreuil Greg M Greg Message-id: <01M0FFVCG86W000078@mauve.mrochek.com> Date: Fri, 24 Mar 2006 09:26:24 -0800 (PST) From: Ned Freed Subject: RE: [lemonade] Future Release a WG item or ind. submission In-reply-to: "Your message dated Fri, 24 Mar 2006 08:08:51 -0600" <54E40201497DF142B06B27255953F7971CD3EEF5@il0015exch007u.ih.lucent.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 References: <54E40201497DF142B06B27255953F7971CD3EEF5@il0015exch007u.ih.lucent.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: lemonade@ietf.org, Tony Hansen X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > Ned asserted that the document was not part of the charter. It isn't. If you believe otherwise please cite the charter work item it fits under. I just reread the charter (for about the tenth time) and I sure don't see it. > I incorrectly agreed, forgetting that we had debated this point and accepted > the document as a WG item when we last met in greater Dallas almost two years > ago. So, there was discussion in the meeting about whether this was or was not > a WG item. It is fair to say the discussion was confused. Excuse me, but it was nothing of the sort. Future release is not part of the work the group was chartered to do. And it doesn't matter what the working group agreed to two years ago unless that agreement caused a charter update. Working groups don't get to add things to their charters without IESG approval. It doesn't matter if there is universal agreement which is repeatedly reaffirmed on the list and at every meeting over the course of a decade. It also doesn't matter that the problem went unnoticed for a while. This just isn't how the process works. Now, I have no problem with the charter being amended to add this. I also have no problem with this document proceeding as an individual submission and being reviewed in this group. But it canont proceed as a working group document without a charter revision. Period! Full stop! The issue here isn't that future release is a bad proposal. It isn't - it's a good proposal. The issue here is one of precedent. If we let working groups work on anything they feel like charters won't be worth the electrons they're composed of. Sooner or later there will be a group that after being chartered wants to embrace something that's a really bad idea. We cannot afford a situation such a group can point over here and say "it didn't matter that this was out of scope for LEMONADE - you let them do it anything". We really don't have all that many rules and restrictions, and that makes the ones we do have even more important. > The current document is the result of incorporating comments received during > WG last call. This is document is a WG work item and is now ready for IETF > last-call (once the ID clears the publishing queue). And I again repeat that it either needs to be renamed as a non-WG document or we need a charter amendment. Please don't make me have to appeal this, because I will if I have to. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Mar 24 13:10:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMqkK-0006ZH-93; Fri, 24 Mar 2006 13:10:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMqkJ-0006VE-H2 for lemonade@ietf.org; Fri, 24 Mar 2006 13:10:47 -0500 Received: from mxout7.cac.washington.edu ([140.142.32.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMqkI-0004Xa-4V for lemonade@ietf.org; Fri, 24 Mar 2006 13:10:47 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout7.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW06.03) with ESMTP id k2OIAhnv005870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 Mar 2006 10:10:44 -0800 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW06.03) with ESMTP id k2OIAf2Q026737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Mar 2006 10:10:43 -0800 Date: Fri, 24 Mar 2006 10:10:41 -0800 (PST) From: Mark Crispin To: Ned Freed Subject: RE: [lemonade] Future Release a WG item or ind. submission In-Reply-To: <01M0FFVCG86W000078@mauve.mrochek.com> Message-ID: References: <54E40201497DF142B06B27255953F7971CD3EEF5@il0015exch007u.ih.lucent.com> <01M0FFVCG86W000078@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: lemonade@ietf.org, Tony Hansen , Vaudreuil Greg M Greg X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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, 24 Mar 2006, Ned Freed wrote: > And I again repeat that it either needs to be renamed as a non-WG document or > we need a charter amendment. Either of these two courses of action will be considerably less painful than an appeal. I personally vote for a non-WG document that was reviewed in the WG. This is the easiest course of action, and I doubt very much that it will be at all controversial. A charter amendment can open up avenues for mischief (not to mention delaying the eventual termination of the WG). Let's just do it. Given that my Lemonade work is more or less on idle with the approval of the trio, I'm willing to take on responsibility for this document and shepherding it through approval. However, if I do so, be warned that I'll substantially revise it; no technical change, but much less text. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Mar 24 13:45:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMrHs-0008NF-LF; Fri, 24 Mar 2006 13:45:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMrHr-0008NA-Gk for lemonade@ietf.org; Fri, 24 Mar 2006 13:45:27 -0500 Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMrHq-0005eN-7W for lemonade@ietf.org; Fri, 24 Mar 2006 13:45:27 -0500 Received: from gawhitelaptop (c-67-162-191-81.hsd1.tx.comcast.net[67.162.191.81]) by comcast.net (rwcrmhc11) with SMTP id <20060324184525m1100c4orie>; Fri, 24 Mar 2006 18:45:25 +0000 From: "Greg White" To: Subject: RE: [lemonade] Future Release a WG item or ind. submission Date: Fri, 24 Mar 2006 12:45:01 -0600 Message-ID: <002f01c64f73$0ee8f7e0$6401a8c0@gawhitelaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I'll take care of it, but why do you think it needs substantially less text? Greg W. -----Original Message----- From: Mark Crispin [mailto:mrc@CAC.Washington.EDU] Sent: Friday, March 24, 2006 12:11 PM To: Ned Freed Cc: lemonade@ietf.org; Tony Hansen; Vaudreuil Greg M Greg Subject: RE: [lemonade] Future Release a WG item or ind. submission On Fri, 24 Mar 2006, Ned Freed wrote: > And I again repeat that it either needs to be renamed as a non-WG > document or we need a charter amendment. Either of these two courses of action will be considerably less painful than an appeal. I personally vote for a non-WG document that was reviewed in the WG. This is the easiest course of action, and I doubt very much that it will be at all controversial. A charter amendment can open up avenues for mischief (not to mention delaying the eventual termination of the WG). Let's just do it. Given that my Lemonade work is more or less on idle with the approval of the trio, I'm willing to take on responsibility for this document and shepherding it through approval. However, if I do so, be warned that I'll substantially revise it; no technical change, but much less text. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Mar 24 16:13:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMtaz-0000ZM-Bh; Fri, 24 Mar 2006 16:13:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMtax-0000ZB-G6 for lemonade@ietf.org; Fri, 24 Mar 2006 16:13:19 -0500 Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMtaw-0003NG-2Q for lemonade@ietf.org; Fri, 24 Mar 2006 16:13:19 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout2.cac.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k2OLDB4l018059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 Mar 2006 13:13: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.5+UW05.10/8.13.5+UW06.03) with ESMTP id k2OLDAN1004832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Mar 2006 13:13:11 -0800 Date: Fri, 24 Mar 2006 13:13:09 -0800 (PST) From: Mark Crispin To: Greg White Subject: RE: [lemonade] Future Release a WG item or ind. submission In-Reply-To: <002f01c64f73$0ee8f7e0$6401a8c0@gawhitelaptop> Message-ID: References: <002f01c64f73$0ee8f7e0$6401a8c0@gawhitelaptop> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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, 24 Mar 2006, Greg White wrote: > I'll take care of it, but why do you think it needs substantially less text? 25K of text for such a minor extension is ridiculous. This is the sort of bloat that encourages people not to read specifications. There's obvious fluff in the document: statements of opinion ("It is unfortunate to define two seemingly identical ways to indicate a future delivery time."), redundancy, or statement of the obvious. If something isn't necessary to define the protocol, it should be removed. I don't particularly care for the use of the passive voice or other wordiness in the necessary text. For example, the Framework can be expressed much more succinctly; and the result would be quite a bit clearer. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Mar 24 16:31:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMtso-00019u-34; Fri, 24 Mar 2006 16:31:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMtsm-00019l-Ja for lemonade@ietf.org; Fri, 24 Mar 2006 16:31:44 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57] helo=zcars04f.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMtsm-00042q-6M for lemonade@ietf.org; Fri, 24 Mar 2006 16:31:44 -0500 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2OLVgo27570 for ; Fri, 24 Mar 2006 16:31:42 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [lemonade] Draft liaison to OMA Date: Fri, 24 Mar 2006 16:31:28 -0500 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D0938385E@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [lemonade] Draft liaison to OMA Thread-Index: AcZPik+eu0UG4f5kQy6j10RZw7KCgA== From: "Glenn Parsons" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 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="===============1121798702==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============1121798702== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64F8A.570F5D61" This is a multi-part message in MIME format. ------_=_NextPart_001_01C64F8A.570F5D61 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, A revised liaison based on comments is attached... And a revised slide deck has been uploaded: http://www3.ietf.org/proceedings/06mar/slides/lemonade-5.ppt=20 I will send these to the OMA over the weekend.=20 Cheers, Glenn. From: IETF LEMONADE Working Group To: OMA MWG MEM Sub Working Group Title: Regarding the LEMONADE Profile=09 Response contact: lemonade@ietf.org Purpose: For Information The LEMONADE working group (WG) would like to thank the OMA Mobile Email Sub Working Group for your latest liaison. We appreciate your response to the questions that we had asked in our previous liaison. We have a specific comment based on your feedback on subsetting the OMA STI parameters for content transformation.=20 For the IMAP CONVERT protocol, the LEMONADE WG, as part of the IETF, must be cognizant that the consumers of our protocol specifications includes the entire set of Internet developers. Many of the media conversions that are obvious for the mobile environment, such as image or multimedia conversion, are not relevant for many of the consumers of IETF protocols. Therefore, the only 'Mandatory to Implement' conversion that will appear in the CONVERT protocol is HTML to TEXT. Virtually all messaging systems from almost all Internet domains can use this conversion, so including it in the set of mandatory conversions does not put an undue burden on implementations that do not focus on the mobile environment. That said, the HTML to TEXT conversion exercises the entire functionality of the CONVERT protocol. Be assured that the protocol itself can support any subset or even the entire OMA STI parameter suite. Thus, we encourage the OMA to further subset the full list of STI parameters to make it realistic for the OMA mobile enabler. As a result, we propose that LEMONADE would not specify the STI list decided by OMA MEM, but that this would be included in the OMA MEM TS. As we have indicated before, the LEMONADE WG is working on a set of extensions to IMAP and ESMTP to support mobile email. This set will be succinctly described in the LEMONADE profile (draft-ietf-lemonade-profile-bis). We understand that the OMA TS will normatively reference the LEMONADE profile for the MEM protocol. In order to help you understand this protocol better, we have attached a presentation to update OMA MEM on the content of the LEMONADE profile.=20 Up-to-date information on LEMONADE Internet-Drafts and RFCs can always be found at http://www.ietf.org/html.charters/lemonade-charter.html with more detail tracked on the supplemental site. Finally, as information, the next meetings of the IETF LEMONADE WG are: * May 31 - IETF LEMONADE 65.5 interim meeting - TBD * Jul 10-14 - IETF 66 plenary - Montreal ------_=_NextPart_001_01C64F8A.570F5D61 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [lemonade] Draft liaison to OMA

Folks,
A revised liaison = based on comments is attached…
And a revised slide = deck has been uploaded:
= http://www3.ietf.org/proceedings/06mar/slides/lemonade-5.p= pt
I will send these to = the OMA over the weekend.
Cheers,
Glenn.





From: IETF LEMONADE Working = Group
To: OMA MWG MEM Sub Working = Group
Title: Regarding the LEMONADE = Profile  
Response contact:  = lemonade@ietf.org
Purpose:  For = Information


The LEMONADE working group (WG) = would like to thank the OMA Mobile Email Sub Working Group for your = latest liaison.

We appreciate your response to = the questions that we had asked in our previous liaison.  We have a = specific comment based on your feedback on subsetting the OMA STI = parameters for content transformation.

For the IMAP CONVERT protocol, = the LEMONADE WG, as part of the IETF, must be cognizant that the = consumers of our protocol specifications includes the entire set of = Internet developers.  Many of the media conversions that are = obvious for the mobile environment, such as image or multimedia = conversion, are not relevant for many of the consumers of IETF = protocols.  Therefore, the only ‘Mandatory to = Implement’ conversion that will appear in the CONVERT protocol is = HTML to TEXT.  Virtually all messaging systems from almost all = Internet domains can use this conversion, so including it in the set of = mandatory conversions does not put an undue burden on implementations = that do not focus on the mobile environment.  That said, the HTML = to TEXT conversion exercises the entire functionality of the CONVERT = protocol.  Be assured that the protocol itself can support any = subset or even the entire OMA STI parameter suite.  Thus, we = encourage the OMA to further subset the full list of STI parameters to = make it realistic for the OMA mobile enabler.  As a result, we = propose that LEMONADE would not specify the STI list decided by OMA MEM, = but that this would be included in the OMA MEM TS.

As we have indicated before, the = LEMONADE WG is working on a set of extensions to IMAP and ESMTP to = support mobile email.  This set will be succinctly described in the = LEMONADE profile (draft-ietf-lemonade-profile-bis).  We understand = that the OMA TS will normatively reference the LEMONADE profile for the = MEM protocol.  In order to help you understand this protocol = better, we have attached a presentation to update OMA MEM on the content = of the LEMONADE profile.

Up-to-date information on = LEMONADE Internet-Drafts and RFCs can always be found at http://www.ietf.org/html.charters/lemonade-charter.html with more detail tracked on the = supplemental site.

Finally, as information, the next = meetings of the IETF LEMONADE WG are:

  • May 31 – IETF LEMONADE = 65.5 interim meeting - TBD
  • Jul 10-14 – IETF 66 = plenary - Montreal

------_=_NextPart_001_01C64F8A.570F5D61-- --===============1121798702== 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 --===============1121798702==-- From lemonade-bounces@ietf.org Fri Mar 24 20:56:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMy12-0000Nf-IQ; Fri, 24 Mar 2006 20:56:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMy10-0000Ed-NY for lemonade@ietf.org; Fri, 24 Mar 2006 20:56:30 -0500 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMy0x-0005o5-DG for lemonade@ietf.org; Fri, 24 Mar 2006 20:56:30 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1FMy0w-00017X-Ak for lemonade@ietf.org; Sat, 25 Mar 2006 01:56:26 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 8A67F498003 for ; Sat, 25 Mar 2006 02:00:17 +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 02317-09 for ; Sat, 25 Mar 2006 02:00:09 +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 D08A4498002 for ; Sat, 25 Mar 2006 02:00:07 +0000 (GMT) Date: Sat, 25 Mar 2006 01:56:15 +0000 MIME-Version: 1.0 Message-Id: <15871.1143251776.008607@peirce.dave.cridland.net> From: Dave Cridland To: Enhancements to Internet email to support diverse service enivronments Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Heisenberg-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [lemonade] Server Implementations Wanted X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hiya folks, To help me (and anyone else interested) get a handle on the various forms of compression on the table, I'm just finishing implementing the third, so I'll have TLS DEFLATE, COMPRESS=DEFLATE, and LZIP. Does anyone have a server implementation I can test against? For extra marks, a server supporting a combination of one or more would be interesting. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Mar 25 10:21:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNAZT-0002jO-VB; Sat, 25 Mar 2006 10:20:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNAZS-0002jJ-UU for lemonade@ietf.org; Sat, 25 Mar 2006 10:20:54 -0500 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNAZR-0003hM-Lf for lemonade@ietf.org; Sat, 25 Mar 2006 10:20:54 -0500 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M0G1SCXMA800007A@mauve.mrochek.com> for lemonade@ietf.org; Sat, 25 Mar 2006 07:20:51 -0800 (PST) To: Stephane H Maes Message-id: <01M0GP9DDIP600007A@mauve.mrochek.com> Date: Sat, 25 Mar 2006 07:17:33 -0800 (PST) From: Ned Freed Subject: RE: [lemonade] Future Release a WG item or ind. submission In-reply-to: "Your message dated Fri, 24 Mar 2006 07:33:48 -0800" <20060324073348062.00000001692@smaes-lap3> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <6BB7A015EDB2592F27C60C6B@107.114.96.204.in-addr.arpa> <20060324073348062.00000001692@smaes-lap3> X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: lemonadeietforg X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > Hmm I don't recall a statement that object level encryption would not be > within the charter. This was stated about future delivery... Correct. It's a bit of a squeeze, but object level crypto seems to fit under item 3 in the charter. Of course just because something fits doesn't make it a good proposal. I'm still quite concerned about the various security issues raised during the meeting. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Mar 25 10:49:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNB1K-0008W1-MS; Sat, 25 Mar 2006 10:49:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNB1J-0008Vw-Qn for lemonade@ietf.org; Sat, 25 Mar 2006 10:49:41 -0500 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNB1I-0004bN-Gj for lemonade@ietf.org; Sat, 25 Mar 2006 10:49:41 -0500 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M0G1SCXMA800007A@mauve.mrochek.com> for lemonade@ietf.org; Sat, 25 Mar 2006 07:49:38 -0800 (PST) To: Keith Moore Message-id: <01M0GQA1KVFK00007A@mauve.mrochek.com> Date: Sat, 25 Mar 2006 07:43:05 -0800 (PST) From: Ned Freed Subject: Re: [lemonade] on MTI conversions In-reply-to: "Your message dated Wed, 22 Mar 2006 10:37:48 -0500" <44216F4C.3000601@cs.utk.edu> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed References: <44216F4C.3000601@cs.utk.edu> X-Spam-Score: 0.1 (/) 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 > listening to the discussion on conversions, I question the need for an > MTI conversion set. since conversion is an optional feature, I don't > see how failure to implement any particular conversion results in > degraded interoperability of the protocol. It's an optional feature in general of course, but it remains to be seen whether it it is going to be optional or not in the revised LEMONADE profile. (There's also the issue as to how it relates to streaming, which since we don't have a draft is kinda hard to pin down.) > however I do see the need to demonstrate interoperability of the > conversion feature so that it can advance along the standards track. so > for these purposes I would propose that there be an informal implementor > agreement to implement two or three trivial conversions (that require > parameters) for the purpose of interop testing. It's an interesting idea, but I'm far from convinced it would fly with the IESG. Heck, I'm not completely convinced myself. In any case, I think we need to first see how the profile situation plays out before deciding to try such a thing. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Mar 25 15:16:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNFBo-00032W-Nd; Sat, 25 Mar 2006 15:16:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNFBn-0002vV-AW for lemonade@ietf.org; Sat, 25 Mar 2006 15:16:47 -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 1FNFBn-0006aw-92 for lemonade@ietf.org; Sat, 25 Mar 2006 15:16:47 -0500 Received: from igw2.watson.ibm.com ([129.34.20.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FNF5M-0006k7-52 for lemonade@ietf.org; Sat, 25 Mar 2006 15:10:09 -0500 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.12.11/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id k2PKAOKD001250 for ; Sat, 25 Mar 2006 15:10:24 -0500 Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id k2PKA6h27432 for ; Sat, 25 Mar 2006 15:10:07 -0500 Received: from mars (mars.watson.ibm.com [9.2.40.64]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id k2PKA6B48352 for ; Sat, 25 Mar 2006 15:10:06 -0500 Received: from SATURN ([9.12.236.3]) by mars.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1143317406.3722; Sat, 25 Mar 2006 15:10:06 -0400 Message-ID: <4425A39D.3010100@watson.ibm.com> Date: Sat, 25 Mar 2006 15:10:05 -0500 From: Barry Leiba User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: lemonadeietforg Subject: Re: [lemonade] Future Release a WG item or ind. submission References: <6BB7A015EDB2592F27C60C6B@107.114.96.204.in-addr.arpa> <20060324073348062.00000001692@smaes-lap3> <01M0GP9DDIP600007A@mauve.mrochek.com> In-Reply-To: <01M0GP9DDIP600007A@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org >> Hmm I don't recall a statement that object level encryption would not be >> within the charter. This was stated about future delivery... ... > Of course just because something fits doesn't make it a good proposal. I'm > still quite concerned about the various security issues raised during > the meeting. Agreed; as I said in the meeting, it's a Very Bad Idea for us to design our own encryption protocol without some close supervision by the Security Area. Get EKR involved, and if he thinks the object-level encryption spec is in good shape, then I'll be a looooot happier. Barry -- Barry Leiba, Pervasive Computing Technology (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Mar 25 16:39:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNGTQ-0000i9-Sj; Sat, 25 Mar 2006 16:39:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNGTP-0000i4-GS for lemonade@ietf.org; Sat, 25 Mar 2006 16:39:03 -0500 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNGTP-0001gh-3Z for lemonade@ietf.org; Sat, 25 Mar 2006 16:39:03 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1FNGTN-0004Nu-0U; Sat, 25 Mar 2006 21:39:01 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 80680498003; Sat, 25 Mar 2006 21:43:00 +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 06597-02; Sat, 25 Mar 2006 21:42: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 A0AAC498002; Sat, 25 Mar 2006 21:42:48 +0000 (GMT) Date: Sat, 25 Mar 2006 21:38:48 +0000 Subject: Re: [lemonade] on MTI conversions References: <44216F4C.3000601@cs.utk.edu> <01M0GQA1KVFK00007A@mauve.mrochek.com> In-Reply-To: <01M0GQA1KVFK00007A@mauve.mrochek.com> MIME-Version: 1.0 Message-Id: <19105.1143322728.446058@peirce.dave.cridland.net> From: Dave Cridland To: Ned Freed 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: cab78e1e39c4b328567edb48482b6a69 Cc: Enhancements to Internet email to support diverse service enivronments , Keith Moore X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 Mar 25 15:43:05 2006, Ned Freed wrote: >> listening to the discussion on conversions, I question the need >> for an >> MTI conversion set. since conversion is an optional feature, I >> don't >> see how failure to implement any particular conversion results in >> degraded interoperability of the protocol. > > It's an optional feature in general of course, but it remains to be > seen > whether it it is going to be optional or not in the revised > LEMONADE profile. > (There's also the issue as to how it relates to streaming, which > since we don't > have a draft is kinda hard to pin down.) > > If we make it mandatory in the Lemonade Profile, we can always add in MTI conversion at that point, specific to the Lemonade Profile. In fact, I'd have thought we would want to add in a set of MTI conversions if we bring it into the Profile, whatever it has already. >> however I do see the need to demonstrate interoperability of the >> conversion feature so that it can advance along the standards >> track. so >> for these purposes I would propose that there be an informal >> implementor >> agreement to implement two or three trivial conversions (that >> require >> parameters) for the purpose of interop testing. > > It's an interesting idea, but I'm far from convinced it would fly > with the > IESG. Heck, I'm not completely convinced myself. > > I have to admit I'm not entirely happy with the idea of an MTI being present purely to fix a process issue. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Mar 25 17:26:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNHDa-0007yX-HA; Sat, 25 Mar 2006 17:26:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNHDZ-0007yE-IY for lemonade@ietf.org; Sat, 25 Mar 2006 17:26:45 -0500 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNHDZ-0003wk-7U for lemonade@ietf.org; Sat, 25 Mar 2006 17:26:45 -0500 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M0GYLGXNHS00007A@mauve.mrochek.com> for lemonade@ietf.org; Sat, 25 Mar 2006 14:26:42 -0800 (PST) To: Dave Cridland Message-id: <01M0H45BMQPM00007A@mauve.mrochek.com> Date: Sat, 25 Mar 2006 14:11:14 -0800 (PST) From: Ned Freed Subject: Re: [lemonade] on MTI conversions In-reply-to: "Your message dated Sat, 25 Mar 2006 21:38:48 +0000" <19105.1143322728.446058@peirce.dave.cridland.net> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <44216F4C.3000601@cs.utk.edu> <01M0GQA1KVFK00007A@mauve.mrochek.com> <19105.1143322728.446058@peirce.dave.cridland.net> X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Enhancements to Internet email to support diverse service enivronments , Keith Moore , Ned Freed X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > On Sat Mar 25 15:43:05 2006, Ned Freed wrote: > >> listening to the discussion on conversions, I question the need > >> for an > >> MTI conversion set. since conversion is an optional feature, I > >> don't > >> see how failure to implement any particular conversion results in > >> degraded interoperability of the protocol. > > > > It's an optional feature in general of course, but it remains to be > > seen > > whether it it is going to be optional or not in the revised > > LEMONADE profile. > > (There's also the issue as to how it relates to streaming, which > > since we don't > > have a draft is kinda hard to pin down.) > > > > > If we make it mandatory in the Lemonade Profile, we can always add in > MTI conversion at that point, specific to the Lemonade Profile. In > fact, I'd have thought we would want to add in a set of MTI > conversions if we bring it into the Profile, whatever it has already. Keep in mind that even if this doesn't appear as part of the LEMONADE profile the sense in the room was that a fairly significant set of converters are bould to be part of OMA requirements in this area. > >> however I do see the need to demonstrate interoperability of the > >> conversion feature so that it can advance along the standards > >> track. so > >> for these purposes I would propose that there be an informal > >> implementor > >> agreement to implement two or three trivial conversions (that > >> require > >> parameters) for the purpose of interop testing. > > > > It's an interesting idea, but I'm far from convinced it would fly > > with the > > IESG. Heck, I'm not completely convinced myself. > > > > > I have to admit I'm not entirely happy with the idea of an MTI being > present purely to fix a process issue. First, adequate demonstrability of interoperability is hardly a mere "process issue". And the record on interoperability in this space when only toy placeholders are required is spotty at best. (If memory serves, this is more or less what the GOSIP profile of X.400 called for, and that scheme never interoperated worth spit on any system I ever saw.) Second, it is far from clear to me that a mandatory to implement conversion serves no other purpose but to provide an interop guarantee. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Mar 25 17:36:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNHNC-0005TR-DE; Sat, 25 Mar 2006 17:36:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNHNA-0005Qx-TI for lemonade@ietf.org; Sat, 25 Mar 2006 17:36:40 -0500 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNHNA-00042S-Ey for lemonade@ietf.org; Sat, 25 Mar 2006 17:36:40 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1FNHN9-0002EZ-HC; Sat, 25 Mar 2006 22:36:39 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id B2CD1498003; Sat, 25 Mar 2006 22:40:39 +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 06597-07; Sat, 25 Mar 2006 22:40: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 1B362498002; Sat, 25 Mar 2006 22:40:28 +0000 (GMT) Date: Sat, 25 Mar 2006 22:36:27 +0000 Subject: Re: [lemonade] on MTI conversions References: <44216F4C.3000601@cs.utk.edu> <01M0GQA1KVFK00007A@mauve.mrochek.com> <19105.1143322728.446058@peirce.dave.cridland.net> <01M0H45BMQPM00007A@mauve.mrochek.com> In-Reply-To: <01M0H45BMQPM00007A@mauve.mrochek.com> MIME-Version: 1.0 Message-Id: <19105.1143326187.491123@peirce.dave.cridland.net> From: Dave Cridland To: Ned Freed 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: 31247fb3be228bb596db9127becad0bc Cc: Enhancements to Internet email to support diverse service enivronments , Keith Moore X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 Mar 25 22:11:14 2006, Ned Freed wrote: >> On Sat Mar 25 15:43:05 2006, Ned Freed wrote: >> >> listening to the discussion on conversions, I question the need >> >> for an >> >> MTI conversion set. since conversion is an optional feature, I >> >> don't >> >> see how failure to implement any particular conversion results >> in >> >> degraded interoperability of the protocol. >> > >> > It's an optional feature in general of course, but it remains to >> be >> > seen >> > whether it it is going to be optional or not in the revised >> > LEMONADE profile. >> > (There's also the issue as to how it relates to streaming, which >> > since we don't >> > have a draft is kinda hard to pin down.) >> > >> > >> If we make it mandatory in the Lemonade Profile, we can always add >> in >> MTI conversion at that point, specific to the Lemonade Profile. In >> fact, I'd have thought we would want to add in a set of MTI >> conversions if we bring it into the Profile, whatever it has >> already. > > Keep in mind that even if this doesn't appear as part of the > LEMONADE profile > the sense in the room was that a fairly significant set of > converters are bould > to be part of OMA requirements in this area. > > Yes, true, there are multiple levels at which conversions could be mandated. >> >> however I do see the need to demonstrate interoperability of the >> >> conversion feature so that it can advance along the standards >> >> track. so >> >> for these purposes I would propose that there be an informal >> >> implementor >> >> agreement to implement two or three trivial conversions (that >> >> require >> >> parameters) for the purpose of interop testing. >> > >> > It's an interesting idea, but I'm far from convinced it would fly >> > with the >> > IESG. Heck, I'm not completely convinced myself. >> > >> > >> I have to admit I'm not entirely happy with the idea of an MTI >> being >> present purely to fix a process issue. > > First, adequate demonstrability of interoperability is hardly a > mere "process > issue". And the record on interoperability in this space when only > toy > placeholders are required is spotty at best. The former of these statements I agree with, but only when, in this case, the conversion required is actually genuinely useful to mandate for reasons other than purely demonstrating interop - that would be an instance of the latter. > Second, it is far from clear to me that a mandatory to implement > conversion > serves no other purpose but to provide an interop guarantee. I think we're in full agreement here - you, myself, and Keith. My concern - and I have the possibly incorrect impression this is Keith's concern too - is that the discussion on MTI conversions in the WG meeting seemed purely related to getting one to pass some idea of interop testing, and not really to serve any other purpose. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Mar 25 17:48:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNHYN-0004nO-Qk; Sat, 25 Mar 2006 17:48:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNHYM-0004kP-C8 for lemonade@ietf.org; Sat, 25 Mar 2006 17:48:14 -0500 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNHYM-00049S-0m for lemonade@ietf.org; Sat, 25 Mar 2006 17:48:14 -0500 Received: from localhost (shu [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 67D4213B4E; Sat, 25 Mar 2006 17:48:13 -0500 (EST) Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18316-10; Sat, 25 Mar 2006 17:48:11 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 1378F13B47; Sat, 25 Mar 2006 17:48:11 -0500 (EST) Message-ID: <4425C8A8.7020802@cs.utk.edu> Date: Sat, 25 Mar 2006 17:48:08 -0500 From: Keith Moore User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: Ned Freed Subject: Re: [lemonade] on MTI conversions References: <44216F4C.3000601@cs.utk.edu> <01M0GQA1KVFK00007A@mauve.mrochek.com> <19105.1143322728.446058@peirce.dave.cridland.net> <01M0H45BMQPM00007A@mauve.mrochek.com> In-Reply-To: <01M0H45BMQPM00007A@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org >> I have to admit I'm not entirely happy with the idea of an MTI being >> present purely to fix a process issue. > > First, adequate demonstrability of interoperability is hardly a mere > "process issue". yes, but the point is that demonstrating interoperability is a separate issue from MTI. the purpose of demonstrating interoperability of a feature is to validate the specification - if two implementations of the same spec interoperate, this provides a sanity check of the spec. the purpose of MTI options is to ensure that two implementations that each conform to the spec will be able to interoperate even if they implement different sets of options. without MTI one implementation could implement only option A, another could implement only option B, and they couldn't talk to one another. for instance if a SMTP client only implemented BDAT and a server only implemented DATA, they couldn't exchange messages. but for the case of conversion of body parts in IMAP, the MTI conversion option is already provided for in the base IMAP spec - it's the null conversion. since all IMAP servers have to be able to provide body parts in their native form - without converting them - the basis for interoperability already exists. if someone wants to be pedantic about it, define a conversion named "NULL", which would serve no other purpose than to be able to test the command parsing code. but at least it would be easy to implement and hopefully noncontroversial. of course if other profiles want to define other MTI conversions before compliance can be claimed with those profiles, that's fine. but I got the strong impression that a lot of time was being wasted in the meeting trying to figure out which marginally useful conversion all Lemonade servers have to implement for no other purpose than to satisfy a misunderstanding of IESG MTI criteria. Keith _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Mar 25 18:47:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNITH-000814-MI; Sat, 25 Mar 2006 18:47:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNITG-00080z-D7 for lemonade@ietf.org; Sat, 25 Mar 2006 18:47:02 -0500 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNITE-0005lL-1H for lemonade@ietf.org; Sat, 25 Mar 2006 18:47:02 -0500 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M0GYLGXNHS00007A@mauve.mrochek.com> for lemonade@ietf.org; Sat, 25 Mar 2006 15:46:56 -0800 (PST) To: Keith Moore Message-id: <01M0H6XT0KW200007A@mauve.mrochek.com> Date: Sat, 25 Mar 2006 15:29:50 -0800 (PST) From: Ned Freed Subject: Re: [lemonade] on MTI conversions In-reply-to: "Your message dated Sat, 25 Mar 2006 17:48:08 -0500" <4425C8A8.7020802@cs.utk.edu> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed References: <44216F4C.3000601@cs.utk.edu> <01M0GQA1KVFK00007A@mauve.mrochek.com> <19105.1143322728.446058@peirce.dave.cridland.net> <01M0H45BMQPM00007A@mauve.mrochek.com> <4425C8A8.7020802@cs.utk.edu> X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Enhancements to Internet email to support diverse service enivronments , Ned Freed X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > yes, but the point is that demonstrating interoperability is a separate > issue from MTI. That depends on what sort of interoperability you're talking about. Let's please remember that this is the LEMONADE group, with some fairly specific goals for support of some fairly specific sorts of clients. The conversion facility isn't being developed because server-side conversion is something we all lust after, but rather because specific sorts of conversions are needed by some limited-capability clients. Having said that, I think there's a conundrum lurking in all this, which is that for various reasons (IPR concerns being the most obvious) it may not be possible to specify the full set of MTI conversions a LEMONADE client actually needs. As I pointed out at the meeting, this gets very close to the same set of issues that had VPIM all wrapped around the axle for some time. To put this another way, I would be willing to accept a toy MTI conversion despite my serious misgivings if it can be shown that the set of conversions generally useful to a LEMONADE client and which we are able to mandate in an IETF specification is empty. But I don't think that's the case: The obvious counterexample is the HTML to text the WG settled on. > the purpose of demonstrating interoperability of a feature is to > validate the specification - if two implementations of the same spec > interoperate, this provides a sanity check of the spec. But this begs the question of what should be in the specification to meet our WG requirements. > of course if other profiles want to define other MTI conversions before > compliance can be claimed with those profiles, that's fine. but I got > the strong impression that a lot of time was being wasted in the meeting > trying to figure out which marginally useful conversion all Lemonade > servers have to implement for no other purpose than to satisfy a > misunderstanding of IESG MTI criteria. I believe this impression is not only incorrect, it is actually backwards. The slide initially showed a fairly significant list of MTI conversions. It was argued that some aren't needed by all clients and others are encumbered in various ways. This brought the list down to HTML to text, but with the caveat that the others will probably still be mandated by some OMA spec or other. It was then argued that the one remaining isn't generally useful, but I didn't see a lot of people buying into the argument. The need for one MTI was only raised as an afterthought. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Mar 25 19:08:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNInh-00077B-To; Sat, 25 Mar 2006 19:08:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNIng-000776-Pp for lemonade@ietf.org; Sat, 25 Mar 2006 19:08:08 -0500 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNIng-0007OV-Gv for lemonade@ietf.org; Sat, 25 Mar 2006 19:08:08 -0500 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M0GYLGXNHS00007A@mauve.mrochek.com> for lemonade@ietf.org; Sat, 25 Mar 2006 16:08:04 -0800 (PST) To: Barry Leiba Message-id: <01M0H7O14GE800007A@mauve.mrochek.com> Date: Sat, 25 Mar 2006 16:03:25 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Sat, 25 Mar 2006 15:10:05 -0500" <4425A39D.3010100@watson.ibm.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed References: <6BB7A015EDB2592F27C60C6B@107.114.96.204.in-addr.arpa> <20060324073348062.00000001692@smaes-lap3> <01M0GP9DDIP600007A@mauve.mrochek.com> <4425A39D.3010100@watson.ibm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: lemonadeietforg Subject: [lemonade] Object encryption (was: Future Release a WG item or ind. submission) X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org (subject changed because this has nothing to do with future release) > >> Hmm I don't recall a statement that object level encryption would not be > >> within the charter. This was stated about future delivery... > ... > > Of course just because something fits doesn't make it a good proposal. I'm > > still quite concerned about the various security issues raised during > > the meeting. > Agreed; as I said in the meeting, it's a Very Bad Idea for us to design > our own encryption protocol without some close supervision by the > Security Area. Get EKR involved, and if he thinks the object-level > encryption spec is in good shape, then I'll be a looooot happier. Yep - EKR or whoever our designated security area advisor is needs to see this sooner rather than later. Someone in the room said it's EKR but that needs to be verified. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Mar 26 23:23:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNjGa-0005RQ-PW; Sun, 26 Mar 2006 23:23:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNjDM-0003JJ-6Z; Sun, 26 Mar 2006 23:20:24 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNjDL-0000Gl-V5; Sun, 26 Mar 2006 23:20:24 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k2R4KLBX026282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Mar 2006 04:20:21 GMT Received: from mirror by ietf.org with local (Exim 4.43) id 1FNjDJ-0006Fc-4H; Sun, 26 Mar 2006 23:20:21 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: OMA-LIAISON@mail.openmobilealliance.org From: Glenn Parsons(IETF LEMONADE WG) Message-Id: Date: Sun, 26 Mar 2006 23:20:21 -0500 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by oak.neustar.com id k2R4KLBX026282 X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-Mailman-Approved-At: Sun, 26 Mar 2006 23:23:43 -0500 Cc: Gparsons@nortel.com, lemonade@ietf.org, statements@ietf.org, hardie@qualcomm.com, dean.willis@softarmor.com Subject: [lemonade] New Liaison Statement, "Regarding the LEMONADE Profile" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Title: Regarding the LEMONADE Profile Submission Date: 2006-03-26 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_det= ail.cgi?detail_id=3D206=20 From: Glenn Parsons(IETF LEMONADE WG) To: OMA MEM(OMA-LIAISON@mail.openmobilealliance.org) Cc: lemonade@ietf.org dean.willis@softarmor.com hardie@qualcomm.com Reponse Contact: lemonade@ietf.org Technical Contact: Gparsons@nortel.com eburger@cantata.com Purpose: For information=20 Body:=20 The LEMONADE working group (WG) would like to thank the OMA Mobile Email = Sub Working Group for your latest liaison. We appreciate your response to the questions that we had asked in our pre= vious liaison. We have a specific comment based on your feedback on subs= etting the OMA STI parameters for content transformation.=20 For the IMAP CONVERT protocol, the LEMONADE WG, as part of the IETF, must= be cognizant that the consumers of our protocol specifications includes = the entire set of Internet developers. Many of the media conversions tha= t are obvious for the mobile environment, such as image or multimedia con= version, are not relevant for many of the consumers of IETF protocols. T= herefore, the only =E2=80=98Mandatory to Implement=E2=80=99 conversion th= at will appear in the CONVERT protocol is HTML to TEXT. Virtually all me= ssaging systems from almost all Internet domains can use this conversion,= so including it in the set of mandatory conversions does not put an undu= e burden on implementations that do not focus on the mobile environment. = That said, the HTML to TEXT conversion exercises the entire functionalit= y of the CONVERT protocol. Be assured that the protocol itself can suppo= rt any subset or even the entire OMA STI parameter suite. Thus, we encou= rage the OMA to further subset the full list of STI parameters to make it= realistic for the OMA mobile enabler. As a result, we propose that LEMO= NADE would not specify the STI list decided by OMA MEM, but that this wou= ld be included in the OMA MEM TS. As we have indicated before, the LEMONADE WG is working on a set of exten= sions to IMAP and ESMTP to support mobile email. This set will be succin= ctly described in the LEMONADE profile (draft-ietf-lemonade-profile-bis).= We understand that the OMA TS will normatively reference the LEMONADE p= rofile for the MEM protocol. In order to help you understand this protoc= ol better, we have attached a presentation to update OMA MEM on the conte= nt of the LEMONADE profile.=20 Up-to-date information on LEMONADE Internet-Drafts and RFCs can always be= found at http://www.ietf.org/html.charters/lemonade-charter.html with mo= re detail tracked on the supplemental site. Finally, as information, the next meetings of the IETF LEMONADE WG are: - May 31 =E2=80=93 IETF LEMONADE 65.5 interim meeting =E2=80=93 Ottawa (d= etails TBD) - Jul 10-14 =E2=80=93 IETF 66 plenary - Montreal Attachment(s): Liaison text (https://datatracker.ietf.org/documents/LIAISON/file286= .pdf) LEMONADE profile update (https://datatracker.ietf.org/documents/LIAI= SON/file287.pdf) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Mar 31 11:25:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPMRP-0006NR-Fb; Fri, 31 Mar 2006 11:25:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP3mN-0005VP-Sv for lemonade@ietf.org; Thu, 30 Mar 2006 15:30:03 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP3mJ-0006oN-K2 for lemonade@ietf.org; Thu, 30 Mar 2006 15:30:03 -0500 Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k2UKTxSD024752 for ; Thu, 30 Mar 2006 13:29:59 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IWY00901J3I3700@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Thu, 30 Mar 2006 13:29:59 -0700 (MST) Received: from Tundra ([199.247.232.254]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IWY0079GJLXXV62@mail-amer.sun.com> for lemonade@ietf.org; Thu, 30 Mar 2006 13:29:59 -0700 (MST) Date: Thu, 30 Mar 2006 12:29:54 -0800 From: Peter Coates To: lemonade@ietf.org Message-id: <13fb01c65438$b5793880$d3219681@Tundra> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcZUOLRhrYUvX3o5Qk6cijkNo6ewvQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-Mailman-Approved-At: Fri, 31 Mar 2006 11:25:37 -0500 Subject: [lemonade] confusion on syntax of the access portion of the URLAUTH X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org the description of the access portion of URLAUTH tells me about the meaning of authuser, anonymous, user+userid, and submit+userid. the ABNF tells me that access = ("submit+" iuserauth) / ("user+" iuserauth) / "authuser" / "anonymous" iuserauth is defined in RFC 2192 as iuserauth = enc_user [iauth] / [enc_user] iauth What would the meaning be of a URLAUTH with an access portion of the form ;URLAUTH=user+;auth=* or ;URLAUTH=submit+;auth=xxx Would such forms be legal? the syntax seems a bit tortured. But I assume this is deliberate as it would have been easy to define access as access = ("submit+" enc_user) / ("user+" enc_user) / "authuser" / "anonymous" if that had been the intent. I also note that iuserauth is replaced with iuserinfo in draft-ietf-lemonade-rfc2192bis-01.txt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Mar 31 21:24:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPVmZ-00025d-8e; Fri, 31 Mar 2006 21:24:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPVmX-000247-J7 for lemonade@ietf.org; Fri, 31 Mar 2006 21:24:05 -0500 Received: from mxout3.cac.washington.edu ([140.142.32.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPVmW-00059w-8t for lemonade@ietf.org; Fri, 31 Mar 2006 21:24:05 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout3.cac.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k312O3r0001503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 31 Mar 2006 18:24:03 -0800 X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k312O2DO007492 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 31 Mar 2006 18:24:02 -0800 Date: Fri, 31 Mar 2006 18:26:05 -0800 (Pacific Standard Time) From: Mark Crispin To: Peter Coates Subject: Re: [lemonade] confusion on syntax of the access portion of the URLAUTH In-Reply-To: <13fb01c65438$b5793880$d3219681@Tundra> Message-ID: References: <13fb01c65438$b5793880$d3219681@Tundra> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I think that we decided that iauth wasn't meaningful in IMAP URLs that use URLAUTH, because we don't allow relative IMAP URLs with URLAUTH. But I forget why we used the iuserauth instead of the enc_user rule. Should we fix this? Can I get away with doing so during AUTH48? -- 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