From dkarp@zimbra.com Sat Nov 7 15:45:53 2009 Return-Path: X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 432093A67D3 for ; Sat, 7 Nov 2009 15:45:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-vb7YUepZGB for ; Sat, 7 Nov 2009 15:45:52 -0800 (PST) Received: from mta02.zimbra.com (mta02.zimbra.com [207.126.229.144]) by core3.amsl.com (Postfix) with ESMTP id 97A053A679C for ; Sat, 7 Nov 2009 15:45:52 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.zimbra.com (Postfix) with ESMTP id B3F5CC780BF; Sat, 7 Nov 2009 15:46:17 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.com Received: from mta02.zimbra.com ([127.0.0.1]) by localhost (mta02.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsHbS6lRsWnm; Sat, 7 Nov 2009 15:46:17 -0800 (PST) Received: from dogfood.zimbra.com (dogfood.zimbra.com [207.126.229.140]) by mta02.zimbra.com (Postfix) with ESMTP id 39933C780BA; Sat, 7 Nov 2009 15:46:17 -0800 (PST) Date: Sat, 7 Nov 2009 15:46:16 -0800 (PST) From: Dan Karp To: eburger@standardstrack.com Message-ID: <661875402.14422.1257637576746.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <607407038-1256157775-cardhu_decombobulator_blackberry.rim.net-1036114557-@bda365.bisx.prod.on.blackberry> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 6.0.2_GA_1912.RHEL4_64 (ZimbraWebClient - SAF3 (Mac)/6.0.2_GA_1912.RHEL4_64) Cc: lemonade@ietf.org Subject: Re: [lemonade] Clarification on LEMONADE "use" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 23:45:53 -0000 > Clearly, given the modular nature of LEMONADE, I would not expect > anyone to implement all of LEMONADE. Does that change anyone's > hesitation to say "yes"? Is there a minimum subset required to answer "yes"? From eburger@standardstrack.com Sat Nov 7 17:49:41 2009 Return-Path: X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4EEA3A689A for ; Sat, 7 Nov 2009 17:49:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FkfAxFNdrF5 for ; Sat, 7 Nov 2009 17:49:41 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19b.inmotionhosting.com [66.117.3.189]) by core3.amsl.com (Postfix) with ESMTP id 37E2D3A6878 for ; Sat, 7 Nov 2009 17:49:41 -0800 (PST) Received: from host-40-25.meeting.ietf.org ([133.93.40.25]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1N6wui-0003cD-SS; Sat, 07 Nov 2009 17:49:58 -0800 Message-Id: From: Eric Burger To: Dan Karp In-Reply-To: <661875402.14422.1257637576746.JavaMail.root@dogfood.zimbra.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 8 Nov 2009 10:49:59 +0900 References: <661875402.14422.1257637576746.JavaMail.root@dogfood.zimbra.com> X-Mailer: Apple Mail (2.936) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: lemonade@ietf.org Subject: Re: [lemonade] Clarification on LEMONADE "use" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 01:49:41 -0000 Given I'm looking to do some PR saying, "look at how many people are implementing LEMONADE," I would offer anything goes. Of course, the minimum useful set is Profile 1. On Nov 8, 2009, at 8:46 AM, Dan Karp wrote: >> Clearly, given the modular nature of LEMONADE, I would not expect >> anyone to implement all of LEMONADE. Does that change anyone's >> hesitation to say "yes"? > > Is there a minimum subset required to answer "yes"? From eburger@standardstrack.com Sat Nov 7 17:51:04 2009 Return-Path: X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B536C3A67DB for ; Sat, 7 Nov 2009 17:51:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbi5k3jXG04G for ; Sat, 7 Nov 2009 17:51:04 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19b.inmotionhosting.com [66.117.3.189]) by core3.amsl.com (Postfix) with ESMTP id 2337E3A67BD for ; Sat, 7 Nov 2009 17:51:04 -0800 (PST) Received: from host-40-25.meeting.ietf.org ([133.93.40.25]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1N6ww5-0003nX-UI for lemonade@ietf.org; Sat, 07 Nov 2009 17:51:22 -0800 Message-Id: <46CD1D26-AF86-4539-8291-7A5A52E56773@standardstrack.com> From: Eric Burger To: lemonade@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 8 Nov 2009 10:51:25 +0900 X-Mailer: Apple Mail (2.936) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Subject: [lemonade] Who's doing what X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 01:51:04 -0000 Along Dan's query, I put up a draft of what's out there. I would appreciate it if you could review it for accuracy. Thanks. http://www.standardstrack.com/ietf/lemonade/Lemonade-Plans.html From ned.freed@mrochek.com Sun Nov 8 16:32:43 2009 Return-Path: X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E6913A6A46 for ; Sun, 8 Nov 2009 16:32:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrCx7Q3Tsmgl for ; Sun, 8 Nov 2009 16:32:42 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id AA9EF3A6A21 for ; Sun, 8 Nov 2009 16:32:42 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NFUUE8ZZKW003OBJ@mauve.mrochek.com> for lemonade@ietf.org; Sun, 8 Nov 2009 16:33:03 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NFUS14F00W0002QL@mauve.mrochek.com>; Sun, 08 Nov 2009 16:33:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1257726685; bh=QctBaJE32pnDlF68TrDQbPWYAIOkHztc1e31pHlADtE=; h=Date:From:Subject:In-reply-to:To:Cc:Message-id:MIME-version: Content-type:References; b=DC0QPHJd8QHpaqVANGz11wJCFGp4dLbkWxeKZykSFR/BYezrrwfg/Gr9tTZ6tgk5T vn7O2ShR+Cc7InToCH3gEcLLD38I9QZ36Eb23GSrF87xz6pFckMn0Gb1EXJEz7Fb76 rtRTNBJODjJ0jincolPGGjrLfiXO1CDA/qac4j9Y= Date: Sun, 08 Nov 2009 15:54:43 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Sun, 08 Nov 2009 10:49:59 +0900" To: Eric Burger Message-id: <01NFUUE81PRK0002QL@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed; DelSp=yes Content-transfer-encoding: 7BIT References: <661875402.14422.1257637576746.JavaMail.root@dogfood.zimbra.com> Cc: lemonade@ietf.org Subject: Re: [lemonade] Clarification on LEMONADE "use" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 00:32:43 -0000 > Given I'm looking to do some PR saying, "look at how many people are > implementing LEMONADE," I would offer anything goes. Then I'm afraid you need to start being a lot more realistic about all this. > Of course, the minimum useful set is Profile 1. That's simply not true. The LEMONADE profile includes any number of things that are in no way essential to the effective operation of clients in general and mobile clients in particular. I'll first pick on a specification I wrote as a particularly obvious example of this: ENHANCEDSTATUSCODES. This extension provides some real utility, sure, but not having it would hardly have the effect of making the remainer of LEMONADE "useless" or for that matter making a client significantly less usable. This is readily demonstrable, BTW, in that very few clients - of any sort - take advantage of this extension to present localized error messages. That said, assuming I thought having a LEMONDATE profile makes (which I don't - I have always believed that profiles are at best pointless and often actively counterproductive), I would have no problem with ENHANCEDSTATUSCODE being part of it. Why? Because it's a very simple extension to implement, often involving nothing but a handful of changes to constant strings. So the cost is low and the benefits are worth that small cost. The same cannot be said for BINARYMIME. The cost here is very significant, both in terms of implementation and operational difficulties. IMNSHO these costs far, far, far outweigh the benefits the extension delivers. In fact I believe the costs are so high we've never finished up and activated the latent support for BINARYMIME in our product and, absent some significant change in the operqtional, almost certainly never will. These are just two examples; there are plenty of others, especially once you get past SMTP and into the IMAP and Sieve requirements. As one final example, although we have seen any number of requests for additional comparator capabilities (mostly ones that ignore or compress whitespace in some way), we have yet to receive a single request for i;unicode-casemap comparator support, so based on our experience in the field I see less than zero jusitification for its inclusion in the profile. In summary, as long as you insist that RFC 5550 represents the useful minimium that has to be there, I'm doubtful you're going to see much if any suport for this PR effort of yours. If, OTOH, you want to talk about support for specific capabilities LEMONADE provides without reference to the profile, then that's a conversation I for one would not be adverse to having. Ned From ned.freed@mrochek.com Sun Nov 8 22:12:50 2009 Return-Path: X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60FB43A69E8 for ; Sun, 8 Nov 2009 22:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAOoVhWvs6E5 for ; Sun, 8 Nov 2009 22:12:47 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id A67863A6974 for ; Sun, 8 Nov 2009 22:12:45 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NFV69VZ8SW00464I@mauve.mrochek.com> for lemonade@ietf.org; Sun, 8 Nov 2009 22:13:08 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NFV51U6ILC0002QL@mauve.mrochek.com>; Sun, 08 Nov 2009 22:13:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1257747089; bh=SdyP7Vd9Hh4qtzvD6wegv9yZRKjR3yQWcsgWF9R7E0c=; h=Date:From:Subject:In-reply-to:To:Cc:Message-id:MIME-version: Content-type:References; b=DK9CccEOcj9xe6+V3pOvkIf3Hje9KW9loOQNqgg8uIwvdo+Sfdz4e5Fd3FNCFC2cd GjygDgFA75BaBDod1nDDRSthp7NbR5k8bMcc5sc3f6cyoR2VyzCdVLO7t8vvDfUHyP m/4OmdF8uIqpLIKYarvPRPK5M7gj8KzRayNTUrj0= Date: Sun, 08 Nov 2009 21:39:13 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Sun, 08 Nov 2009 19:21:25 -0800 (PST)" To: Mark Crispin Message-id: <01NFV69TYP2I0002QL@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed Content-transfer-encoding: 7BIT References: <661875402.14422.1257637576746.JavaMail.root@dogfood.zimbra.com> <01NFUUE81PRK0002QL@mauve.mrochek.com> Cc: lemonade@ietf.org, Ned Freed Subject: Re: [lemonade] Clarification on LEMONADE "use" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 06:12:50 -0000 > > As one final example, although we have seen any number of requests for > > additional comparator capabilities (mostly ones that ignore or compress > > whitespace in some way), we have yet to receive a single request for > > i;unicode-casemap comparator support, so based on our experience in the > > field I see less than zero jusitification for its inclusion in the > > profile. > So much for i18n! :( First of all, this was in the context of Sieve, not IMAP. See RFC 5500, section 6. AFAIK the LEMONADE profile says nothing about supporting i;unicode-casemap in IMAP searches, although perhaps that's implicit in its requirement of support for ESEARCH or some other extension. Now, as for the impact on i18n, my observation has been that there's something of a gap between what the standards say needs to be done and what actual users ask for. This is a case in point - we have a lot of customers all over the world and we therefore take i18n issues pretty seriously, but the one comparator several groups really seem to want Sieve support for is the one that ignores whitespace. Why case-insensitivity isn't a comparable priority, I have no idea. > I think that is because hardly anyone uses IMAP SEARCH (nor, for that > matter, ENVELOPE and BODYSTRUCTURE). They all treat IMAP as a glorified > POP, and download messages to the client for subsequent processing. Since I wasn't talking about IMAP SEARCH this isn't especially relevant to the matter at hand, but FWIW, we support clients that make very heavy use of IMAP SEARCH, so much so that we've invested a lot of effort in preindexing support for it. Ned From mrcrispin@panda.com Sun Nov 8 19:21:02 2009 Return-Path: X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 588EF3A67DD for ; Sun, 8 Nov 2009 19:21:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGVTiDFDFL-A for ; Sun, 8 Nov 2009 19:21:01 -0800 (PST) Received: from Panda.COM (panda.com [206.124.149.114]) by core3.amsl.com (Postfix) with ESMTP id 62DC13A6A4E for ; Sun, 8 Nov 2009 19:21:01 -0800 (PST) Received: from hsinghsing.panda.com mrcrispin@Panda.COM [206.124.149.116] by Panda.COM with M+ Extreme Email Engine 2008.3.internal via secured & encrypted transport (TLS); Sun, 08 Nov 2009 19:21:26 -0800 X-MailFrom: mrcrispin@panda.com Date: Sun, 8 Nov 2009 19:21:25 -0800 (PST) From: Mark Crispin Sender: mrc@hsinghsing.panda.com To: Ned Freed In-Reply-To: <01NFUUE81PRK0002QL@mauve.mrochek.com> Message-ID: References: <661875402.14422.1257637576746.JavaMail.root@dogfood.zimbra.com> <01NFUUE81PRK0002QL@mauve.mrochek.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Mon, 09 Nov 2009 15:38:36 -0800 Cc: lemonade@ietf.org Subject: Re: [lemonade] Clarification on LEMONADE "use" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 03:52:30 -0000 On Sun, 8 Nov 2009, Ned Freed wrote: > Then I'm afraid you need to start being a lot more realistic about all this. +1 > That's simply not true. The LEMONADE profile includes any number of > things that are in no way essential to the effective operation of > clients in general and mobile clients in particular. +1 > As one final example, although we have seen any number of requests for > additional comparator capabilities (mostly ones that ignore or compress > whitespace in some way), we have yet to receive a single request for > i;unicode-casemap comparator support, so based on our experience in the > field I see less than zero jusitification for its inclusion in the > profile. So much for i18n! :( I think that is because hardly anyone uses IMAP SEARCH (nor, for that matter, ENVELOPE and BODYSTRUCTURE). They all treat IMAP as a glorified POP, and download messages to the client for subsequent processing. If matters were otherwise, the utterly broken IMAP servers of the world would have been fixed long ago. Curiously, we actually have a priority for i;unicode-casemap and SORT, but not for LEMONADE. -- 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. From arnt@gulbrandsen.priv.no Tue Nov 17 03:46:58 2009 Return-Path: X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 114BB3A68D1 for ; Tue, 17 Nov 2009 03:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADU2znRyAL6Y for ; Tue, 17 Nov 2009 03:46:57 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by core3.amsl.com (Postfix) with ESMTP id 37BD53A67EB for ; Tue, 17 Nov 2009 03:46:57 -0800 (PST) Received: from fri.gulbrandsen.priv.no (kalyani.aox.org [79.140.39.164]) by strange.aox.org (Postfix) with ESMTP id 44FA7FA075C for ; Tue, 17 Nov 2009 11:46:55 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no (HELO lochnagar.gulbrandsen.priv.no) by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.0) with esmtp id 1258458249-4938-4937/5/185 for lemonade@ietf.org; Tue, 17 Nov 2009 12:44:09 +0100 Message-Id: Date: Tue, 17 Nov 2009 12:48:09 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Content-Type: text/plain; format=flowed Mime-Version: 1.0 Subject: [lemonade] FUTURERELEASE syntax problem X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 11:46:58 -0000 Hi Gregory, Gregory and everyone, the futurerelease RFC contains a dangling production, so HOLDUNTIL is not well-defined. The syntax is of the date-time argument is not defined at this RFC, I can't find the same production name in any other RFC (I think I checked RFC[34]???.txt, or maybe all of them), and there is no example showing HOLDUNTIL usage either. HOLDFOR has a strict and usable definition (and HOLDFOR 30-60 seconds is a very nice way to defang mail loops, if I may say so). When I implemented HOLDFOR a few months ago, I sent both authors mail about the dangling production, and made HOLDUNTIL emit a 50x error. I am terribly sorry to be the one to raise this issue. Arnt From ned.freed@mrochek.com Tue Nov 17 07:50:32 2009 Return-Path: X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3005A3A6AB5 for ; Tue, 17 Nov 2009 07:50:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxQL2yDk8KXR for ; Tue, 17 Nov 2009 07:50:31 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id E0DF43A6968 for ; Tue, 17 Nov 2009 07:50:30 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; Format=flowed Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NG6WRDKROW004JE7@mauve.mrochek.com> for lemonade@ietf.org; Tue, 17 Nov 2009 07:50:24 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NG5R50KD680000BI@mauve.mrochek.com>; Tue, 17 Nov 2009 07:50:22 -0800 (PST) Message-id: <01NG6WRCCKXI0000BI@mauve.mrochek.com> Date: Tue, 17 Nov 2009 07:41:45 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Tue, 17 Nov 2009 12:48:09 +0100" References: To: Arnt Gulbrandsen DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1258472901; bh=3O8t7IUB19RBS5bCfpNQw0mqPd1tmltFqe5p0Da9vFM=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=sucF/sNwzCs0qiVIDyCsk4rXht+SAcR4kCIUgZmlF//sx1Jx9CH3kAEmZomrv1MqS 5C6Sv+Zpfr1NEhb3Bb2DmI/9LDydtwvZVXSXJn+FEs/OT3+9BDqhoC4p9Y4XDxMsek t0Q6YJMBNxx9JU1OSgjkc74ld8cHwc/2Q5IwJR4I= Cc: lemonade@ietf.org Subject: Re: [lemonade] FUTURERELEASE syntax problem X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 15:50:32 -0000 > Hi Gregory, Gregory and everyone, > the futurerelease RFC contains a dangling production, so HOLDUNTIL is > not well-defined. The syntax is of the date-time argument is not > defined at this RFC, The date-time production comes from RFC 3339, section 5.6, and there's a reference to that effect. So this isn't a problem. The issue here isn't the date-time prodution, but rather the Internet-style-date-time-UTC production refrenced by: future-release-date-time = Internet-style-date-time-UTC The fix is quite simple: future-release-date-time = date-time This can easily be addressed with an erratum. > I can't find the same production name in any other > RFC (I think I checked RFC[34]???.txt, or maybe all of them), and there > is no example showing HOLDUNTIL usage either. The lack of examples is indeed unfortunate. It should be noted and addressed in any future revision. > HOLDFOR has a strict and usable definition (and HOLDFOR 30-60 seconds is > a very nice way to defang mail loops, if I may say so). > When I implemented HOLDFOR a few months ago, I sent both authors mail > about the dangling production, and made HOLDUNTIL emit a 50x error. That seems ... excessive. Yes, the production is broken and there are no examples, but the intent here is quite clear, espectially if you go back and look at -03 of the I-D this came from: http://tools.ietf.org/html/draft-vaudreuil-futuredelivery-03 In that version it clearly states that the format of Internet-style-date-time-UTC comes from RFC 3339. The problem is simply that the production name didn't match the production name used in RFC 3339, and whoever did the find-and-replace to change Internet-style-date-time-UTC to date-time missed a spot. Ned From arnt@gulbrandsen.priv.no Tue Nov 17 08:13:55 2009 Return-Path: X-Original-To: lemonade@core3.amsl.com Delivered-To: lemonade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FDCF3A6849 for ; Tue, 17 Nov 2009 08:13:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMUpmHPXzwyn for ; Tue, 17 Nov 2009 08:13:53 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by core3.amsl.com (Postfix) with ESMTP id 77A8A3A6821 for ; Tue, 17 Nov 2009 08:13:53 -0800 (PST) Received: from fri.gulbrandsen.priv.no (kalyani.aox.org [79.140.39.164]) by strange.aox.org (Postfix) with ESMTP id D4887FA06F9; Tue, 17 Nov 2009 16:13:51 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no (HELO lochnagar.gulbrandsen.priv.no) by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.0) with esmtp id 1258474265-4938-4937/5/195 (3 recipients); Tue, 17 Nov 2009 17:11:05 +0100 Message-Id: Date: Tue, 17 Nov 2009 17:15:06 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org References: <01NG6WRCCKXI0000BI@mauve.mrochek.com> In-Reply-To: <01NG6WRCCKXI0000BI@mauve.mrochek.com> Content-Type: text/plain; format=flowed Mime-Version: 1.0 Cc: Ned Freed Subject: Re: [lemonade] FUTURERELEASE syntax problem X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 16:13:55 -0000 Ned Freed writes: > The issue here isn't the date-time prodution, but rather the > Internet-style-date-time-UTC production refrenced by: Right. (I didn't say date-time production, I said the date-time argument.) > future-release-date-time = Internet-style-date-time-UTC > > The fix is quite simple: > > future-release-date-time = date-time > > This can easily be addressed with an erratum. I'm happy if everyone agrees that this the intended syntax. >> When I implemented HOLDFOR a few months ago, I sent both authors mail >> about the dangling production, and made HOLDUNTIL emit a 50x error. > > That seems ... excessive. (Well, I didn't release it so far, so...) > Yes, the production is broken and there are no examples, but the > intent here is quite clear, espectially if you go back and look at > -03 of the I-D this came from: That's the kind of clarity I like when there's an erratum spelling it out, but not when I'm making educated guesses on my own. Arnt From wwwrun@core3.amsl.com Tue Nov 17 16:34:20 2009 Return-Path: X-Original-To: lemonade@ietf.org Delivered-To: lemonade@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id E50623A6898; Tue, 17 Nov 2009 16:34:20 -0800 (PST) From: Dean Willis(OMA) To: Glenn Parsons , Eric Burger , lemonade@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20091118003420.E50623A6898@core3.amsl.com> Date: Tue, 17 Nov 2009 16:34:20 -0800 (PST) Cc: Alexey Melnikov , Mike Parsel the OMA MWG Vice-Chair , Hubert Segond the OMA MEM Chair , Kyung-Tak Lee the OMA MWG Chair Subject: [lemonade] New Liaison Statement, "LS to IETF Lemonade Group on MEM Activity" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: OMA-LIAISON@mail.openmobilealliance.org List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 00:34:21 -0000 Title: LS to IETF Lemonade Group on MEM Activity Submission Date: 2009-11-17 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=617 From: Dean Willis(OMA) To: IETF Lemonade Working Group(Glenn Parsons , Eric Burger , lemonade@ietf.org) Cc: Lisa Dusseault Alexey Melnikov Reponse Contact: Kyung-Tak Lee the OMA MWG Chair Mike Parsel the OMA MWG Vice-Chair Hubert Segond the OMA MEM Chair Technical Contact: Kyung-Tak Lee the OMA MWG Chair Mike Parsel the OMA MWG Vice-Chair Hubert Segond the OMA MEM Chair Purpose: For information Body: 1 Overview This Liaison Statement is to update IETF Lemonade WG on the progress in OMA MWG-MEM and to inform the IETF group of the future of MEM. 2 Proposal The OMA MWG group would like to update you on the progress of the OMA MWG-MEM. Please find below the status and link to the latest versions of the relevant documents made by OMA MWG-MEM sub-working group: � The MEM 1.0 ERP for Candidate Approval has been ratified by the OMA Board in September 21 � The Candidate version of the MEM 1.0 Enabler has been uploaded to the public OMA portal as: http://www.openmobilealliance.org/Technical/release_program/mem_v1_0.aspx � In addition, Candidate approval has been sought for the Enabler Test Requirements associated with the release. And to inform the IETF Lemonade WG that the MWG-MEM group has been closed but any future MEM activity will continue under the OMA MWG WG. Therefore, any MEM-related matter should be addressed to MWG instead via the OMA liaison contact address. 3 Requested Action(s) IETF Lemonade WG is kindly invited to take notice of the Candidate ETR for MEM published in OMA Portal. 4 Conclusion OMA MWG group would like to thank the IETF LEMONADE group for their collaboration with MEM group during the last few years and its kind consideration of the present Liaison Statement and looks forward for continued collaboration in the future. Attachment(s): PDF of LS received from OMA (https://datatracker.ietf.org/documents/LIAISON/file737.pdf)