From lemonade-bounces@ietf.org Mon Oct 03 06:24:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMNUS-00088b-KW; Mon, 03 Oct 2005 06:24:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMNUQ-00088T-JB for lemonade@megatron.ietf.org; Mon, 03 Oct 2005 06:24:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18639 for ; Mon, 3 Oct 2005 06:24:08 -0400 (EDT) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMNcs-0002TA-Sr for lemonade@ietf.org; Mon, 03 Oct 2005 06:32:55 -0400 Received: from [172.16.2.132] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 3 Oct 2005 11:17:38 +0100 Message-ID: <43410540.1040503@isode.com> Date: Mon, 03 Oct 2005 11:17:36 +0100 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 MIME-Version: 1.0 To: Sam Hartman Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-burl-03.txt References: <6D44707AB39734523BAC9974@[10.1.110.5]> <433D5CA4.80406@isode.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: lemonade@ietf.org, Chris Newman X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Sam Hartman wrote: >I'm afraid that I'm going to have to insist on text similar to that >Chris proposes adding to the draft. I don't think an RFC 3501 >reference is sufficient. > > Duplicating requirements specified in another requirement is a bad thing, as documents can get out of sync. If a reader asks the question "what is a mandatory to implement authentication mechanism when a submit server talks to an IMAP server?", there is only one possible answer to this question if normative references from BURL are followed. I would insist that the text must be clarified to point out that the mandatory to implement authentication mechanism is taken from RFC 3501 by saying something like "As defined in RFC 3501 ..." >I think there are enough additional issues that have surfaced in this >discussion that it is clear to me that e are going beyond RFC 3501 in >what we say. I believe that is necessary and I believe that there is >no way to do so without duplication of 3501 text. > > BTW, I am fine with the rest of the Chris' text. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Oct 03 07:48:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMOoM-00062Z-RR; Mon, 03 Oct 2005 07:48:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMOoM-00062U-5e for lemonade@megatron.ietf.org; Mon, 03 Oct 2005 07:48:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22489 for ; Mon, 3 Oct 2005 07:48:49 -0400 (EDT) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMOwo-0004Mm-7b for lemonade@ietf.org; Mon, 03 Oct 2005 07:57:35 -0400 Received: from [172.16.2.132] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 3 Oct 2005 12:48:38 +0100 Message-ID: <43411A97.8090403@isode.com> Date: Mon, 03 Oct 2005 12:48:39 +0100 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 MIME-Version: 1.0 To: Lemonade WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Subject: [lemonade] Please review IMAP/SMTP extensions included in Lemonade profile Phase 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org As per discussion at Lemonade interim, Stephane and I would like to do the following changes to the Lemonade Profile Phase 1 document: 1). Add LITERAL+ 2). Remove quick reconnect (as the document is not ready) and add CONDSTORE (quick synchronization). 3). Removed POSTADDRESS (was an open issue), as it depends on LIST-EXTENDED, which is not quite done yet. Any objections to the change? Any additional changes? Thanks, Alexey _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Oct 03 09:06:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMQ1k-0005Sq-K3; Mon, 03 Oct 2005 09:06:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMQ1i-0005Sf-IE for lemonade@megatron.ietf.org; Mon, 03 Oct 2005 09:06:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27450 for ; Mon, 3 Oct 2005 09:06:40 -0400 (EDT) Received: from dsl-217-155-137-62.zen.co.uk ([217.155.137.62] helo=gw2.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMQAB-0006hm-0R for lemonade@ietf.org; Mon, 03 Oct 2005 09:15:28 -0400 Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by gw2.dave.cridland.net (Postfix) with ESMTP id A1314154015; Mon, 3 Oct 2005 13:06:01 +0000 (UTC) Date: Mon, 03 Oct 2005 14:05:55 +0100 Subject: Re: [lemonade] Please review IMAP/SMTP extensions included in Lemonade profile Phase 1 References: <43411A97.8090403@isode.com> In-Reply-To: <43411A97.8090403@isode.com> MIME-Version: 1.0 Message-Id: <24392.1128344761.311414@peirce.dave.cridland.net> From: Dave Cridland To: Alexey Melnikov Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Mon Oct 3 12:48:39 2005, Alexey Melnikov wrote: > As per discussion at Lemonade interim, Stephane and I would like to > do the following changes to the Lemonade Profile Phase 1 document: > > 1). Add LITERAL+ > 2). Remove quick reconnect (as the document is not ready) and add > CONDSTORE (quick synchronization). > 3). Removed POSTADDRESS (was an open issue), as it depends on > LIST-EXTENDED, which is not quite done yet. > > Any objections to the change? Any additional changes? I knew there was something else I meant to bring up. IDLE isn't present in the list of extensions. Given the comments made at the meeting about long-lived connections being better for mobile devices, and transmission being very costly to the battery, this suggests that IDLE is likely a requirement. Secondly, I think the examples need reworking such that the capability strings returned include all required extensions, and preferably no undefined ones (one example includes SCAN). Examples: A0051 (Page 6): Reviewed, appears fine to me. Note that explanatory paragraph following has mismatched parenthesis. A0052 (Page 6/7): a) Includes a Received and a Return-Path header, which seems unlikely b) Has an extraneous SP after " in first URL string. c) Format=flowed message C-T header has superfluous charset parameter, C-T-E is also superfluous. A0053: I didn't know $Forwarded could be applied to a message for which only some parts had been forwarded. I'm not sure we should be trying to complicate the issue by referring to keywords which haven't yet been standardized, without any reference. In any case, this flag shouldn't be set until after the ESMTP transaction has been completed, IMHO. A0054: This should use an EXPIRES - otherwise someone intercepting the ESMTP transaction traffic can resend the message to themselves. ESMTP Transaction (Page 7/8): Should use TLS. Server should be lemonade compliant, supporting all mandatory to implement extensions. b0002 (Page 11): I think this is being cut, but in any case, the capability strings include "SCAN", and do not include mandatory to implement Lemonade extensions. Dave. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Oct 03 11:02:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMRpM-0000IO-Li; Mon, 03 Oct 2005 11:02:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMRpL-0000I8-Gi for lemonade@megatron.ietf.org; Mon, 03 Oct 2005 11:02:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10129 for ; Mon, 3 Oct 2005 11:02:01 -0400 (EDT) Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMRxp-0001wa-5m for lemonade@ietf.org; Mon, 03 Oct 2005 11:10:50 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout2.cac.washington.edu (8.13.4+UW05.04/8.13.4+UW05.09) with ESMTP id j93F1vMM017423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 3 Oct 2005 08:01:57 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.4+UW05.04/8.13.4+UW05.09) with ESMTP id j93F1leJ004908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Oct 2005 08:01:56 -0700 Date: Mon, 3 Oct 2005 08:01:46 -0700 (PDT) From: Mark Crispin To: Alexey Melnikov Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-burl-03.txt In-Reply-To: <43410540.1040503@isode.com> Message-ID: References: <6D44707AB39734523BAC9974@[10.1.110.5]> <433D5CA4.80406@isode.com> <43410540.1040503@isode.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: 7655788c23eb79e336f5f8ba8bce7906 Cc: lemonade@ietf.org, Chris Newman , Sam Hartman X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Mon, 3 Oct 2005, Alexey Melnikov wrote: > I would insist that the text must be clarified to point out that the > mandatory to implement authentication mechanism is taken from RFC 3501 by > saying something like "As defined in RFC 3501 ..." This sounds like an acceptable compromise to me. Also, any text that exposits upon, or extends, what RFC 3501 says should be clearly marked as such. RFC 3501 requires blah blah blah. Among other things, this means blah blah blah. Furthermore, this document additionally requires blah blah blah. To express Alexey's concerns in another way, implementors need to understand what text is normative, and what is merely expository. We have bad experiences in the past when this has not been clear, particularly when text is duplicated. -- 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 Mon Oct 03 16:00:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMWUS-0004YK-QV; Mon, 03 Oct 2005 16:00:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMWUQ-0004Xx-J0 for lemonade@megatron.ietf.org; Mon, 03 Oct 2005 16:00:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29286 for ; Mon, 3 Oct 2005 16:00:44 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMWcw-0002in-Pd for lemonade@ietf.org; Mon, 03 Oct 2005 16:09:36 -0400 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j93JtRdt014000 for ; Mon, 3 Oct 2005 15:00:27 -0500 (CDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 3 Oct 2005 14:55:12 -0500 Message-ID: <54E40201497DF142B06B27255953F797185F5B01@il0015exch007u.ih.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: lemonade@ietf.org Date: Mon, 3 Oct 2005 14:55:07 -0500 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: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [lemonade] GV review of draft-ietf-lemonade-mms-mapping-05.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org I have reviewed the recently posted -05 version of this document and have the following comments. My comments from earlier reviews have been addressed. Formatting issue: The tables are given their own section, but because they are not true sections, it makes it hard to figure out which section to cite for these comments. I will assume the tables do not begin a new section for the purposes of these comments. The practice also makes the TOC overly complex. Section 2.1.3.2 Future Delivery is a bit squishy, here and in section 2.1.3.3. Because it may be possible to consider the gateway to be a submitting UA in the general model, the first-hop MTA after the gateway can be considered the submission server. Whether this makes sense or not is besides the point. I suggest the following text for handing an MMS with the X-Mms-delivery-time header: "Future Delivery is a submission facility and does not provide for passing the delivery-time to the final system. If the Gateway recieves a message with an X-Mms-delivery-time header, the gateway is responsible for ensuring that the message is held until the appointed time. If the next-hop MTA supports the deliver-after SMTP extension, the gateway may map the X-MMs-Delivery-time header to the SMTP deliver-after parameter." There are a number of places in this section where there are requirements that are redundant with the base SMTP and MSG-FMT specifications. I'd prefer to see language in the flavor of an implementors note with reference rather than using the normative "MUST and SHOULD" conventions. Examples are "The address(es) in the 'From:' header SHOULD be in the form of fully-qualified domains." I'd prefer text here and elsewhere of the form "From: headers should be fully compliant to the requirements in [MSG-FMT]." I don't recall that MMS permits sending of unencoded 8-bit characters in addresses. If it does, and that is the motivation for the discussion of 8-bit header encoding, then please note that explicitly. Otherwise, the discussion of 8-bit text in addresses seems to cause confusion. Address-hiding. This document makes the default action to unhide an address and forward the message. It seems that as a matter of policy, one may chose to do the opposite, that is, to return a message to sender rather than disclose what was requested to remain hidden. At a minimum, we need text here or in the security considerations section to make clear that there is a trade-off between maximum interoperability and the need to protect identity as supported by the address hiding header. Section 2.1.3.3 Future Delivery: It may seem odd, but I can imagine the MMS gateway being used as a submission server for certian mobile clients. In such a case, it makes perfect sense to accept a deliver-after SMTP parameter and map it onto an X-Mms-delivery-time if the next hop is an MMS relay. Priority: I don't recall the discussion on why we agreed to support both importance and X-priority. Assuming we agreed to retain both, there needs to be text following the table defining what action to take where an X-priority and Importance header contradict. I suggest "If the X-priority and X-importance value conflict, the value included in the importance header takes precidence" Security Considerations Again, we need some text discussing address hiding, a security consideration unique to the interaction between the two services. Might also find similar with reverse-charging providing a revenue-leak. Both of these unsupported features are unsupported in Internet mail precisely because they are hard to do securely across administrative domains. References: Two places discuss future delivery without making a helpful informative reference to the ID. I'd suggest an additional reference. Greg V. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Oct 04 10:50:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMo7u-00075x-Tq; Tue, 04 Oct 2005 10:50:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMo7H-0006vX-DQ; Tue, 04 Oct 2005 10:50:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24557; Tue, 4 Oct 2005 10:50:00 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMoFx-0003AU-My; Tue, 04 Oct 2005 10:59:02 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EMo7F-0007jS-Jl; Tue, 04 Oct 2005 10:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 04 Oct 2005 10:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-urlauth-08.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. Title : Internet Message Access Protocol (IMAP) - URLAUTH Extension Author(s) : M. Crispin Filename : draft-ietf-lemonade-urlauth-08.txt Pages : 5 Date : 2005-10-4 This document describes the URLAUTH extension to the Internet Message Access Protocol (IMAP) (RFC 3501) and the IMAP URL Scheme (IMAPURL) (RFC 2192). This extension provides a means by which an IMAP client can use URLs carrying authorization to access limited message data on the IMAP server. An IMAP server which supports this extension indicates this with a capability name of "URLAUTH". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-urlauth-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-urlauth-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-urlauth-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-4101801.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-urlauth-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-urlauth-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-4101801.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --NextPart-- From lemonade-bounces@ietf.org Tue Oct 04 11:40:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMou2-0005bM-JS; Tue, 04 Oct 2005 11:40:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMou1-0005b2-0N for lemonade@megatron.ietf.org; Tue, 04 Oct 2005 11:40:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03467 for ; Tue, 4 Oct 2005 11:40:22 -0400 (EDT) Received: from mxout7.cac.washington.edu ([140.142.32.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMp2h-0006gs-D0 for lemonade@ietf.org; Tue, 04 Oct 2005 11:49:24 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout7.cac.washington.edu (8.13.4+UW05.04/8.13.4+UW05.09) with ESMTP id j94FeKrt028595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 4 Oct 2005 08:40:20 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.4+UW05.04/8.13.4+UW05.09) with ESMTP id j94Fe8te030809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 4 Oct 2005 08:40:20 -0700 Date: Tue, 4 Oct 2005 08:40:08 -0700 (PDT) From: Mark Crispin To: lemonade@ietf.org Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-urlauth-08.txt In-Reply-To: Message-ID: References: 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: 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org This draft supposedly addresses all the issues raised by the IESG, but as it was primarily a solo effort on my part it needs review by the WG. -- 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 Oct 04 18:55:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMvgg-0000Ae-IP; Tue, 04 Oct 2005 18:55:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMvgf-0000AZ-UT for lemonade@megatron.ietf.org; Tue, 04 Oct 2005 18:55:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15090 for ; Tue, 4 Oct 2005 18:55:02 -0400 (EDT) Received: from warlock.qualcomm.com ([129.46.50.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMvpR-0007Mt-2k for lemonade@ietf.org; Tue, 04 Oct 2005 19:04:09 -0400 Received: from [10.104.191.153] (loud.qualcomm.com [129.46.172.15]) by warlock.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j94Msm7S029043; Tue, 4 Oct 2005 15:54:49 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <54E40201497DF142B06B27255953F797185F5B01@il0015exch007u.ih.lucent.com > References: <54E40201497DF142B06B27255953F797185F5B01@il0015exch007u.ih.lucent.com > X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Tue, 4 Oct 2005 15:54:38 -0700 To: "Vaudreuil, Greg M (Greg)" , lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] GV review of draft-ietf-lemonade-mms-mapping-05.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Hi Greg, Thanks for the review. At 2:55 PM -0500 10/3/05, Greg M (Greg) Vaudreuil wrote: > I have reviewed the recently posted -05 version of this document > and have the following comments. My comments from earlier reviews > have been addressed. Please note that -05 was actually written a couple of week ago, and was posted to the list. There was a problem with the formal I-D publication, which is why the notice was just sent now. So, -05 is *not* the -06 that I am about to post. > > Formatting issue: The tables are given their own section, but > because they are not true sections, it makes it hard to figure out > which section to cite for these comments. I will assume the tables > do not begin a new section for the purposes of these comments. The > practice also makes the TOC overly complex. > > Section 2.1.3.2 > > Future Delivery is a bit squishy, here and in section 2.1.3.3. > Because it may be possible to consider the gateway to be a > submitting UA in the general model, the first-hop MTA after the > gateway can be considered the submission server. Whether this > makes sense or not is besides the point. I suggest the following > text for handing an MMS with the X-Mms-delivery-time header: > "Future Delivery is a submission facility and does not provide for > passing the delivery-time to the final system. If the Gateway > recieves a message with an X-Mms-delivery-time header, the gateway > is responsible for ensuring that the message is held until the > appointed time. If the next-hop MTA supports the deliver-after > SMTP extension, the gateway may map the X-MMs-Delivery-time header > to the SMTP deliver-after parameter." I don't want to reference future-delivery since that will delay publication, and we already have 3GPP2 documents waiting on this document. > > > There are a number of places in this section where there are > requirements that are redundant with the base SMTP and MSG-FMT > specifications. I'd prefer to see language in the flavor of an > implementors note with reference rather than using the normative > "MUST and SHOULD" conventions. Examples are "The address(es) in > the 'From:' header SHOULD be in the form of fully-qualified > domains." I'd prefer text here and elsewhere of the form "From: > headers should be fully compliant to the requirements in [MSG-FMT]." If you want to send me the examples from -06 where these should be changed, I can reword them to something like "per [reference], blah blah blah MUST be done", or maybe "blah MUST be fully compliant to [reference], including blah blah blah". Just saying "fully compliant" doesn't really help, I think. > > I don't recall that MMS permits sending of unencoded 8-bit > characters in addresses. If it does, and that is the motivation for > the discussion of 8-bit header encoding, then please note that > explicitly. Otherwise, the discussion of 8-bit text in addresses > seems to cause confusion. This text has been reworded in -06, please review that. > > Address-hiding. This document makes the default action to unhide an > address and forward the message. It seems that as a matter of > policy, one may chose to do the opposite, that is, to return a > message to sender rather than disclose what was requested to remain > hidden. At a minimum, we need text here or in the security > considerations section to make clear that there is a trade-off > between maximum interoperability and the need to protect identity > as supported by the address hiding header. I added text that "A message that contains an 'X-Mms-Sender-Visibility:' header with a value of 'Hide' SHOULD be rejected." > > Section 2.1.3.3 > > Future Delivery: It may seem odd, but I can imagine the MMS gateway > being used as a submission server for certian mobile clients. In > such a case, it makes perfect sense to accept a deliver-after SMTP > parameter and map it onto an X-Mms-delivery-time if the next hop is > an MMS relay. This can be added to a revision of the document after future delivery is standardized. > > Priority: I don't recall the discussion on why we agreed to > support both importance and X-priority. Assuming we agreed to > retain both, there needs to be text following the table defining > what action to take where an X-priority and Importance header > contradict. I suggest "If the X-priority and X-importance value > conflict, the value included in the importance header takes > precidence" This text was added to -06 in the Internet Mail to MMS case. All mention of X-Priority was deleted from -06 in the MMS to Internet mail direction. > > Security Considerations > > Again, we need some text discussing address hiding, a security > consideration unique to the interaction between the two services. > Might also find similar with reverse-charging providing a > revenue-leak. Both of these unsupported features are unsupported > in Internet mail precisely because they are hard to do securely > across administrative domains. The document says: Some MMS features contain inherently more risk than others, including reply charging and sender address hiding. Support for these mechanisms are not included in this document. Is there other text you'd like to see? > > References: > > Two places discuss future delivery without making a helpful > informative reference to the ID. I'd suggest an additional > reference. -06 only has one occurrence of the word "future", and I don't think it needs a reference. Please have a look at -06 and see if you still feel the need for a reference. Note that any reference would need to be informative and vague to avoid delaying publication. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- People demand freedom of speech to make up for the freedom of thought which they avoid. --Kierkegaard _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Oct 04 19:06:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMvsA-000440-Np; Tue, 04 Oct 2005 19:06:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMvs8-00043s-NK for lemonade@megatron.ietf.org; Tue, 04 Oct 2005 19:06:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15448 for ; Tue, 4 Oct 2005 19:06:53 -0400 (EDT) Received: from warlock.qualcomm.com ([129.46.50.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMw0u-0007ZY-Ej for lemonade@ietf.org; Tue, 04 Oct 2005 19:16:00 -0400 Received: from [10.104.191.153] (loud.qualcomm.com [129.46.172.15]) by warlock.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j94N6i7S001414 for ; Tue, 4 Oct 2005 16:06:45 -0700 (PDT) Mime-Version: 1.0 Message-Id: X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Tue, 4 Oct 2005 16:05:36 -0700 To: Lemonade From: Randall Gellens Subject: [lemonade] Updated (-06) MMS-Mappings Draft Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org As promised, I've prepared an -06 revision of the MMS Mappings draft. It should appear in the I-D directory soon, but in the meantime it is available at . Also, a diff from -05 is available at . -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- It is not enough to write in Yiddish; one must have something to say. --Y.L. Peretz _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Oct 04 19:45:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMwT1-0001BW-TC; Tue, 04 Oct 2005 19:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMwT0-0001AN-6A for lemonade@megatron.ietf.org; Tue, 04 Oct 2005 19:45:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16497 for ; Tue, 4 Oct 2005 19:44:58 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMwbk-0008EG-Ua for lemonade@ietf.org; Tue, 04 Oct 2005 19:54:06 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j94NihBG018235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Oct 2005 16:44:44 -0700 (PDT) Received: from [10.104.191.153] (loud.qualcomm.com [129.46.172.15]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j94NidS3014496; Tue, 4 Oct 2005 16:44:40 -0700 (PDT) Mime-Version: 1.0 Message-Id: X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Tue, 4 Oct 2005 16:44:36 -0700 To: "Stephane H. Maes" , Alexey Melnikov , Lemonade 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: 8b30eb7682a596edff707698f4a80f7d Cc: Subject: [lemonade] AIs for Suggested Text for 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Completing two action items from London: (1) Text for Profile section 2.8 on why CHUNKING is needed: 2.8 CHUNKING Support Lemonade-compliant servers MUST support the CHUNKING extension [reference]. Supporting both CHUNKING and BURL allows clients create a new message containing all or part of a previously-received message without needing to first compose a new message using CATENATE. (2) Text for Profile on why sending URLAUTH over unprotected link is never worse than sending actual text, and is better if a role restriction is used; maybe a new section 8.1 on submission (moving current 8.1 to 8.2): 8.1 Confidentiality Protection of Submitted Messages When clients submit new messages, link protection such as TLS guards against an eavesdropper seeing the contents of the submitted message. It's worth noting, however, that even if TLS is not used, the security risks are no worse if BURL is used to reference the text than if the text is submitted directly. If BURL is not used, an eavesdropper gains access to the full text of the message. If BURL is used, the eavesdropper may or may not be able to gain such access, depending on the form of BURL used. For example, some forms restrict use of the URL to an entity authorized as a submission server or a specific user. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- A server is only as secure as its dumbest administrator --Steve Dorner _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Oct 05 05:53:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN5xf-0006c4-UI; Wed, 05 Oct 2005 05:53:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN5xd-0006bv-Ua for lemonade@megatron.ietf.org; Wed, 05 Oct 2005 05:53:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10264 for ; Wed, 5 Oct 2005 05:53:15 -0400 (EDT) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EN66U-0005l2-21 for lemonade@ietf.org; Wed, 05 Oct 2005 06:02:27 -0400 Received: from [172.16.2.142] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 5 Oct 2005 10:52:18 +0100 Message-ID: <4343A252.1040508@isode.com> Date: Wed, 05 Oct 2005 10:52:18 +0100 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: Randall Gellens References: In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: Lemonade , "Stephane H. Maes" Subject: [lemonade] Re: AIs for Suggested Text for 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Randall Gellens wrote: > Completing two action items from London: Thanks for the text! > (1) Text for Profile section 2.8 on why CHUNKING is needed: > > 2.8 CHUNKING Support > > Lemonade-compliant servers MUST support the CHUNKING extension > [reference]. Supporting both CHUNKING and BURL allows clients create > a new message containing all or part of a previously-received message > without needing to first compose a new message using CATENATE. I've added this to 2.5 instead. There were already some text there talking about CHUNKING. > (2) Text for Profile on why sending URLAUTH over unprotected link is > never worse than sending actual text, and is better if a role > restriction is used; maybe a new section 8.1 on submission (moving > current 8.1 to 8.2): Added as 8.1. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Oct 05 16:12:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENFd5-0001OK-7L; Wed, 05 Oct 2005 16:12:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENFH9-00052l-RL; Wed, 05 Oct 2005 15:50:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13741; Wed, 5 Oct 2005 15:50:01 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENFQ5-00063F-ED; Wed, 05 Oct 2005 15:59:18 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ENFH8-0008VM-1T; Wed, 05 Oct 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 05 Oct 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-mms-mapping-06.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org 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 : Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail Author(s) : R. Gellens Filename : draft-ietf-lemonade-mms-mapping-06.txt Pages : 34 Date : 2005-10-5 The cellular telephone industry has defined a service known as the Multimedia Messaging Service (MMS). This service uses formats and protocols which are similar to, but differ in key ways from, those used in Internet mail. One important difference between MMS and Internet Mail is that MMS uses headers which start with "X-Mms-" to carry a variety of user agent and server related information elements. This document specifies how to exchange messages between these two services, including mapping information elements as used in MMS X-Mms-* headers as well as delivery and disposition reports, to and from that used in SMTP and Internet message headers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-mms-mapping-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-mms-mapping-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-mms-mapping-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-5114257.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-mms-mapping-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-mms-mapping-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-5114257.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 Oct 06 07:18:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENTlh-0006di-Nd; Thu, 06 Oct 2005 07:18:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENTlf-0006dd-Oa for lemonade@megatron.ietf.org; Thu, 06 Oct 2005 07:18:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25376 for ; Thu, 6 Oct 2005 07:18:30 -0400 (EDT) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENTuj-0002Be-DN for lemonade@ietf.org; Thu, 06 Oct 2005 07:27:54 -0400 Received: from [172.16.2.187] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 6 Oct 2005 12:18:04 +0100 Message-ID: <434507EC.8040306@isode.com> Date: Thu, 06 Oct 2005 12:18:04 +0100 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 MIME-Version: 1.0 To: Dave Cridland Subject: Re: [lemonade] Please review IMAP/SMTP extensions included in Lemonade profile Phase 1 References: <43411A97.8090403@isode.com> <24392.1128344761.311414@peirce.dave.cridland.net> In-Reply-To: <24392.1128344761.311414@peirce.dave.cridland.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Dave Cridland wrote: > Examples: > > A0051 (Page 6): Reviewed, appears fine to me. Note that explanatory > paragraph following has mismatched parenthesis. Fixed, thanks. > A0052 (Page 6/7): > a) Includes a Received and a Return-Path header, which seems unlikely We are forwarding a received message. > b) Has an extraneous SP after " in first URL string. Fixed, thanks. > c) Format=flowed message C-T header has superfluous charset parameter, > C-T-E is also superfluous. I would rather not change the messages, as this would affect byte counts. > A0053: I didn't know $Forwarded could be applied to a message for > which only some parts had been forwarded. The example if effectively forwarding the whole message. Plus it adds a textual annotation to it. > I'm not sure we should be trying to complicate the issue by referring > to keywords which haven't yet been standardized, without any reference. This is easy to fix, if people want me to address the issue. I can extract the relevant text from draft-melnikov-imap-keywords-03.txt and add it to Lemonade Profile, or publish as a separate document. > In any case, this flag shouldn't be set until after the ESMTP > transaction has been completed, IMHO. Fixed. > A0054: This should use an EXPIRES - otherwise someone intercepting the > ESMTP transaction traffic can resend the message to themselves. [I wish URLAUTH had an example that I could use ;-).] Done _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Oct 06 09:03:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENVOy-0000se-A6; Thu, 06 Oct 2005 09:03:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENVOx-0000sZ-0b for lemonade@megatron.ietf.org; Thu, 06 Oct 2005 09:03:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00954 for ; Thu, 6 Oct 2005 09:03:09 -0400 (EDT) Received: from dsl-217-155-137-62.zen.co.uk ([217.155.137.62] helo=gw2.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENVY0-0006gR-Er for lemonade@ietf.org; Thu, 06 Oct 2005 09:12:34 -0400 Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by gw2.dave.cridland.net (Postfix) with ESMTP id 6E35315401F; Thu, 6 Oct 2005 13:02:49 +0000 (UTC) Date: Thu, 06 Oct 2005 14:02:48 +0100 Subject: Re: [lemonade] Please review IMAP/SMTP extensions included in Lemonade profile Phase 1 References: <43411A97.8090403@isode.com> <24392.1128344761.311414@peirce.dave.cridland.net> <434507EC.8040306@isode.com> In-Reply-To: <434507EC.8040306@isode.com> MIME-Version: 1.0 Message-Id: <8591.1128603769.385097@peirce.dave.cridland.net> From: Dave Cridland To: Alexey Melnikov Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Thu Oct 6 12:18:04 2005, Alexey Melnikov wrote: > Dave Cridland wrote: >> A0052 (Page 6/7): >> a) Includes a Received and a Return-Path header, which seems >> unlikely > > We are forwarding a received message. > > Sort of. You're forwarding an attachment of an existing message. Certainly my implementation wouldn't copy trace headers in this instance. I think you'd need Resent-From, etc, if you're submitting a message with trace headers, and I'm dubious that using a Return-Path: pointing to Bob is correct in this case. Moreover, I think you risk confusing client implementors into thinking they should insert trace headers themselves. And to *really* nitpick, I'm most impressed that Bob can forward a message two seconds before it's arrived. Now I know what future delivery really means... ;-) >> c) Format=flowed message C-T header has superfluous charset >> parameter, C-T-E is also superfluous. > > I would rather not change the messages, as this would affect byte > counts. > > I'm nitpicking, I know. Would this help? [...] (TEXT {462} I: + Ready for literal data M: Message-ID: <419399E1.6000505@example.org> M: Date: Thu, 12 Nov 2004 16:57:05 +0000 M: From: Bob Ar M: MIME-Version: 1.0 M: To: foo@example.net M: Subject: About our holiday trip M: Content-Type: multipart/mixed; M: boundary="------------030308070208000400050907" M: M: --------------030308070208000400050907 M: Content-Type: text/plain; format=flowed M: M: Our travel agent has sent the updated schedule. M: M: Cheers, M: Bob M: M: --------------030308070208000400050907 M: URL [...] I've stripped out the trace headers, any redundant MIME parameters and headers, and removed the X- prefixed header. Don't ask me why it comes out only 62% of the size. >> A0053: I didn't know $Forwarded could be applied to a message for >> which only some parts had been forwarded. > > The example if effectively forwarding the whole message. Plus it > adds a textual annotation to it. > > I'm not quite sure I agree. >> I'm not sure we should be trying to complicate the issue by >> referring to keywords which haven't yet been standardized, without >> any reference. > > This is easy to fix, if people want me to address the issue. > I can extract the relevant text from > draft-melnikov-imap-keywords-03.txt and add it to Lemonade Profile, > or publish as a separate document. > > Entirely up to the panel - I use $Forwarded anyway, and I'm quite happy with it. 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 Oct 06 15:51:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENblu-00076S-5a; Thu, 06 Oct 2005 15:51:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENbkm-0006Xr-JW; Thu, 06 Oct 2005 15:50:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26714; Thu, 6 Oct 2005 15:50:05 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENbtq-0007uB-Ec; Thu, 06 Oct 2005 15:59:31 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ENbkg-0002qL-7p; Thu, 06 Oct 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 06 Oct 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-rfc2192bis-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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. Title : IMAP URL Scheme Author(s) : A. Melnikov, et al. Filename : draft-ietf-lemonade-rfc2192bis-00.txt Pages : 20 Date : 2005-10-6 IMAP [IMAP4] is a rich protocol for accessing remote message stores. It provides an ideal mechanism for accessing public mail- ing list archives as well as private and shared message stores. This document defines a URL scheme for referencing objects on an IMAP server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-rfc2192bis-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-rfc2192bis-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-rfc2192bis-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: <2005-10-6133219.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-rfc2192bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-rfc2192bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-6133219.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 Oct 10 15:50:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP3fF-0005Hp-S3; Mon, 10 Oct 2005 15:50:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP3et-0005AE-FG; Mon, 10 Oct 2005 15:50:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17017; Mon, 10 Oct 2005 15:50:01 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EP3oq-0006dG-QB; Mon, 10 Oct 2005 16:00:21 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EP3er-0002MP-Vs; Mon, 10 Oct 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 10 Oct 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-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: , Sender: lemonade-bounces@ietf.org 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-00.txt Pages : 13 Date : 2005-10-10 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-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-convert-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-convert-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: <2005-10-10110036.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-convert-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-convert-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-10110036.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 Oct 10 18:37:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP6Gy-0002pm-Vu; Mon, 10 Oct 2005 18:37:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP6Gx-0002ph-L1 for lemonade@megatron.ietf.org; Mon, 10 Oct 2005 18:37:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00042 for ; Mon, 10 Oct 2005 18:37:28 -0400 (EDT) Received: from warlock.qualcomm.com ([129.46.50.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EP6Qv-0003rU-Po for lemonade@ietf.org; Mon, 10 Oct 2005 18:47:51 -0400 Received: from [192.168.1.13] (loud.qualcomm.com [129.46.172.15]) by warlock.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j9AMbC7S012304; Mon, 10 Oct 2005 15:37:13 -0700 (PDT) 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, 10 Oct 2005 15:37:01 -0700 To: Mark Crispin , lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-urlauth-08.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org At 8:40 AM -0700 10/4/05, Mark Crispin wrote: > This draft supposedly addresses all the issues raised by the IESG, > but as it was primarily a solo effort on my part it needs review by > the WG. I've reviewed the changes and they look good to me. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- There is a life-size picture of a dogcow conveniently located in the Finder. Look under "Page Setup..." Now look under "Options." Like any talented dog, it can do flips. Like any talented cow, it can do precision bitmap alignment. --Apple Tech Note #31 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Oct 10 20:03:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP7bz-0004sH-V5; Mon, 10 Oct 2005 20:03:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP7by-0004rI-Dt for lemonade@megatron.ietf.org; Mon, 10 Oct 2005 20:03:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03220 for ; Mon, 10 Oct 2005 20:03:17 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EP7lx-0005fY-HT for lemonade@ietf.org; Mon, 10 Oct 2005 20:13:38 -0400 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j9B034vb014670 for ; Mon, 10 Oct 2005 19:03:06 -0500 (CDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 10 Oct 2005 19:03:04 -0500 Message-ID: <54E40201497DF142B06B27255953F797188569C9@il0015exch007u.ih.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: lemonade@ietf.org Date: Mon, 10 Oct 2005 19:03:03 -0500 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: 7aefe408d50e9c7c47615841cb314bed Subject: [lemonade] Future Delivery Date-time Syntax X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org I am soliciting opinions on which date-time syntax to use. Clients already are familar with RFC 2822 date-time. However, RFC 3339 (new protocols should...) and previous discussion on this list suggest that the format defined in 3339 be used. Preferences? Greg V. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Oct 10 20:18:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP7qg-0007uH-3h; Mon, 10 Oct 2005 20:18:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP7qe-0007u9-Ls for lemonade@megatron.ietf.org; Mon, 10 Oct 2005 20:18:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03997 for ; Mon, 10 Oct 2005 20:18:27 -0400 (EDT) Received: from mxout4.cac.washington.edu ([140.142.33.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EP80Y-00066D-FV for lemonade@ietf.org; Mon, 10 Oct 2005 20:28:45 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout4.cac.washington.edu (8.13.4+UW05.04/8.13.4+UW05.09) with ESMTP id j9B0IHOF025665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Oct 2005 17:18:18 -0700 X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.4+UW05.04/8.13.4+UW05.09) with ESMTP id j9B0IHdf009604 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 10 Oct 2005 17:18:17 -0700 Date: Mon, 10 Oct 2005 17:18:17 -0700 (Pacific Daylight Time) From: Mark Crispin To: "Vaudreuil, Greg M (Greg)" Subject: Re: [lemonade] Future Delivery Date-time Syntax In-Reply-To: <54E40201497DF142B06B27255953F797188569C9@il0015exch007u.ih.lucent.com> Message-ID: References: <54E40201497DF142B06B27255953F797188569C9@il0015exch007u.ih.lucent.com> 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='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Mon, 10 Oct 2005, Vaudreuil, Greg M (Greg) wrote: > I am soliciting opinions on which date-time syntax to use. Clients > already are familar with RFC 2822 date-time. However, RFC 3339 (new > protocols should...) and previous discussion on this list suggest that > the format defined in 3339 be used. As tempting as it is to use RFC 2822 format, the arguments in favor of RFC 3339 are compelling. Among other things: . it has the heavy weight of standardization . it's ISO 8601 . it omits redundant data (day of week) and avoids the "Anglo-centric" flamewars for names of months . it doesn't have embedded spaces (this is a big one for me) RFC 3339 does have some bugs (it refers to a nonexistant year "0000AD"), but it seems to be a definite step in the right direction. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Oct 10 20:55:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP8QP-00083M-Uk; Mon, 10 Oct 2005 20:55:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP8QN-00083H-VR for lemonade@megatron.ietf.org; Mon, 10 Oct 2005 20:55:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05653 for ; Mon, 10 Oct 2005 20:55:22 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EP8aO-00075j-Hr for lemonade@ietf.org; Mon, 10 Oct 2005 21:05:44 -0400 Received: from dm-usca19-13.red.iplanet.com (host-179-56-18-192.iplanet.com [192.18.56.179] (may be forged)) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j9B0tMvD016989; Mon, 10 Oct 2005 18:55:22 -0600 (MDT) Received: from we-gotmail.red.iplanet.com (gotmail-2.red.iplanet.com [192.18.73.252]) by dm-usca19-13.red.iplanet.com (8.11.7p1+Sun/8.11.7/IPLANET,v1.2) with ESMTP id j9B0tMU09791; Mon, 10 Oct 2005 17:55:22 -0700 (PDT) Received: from [192.18.127.162] (dhcp-usca15-127-162.red.iplanet.com [192.18.127.162]) by we-gotmail.red.iplanet.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTPSA id <0IO600J057W7LZ00@we-gotmail.red.iplanet.com>; Mon, 10 Oct 2005 17:55:21 -0700 (PDT) Date: Mon, 10 Oct 2005 17:54:46 -0700 (Pacific Daylight Time) From: Anil SRIVASTAVA Subject: Re: [lemonade] Future Delivery Date-time Syntax In-reply-to: <54E40201497DF142B06B27255953F797188569C9@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.63 - Got Pine? Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Accept-Language: English; en X-Message-Class: normal X-Endorsement: This message brought to you by Sun Java System Messaging Server 6.2 References: <54E40201497DF142B06B27255953F797188569C9@il0015exch007u.ih.lucent.com> X-Message-flag: Outlook: the best virus distribution system around X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7BIT 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On 2005-10-10/19:03 [-0500], gregv@lucent.com [Vaudreuil, Greg M (Greg)] wrote: > > I am soliciting opinions on which date-time syntax to use. Clients > already are familar with RFC 2822 date-time. However, RFC 3339 (new > protocols should...) and previous discussion on this list suggest that > the format defined in 3339 be used. RFC3399 should be the syntax used for future-delivery. The fact that is the proposed standard for time for Internet protcols is big one in its favor. > > Preferences? > > Greg V. > > > _______________________________________________ > 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 Tue Oct 11 01:20:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPCZH-0004Sm-6G; Tue, 11 Oct 2005 01:20:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPCZF-0004RB-LA for lemonade@megatron.ietf.org; Tue, 11 Oct 2005 01:20:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15853 for ; Tue, 11 Oct 2005 01:20:48 -0400 (EDT) Received: from monkey.teamware.com ([62.61.83.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPCjH-0004S2-5y for lemonade@ietf.org; Tue, 11 Oct 2005 01:31:12 -0400 Received: from intrepid (intrepid.teamw.com [10.142.128.11]) by monkey.teamware.com (8.11.6/8.11.6) with ESMTP id j9B5SOV29874 for ; Tue, 11 Oct 2005 08:28:24 +0300 Received: from [10.142.130.127] ([10.142.130.127]) by intrepid with ESMTP id mab8vtai; 11 Oct 2005 08:31:00 +0300 Message-ID: <434B4B2F.9050305@teamware.com> Date: Tue, 11 Oct 2005 08:18:39 +0300 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: lemonade@ietf.org Subject: Re: [lemonade] Future Delivery Date-time Syntax References: <54E40201497DF142B06B27255953F797188569C9@il0015exch007u.ih.lucent.com> In-Reply-To: <54E40201497DF142B06B27255953F797188569C9@il0015exch007u.ih.lucent.com> X-TWG-MDN: none 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=-2.688, required 5, autolearn=disabled, ALL_TRUSTED -2.82, AWL 0.10, WORKSTATION_NAME6 0.03) X-MailScanner-From: adb@teamware.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Vaudreuil, Greg M (Greg) wrote: > I am soliciting opinions on which date-time syntax to use. Clients already > are familar with RFC 2822 date-time. However, RFC 3339 (new protocols > should...) and previous discussion on this list suggest that the format > defined in 3339 be used. > > Preferences? 3339. Antony _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Oct 11 03:54:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPEyC-0001EZ-Q0; Tue, 11 Oct 2005 03:54:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPEyA-0001EU-Ja for lemonade@megatron.ietf.org; Tue, 11 Oct 2005 03:54:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06296 for ; Tue, 11 Oct 2005 03:54:40 -0400 (EDT) Received: from dsl-217-155-137-62.zen.co.uk ([217.155.137.62] helo=gw2.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPF8D-0008HS-RB for lemonade@ietf.org; Tue, 11 Oct 2005 04:05:07 -0400 Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by gw2.dave.cridland.net (Postfix) with ESMTP id 5DCB015400B; Tue, 11 Oct 2005 07:54:12 +0000 (UTC) Date: Tue, 11 Oct 2005 08:54:10 +0100 Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-urlauth-08.txt References: In-Reply-To: MIME-Version: 1.0 Message-Id: <26342.1129017252.055254@peirce.dave.cridland.net> From: Dave Cridland To: Mark Crispin Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Tue Oct 4 02:40:08 2005, Mark Crispin wrote: > This draft supposedly addresses all the issues raised by the IESG, > but as it was primarily a solo effort on my part it needs review by > the WG. Nit: Section 2, first para, missing quote before ;EXPIRES=" Otherwise, all looks fine to me. Dave. -- Dave Cridland - using Infotrope Polymer http://dave.cridland.net/acap/polymer.html _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Oct 11 03:58:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPF1k-0002C9-OC; Tue, 11 Oct 2005 03:58:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPF1i-0002By-Jk for lemonade@megatron.ietf.org; Tue, 11 Oct 2005 03:58:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06481 for ; Tue, 11 Oct 2005 03:58:20 -0400 (EDT) Received: from dsl-217-155-137-62.zen.co.uk ([217.155.137.62] helo=gw2.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPFBl-0008QN-UL for lemonade@ietf.org; Tue, 11 Oct 2005 04:08:47 -0400 Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by gw2.dave.cridland.net (Postfix) with ESMTP id 3A9CC15400B; Tue, 11 Oct 2005 07:58:12 +0000 (UTC) Date: Tue, 11 Oct 2005 08:58:11 +0100 Subject: Re: [lemonade] Future Delivery Date-time Syntax References: <54E40201497DF142B06B27255953F797188569C9@il0015exch007u.ih.lucent.com> In-Reply-To: <54E40201497DF142B06B27255953F797188569C9@il0015exch007u.ih.lucent.com> MIME-Version: 1.0 Message-Id: <26342.1129017491.939253@peirce.dave.cridland.net> From: Dave Cridland To: "Vaudreuil\, Greg M \(Greg\)" Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Mon Oct 10 15:03:03 2005, Vaudreuil, Greg M (Greg) wrote: > > I am soliciting opinions on which date-time syntax to use. Clients > already are familar with RFC 2822 date-time. However, RFC 3339 > (new protocols should...) and previous discussion on this list > suggest that the format defined in 3339 be used. > > Preferences? RFC3339, because of Mark's stated reasons, and because clients have historically mucked up RFC[2]822 date format. Dave. -- Dave Cridland - using Infotrope Polymer http://dave.cridland.net/acap/polymer.html _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Oct 11 05:57:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPGtO-00031m-1a; Tue, 11 Oct 2005 05:57:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPGtM-0002zN-Sy for lemonade@megatron.ietf.org; Tue, 11 Oct 2005 05:57:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11117 for ; Tue, 11 Oct 2005 05:57:50 -0400 (EDT) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPH3R-0002pk-2i for lemonade@ietf.org; Tue, 11 Oct 2005 06:08:18 -0400 Received: from [172.16.2.150] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 11 Oct 2005 10:57:36 +0100 Message-ID: <434B8C91.8090107@isode.com> Date: Tue, 11 Oct 2005 10:57:37 +0100 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 MIME-Version: 1.0 To: "Vaudreuil, Greg M (Greg)" Subject: Re: [lemonade] Future Delivery Date-time Syntax References: <54E40201497DF142B06B27255953F797188569C9@il0015exch007u.ih.lucent.com> In-Reply-To: <54E40201497DF142B06B27255953F797188569C9@il0015exch007u.ih.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Vaudreuil, Greg M (Greg) wrote: >I am soliciting opinions on which date-time syntax to use. Clients already are familar with RFC 2822 date-time. However, RFC 3339 (new protocols should...) and previous discussion on this list suggest that the format defined in 3339 be used. > >Preferences? > > For consistency with URLAUTH I would suggest to use RFC 3339. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Oct 11 07:45:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPIZt-0002su-EA; Tue, 11 Oct 2005 07:45:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPIZs-0002sp-55 for lemonade@megatron.ietf.org; Tue, 11 Oct 2005 07:45:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16349 for ; Tue, 11 Oct 2005 07:45:50 -0400 (EDT) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPIjx-0005h5-Ow for lemonade@ietf.org; Tue, 11 Oct 2005 07:56:18 -0400 Received: from [172.16.2.150] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 11 Oct 2005 12:45:32 +0100 Message-ID: <434BA5DD.4080705@isode.com> Date: Tue, 11 Oct 2005 12:45:33 +0100 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 MIME-Version: 1.0 To: IMAP Extensions WG Content-Type: multipart/mixed; boundary="------------000708070907010809050105" X-Spam-Score: 1.1 (+) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc Cc: Lemonade WG Subject: [lemonade] [Fwd: I-D ACTION:draft-melnikov-imap-ext-abnf-05.txt] X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --------------000708070907010809050105 Content-type: multipart/alternative; boundary="------------060403000605060503060207" --------------060403000605060503060207 Content-type: text/plain; charset="us-ascii" Hi folks, I intend to LC the following draft shortly, so now is a good time for people to review it. Thanks, Alexey -------- Original Message -------- Subject: I-D ACTION:draft-melnikov-imap-ext-abnf-05.txt Date: Mon, 10 Oct 2005 15:50:01 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Collected extensions to IMAP4 ABNF Author(s) : C. Daboo, A. Melnikov Filename : draft-melnikov-imap-ext-abnf-05.txt Pages : 0 Date : 2005-10-10 Over years many documents from IMAPEXT and LEMONADE working groups, as well as many individual documents have added syntactic extensions to many base IMAP commands described in RFC 3501. For ease of reference this document collects most of such ABNF changes in one place. This document updates ABNF in RFC 3501, RFC 2342 and RFC 2088. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-melnikov-imap-ext-abnf-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-melnikov-imap-ext-abnf-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-melnikov-imap-ext-abnf-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- Alexey Melnikov __________________________________________ Isode M-Box Message Store developer http://www.isode.com/products/m-box.html IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html Personal Home Page: http://www.melnikov.ca __________________________________________ --------------060403000605060503060207 Content-type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi folks,
I intend to LC the following draft shortly, so now is a good time for people to review it.

Thanks,
Alexey
-------- Original Message --------
Subject: I-D ACTION:draft-melnikov-imap-ext-abnf-05.txt
Date: Mon, 10 Oct 2005 15:50:01 -0400
From: Internet-Drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Collected extensions to IMAP4 ABNF
	Author(s)	: C. Daboo, A. Melnikov
	Filename	: draft-melnikov-imap-ext-abnf-05.txt
	Pages		: 0
	Date		: 2005-10-10
	
Over years many documents from IMAPEXT and LEMONADE working groups,
   as well as many individual documents have added syntactic
   extensions to many base IMAP commands described in RFC 3501. For
   ease of reference this document collects most of such ABNF changes
   in one place.
   
   This document updates ABNF in RFC 3501, RFC 2342 and RFC 2088.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-melnikov-imap-ext-abnf-05.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-melnikov-imap-ext-abnf-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-melnikov-imap-ext-abnf-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.



-- 
Alexey Melnikov
__________________________________________
Isode M-Box Message Store developer
http://www.isode.com/products/m-box.html

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html

Personal Home Page: http://www.melnikov.ca
__________________________________________
--------------060403000605060503060207-- --------------000708070907010809050105 Content-type: Message/External-body; name="draft-melnikov-imap-ext-abnf-05.txt" Content-transfer-encoding: 7bit Content-Disposition: inline; filename="draft-melnikov-imap-ext-abnf-05.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-10-10104152.I-D@ietf.org> --------------000708070907010809050105 Content-type: text/plain; name="file:///D|/TEMP/nsmail-1.txt" Content-transfer-encoding: 7bit Content-Disposition: inline; filename="file:///D|/TEMP/nsmail-1.txt" Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------000708070907010809050105 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 --------------000708070907010809050105-- From lemonade-bounces@ietf.org Tue Oct 11 10:25:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPL4A-0002Xy-9I; Tue, 11 Oct 2005 10:25:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPL47-0002X1-VW for lemonade@megatron.ietf.org; Tue, 11 Oct 2005 10:25:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27445 for ; Tue, 11 Oct 2005 10:25:13 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPLEE-00029s-Nd for lemonade@ietf.org; Tue, 11 Oct 2005 10:35:43 -0400 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j9BEP4Mw000770; Tue, 11 Oct 2005 09:25:04 -0500 (CDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 11 Oct 2005 09:25:03 -0500 Message-ID: <54E40201497DF142B06B27255953F79718856C8E@il0015exch007u.ih.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: Randall Gellens , lemonade@ietf.org Date: Tue, 11 Oct 2005 09:24:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: [lemonade] GV review of draft-ietf-lemonade-mms-mapping-06.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Document -06 addresses most of my concerns. My remaining issue is with the handling of future delivery. If we agree to punt this until a subsequent revision as proposed :-( then I suggest only that the "SHOULD NOT" text be removed from section 2.1.3.3. A week after this is published, future delivery will be published, and at that point it is entirely reasonable to map between the two in an obvious but not standardized way. However, I believe the reference to future delivery is worth the several week cost. Future delivery is in WG last call now, and should clear as soon as I (or Greg white) submit the revision with the one correction. The time-delta between the approval of the two specs is noise compared to the depth of the RFC Editor queue. Greg V. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Oct 12 16:40:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPnOi-0003B8-8d; Wed, 12 Oct 2005 16:40:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPnOg-0003At-T4; Wed, 12 Oct 2005 16:40:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03863; Wed, 12 Oct 2005 16:40:19 -0400 (EDT) Received: from mxout4.cac.washington.edu ([140.142.33.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPnZ3-0004Qa-2Q; Wed, 12 Oct 2005 16:51:06 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout4.cac.washington.edu (8.13.4+UW05.04/8.13.4+UW05.09) with ESMTP id j9CKeEhM010903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 Oct 2005 13:40:15 -0700 X-Auth-Received: from Shimo-Tomobiki.panda.com ([65.122.177.186]) (authenticated authid=mrc) by smtp.washington.edu (8.13.4+UW05.04/8.13.4+UW05.09) with ESMTP id j9CKeBrE024457 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 12 Oct 2005 13:40:13 -0700 Date: Wed, 12 Oct 2005 13:40:09 -0700 From: Mark Crispin To: lemonade@ietf.org Message-ID: 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='__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: 7bac9cb154eb5790ae3b2913587a40de Cc: iesg@iesg.org Subject: [lemonade] draft-ietf-lemonade-urlauth-08.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Since I posted URLAUTH draft 08, there has been only one issue (a missing double-quote in the text) discovered. Do I need to do anything to have the IESG review it and determine that I have addressed all their DISCUSS concerns, or will this happen automatically? -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Oct 12 17:45:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPoPM-0006e4-7d; Wed, 12 Oct 2005 17:45:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPoPL-0006dm-39 for lemonade@megatron.ietf.org; Wed, 12 Oct 2005 17:45:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07435 for ; Wed, 12 Oct 2005 17:45:03 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPoZi-0006DX-8f for lemonade@ietf.org; Wed, 12 Oct 2005 17:55:51 -0400 Received: from ATLANTIS.Brooktrout.com (oceans12.brooktrout.com [204.176.75.122]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j9CLg9Ra008718 for ; Wed, 12 Oct 2005 17:42:09 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Oct 2005 17:41:43 -0400 Message-ID: <330A23D8336C0346B5C1A5BB1966664701533D41@ATLANTIS.Brooktrout.com> Thread-Topic: IETF 64 Slots Thread-Index: AcXPdbzczTD4nB0CQC+ei5vM9exTpA== From: "Eric Burger" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Subject: [lemonade] IETF 64 Slots X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Meeting times (as always, tentative): MONDAY, November 7, 2005 1300-1500 Afternoon Session I APP lemonade Enhancements to Internet email to Support Diverse Service Environments WG WEDNESDAY, November 9, 2005 0900-1130 Morning Session I APP lemonade Enhancements to Internet email to Support Diverse Service Environments WG We're taking agenda requests. The web site has been somewhat updated... http://flyingfox.snowshore.com/i-d/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Oct 12 18:10:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPonm-0007Hu-Tt; Wed, 12 Oct 2005 18:10:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPonl-0007Gm-9z; Wed, 12 Oct 2005 18:10:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08507; Wed, 12 Oct 2005 18:10:17 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPoy8-0006nA-Js; Wed, 12 Oct 2005 18:21:06 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j9CMA29W020891; Wed, 12 Oct 2005 15:10:02 -0700 (PDT) Received: from [129.46.225.108] (carbuncle.qualcomm.com [129.46.225.108]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j9CM9x7S007189; Wed, 12 Oct 2005 15:10:00 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 12 Oct 2005 15:09:57 -0700 To: Mark Crispin , lemonade@ietf.org From: Ted Hardie Subject: Re: [lemonade] draft-ietf-lemonade-urlauth-08.txt Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: iesg@iesg.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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Howdy, There are no blocking comments for this document, but it is part of a multi-document ballot. Once the chairs (as proto shepherds) have determined that all of the issues raised for the set have been addressed (by conversations with the relevant ADs, changes in the documents, etc.), the document set as a whole will go back on the IESG telechat agenda. Often, the relevant ADs review the changes once they have been note, and the set never has to go back on an agenda, but that will trigger a re-review if one has not already occurred The chairs can also request that the ballot be split and the documents which are ready go forward to the RFC Editor. Given the interconnected nature of these three, I don't anticipate that here, but it can happen. regards, Ted At 1:40 PM -0700 10/12/05, Mark Crispin wrote: >Since I posted URLAUTH draft 08, there has been only one issue (a missing double-quote in the text) discovered. Do I need to do anything to have the IESG review it and determine that I have addressed all their DISCUSS concerns, or will this happen automatically? > >-- Mark -- > >http://staff.washington.edu/mrc >Science does not emerge from voting, party politics, or public debate. >Si vis pacem, para bellum. > >_______________________________________________ >lemonade mailing list >lemonade@ietf.org >https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Oct 14 10:47:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQQqS-0000xz-Mi; Fri, 14 Oct 2005 10:47:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQQqR-0000xY-Lo for lemonade@megatron.ietf.org; Fri, 14 Oct 2005 10:47:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14782 for ; Fri, 14 Oct 2005 10:47:35 -0400 (EDT) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQR1B-0005fY-6T for lemonade@ietf.org; Fri, 14 Oct 2005 10:58:45 -0400 Received: from [172.16.2.127] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 14 Oct 2005 15:44:10 +0100 Message-ID: <434FC439.5080607@isode.com> Date: Fri, 14 Oct 2005 15:44:09 +0100 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: Mark Crispin Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-urlauth-08.txt References: In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Mark Crispin wrote: > This draft supposedly addresses all the issues raised by the IESG, but > as it was primarily a solo effort on my part it needs review by the WG. I like the changes, but I have few comments: 1). >Introduction > > In [IMAPURL], a URL of the form imap://fred@example.com/INBOX/;uid=20 > requires authorization as userid "fred". However, [IMAPURL] implies > that it only supports authentication, Actually, this is not true. IMAP URL uses the term "userid", which is synonymous to authorization identity in SASL. There is no way to specify authentication identity, because IMAP URLs are not allowed to contain passwords. When a client uses LOGIN command, authentication identity is always the same as authorization identity. > and confuses the concepts authentication and authorization. > The URLAUTH extension defines an authorization mechanism for IMAP > URLs to replace [IMAPURL]'s authentication-only mechanism. Same as above. > URLAUTH > conveys authorization in the URL name itself, and reuses a portion of what is "URL name"? > the syntax of the [IMAPURL] authentication mechanism to convey the > authorization identity (which also defines the default namespace in > [IMAP]). This is still confusing (at least for me). I think what you are trying to say that in the following IMAP URL: "dave" is used for authorization and "fred" is used to define mailbox scope. If this is correct, then I think the following text is clearer: URLAUTH conveys authorization in the URL itself, and redefines a portion of the syntax of the [IMAPURL] authentication mechanism to convey the default mailbox scope [IMAP]. 2). draft-ietf-lemonade-rfc2192bis-00.txt have renamed some of IMAP URL non-terminals to be more aligned with the generic URI syntax. Oh well, we don't have to worry about URLAUTH until draft-ietf-lemonade-rfc2192bis-XX.txt is published as an RFC. 3). ABNF reference must be updated to RFC 4234. Alexey _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Oct 14 10:57:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQR0I-0005ty-6Q; Fri, 14 Oct 2005 10:57:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQR0G-0005tl-7w for lemonade@megatron.ietf.org; Fri, 14 Oct 2005 10:57:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17159 for ; Fri, 14 Oct 2005 10:57:44 -0400 (EDT) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQRAy-0006cL-Uo for lemonade@ietf.org; Fri, 14 Oct 2005 11:08:54 -0400 Received: from [172.16.2.127] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 14 Oct 2005 15:57:34 +0100 Message-ID: <434FC758.4010501@isode.com> Date: Fri, 14 Oct 2005 15:57:28 +0100 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: Dave Cridland Subject: Re: [lemonade] Please review IMAP/SMTP extensions included in Lemonade profile Phase 1 References: <43411A97.8090403@isode.com> <24392.1128344761.311414@peirce.dave.cridland.net> In-Reply-To: <24392.1128344761.311414@peirce.dave.cridland.net> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Dave Cridland wrote: > On Mon Oct 3 12:48:39 2005, Alexey Melnikov wrote: > >> As per discussion at Lemonade interim, Stephane and I would like to >> do the following changes to the Lemonade Profile Phase 1 document: >> >> 1). Add LITERAL+ >> 2). Remove quick reconnect (as the document is not ready) and add >> CONDSTORE (quick synchronization). >> 3). Removed POSTADDRESS (was an open issue), as it depends on >> LIST-EXTENDED, which is not quite done yet. >> >> Any objections to the change? Any additional changes? > > I knew there was something else I meant to bring up. > > IDLE isn't present in the list of extensions. Given the comments made > at the meeting about long-lived connections being better for mobile > devices, and transmission being very costly to the battery, this > suggests that IDLE is likely a requirement. IDLE is closely related to push notifications. I would rather postpone it till phase 2. > Secondly, I think the examples need reworking such that the capability > strings returned include all required extensions, and preferably no > undefined ones (one example includes SCAN). This is done now. > ESMTP Transaction (Page 7/8): Should use TLS. Server should be > lemonade compliant, supporting all mandatory to implement extensions. Fixed as well. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Oct 14 20:06:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQZZ5-0002Pk-Bc; Fri, 14 Oct 2005 20:06:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQZZ4-0002PZ-0P for lemonade@megatron.ietf.org; Fri, 14 Oct 2005 20:06:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05979 for ; Fri, 14 Oct 2005 20:06:12 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQZjs-00033C-Lr for lemonade@ietf.org; Fri, 14 Oct 2005 20:17:29 -0400 Received: from dm-usca15-11.red.iplanet.com (host-185-56-18-192.iplanet.com [192.18.56.185] (may be forged)) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j9F06BJE024108; Fri, 14 Oct 2005 18:06:12 -0600 (MDT) Received: from we-gotmail.red.iplanet.com (gotmail-2.red.iplanet.com [192.18.73.252]) by dm-usca15-11.red.iplanet.com (8.11.7p1+Sun/8.11.7/IPLANET,v1.2) with ESMTP id j9F064w25427; Fri, 14 Oct 2005 17:06:05 -0700 (PDT) Received: from [192.18.127.162] (dhcp-usca15-127-162.red.iplanet.com [192.18.127.162]) by we-gotmail.red.iplanet.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTPSA id <0IOD0064ZKA2DS00@we-gotmail.red.iplanet.com>; Fri, 14 Oct 2005 17:06:03 -0700 (PDT) Date: Fri, 14 Oct 2005 17:05:30 -0700 (Pacific Daylight Time) From: Anil SRIVASTAVA Subject: Re: [lemonade] Please review IMAP/SMTP extensions included in Lemonade profile Phase 1 In-reply-to: <434FC758.4010501@isode.com> To: Alexey Melnikov Message-id: Organization: Sun Microsystems [http://www.sun.com] MIME-version: 1.0 X-Mailer: Pine 4.63 - Got Pine? Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Accept-Language: English; en X-Message-Class: normal X-Endorsement: This message brought to you by Sun Java System Messaging Server 6.2 References: <43411A97.8090403@isode.com> <24392.1128344761.311414@peirce.dave.cridland.net> <434FC758.4010501@isode.com> X-Message-flag: Outlook: the best virus distribution system around X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7BIT 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On 2005-10-14/15:57 [+0100], alexey.melnikov@isode.com [Alexey Melnikov] wrote: > Dave Cridland wrote: > > > On Mon Oct 3 12:48:39 2005, Alexey Melnikov wrote: > > > > > As per discussion at Lemonade interim, Stephane and I would like to do the > > > following changes to the Lemonade Profile Phase 1 document: > > > > > > 1). Add LITERAL+ > > > 2). Remove quick reconnect (as the document is not ready) and add > > > CONDSTORE (quick synchronization). > > > 3). Removed POSTADDRESS (was an open issue), as it depends on > > > LIST-EXTENDED, which is not quite done yet. > > > > > > Any objections to the change? Any additional changes? > > > > I knew there was something else I meant to bring up. > > > > IDLE isn't present in the list of extensions. Given the comments > > made at the meeting about long-lived connections being better for > > mobile devices, and transmission being very costly to the battery, > > this suggests that IDLE is likely a requirement. > > IDLE is closely related to push notifications. I would rather postpone > it till phase 2. Push notifications as discussed so far can be both in-band and out of band. IDLE can be one way to get server initiated notifications delivered to the MUA in-band. I don't see a reason to exclude that for now from the Lemonade profile as it will allow for MUA to keep the mailbox in sync with the server without polling. I would vote for keeping IDLE as part of a pahse 1 required extension. > > > Secondly, I think the examples need reworking such that the > > capability strings returned include all required extensions, and > > preferably no undefined ones (one example includes SCAN). > > This is done now. > > > ESMTP Transaction (Page 7/8): Should use TLS. Server should be > > lemonade compliant, supporting all mandatory to implement > > extensions. > > Fixed as well. > > > _______________________________________________ > 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 Sun Oct 16 13:32:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERCMe-0004fn-Cb; Sun, 16 Oct 2005 13:32:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERCMb-0004dF-2E for lemonade@megatron.ietf.org; Sun, 16 Oct 2005 13:32:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11778 for ; Sun, 16 Oct 2005 13:31:55 -0400 (EDT) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERCXl-0008W8-4t for lemonade@ietf.org; Sun, 16 Oct 2005 13:43:33 -0400 Received: from [192.168.0.2] ([62.3.217.253]) by rufus.isode.com via TCP (internal) with ESMTPA; Sun, 16 Oct 2005 18:31:51 +0100 Message-ID: <43527757.3080701@isode.com> Date: Sun, 16 Oct 2005 16:52:55 +0100 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: Dave Cridland Subject: Re: [lemonade] Please review IMAP/SMTP extensions included in Lemonade profile Phase 1 References: <43411A97.8090403@isode.com> <24392.1128344761.311414@peirce.dave.cridland.net> <434507EC.8040306@isode.com> <8591.1128603769.385097@peirce.dave.cridland.net> In-Reply-To: <8591.1128603769.385097@peirce.dave.cridland.net> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Dave Cridland wrote: > On Thu Oct 6 12:18:04 2005, Alexey Melnikov wrote: > >> Dave Cridland wrote: >> >>> A0052 (Page 6/7): >>> a) Includes a Received and a Return-Path header, which seems unlikely >> >> We are forwarding a received message. > > Sort of. You're forwarding an attachment of an existing message. > Certainly my implementation wouldn't copy trace headers in this instance. After rereading some bits on RFC 2822 I agree with you. > I think you'd need Resent-From, etc, if you're submitting a message > with trace headers, and I'm dubious that using a Return-Path: pointing > to Bob is correct in this case. Moreover, I think you risk confusing > client implementors into thinking they should insert trace headers > themselves. Yes, there is such danger. > And to *really* nitpick, I'm most impressed that Bob can forward a > message two seconds before it's arrived. Now I know what future > delivery really means... ;-) > >>> c) Format=flowed message C-T header has superfluous charset >>> parameter, C-T-E is also superfluous. >> >> I would rather not change the messages, as this would affect byte >> counts. > > I'm nitpicking, I know. Would this help? > > [...] (TEXT {462} > I: + Ready for literal data > M: Message-ID: <419399E1.6000505@example.org> > M: Date: Thu, 12 Nov 2004 16:57:05 +0000 > M: From: Bob Ar > M: MIME-Version: 1.0 > M: To: foo@example.net > M: Subject: About our holiday trip > M: Content-Type: multipart/mixed; > M: boundary="------------030308070208000400050907" > M: > M: --------------030308070208000400050907 > M: Content-Type: text/plain; format=flowed > M: > M: Our travel agent has sent the updated schedule. > M: > M: Cheers, > M: Bob > M: > M: --------------030308070208000400050907 > M: URL [...] > > I've stripped out the trace headers, any redundant MIME parameters and > headers, and removed the X- prefixed header. Don't ask me why it comes > out only 62% of the size. Ok, I've used your example. >>> A0053: I didn't know $Forwarded could be applied to a message for >>> which only some parts had been forwarded. >> >> The example if effectively forwarding the whole message. Plus it adds >> a textual annotation to it. > > I'm not quite sure I agree. Forwarding is an UI operation and there is no requirements on how exactly it should be done. All clients I've seen allow to users to edit forwarded messages, including subject. >>> I'm not sure we should be trying to complicate the issue by >>> referring to keywords which haven't yet been standardized, without >>> any reference. >> >> This is easy to fix, if people want me to address the issue. >> I can extract the relevant text from >> draft-melnikov-imap-keywords-03.txt and add it to Lemonade Profile, >> or publish as a separate document. > > Entirely up to the panel - I use $Forwarded anyway, and I'm quite > happy with it. Ok, this is another open issue I've added to the document. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Oct 16 22:50:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERL4b-0007Zu-4f; Sun, 16 Oct 2005 22:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERL4a-0007Ye-Et for lemonade@megatron.ietf.org; Sun, 16 Oct 2005 22:50:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10018 for ; Sun, 16 Oct 2005 22:49:53 -0400 (EDT) Received: from rwcrmhc14.comcast.net ([216.148.227.89] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERLFo-0005Pz-Pq for lemonade@ietf.org; Sun, 16 Oct 2005 23:01:38 -0400 Received: from gawhitelaptop (c-67-172-200-59.hsd1.tx.comcast.net[67.172.200.59]) by comcast.net (rwcrmhc14) with SMTP id <2005101702494901400kjut2e>; Mon, 17 Oct 2005 02:49:49 +0000 From: "Greg White" To: Date: Sun, 16 Oct 2005 21:49:33 -0500 Message-ID: <023501c5d2c5$676304e0$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.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Subject: [lemonade] Question 1: how to rename the future delivery extension X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Hello folks, Apologies for the silence, but I am now caught up on the list, getting = ready to make edits, and wanted to pose some questions and provide choices = based on my observations. I'll pose each question in a different email. Question 1: It seems as if the list is split as to whether the name of the extension = be changed according to the function the extension actually provides. I = now understand that FUTUREDELIVERY is a misnomer, and agree that the name, = and associated verbiage in the draft, be changed to reflect truth. I have = seen FUTURESUBMISSION suggested on the list. Based on the change we are = making to the draft abstract, FUTURERELEASE also seems like a workable choice. = The change to the abstract is as follows:=20 "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." I personally am leaning towards FUTURERELEASE, changing the name of the draft to "SMTP Service Extension for Future Message Release", and = changing the affected text. Any comments? Greg White _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Oct 16 23:21:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERLYu-0006ql-SC; Sun, 16 Oct 2005 23:21:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERLYt-0006o0-4b for lemonade@megatron.ietf.org; Sun, 16 Oct 2005 23:21:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11157 for ; Sun, 16 Oct 2005 23:21:11 -0400 (EDT) Received: from mxout1.cac.washington.edu ([140.142.32.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERLk7-00061a-I6 for lemonade@ietf.org; Sun, 16 Oct 2005 23:32:56 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout1.cac.washington.edu (8.13.4+UW05.04/8.13.4+UW05.09) with ESMTP id j9H3LDDt027137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 16 Oct 2005 20:21:13 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.4+UW05.04/8.13.4+UW05.09) with ESMTP id j9H3LBgk005636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 16 Oct 2005 20:21:12 -0700 Date: Sun, 16 Oct 2005 20:21:10 -0700 (PDT) From: Mark Crispin To: Greg White Subject: Re: [lemonade] Question 1: how to rename the future delivery extension In-Reply-To: <023501c5d2c5$676304e0$6401a8c0@gawhitelaptop> Message-ID: References: <023501c5d2c5$676304e0$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: 08e48e05374109708c00c6208b534009 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org How about HOLDUTIL for the date-time version, and HOLDFOR for the interval version? That seems to state quite clearly what it does. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Oct 16 23:43:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERLuD-0003lf-PE; Sun, 16 Oct 2005 23:43:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERLuC-0003kW-3Y for lemonade@megatron.ietf.org; Sun, 16 Oct 2005 23:43:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12124 for ; Sun, 16 Oct 2005 23:43:12 -0400 (EDT) Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERM5Q-0006Vn-LX for lemonade@ietf.org; Sun, 16 Oct 2005 23:54:58 -0400 Received: from gawhitelaptop (c-67-172-200-59.hsd1.tx.comcast.net[67.172.200.59]) by comcast.net (rwcrmhc11) with SMTP id <2005101703430501300odvtde>; Mon, 17 Oct 2005 03:43:05 +0000 From: "Greg White" To: Date: Sun, 16 Oct 2005 22:42:41 -0500 Message-ID: <023601c5d2cc$d89c7220$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.1 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable Subject: [lemonade] Question 2: how to change the extension framework X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Based on reading the list... Question 2: The list has decided that the framework of the extension needs to be as follows: 1) The submission server needs to be able to handle requests for = future release in BOTH of the following ways: =20 a) hold until a given time interval elapses, then release message b) hold until a given date-time occurs, then release message. 2) The client can choose EITHER 1a) OR 1b), as his future release = method when submitting a future release request. In the following discussions, I am not proposing actual syntax for the draft, just extension framework options... Here are two options that stand out to me for replacing the AFTER = parameter: option 1: introducing two parameters "HOLDFOR=3Dtime_interval" and "HOLDUNTIL=3DRFC3339_date_time", with appropriate text (and ABNF?) = indicating that the client MUST use ONLY ONE of the parameters on the MAIL command option 2: introducing one parameter, HOLD, which has two parm values, hold-type and hold-info. The parameter usage would then look like this: "HOLD=3Dfor;time_interval" or "HOLD=3Duntil;RFC3339_date_time". I got = the idea from the ORCPT parm of the DSN extension which is, basically, "ORCPT=3Daddr-spec;addr" My preference is option 2, because "my gut feeling" is that the = associated draft text and ABNF would be cleaner, and aligns with other extension = work, but I will defer to the mail experts. Here are some options that stand out to me for fixing the EHLO keyword: I am making the assumption that, since we now offer hold-for and = hold-until options, we need to advertise the max-hold-for-value (time interval) and max-hold-until-value (RFC3339 date-time) in the EHLO response, and need = to ensure that the two values essentially indicate the same point-in-future-time... option 1: FUTURERELEASE FOR;max-hold-for-value = UNTIL;max-hold-until-value option 2: assuming that there is no restriction on the number of = keywords advertised by a single extension (I do not know if this assumption is = true, just riffing of the top of my head): FUTURERELEASE FOR;max-hold-for-value FUTURERELEASE UNTIL;max-hold-until-value option 3: assuming that there is no restriction on the number of = keywords advertised by a single extension and there is no requirement that the keyword(s) somehow reflect or align with the official name of the = extension (again, I don't know if these assumptions are true...) HOLDFOR max-hold-for-value HOLDUNTIL max-hold-until-value My preference is option 1, again because "my gut" tells me this is = cleaner, and better fits the rules for SMTP extension frameworks, but again I = will defer to the mail experts. What say you? Greg White _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Oct 17 00:05:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERMFa-00019f-Eg; Mon, 17 Oct 2005 00:05:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERMFY-00019a-KY for lemonade@megatron.ietf.org; Mon, 17 Oct 2005 00:05:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13095 for ; Mon, 17 Oct 2005 00:05:16 -0400 (EDT) Received: from mxout5.cac.washington.edu ([140.142.32.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERMQn-0007AT-Ej for lemonade@ietf.org; Mon, 17 Oct 2005 00:17:02 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.13.4+UW05.04/8.13.4+UW05.09) with ESMTP id j9H45KBu016099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 16 Oct 2005 21:05:21 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.4+UW05.04/8.13.4+UW05.09) with ESMTP id j9H45J1G019080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 16 Oct 2005 21:05:20 -0700 Date: Sun, 16 Oct 2005 21:05:19 -0700 (PDT) From: Mark Crispin To: Greg White Subject: Re: [lemonade] Question 2: how to change the extension framework In-Reply-To: <023601c5d2cc$d89c7220$6401a8c0@gawhitelaptop> Message-ID: References: <023601c5d2cc$d89c7220$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: 30ac594df0e66ffa5a93eb4c48bcb014 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org My feeling is that syntactic sugar is pretty much unimportant, as long as the functionality and the association of the syntax to the functionality is unambiguous. -- 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 Mon Oct 17 00:25:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERMYW-00062X-DS; Mon, 17 Oct 2005 00:25:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERMYU-00061F-Fh for lemonade@megatron.ietf.org; Mon, 17 Oct 2005 00:24:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13902 for ; Mon, 17 Oct 2005 00:24:50 -0400 (EDT) Received: from rwcrmhc13.comcast.net ([216.148.227.118] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERMji-0007bq-LF for lemonade@ietf.org; Mon, 17 Oct 2005 00:36:36 -0400 Received: from gawhitelaptop (c-67-172-200-59.hsd1.tx.comcast.net[67.172.200.59]) by comcast.net (rwcrmhc13) with SMTP id <2005101704244601500rfagte>; Mon, 17 Oct 2005 04:24:46 +0000 From: "Greg White" To: Date: Sun, 16 Oct 2005 23:24:25 -0500 Message-ID: <023701c5d2d2$ab42e420$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.1 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable Subject: [lemonade] Question 3: is future delivery interaction with DSN necessary X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org The following is clipped from the current version of the future delivery draft: 4.2.2 MSA interaction with DSN 1) If an MSA generates a DSN for a message that includes a Future Delivery request, the MSA MUST include an Arrival-Date: field in the machine-readable body part of the DSN. 2) If an MSA generates a DSN for a message that includes a Future Delivery request, the MSA MUST include a Future-Delivery-Date: field in the machine-readable body part of the DSN. The Future-Delivery-Date: field is an extension to the set of DSN per-message fields described in [n8]. Using ABNF [n2], the syntax of this new field is as follows: future-delivery-date-field =3D "Future-Delivery-Date:" = date-time The value of date-time is calculated by adding the value of the future-delivery-interval-param to the locale-specific absolute time at which the MSA received the message. The date-time format is described in [n5]; however, a numeric zone value MUST be used within the date-time in order to align with other date fields defined in [n8]. My assumption is that when a submission server encounters a fatal error trying to send a message to the next hop, a DSN is generated and = deposited in the mailbox of the message-sender. Based on this assumption, my = thoughts were: 1) requiring a Future-Delivery-Date: field would lend context to the = DSN and provide more info re. the original message 2) requiring an Arrival-Date: field (which indicates the date-time at = which the original message arrived at the reporting server, in this case, the = MSA) would provide help indicate client input error (i.e. if Arrival-Date: = occurs after Future-Delivery-Date:, the user mucked up his input...). So, my questions are: 1) Is any of this information important/usable when an MSA generates a = DSN for a future delivery message? 2) If we keep the Future-Delivery-Date: field, is this the field to be = used regardless of future request method (hold-for or hold-until), or should there be a separate field for the hold-for method (e.g. Future-Delivery-Interval:)? 3) If we need this info, what about a Future-Delivery-Date: field and a Future-Delivery-Type: field that basically contains the info from the = MAIL command parameter? 4) If we need this info, does the Future-Delivery-Date: value need to = be RFC3339 (all the other date-time values is DSN are RFC2822)? If the = value is RFC3339, does this violate existing DSN specs? Again, thanks for your comments... Greg White _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Oct 17 00:31:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERMfG-0007vG-8u; Mon, 17 Oct 2005 00:31:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERMfF-0007v6-7Y for lemonade@megatron.ietf.org; Mon, 17 Oct 2005 00:31:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14241 for ; Mon, 17 Oct 2005 00:31:49 -0400 (EDT) Received: from rwcrmhc12.comcast.net ([204.127.198.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERMqU-0007mB-Fc for lemonade@ietf.org; Mon, 17 Oct 2005 00:43:35 -0400 Received: from gawhitelaptop (c-67-172-200-59.hsd1.tx.comcast.net[67.172.200.59]) by comcast.net (rwcrmhc12) with SMTP id <2005101704314501400l4vlqe>; Mon, 17 Oct 2005 04:31:45 +0000 From: "Greg White" To: Date: Sun, 16 Oct 2005 23:31:24 -0500 Message-ID: <023801c5d2d3$a54fa5c0$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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Subject: [lemonade] Question 4: should future-delivery be per-recipient? X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org OK, here's the last question for right now.... Should a user be able to specify different future-xxxx requests for different recipients of the same message? That is, move the new HOLD parm(s) from the MAIL command to the RCPT command? Or is that just overkill? Greg White _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Oct 17 00:38:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERMls-0001Kd-2G; Mon, 17 Oct 2005 00:38:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERMlq-0001KN-7f for lemonade@megatron.ietf.org; Mon, 17 Oct 2005 00:38:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14569 for ; Mon, 17 Oct 2005 00:38:38 -0400 (EDT) Received: from mxout5.cac.washington.edu ([140.142.32.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERMx5-0007wJ-B9 for lemonade@ietf.org; Mon, 17 Oct 2005 00:50:24 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout5.cac.washington.edu (8.13.4+UW05.04/8.13.4+UW05.09) with ESMTP id j9H4cgHK018409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 16 Oct 2005 21:38:42 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.4+UW05.04/8.13.4+UW05.09) with ESMTP id j9H4ceLx009427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 16 Oct 2005 21:38:41 -0700 Date: Sun, 16 Oct 2005 21:38:40 -0700 (PDT) From: Mark Crispin To: Greg White Subject: Re: [lemonade] Question 4: should future-delivery be per-recipient? In-Reply-To: <023801c5d2d3$a54fa5c0$6401a8c0@gawhitelaptop> Message-ID: References: <023801c5d2d3$a54fa5c0$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: 08170828343bcf1325e4a0fb4584481c Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Sun, 16 Oct 2005, Greg White wrote: > Should a user be able to specify different future-xxxx requests for > different recipients of the same message? That is, move the new HOLD > parm(s) from the MAIL command to the RCPT command? Or is that just > overkill? I think it's overkill. But that may be because I can easily implement it for all recipients and it'd be quite a bit more work to do it with different values for individuals recipients. So I'm biased. :-) -- 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 Mon Oct 17 01:49:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERNsT-0001t1-7L; Mon, 17 Oct 2005 01:49:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERNsR-0001st-0L for lemonade@megatron.ietf.org; Mon, 17 Oct 2005 01:49:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18178 for ; Mon, 17 Oct 2005 01:49:32 -0400 (EDT) Received: from monkey.teamware.com ([62.61.83.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERO3g-0001ET-BD for lemonade@ietf.org; Mon, 17 Oct 2005 02:01:17 -0400 Received: from intrepid (intrepid.teamw.com [10.142.128.11]) by monkey.teamware.com (8.11.6/8.11.6) with ESMTP id j9H5veu04261 for ; Mon, 17 Oct 2005 08:57:41 +0300 Received: from [10.142.130.127] ([10.142.130.127]) by intrepid with ESMTP id mah912e3; 17 Oct 2005 09:01:00 +0300 Message-ID: <43533B0E.1050605@teamware.com> Date: Mon, 17 Oct 2005 08:47:58 +0300 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 CC: lemonade@ietf.org Subject: Re: [lemonade] Question 4: should future-delivery be per-recipient? References: <023801c5d2d3$a54fa5c0$6401a8c0@gawhitelaptop> In-Reply-To: <023801c5d2d3$a54fa5c0$6401a8c0@gawhitelaptop> 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=-2.337, required 5, autolearn=disabled, ALL_TRUSTED -2.82, AWL -0.26, RM_tl_ToNone 0.71, WORKSTATION_NAME6 0.03) X-MailScanner-From: adb@teamware.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Greg White wrote: > OK, here's the last question for right now.... > > Should a user be able to specify different future-xxxx requests for > different recipients of the same message? That is, move the new HOLD > parm(s) from the MAIL command to the RCPT command? Or is that just > overkill? Linking message release to recipients would be useful if this were about delivery, but I agree with Mark that the extra implementation effort is overkill. Antony _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Oct 17 09:31:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERV5j-0007h6-BL; Mon, 17 Oct 2005 09:31:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERV5h-0007gy-MR for lemonade@megatron.ietf.org; Mon, 17 Oct 2005 09:31:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12271 for ; Mon, 17 Oct 2005 09:31:42 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERVH1-00062D-Nm for lemonade@ietf.org; Mon, 17 Oct 2005 09:43:33 -0400 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j9HDVbG0021131; Mon, 17 Oct 2005 08:31:38 -0500 (CDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 17 Oct 2005 08:31:37 -0500 Message-ID: <54E40201497DF142B06B27255953F79718AFAA1C@il0015exch007u.ih.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: Greg White , lemonade@ietf.org Subject: RE: [lemonade] Question 4: should future-delivery be per-recipie nt? Date: Mon, 17 Oct 2005 08:31:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org I believe we had discussions in NOTARY and decided that it is better to use per-message options. For most cases, a sender can issue two messages if they want delivery options different for different recipients. This aligned with evolving best practice of having the sender send multiple nearly identical messages rather than a single per-recipient message when you are interested in different network handling per recipient such as tracking or correlating DSN's with list recipients. Same logic would appear to hold here. Greg V. -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org]On Behalf Of Greg White Sent: Monday, October 17, 2005 12:31 AM To: lemonade@ietf.org Subject: [lemonade] Question 4: should future-delivery be per-recipient? OK, here's the last question for right now.... Should a user be able to specify different future-xxxx requests for different recipients of the same message? That is, move the new HOLD parm(s) from the MAIL command to the RCPT command? Or is that just overkill? Greg White _______________________________________________ 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 Oct 17 19:05:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERe2b-0000sd-Ro; Mon, 17 Oct 2005 19:05:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERe2a-0000r3-NB for lemonade@megatron.ietf.org; Mon, 17 Oct 2005 19:05:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13570 for ; Mon, 17 Oct 2005 19:05:04 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EReDx-0007Nb-KP for lemonade@ietf.org; Mon, 17 Oct 2005 19:17:01 -0400 Received: from fe-amer-10.sun.com ([192.18.108.184]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j9HN58eT010565 for ; Mon, 17 Oct 2005 17:05:08 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.1 HotFix 0.11 (built Jan 28 2005)) id <0IOJ00J011DQJT00@mail-amer.sun.com> (original mail from Anil.Srivastava@Sun.COM) for lemonade@ietf.org; Mon, 17 Oct 2005 17:05:08 -0600 (MDT) Received: from [192.18.127.162] by mail-amer.sun.com (Sun Java System Messaging Server 6.1 HotFix 0.11 (built Jan 28 2005)) with ESMTPSA id <0IOJ006SW1GJVKJ0@mail-amer.sun.com>; Mon, 17 Oct 2005 17:05:08 -0600 (MDT) Date: Mon, 17 Oct 2005 16:04:34 -0700 From: Anil SRIVASTAVA Subject: Re: [lemonade] Question 4: should future-delivery be per-recipient? In-reply-to: <023801c5d2d3$a54fa5c0$6401a8c0@gawhitelaptop> To: Greg White Message-id: <43542E02.7040100@Sun.COM> Organization: Sun Microsystems, Inc [http://www.sun.com] MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <023801c5d2d3$a54fa5c0$6401a8c0@gawhitelaptop> User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7BIT 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org [resend due to problems on mail server] Overkill IMHO. The complexity it introduces is not worth the flexibility. I would suggest that this be a per-message option. Anil On 2005-10-16/23:31 [-0500], g.a.white@comcast.net [Greg White] wrote: > OK, here's the last question for right now.... > > Should a user be able to specify different future-xxxx requests for > different recipients of the same message? That is, move the new HOLD > parm(s) from the MAIL command to the RCPT command? Or is that just > overkill? > > Greg White > > > > _______________________________________________ > 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 Tue Oct 18 04:00:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERmOb-0007Rl-Bd; Tue, 18 Oct 2005 04:00:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERmOY-0007QC-Q7 for lemonade@megatron.ietf.org; Tue, 18 Oct 2005 04:00:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11379 for ; Tue, 18 Oct 2005 04:00:19 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERma1-0004ZJ-W6 for lemonade@ietf.org; Tue, 18 Oct 2005 04:12:19 -0400 Received: from ATLANTIS.Brooktrout.com (oceans12.brooktrout.com [204.176.75.122]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j9I7x0ei010768; Tue, 18 Oct 2005 03:59:05 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Question 1: how to rename the future delivery extension Date: Tue, 18 Oct 2005 03:58:32 -0400 Message-ID: <330A23D8336C0346B5C1A5BB196666470158B9AA@ATLANTIS.Brooktrout.com> Thread-Topic: [lemonade] Question 1: how to rename the future delivery extension Thread-Index: AcXSyg8oSTSbTbrWSz2IEaiT79oTuQA73w3Q From: "Eric Burger" To: "Mark Crispin" , "Greg White" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Since I don't think anyone is building 32-bit or 64-bit optimized hardware comparators, I would offer (and agree) with HOLDUNTIL. I could see folks thinking that HOLDUTIL is some sort of "Hold Utility" message. -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] On Behalf Of Mark Crispin Sent: Sunday, October 16, 2005 11:21 PM To: Greg White Cc: lemonade@ietf.org Subject: Re: [lemonade] Question 1: how to rename the future delivery extension How about HOLDUTIL for the date-time version, and HOLDFOR for the interval=20 version? That seems to state quite clearly what it does. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Oct 18 04:10:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERmY4-0003KF-Lz; Tue, 18 Oct 2005 04:10:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERmY2-0003K8-MX for lemonade@megatron.ietf.org; Tue, 18 Oct 2005 04:10:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11801 for ; Tue, 18 Oct 2005 04:10:07 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERmjX-0004p4-CR for lemonade@ietf.org; Tue, 18 Oct 2005 04:22:07 -0400 Received: from ATLANTIS.Brooktrout.com (oceans12.brooktrout.com [204.176.75.122]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j9I863ei011148; Tue, 18 Oct 2005 04:06:04 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Question 2: how to change the extension framework Date: Tue, 18 Oct 2005 04:05:36 -0400 Message-ID: <330A23D8336C0346B5C1A5BB196666470158B9AE@ATLANTIS.Brooktrout.com> Thread-Topic: [lemonade] Question 2: how to change the extension framework Thread-Index: AcXSzRGQFbDETLBoRCaBXqXJssljEwA7OQOA From: "Eric Burger" To: "Greg White" X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org The ugly duckling in EHLO Option 1 is what to do if the two specifications do NOT result in the same future time. I know this is hard to believe, but some server implementations have bugs, and others may wish to exploit client implementation errors by sending bad protocol elements. [Randy - keep your flags to yourself :-] The problem is, I don't have text to offer. I was inclined to say, "The server uses Delta Time to indicate the maximum hold Time, and if the client wants to use date-time, it has to convert the delta time to date-time." However, that assumes the client has all of the local and (if you believe the I'm a U.S. user traveling in the U.K. sending a message to Japan and I want to specify the release time in Japan) global time zone rules. -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] On Behalf Of Greg White Sent: Sunday, October 16, 2005 11:43 PM To: lemonade@ietf.org Subject: [lemonade] Question 2: how to change the extension framework Based on reading the list... Question 2: The list has decided that the framework of the extension needs to be as follows: 1) The submission server needs to be able to handle requests for future release in BOTH of the following ways: =20 a) hold until a given time interval elapses, then release message b) hold until a given date-time occurs, then release message. 2) The client can choose EITHER 1a) OR 1b), as his future release method when submitting a future release request. In the following discussions, I am not proposing actual syntax for the draft, just extension framework options... Here are two options that stand out to me for replacing the AFTER parameter: option 1: introducing two parameters "HOLDFOR=3Dtime_interval" and "HOLDUNTIL=3DRFC3339_date_time", with appropriate text (and ABNF?) indicating that the client MUST use ONLY ONE of the parameters on the MAIL command option 2: introducing one parameter, HOLD, which has two parm values, hold-type and hold-info. The parameter usage would then look like this: "HOLD=3Dfor;time_interval" or "HOLD=3Duntil;RFC3339_date_time". I got = the idea from the ORCPT parm of the DSN extension which is, basically, "ORCPT=3Daddr-spec;addr" My preference is option 2, because "my gut feeling" is that the associated draft text and ABNF would be cleaner, and aligns with other extension work, but I will defer to the mail experts. Here are some options that stand out to me for fixing the EHLO keyword: I am making the assumption that, since we now offer hold-for and hold-until options, we need to advertise the max-hold-for-value (time interval) and max-hold-until-value (RFC3339 date-time) in the EHLO response, and need to ensure that the two values essentially indicate the same point-in-future-time... option 1: FUTURERELEASE FOR;max-hold-for-value UNTIL;max-hold-until-value option 2: assuming that there is no restriction on the number of keywords advertised by a single extension (I do not know if this assumption is true, just riffing of the top of my head): FUTURERELEASE FOR;max-hold-for-value FUTURERELEASE UNTIL;max-hold-until-value option 3: assuming that there is no restriction on the number of keywords advertised by a single extension and there is no requirement that the keyword(s) somehow reflect or align with the official name of the extension (again, I don't know if these assumptions are true...) HOLDFOR max-hold-for-value HOLDUNTIL max-hold-until-value My preference is option 1, again because "my gut" tells me this is cleaner, and better fits the rules for SMTP extension frameworks, but again I will defer to the mail experts. What say you? Greg White _______________________________________________ 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 Oct 18 08:35:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERqgS-0000Na-Tf; Tue, 18 Oct 2005 08:35:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERqgR-0000N9-Sz for lemonade@megatron.ietf.org; Tue, 18 Oct 2005 08:35:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26798 for ; Tue, 18 Oct 2005 08:35:02 -0400 (EDT) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERqrs-0003ke-OT for lemonade@ietf.org; Tue, 18 Oct 2005 08:47:07 -0400 Received: from [192.168.0.2] ([62.3.217.253]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 18 Oct 2005 13:34:44 +0100 Message-ID: <4354C3AB.8090201@isode.com> Date: Tue, 18 Oct 2005 10:43:07 +0100 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 MIME-Version: 1.0 To: Greg White Subject: Re: [lemonade] Question 2: how to change the extension framework References: <023601c5d2cc$d89c7220$6401a8c0@gawhitelaptop> In-Reply-To: <023601c5d2cc$d89c7220$6401a8c0@gawhitelaptop> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Greg White wrote: >Based on reading the list... > >Question 2: > >The list has decided that the framework of the extension needs to be as >follows: > > 1) The submission server needs to be able to handle requests for future >release in BOTH of the following ways: > a) hold until a given time interval elapses, then release message > b) hold until a given date-time occurs, then release message. > > 2) The client can choose EITHER 1a) OR 1b), as his future release method >when submitting a future release request. > > >In the following discussions, I am not proposing actual syntax for the >draft, just extension framework options... > > >Here are two options that stand out to me for replacing the AFTER parameter: > >option 1: introducing two parameters "HOLDFOR=time_interval" and >"HOLDUNTIL=RFC3339_date_time", with appropriate text (and ABNF?) indicating >that the client MUST use ONLY ONE of the parameters on the MAIL command > >option 2: introducing one parameter, HOLD, which has two parm values, >hold-type and hold-info. The parameter usage would then look like this: >"HOLD=for;time_interval" or "HOLD=until;RFC3339_date_time". I got the idea >from the ORCPT parm of the DSN extension which is, basically, >"ORCPT=addr-spec;addr" > >My preference is option 2, because "my gut feeling" is that the associated >draft text and ABNF would be cleaner, and aligns with other extension work, >but I will defer to the mail experts. > > #2 seems better, because it is more clear on the fact that one can't specify both "holdfor" and "holduntil" values in the same MAIL FROM command. >Here are some options that stand out to me for fixing the EHLO keyword: > >I am making the assumption that, since we now offer hold-for and hold-until >options, we need to advertise the max-hold-for-value (time interval) and >max-hold-until-value (RFC3339 date-time) in the EHLO response, and need to >ensure that the two values essentially indicate the same >point-in-future-time... > >option 1: FUTURERELEASE FOR;max-hold-for-value UNTIL;max-hold-until-value > >option 2: assuming that there is no restriction on the number of keywords >advertised by a single extension (I do not know if this assumption is true, >just riffing of the top of my head): > > FUTURERELEASE FOR;max-hold-for-value > FUTURERELEASE UNTIL;max-hold-until-value > >option 3: assuming that there is no restriction on the number of keywords >advertised by a single extension and there is no requirement that the >keyword(s) somehow reflect or align with the official name of the extension >(again, I don't know if these assumptions are true...) > > HOLDFOR max-hold-for-value > HOLDUNTIL max-hold-until-value > >My preference is option 1, again because "my gut" tells me this is cleaner, >and better fits the rules for SMTP extension frameworks, but again I will >defer to the mail experts. > > I don't think #2 is allowed. At least it might have peculiar effects on some mail clients. #1 seems cleaner to me as well. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Oct 18 08:43:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERqoi-0002eI-I9; Tue, 18 Oct 2005 08:43:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERqoh-0002eD-3m for lemonade@megatron.ietf.org; Tue, 18 Oct 2005 08:43:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27112 for ; Tue, 18 Oct 2005 08:43:33 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERr0E-0003vL-1I for lemonade@ietf.org; Tue, 18 Oct 2005 08:55:38 -0400 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j9IChP3L021654; Tue, 18 Oct 2005 07:43:26 -0500 (CDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 18 Oct 2005 07:43:25 -0500 Message-ID: <54E40201497DF142B06B27255953F79718BF4BB3@il0015exch007u.ih.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: Eric Burger , Greg White Subject: RE: [lemonade] Question 2: how to change the extension framework Date: Tue, 18 Oct 2005 07:43:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org If you wanted to offer non-redundant but sufficient info, you could declare the servers view of the current time and the max interval. A client needing a future max time can compute it from the interval. Greg V. -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org]On Behalf Of Eric Burger Sent: Tuesday, October 18, 2005 4:06 AM To: Greg White Cc: lemonade@ietf.org Subject: RE: [lemonade] Question 2: how to change the extension framework The ugly duckling in EHLO Option 1 is what to do if the two specifications do NOT result in the same future time. I know this is hard to believe, but some server implementations have bugs, and others may wish to exploit client implementation errors by sending bad protocol elements. [Randy - keep your flags to yourself :-] The problem is, I don't have text to offer. I was inclined to say, "The server uses Delta Time to indicate the maximum hold Time, and if the client wants to use date-time, it has to convert the delta time to date-time." However, that assumes the client has all of the local and (if you believe the I'm a U.S. user traveling in the U.K. sending a message to Japan and I want to specify the release time in Japan) global time zone rules. -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] On Behalf Of Greg White Sent: Sunday, October 16, 2005 11:43 PM To: lemonade@ietf.org Subject: [lemonade] Question 2: how to change the extension framework Based on reading the list... Question 2: The list has decided that the framework of the extension needs to be as follows: 1) The submission server needs to be able to handle requests for future release in BOTH of the following ways: a) hold until a given time interval elapses, then release message b) hold until a given date-time occurs, then release message. 2) The client can choose EITHER 1a) OR 1b), as his future release method when submitting a future release request. In the following discussions, I am not proposing actual syntax for the draft, just extension framework options... Here are two options that stand out to me for replacing the AFTER parameter: option 1: introducing two parameters "HOLDFOR=time_interval" and "HOLDUNTIL=RFC3339_date_time", with appropriate text (and ABNF?) indicating that the client MUST use ONLY ONE of the parameters on the MAIL command option 2: introducing one parameter, HOLD, which has two parm values, hold-type and hold-info. The parameter usage would then look like this: "HOLD=for;time_interval" or "HOLD=until;RFC3339_date_time". I got the idea from the ORCPT parm of the DSN extension which is, basically, "ORCPT=addr-spec;addr" My preference is option 2, because "my gut feeling" is that the associated draft text and ABNF would be cleaner, and aligns with other extension work, but I will defer to the mail experts. Here are some options that stand out to me for fixing the EHLO keyword: I am making the assumption that, since we now offer hold-for and hold-until options, we need to advertise the max-hold-for-value (time interval) and max-hold-until-value (RFC3339 date-time) in the EHLO response, and need to ensure that the two values essentially indicate the same point-in-future-time... option 1: FUTURERELEASE FOR;max-hold-for-value UNTIL;max-hold-until-value option 2: assuming that there is no restriction on the number of keywords advertised by a single extension (I do not know if this assumption is true, just riffing of the top of my head): FUTURERELEASE FOR;max-hold-for-value FUTURERELEASE UNTIL;max-hold-until-value option 3: assuming that there is no restriction on the number of keywords advertised by a single extension and there is no requirement that the keyword(s) somehow reflect or align with the official name of the extension (again, I don't know if these assumptions are true...) HOLDFOR max-hold-for-value HOLDUNTIL max-hold-until-value My preference is option 1, again because "my gut" tells me this is cleaner, and better fits the rules for SMTP extension frameworks, but again I will defer to the mail experts. What say you? Greg White _______________________________________________ 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 Tue Oct 18 09:02:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERr6z-0001IT-0i; Tue, 18 Oct 2005 09:02:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERr6x-0001Fe-7u for lemonade@megatron.ietf.org; Tue, 18 Oct 2005 09:02:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28298 for ; Tue, 18 Oct 2005 09:02:28 -0400 (EDT) Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERrIR-0004T5-Gx for lemonade@ietf.org; Tue, 18 Oct 2005 09:14:30 -0400 Received: from prosecco.oryx.com (prosecco.oryx.com [195.30.37.38]) by kalyani.oryx.com (Postfix) with ESMTP id 454EC4AC81; Tue, 18 Oct 2005 15:02:31 +0200 (CEST) Message-Id: Date: Tue, 18 Oct 2005 15:01:31 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Question 2: how to change the extension framework References: <023601c5d2cc$d89c7220$6401a8c0@gawhitelaptop> <4354C3AB.8090201@isode.com> In-Reply-To: <4354C3AB.8090201@isode.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Alexey Melnikov writes: > Greg White wrote: >> option 2: introducing one parameter, HOLD, which has two parm >> values, hold-type and hold-info. The parameter usage would then >> look like this: "HOLD=for;time_interval" or >> "HOLD=until;RFC3339_date_time". I got the idea from the ORCPT parm >> of the DSN extension which is, basically, "ORCPT=addr-spec;addr" >> >> My preference is option 2, because "my gut feeling" is that the >> associated draft text and ABNF would be cleaner, and aligns with >> other extension work, but I will defer to the mail experts. > > #2 seems better, because it is more clear on the fact that one can't > specify both "holdfor" and "holduntil" values in the same MAIL FROM > command. mail from: hold=for;999 hold=until;... The same issue seems to apply to RCPT TO...NOTIFY= in RFC 1891, and as far as I can remember, noone has raised that as a problem in the past ten years. (I'm neutral on this. Some things are worth caring about, others not. I don't think it makes a problem wrt. syntax complexity either.) Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Oct 18 09:06:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERrAw-0002BR-Fr; Tue, 18 Oct 2005 09:06:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERrAv-0002BJ-7Q for lemonade@megatron.ietf.org; Tue, 18 Oct 2005 09:06:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28569 for ; Tue, 18 Oct 2005 09:06:34 -0400 (EDT) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERrMR-0004cY-AH for lemonade@ietf.org; Tue, 18 Oct 2005 09:18:37 -0400 Received: from [192.168.0.2] ([62.3.217.253]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 18 Oct 2005 14:06:21 +0100 Message-ID: <4354F34B.6020501@isode.com> Date: Tue, 18 Oct 2005 14:06:19 +0100 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: Arnt Gulbrandsen Subject: Re: [lemonade] Question 2: how to change the extension framework References: <023601c5d2cc$d89c7220$6401a8c0@gawhitelaptop> <4354C3AB.8090201@isode.com> In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="KOI8-R"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Arnt Gulbrandsen wrote: > Alexey Melnikov writes: > >> Greg White wrote: >> >>> option 2: introducing one parameter, HOLD, which has two parm >>> values, hold-type and hold-info. The parameter usage would then >>> look like this: "HOLD=for;time_interval" or >>> "HOLD=until;RFC3339_date_time". I got the idea from the ORCPT parm >>> of the DSN extension which is, basically, "ORCPT=addr-spec;addr" >>> >>> My preference is option 2, because "my gut feeling" is that the >>> associated draft text and ABNF would be cleaner, and aligns with >>> other extension work, but I will defer to the mail experts. >> >> #2 seems better, because it is more clear on the fact that one can't >> specify both "holdfor" and "holduntil" values in the same MAIL FROM >> command. > > mail from: hold=for;999 hold=until;... Not legal if you say that the "hold" parameter can appear only once. > The same issue seems to apply to RCPT TO...NOTIFY= in RFC 1891, and as > far as I can remember, noone has raised that as a problem in the past > ten years. > > (I'm neutral on this. Some things are worth caring about, others not. > I don't think it makes a problem wrt. syntax complexity either.) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Oct 18 09:44:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERrl2-0006sZ-OO; Tue, 18 Oct 2005 09:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERrl0-0006sO-Tq for lemonade@megatron.ietf.org; Tue, 18 Oct 2005 09:43:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00283 for ; Tue, 18 Oct 2005 09:43:51 -0400 (EDT) Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERrwV-0005WY-Ka for lemonade@ietf.org; Tue, 18 Oct 2005 09:55:52 -0400 Received: from prosecco.oryx.com (prosecco.oryx.com [195.30.37.38]) by kalyani.oryx.com (Postfix) with ESMTP id 0E1934AC8C; Tue, 18 Oct 2005 15:43:52 +0200 (CEST) Message-Id: Date: Tue, 18 Oct 2005 15:42:52 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Question 2: how to change the extension framework References: <023601c5d2cc$d89c7220$6401a8c0@gawhitelaptop> <4354C3AB.8090201@isode.com> <4354F34B.6020501@isode.com> In-Reply-To: <4354F34B.6020501@isode.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Alexey Melnikov writes: > Not legal if you say that the "hold" parameter can appear only once. Indeed. So what? Equivalent text is possible for holdfor/holduntil. The point is: RFC 1891 doesn't do it for NOTIFY AFAICT, and noone has raised an issue about that in the past decade, so the issue seems insignificantly small. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Oct 18 11:34:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERtTl-0001vP-Po; Tue, 18 Oct 2005 11:34:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERtTj-0001v3-7Z for lemonade@megatron.ietf.org; Tue, 18 Oct 2005 11:34:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10369 for ; Tue, 18 Oct 2005 11:34:06 -0400 (EDT) Received: from mxout7.cac.washington.edu ([140.142.32.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERtfG-0001RA-Ko for lemonade@ietf.org; Tue, 18 Oct 2005 11:46:12 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout7.cac.washington.edu (8.13.4+UW05.04/8.13.4+UW05.09) with ESMTP id j9IFY8gD027857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 18 Oct 2005 08:34:08 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.4+UW05.04/8.13.4+UW05.09) with ESMTP id j9IFY3Kq004460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 18 Oct 2005 08:34:08 -0700 Date: Tue, 18 Oct 2005 08:34:02 -0700 (PDT) From: Mark Crispin To: Eric Burger Subject: RE: [lemonade] Question 1: how to rename the future delivery extension In-Reply-To: <330A23D8336C0346B5C1A5BB196666470158B9AA@ATLANTIS.Brooktrout.com> Message-ID: References: <330A23D8336C0346B5C1A5BB196666470158B9AA@ATLANTIS.Brooktrout.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Eric - For what it's worth, "HOLDUTIL" was a typo; I meant to say "HOLDUNTIL" and somehow dropped the "N". I agree completely with your comment about not trying to optimize for 32 or 64 bit words. We are long past that! On Tue, 18 Oct 2005, Eric Burger wrote: > Since I don't think anyone is building 32-bit or 64-bit optimized > hardware comparators, I would offer (and agree) with HOLDUNTIL. I could > see folks thinking that HOLDUTIL is some sort of "Hold Utility" message. > > -----Original Message----- > From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] On > Behalf Of Mark Crispin > Sent: Sunday, October 16, 2005 11:21 PM > To: Greg White > Cc: lemonade@ietf.org > Subject: Re: [lemonade] Question 1: how to rename the future delivery > extension > > How about HOLDUTIL for the date-time version, and HOLDFOR for the > interval version? That seems to state quite clearly what it does. -- 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 Oct 18 15:52:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERxVt-0007Ok-A3; Tue, 18 Oct 2005 15:52:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERxTO-0006us-PB; Tue, 18 Oct 2005 15:50:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24461; Tue, 18 Oct 2005 15:50:02 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERxes-0000B5-8u; Tue, 18 Oct 2005 16:02:04 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ERxTG-0001aZ-6w; Tue, 18 Oct 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 18 Oct 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-05.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org 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 Author(s) : S. Maes, A. Melnikov Filename : draft-ietf-lemonade-profile-05.txt Pages : 18 Date : 2005-10-18 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 [RFC3501] extensions and BURL extension to the SUBMIT protocol [RFC2476]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-profile-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-profile-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-profile-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-18120927.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-profile-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-profile-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-18120927.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 Oct 21 08:04:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESvcu-0000Za-FO; Fri, 21 Oct 2005 08:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESvct-0000Yz-AT for lemonade@megatron.ietf.org; Fri, 21 Oct 2005 08:03:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17164 for ; Fri, 21 Oct 2005 08:03:47 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESvoz-0006Ub-Qv for lemonade@ietf.org; Fri, 21 Oct 2005 08:16:30 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9LC3eg10660 for ; Fri, 21 Oct 2005 08:03:41 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Oct 2005 08:03:29 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D06C1DE03@zcarhxm0.corp.nortel.com> Thread-Topic: LEMONADE in London Thread-Index: AcXWDagwJL8Yi73IS5Cv37sGzeJ7zw== From: "Glenn Parsons" To: X-Spam-Score: 0.8 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b Subject: [lemonade] LEMONADE in London X-BeenThere: lemonade@ietf.org X-Mailman-Version: 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="===============1829576411==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============1829576411== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D637.732E2CF3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D637.732E2CF3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, This is a somewhat belated summary of our impressive progress at the LEMONADE interim meeting (including the OMA MEM / IETF LEMONADE workshop). Thanks again to Isode for hosting this event. It was an excellent meeting, despite the challenging connectivity. Let me know if you have any comments on the results or my summary. Cheers, Glenn. LEMONADE London - Sept 28-30 =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 requirements (RD) - summary including feedback on previous LEMONADE concerns OMA architecture (AD) - discussion of the model including which parts might 'belong' to OMA vs IETF - initial LEMONADE view (including 'magic box') presented - OMA interested in detailed IETF proposal on how LEMONADE will realize architecture. Official liaison expected. This will be published as a WG I-D. MMS mapping - WG reviewers volunteered to review comments, new draft if necessary Reconnect - New revision needed to address issues - Vendor implementations are needed on this - There is dependency on CONDSTORE, EXPUNGE, and comparators Future Delivery - new draft due to resolve last issues Trio - CATENATE & BURL issues resolved (chairs to confirm) - URLAUTH needs another spin to resolve 'The LEMONADE profile' - finalize list for first release - Reconnect, post address out - CHUNKING, CONDSTORE, LITERAL+, TLS in - WGLC when draft available mid Oct Notifications / filtering - IAB note reviewed, we are within charter to cover OMA requirements - SIEVE is basis - Greg & Stephane will propose draft Content Transformation - streaming proposal will be made by Eric or Lyndon (based on figure B at 61.5) - static proposal based on LCONVERT by Stephane Compose - discussion tabled, as it is not needed if SMTP had http binding... Compression - agreed to define min codec for TLS, but will decide later HTTP binding - proposal to make optional for IMAP & SMTP - perhaps BCP or Informational=20 - use of IMAP/SMTP ports must be promoted by profile New drafts: - Goal to finish first phase before Vancouver - 00 due by Oct 17 - rest due by Oct 24 Vancouver: - we will have two slots and perhaps additional BOFs ------_=_NextPart_001_01C5D637.732E2CF3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable LEMONADE in London

Folks,

This is a somewhat belated summary of = our impressive progress at the LEMONADE interim meeting (including the = OMA MEM / IETF LEMONADE workshop).

Thanks again to Isode for hosting this = event.  It was an excellent meeting, despite the challenging = connectivity.

Let me know if you have any comments on = the results or my summary.

Cheers,
Glenn.


LEMONADE London - Sept 28-30
=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 requirements (RD)
 - summary including feedback on = previous LEMONADE concerns

OMA architecture (AD)
 - discussion of the model = including which parts might 'belong' to OMA vs IETF
 - initial LEMONADE view = (including 'magic box') presented
 - OMA interested in detailed = IETF proposal on how LEMONADE will realize architecture.  Official = liaison expected.  This will be published as a WG I-D.

MMS mapping
 - WG reviewers volunteered to = review comments, new draft if necessary

Reconnect
 - New revision needed to address = issues
 - Vendor implementations are = needed on this
 - There is dependency on = CONDSTORE, EXPUNGE, and comparators

Future Delivery
 - new draft due to resolve last = issues

Trio
 - CATENATE & BURL issues = resolved (chairs to confirm)
 - URLAUTH needs another spin to = resolve

'The LEMONADE profile'
 - finalize list for first = release
 - Reconnect, post address = out
 - CHUNKING, CONDSTORE, LITERAL+, = TLS in
 - WGLC when draft available mid = Oct

Notifications / filtering
 - IAB note reviewed, we are = within charter to cover OMA requirements
 - SIEVE is basis
 - Greg & Stephane will = propose draft

Content Transformation
 - streaming proposal will be = made by Eric or Lyndon (based on figure B at 61.5)
 - static proposal based on = LCONVERT by Stephane

Compose
 - discussion tabled, as it is = not needed if SMTP had http binding...

Compression
 - agreed to define min codec for = TLS, but will decide later

HTTP binding
 - proposal to make optional for = IMAP & SMTP
 - perhaps BCP or Informational =
 - use of IMAP/SMTP ports must be = promoted by profile

New drafts:
 - Goal to finish first phase = before Vancouver
 - 00 due by Oct 17
 - rest due by Oct 24

Vancouver:
 - we will have two slots and = perhaps additional BOFs

------_=_NextPart_001_01C5D637.732E2CF3-- --===============1829576411== 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 --===============1829576411==-- From lemonade-bounces@ietf.org Fri Oct 21 09:44:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESxCO-0002CD-2q; Fri, 21 Oct 2005 09:44:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESxCM-0002C8-0C for lemonade@megatron.ietf.org; Fri, 21 Oct 2005 09:44:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22214 for ; Fri, 21 Oct 2005 09:44:31 -0400 (EDT) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESxOU-0001Q4-Gn for lemonade@ietf.org; Fri, 21 Oct 2005 09:57:15 -0400 Received: from [172.16.2.146] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 21 Oct 2005 14:44:21 +0100 Message-ID: <4358F0B4.1030905@isode.com> Date: Fri, 21 Oct 2005 14:44:20 +0100 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: Chris Newman MIME-version: 1.0 Content-type: text/plain; charset="KOI8-R"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: lemonade@ietf.org Subject: [lemonade] Comments about draft-ietf-lemonade-burl-03.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Hi Chris, Some last-minute comments on BURL, mostly editorial. 1). >5. Updates to RFC 3463 > > SMTP or Submit servers which advertise ENHANCEDSTATUSCODES [RFC2034] > may includes enhanced status codes defined in RFC 3463 [RFC3463]. "may include"? After rereading this sentence it looks strange to me. Are you trying to say that if RFC 2034 is supported, then enhanced status codes defined in RFC 3463 must be supported as well (in which case "may" ==> MUST)? Or are you trying to say that RFC 2034 only references RFC 1893 (which is a precursor for RFC 3463), so the document is only trying to encourage people to implement RFC 3463? 2). You need to update the text to say that TLS+PLAIN authentication requirement is coming from RFC 3501. Mark has suggested some text. In relation to this: I don't think reference to PLAIN is Normative. It is a normative reference for RFC 3501. 3). Need to update reference to the ABNF document (RFC 4234). Alexey _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Oct 21 09:47:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESxEn-0003PR-0D; Fri, 21 Oct 2005 09:47:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESxEk-0003PB-Kh for lemonade@megatron.ietf.org; Fri, 21 Oct 2005 09:47:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22330 for ; Fri, 21 Oct 2005 09:46:59 -0400 (EDT) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESxQt-0001VL-5p for lemonade@ietf.org; Fri, 21 Oct 2005 09:59:44 -0400 Received: from [172.16.2.146] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 21 Oct 2005 14:46:23 +0100 Message-ID: <4358F12D.4060906@isode.com> Date: Fri, 21 Oct 2005 14:46:21 +0100 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: Glenn Parsons Subject: Re: [lemonade] LEMONADE in London References: <085091CB2CA14E4B8B163FFC37C84E9D06C1DE03@zcarhxm0.corp.nortel.com> In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D06C1DE03@zcarhxm0.corp.nortel.com> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Glenn Parsons wrote: > Reconnect > - New revision needed to address issues > - Vendor implementations are needed on this > - There is dependency on CONDSTORE, EXPUNGE, and comparators > Typo: EXPUNGED. To be more precise: CONSTORE depends on SORT, which depends on I18N, which depends on comparators ;-). _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Oct 22 23:05:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETWAR-0001tM-Hd; Sat, 22 Oct 2005 23:05:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETWAQ-0001t6-2W for lemonade@megatron.ietf.org; Sat, 22 Oct 2005 23:05:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10868 for ; Sat, 22 Oct 2005 23:04:50 -0400 (EDT) Received: from [204.176.205.6] (helo=salvelinus.brooktrout.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETWMt-0005au-80 for lemonade@ietf.org; Sat, 22 Oct 2005 23:17:55 -0400 Received: from ATLANTIS.Brooktrout.com (oceans11.brooktrout.com [204.176.75.121]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j9N2xadU014180 for ; Sat, 22 Oct 2005 22:59:36 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 22 Oct 2005 22:59:10 -0400 Message-ID: <330A23D8336C0346B5C1A5BB19666647016485A4@ATLANTIS.Brooktrout.com> Thread-Topic: Session Times Thread-Index: AcXXfb27S0YZJN39T2GVxr1lNAXWDw== From: "Eric Burger" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Content-Transfer-Encoding: quoted-printable Subject: [lemonade] Session Times X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org The first session MAY be moved to 3:10pm on Monday (from 1pm). That presents a conflict for me, so don't count on it being changed, yet. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Oct 24 10:57:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU3lD-0003cE-VW; Mon, 24 Oct 2005 10:57:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU3lC-0003ad-OZ for lemonade@megatron.ietf.org; Mon, 24 Oct 2005 10:57:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13964; Mon, 24 Oct 2005 10:56:58 -0400 (EDT) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU3xw-0006Tf-9P; Mon, 24 Oct 2005 11:10:25 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9OEuoL09387; Mon, 24 Oct 2005 10:56:51 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 24 Oct 2005 10:56:43 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D06C79753@zcarhxm0.corp.nortel.com> Thread-Topic: Draft LEMONADE agenda Thread-Index: AcXYqyXmLlP1gYuXSt2oxOOagb6Tag== From: "Glenn Parsons" To: X-Spam-Score: 0.8 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: agenda@ietf.org Subject: [lemonade] Draft LEMONADE 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="===============1056377494==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============1056377494== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D8AB.26BB66AF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D8AB.26BB66AF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, This is the draft agenda for the IETF LEMONADE WG. Please let us know if you have any comments. Cheers, Glenn. Session 1 - Mon, Nov 7, 1310h: Agenda bashing OMA liaison Status review draft-ietf-lemonade-goals draft-ietf-lemonade-notify-s2s draft-ietf-lemonade-mms-mapping=20 draft-ietf-lemonade-futuredelivery=20 draft-ietf-lemonade-burl=20 draft-ietf-lemonade-catenate draft-ietf-lemonade-urlauth=20 draft-ietf-lemonade-profile=20 Profile=20 draft-ietf-lemonade-reconnect draft-ietf-lemonade-rfc2192bis draft-ietf-lemonade-convert=20 Session 2 - Wed, Nov 9, 0900h: OMA MEM AD discussion Profile proposals draft-maes-lemonade-notifications-filters-how-to draft-maes-lemonade-notifications-server-to-client draft-maes-lemonade-vfolder draft-newman-lemonade-msgevent draft-maes-lemonade-lzip draft-maes-lemonade-mobile-email draft-maes-lemonade-deliver draft-maes-lemonade-http-binding ------_=_NextPart_001_01C5D8AB.26BB66AF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft LEMONADE agenda

Folks,

This is the draft agenda for the IETF = LEMONADE WG.  Please let us know if you have any comments.

Cheers,
Glenn.



Session 1 - Mon, Nov 7, 1310h:

Agenda bashing
OMA liaison
Status review
  draft-ietf-lemonade-goals
  draft-ietf-lemonade-notify-s2s
  draft-ietf-lemonade-mms-mapping
  draft-ietf-lemonade-futuredelivery
  draft-ietf-lemonade-burl
  draft-ietf-lemonade-catenate
  draft-ietf-lemonade-urlauth
  draft-ietf-lemonade-profile
Profile
  = draft-ietf-lemonade-reconnect
  draft-ietf-lemonade-rfc2192bis
  draft-ietf-lemonade-convert

Session 2 - Wed, Nov 9, 0900h:

OMA MEM AD discussion
Profile proposals
  = draft-maes-lemonade-notifications-filters-how-to
  draft-maes-lemonade-notifications-server-to-client
  draft-maes-lemonade-vfolder
  draft-newman-lemonade-msgevent
  draft-maes-lemonade-lzip
  draft-maes-lemonade-mobile-email
  draft-maes-lemonade-deliver
  draft-maes-lemonade-http-binding

------_=_NextPart_001_01C5D8AB.26BB66AF-- --===============1056377494== 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 --===============1056377494==-- From lemonade-bounces@ietf.org Mon Oct 24 11:24:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU4Bk-0002Nx-Hx; Mon, 24 Oct 2005 11:24:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU4Bj-0002Nq-O1 for lemonade@megatron.ietf.org; Mon, 24 Oct 2005 11:24:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15261; Mon, 24 Oct 2005 11:24:27 -0400 (EDT) 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 1EU4OV-0007Kn-4W; Mon, 24 Oct 2005 11:37:52 -0400 Received: from [216.43.25.67] (127.0.0.1) by episteme-software.com with ESMTP (EIMS X 3.3d14); Mon, 24 Oct 2005 10:24:24 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D06C79753@zcarhxm0.corp.nortel.com> References: <085091CB2CA14E4B8B163FFC37C84E9D06C79753@zcarhxm0.corp.nortel.com> X-Mailer: Eudora [Macintosh version 7.0a12] Date: Mon, 24 Oct 2005 10:24:22 -0500 To: "Glenn Parsons" From: Pete Resnick Subject: Re: [lemonade] Draft LEMONADE agenda Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: lemonade@ietf.org, agenda@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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On 10/24/05 at 10:56 AM -0400, Glenn Parsons wrote: >Status review > draft-ietf-lemonade-goals > draft-ietf-lemonade-notify-s2s > draft-ietf-lemonade-mms-mapping > draft-ietf-lemonade-futuredelivery > draft-ietf-lemonade-burl > draft-ietf-lemonade-catenate > draft-ietf-lemonade-urlauth > draft-ietf-lemonade-profile Smaller picture: No need for status review on catenate. Status: It's in the queue, ready to go to the RFC Editor. Bigger picture: Can we get "Status review" off of the agenda entirely? It's the kind of thing that can be done on the list. Get authors to post their statuses to the list. If there are outstanding issues with any document, put that on the agenda. 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 Mon Oct 24 11:38:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU4Oy-00072g-Gr; Mon, 24 Oct 2005 11:38:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU4Ox-000729-GD for lemonade@megatron.ietf.org; Mon, 24 Oct 2005 11:38:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15924 for ; Mon, 24 Oct 2005 11:38:05 -0400 (EDT) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU4bg-0007ma-9r for lemonade@ietf.org; Mon, 24 Oct 2005 11:51:30 -0400 Received: from [172.16.2.127] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 24 Oct 2005 16:38:02 +0100 Message-ID: <435CFFDA.5010600@isode.com> Date: Mon, 24 Oct 2005 16:38:02 +0100 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: lemonade@ietf.org Subject: Re: [lemonade] Draft LEMONADE agenda References: <085091CB2CA14E4B8B163FFC37C84E9D06C79753@zcarhxm0.corp.nortel.com> In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Pete Resnick wrote: > On 10/24/05 at 10:56 AM -0400, Glenn Parsons wrote: > >> Status review >> draft-ietf-lemonade-goals >> draft-ietf-lemonade-notify-s2s >> draft-ietf-lemonade-mms-mapping >> draft-ietf-lemonade-futuredelivery >> draft-ietf-lemonade-burl >> draft-ietf-lemonade-catenate >> draft-ietf-lemonade-urlauth >> draft-ietf-lemonade-profile > > Smaller picture: No need for status review on catenate. Status: It's > in the queue, ready to go to the RFC Editor. > > Bigger picture: Can we get "Status review" off of the agenda entirely? > It's the kind of thing that can be done on the list. Get authors to > post their statuses to the list. If there are outstanding issues with > any document, put that on the agenda. Agreed. Status of draft-ietf-lemonade-profile: Most work is done, 2 open issues: 1). Should the IMAP IDLE extension be included in Profile Phase 1? 2). Should the IMAP $Forwarded keyword a). be described in profile and b). be part of Phase 1? Alexey _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Oct 24 12:14:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU4xk-0004II-E9; Mon, 24 Oct 2005 12:14:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU4xi-0004Cg-P5 for lemonade@megatron.ietf.org; Mon, 24 Oct 2005 12:14:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18351 for ; Mon, 24 Oct 2005 12:14:01 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU5AT-0000kb-Kl for lemonade@ietf.org; Mon, 24 Oct 2005 12:27:27 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9OGE1708972 for ; Mon, 24 Oct 2005 12:14:02 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Draft LEMONADE agenda Date: Mon, 24 Oct 2005 12:13:56 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D06C79900@zcarhxm0.corp.nortel.com> Thread-Topic: [lemonade] Draft LEMONADE agenda Thread-Index: AcXYrxe+BUGe3QXxRxOT+LnkdRt+kQABmIOg From: "Glenn Parsons" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Pete said: Bigger picture: Can we get "Status review" off of the agenda entirely? It's the kind of thing that can be done on the list. Get authors to post their statuses to the list. If there are outstanding issues with any document, put that on the agenda. I agree that we should not be spending meeting time getting updates. However, typically we prepare a slide that is the status of the drafts that we put up and go past fairly quickly. But sometimes we need meeting time to squeeze the editors/authors :-) Cheers, Glenn. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From pwg-announce-owner@pwg.org Mon Oct 24 12:18:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU4zg-0005Xn-JF; Mon, 24 Oct 2005 12:16:16 -0400 Received: from pwg.org (pwg.org [192.146.101.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18464; Mon, 24 Oct 2005 12:16:02 -0400 (EDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org with ESMTP id j9OGFgOF008051; Mon, 24 Oct 2005 12:15:44 -0400 Received: from localhost (mail@localhost) by pwg.org (8.13.1/8.13.1/Submit) with SMTP id j9OGFgeA008048; Mon, 24 Oct 2005 12:15:42 -0400 Received: by pwg.org (bulk_mailer v1.13); Mon, 24 Oct 2005 12:13:14 -0400 Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org with ESMTP id j9OGDAwI007660 for ; Mon, 24 Oct 2005 12:13:12 -0400 Received: (from majordom@localhost) by pwg.org (8.13.1/8.13.1/Submit) id j9OGDADh007657 for pwg-announce-out; Mon, 24 Oct 2005 12:13:10 -0400 Message-ID: From: "McDonald, Ira" To: "'pwg-announce@pwg.org'" Subject: PWG-ANNOUNCE> PWG Chicago Agenda - 26-28 October 2005 - w/ call-in info Date: Mon, 24 Oct 2005 09:14:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-pwg-announce@pwg.org Hi folks, An updated Chicago schedule from our PWG Steering Committee meeting last week. Some phone participants can only call in at the _beginning_ of each session, so please try to call in then, if possible. Toll Free: 1-866-365-4406 International: 00+1+303-248-9655 Passcode: 2635888# ** PWG Meeting Agenda - Chicago, IL - October 2005 ** 26 October - Wednesday - PWG Plenary (Morning) - 7am PDT / 9am CDT / 10am EDT - Port Mon MIB (Afternoon) - 11am PDT / 1pm CDT / 2pm EDT 27 October - Thursday - DMTF CIM (Morning) - 7am PDT / 9am CDT / 10am EDT - WIMS Protocol (Afternoon) - 11am PDT / 1pm CDT / 2pm EDT 28 October - Friday - PWG 2006 Topics (Morning) - 7am PDT / 9am CDT / 10am EDT NOTE: The BOF on Display and Projector Management MIB will deferred to the January 2006 meeting - per request of Rick Landau and Paul Danbold. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com From lemonade-bounces@ietf.org Mon Oct 24 12:10:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU4uR-0000qU-00; Mon, 24 Oct 2005 12:10:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU4uP-0000q5-3G for lemonade@megatron.ietf.org; Mon, 24 Oct 2005 12:10:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18153 for ; Mon, 24 Oct 2005 12:10:36 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU57A-0000dN-Tk for lemonade@ietf.org; Mon, 24 Oct 2005 12:24:02 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j9OG7tB11250 for ; Mon, 24 Oct 2005 12:07:56 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 24 Oct 2005 12:10:33 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D06C798F5@zcarhxm0.corp.nortel.com> Thread-Topic: LEMONADE profile Thread-Index: AcXYsUEIKMkMf9ldQnGFefSuZ93iqAAA7O2A From: "Glenn Parsons" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable Subject: [lemonade] 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Alexey said: Status of draft-ietf-lemonade-profile: Most work is done, 2 open issues: 1). Should the IMAP IDLE extension be included in Profile Phase 1? 2). Should the IMAP $Forwarded keyword a). be described in profile and b). be part of Phase 1? At London we were planning to initiate a WG last call on the profile today... I think we should go ahead with the noted issues included. Would you agree? Glenn. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Oct 24 12:30:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU5DQ-0001fg-PJ; Mon, 24 Oct 2005 12:30:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU5DP-0001fX-Pe for lemonade@megatron.ietf.org; Mon, 24 Oct 2005 12:30:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19039 for ; Mon, 24 Oct 2005 12:30:14 -0400 (EDT) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU5QB-0001D7-Jq for lemonade@ietf.org; Mon, 24 Oct 2005 12:43:41 -0400 Received: from [172.16.2.127] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 24 Oct 2005 17:30:04 +0100 Message-ID: <435D0C07.4020904@isode.com> Date: Mon, 24 Oct 2005 17:29:59 +0100 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 MIME-Version: 1.0 To: Glenn Parsons Subject: Re: [lemonade] LEMONADE profile References: <085091CB2CA14E4B8B163FFC37C84E9D06C798F5@zcarhxm0.corp.nortel.com> In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D06C798F5@zcarhxm0.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Glenn Parsons wrote: >Alexey said: > >Status of draft-ietf-lemonade-profile: >Most work is done, 2 open issues: >1). Should the IMAP IDLE extension be included in Profile Phase 1? >2). Should the IMAP $Forwarded keyword > a). be described in profile > and > b). be part of Phase 1? > > >At London we were planning to initiate a WG last call on the profile >today... > >I think we should go ahead with the noted issues included. Would you >agree? > > That would certainly be Ok with me. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Oct 25 11:22:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUQdP-000814-28; Tue, 25 Oct 2005 11:22:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUQdN-0007zR-9R for lemonade@megatron.ietf.org; Tue, 25 Oct 2005 11:22:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29201 for ; Tue, 25 Oct 2005 11:22:26 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUQqL-0007vN-8e for lemonade@ietf.org; Tue, 25 Oct 2005 11:36:06 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9PFMKs10232 for ; Tue, 25 Oct 2005 11:22:20 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 25 Oct 2005 11:22:13 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D06D020B7@zcarhxm0.corp.nortel.com> Thread-Topic: Profile WG last call Thread-Index: AcXZd+AoZTZBkinAR56fEiYE+H3JSw== From: "Glenn Parsons" To: X-Spam-Score: 0.6 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Subject: [lemonade] Profile WG last call X-BeenThere: lemonade@ietf.org X-Mailman-Version: 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="===============0182011348==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============0182011348== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D977.E4030842" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D977.E4030842 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, This message announces the commencement of the WG last call on the LEMONADE profile: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-profile-05.txt Please review this document paying special attention to: - the list of MUST implement features (note the editors suggest adding IDLE and $forward to the=20 baseline we agreed in London) - the noted open issues Last call will end 9am on Nov 7th. Cheers, Glenn. ------_=_NextPart_001_01C5D977.E4030842 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Profile WG last call

Folks,

This message announces the commencement = of the WG last call on the LEMONADE profile:
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-profile-05.t= xt

Please review this document = paying special attention to:
 - the list of MUST = implement features
   (note the editors = suggest adding IDLE and $forward to the
    baseline we = agreed in London)
 - the noted open = issues

Last call will end 9am on Nov = 7th.

Cheers,
Glenn.



------_=_NextPart_001_01C5D977.E4030842-- --===============0182011348== 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 --===============0182011348==-- From lemonade-bounces@ietf.org Tue Oct 25 12:46:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EURwX-00073w-AC; Tue, 25 Oct 2005 12:46:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EURwV-00072W-8v for lemonade@megatron.ietf.org; Tue, 25 Oct 2005 12:46:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04452 for ; Tue, 25 Oct 2005 12:46:17 -0400 (EDT) Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUS9T-00023X-KG for lemonade@ietf.org; Tue, 25 Oct 2005 12:59:57 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id DECAE4ACBF for ; Tue, 25 Oct 2005 18:46:21 +0200 (CEST) Message-Id: Date: Tue, 25 Oct 2005 18:46:15 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Profile WG last call References: <085091CB2CA14E4B8B163FFC37C84E9D06D020B7@zcarhxm0.corp.nortel.com> In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D06D020B7@zcarhxm0.corp.nortel.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Glenn Parsons writes: > Folks, > > This message announces the commencement of the WG last call on the > LEMONADE profile: > http://www.ietf.org/internet-drafts/draft-ietf-lemonade-profile-05.txt > > Please review this document paying special attention to: > - the list of MUST implement features > (note the editors suggest adding IDLE and $forward to the > baseline we agreed in London) I have a question about this. Since it's a suggestion not done yet, I assume there are people who don't want to implement IDLE. I further assume that these are clueful people. The question is then: Why? What counts against IDLE? (IMO the list is fine, although I'd prefer adding IDLE and $forward. We'll implement everything on the list.) > - the noted open issues I think literal+ examples, while perhaps desirable, aren't at all important. RFC 2088 will do. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Oct 25 13:08:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUSHU-0006hy-Pn; Tue, 25 Oct 2005 13:08:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUSHQ-0006hg-VW for lemonade@megatron.ietf.org; Tue, 25 Oct 2005 13:08:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06015 for ; Tue, 25 Oct 2005 13:07:52 -0400 (EDT) Received: from mxout1.cac.washington.edu ([140.142.32.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUSUM-0002pR-1L for lemonade@ietf.org; Tue, 25 Oct 2005 13:21:32 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout1.cac.washington.edu (8.13.4+UW05.04/8.13.4+UW05.09) with ESMTP id j9PH7tGY016970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Oct 2005 10:07:55 -0700 X-Auth-Received: from Shimo-Tomobiki.panda.com ([65.122.177.186]) (authenticated authid=mrc) by smtp.washington.edu (8.13.4+UW05.04/8.13.4+UW05.09) with ESMTP id j9PH7Yfg022846 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 25 Oct 2005 10:07:54 -0700 Date: Tue, 25 Oct 2005 10:07:31 -0700 From: Mark Crispin To: Arnt Gulbrandsen Subject: Re: [lemonade] Profile WG last call In-Reply-To: Message-ID: References: <085091CB2CA14E4B8B163FFC37C84E9D06D020B7@zcarhxm0.corp.nortel.com> 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='__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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Tue, 25 Oct 2005, Arnt Gulbrandsen wrote: > The question is then: Why? What counts against IDLE? I've implemented IDLE in my server but not in client code. The big issue with IDLE is that it doesn't work with NAT or any other mechanism which depends upon client activity to maintain connectivity. Verizon's 1xRTT service hangs up after a remarkably short period of inactivity, and then calls again when the client issues new activity. In order to make it usable for non-HTTP traffic, I end up running a ping in the background to keep it active, or I dial my ISP and deal with the lower performance of the analog step. I don't know if this affects LEMONADE issues. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Oct 25 13:24:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUSXA-00077l-51; Tue, 25 Oct 2005 13:24:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUSX7-00074q-MO for lemonade@megatron.ietf.org; Tue, 25 Oct 2005 13:24:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07109 for ; Tue, 25 Oct 2005 13:24:05 -0400 (EDT) Received: from rgminet02.oracle.com ([148.87.122.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUSk4-0003Kc-Hw for lemonade@ietf.org; Tue, 25 Oct 2005 13:37:45 -0400 Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by rgminet02.oracle.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id j9PHNxfX021919 for ; Tue, 25 Oct 2005 11:24:00 -0600 Received: from rgmgw1.us.oracle.com (localhost [127.0.0.1]) by rgmgw1.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j9PHNxpU029173 for ; Tue, 25 Oct 2005 11:23:59 -0600 Received: from us.oracle.com (dhcp-emea-uk-csvpn-gw8-141-144-136-46.vpn.oracle.com [141.144.136.46]) by rgmgw1.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j9PHNsfM028835 for ; Tue, 25 Oct 2005 11:23:58 -0600 From: "Stephane H. Maes" To: "lemonade@ietf.org" Subject: RE: [lemonade] Profile WG last call Date: Tue, 25 Oct 2005 10:23:42 -0700 In-Reply-To: X-Sent-Folder-Path: Sent Items X-Mailer: Oracle Connector for Outlook 9.0.4.2.8 70113 (11.0.6359) Message-ID: <20051025102342549.00000003308@smaes-lap> 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: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org This sounds like the IDLE time out issues that we observed on 2.5G and 3G n= etworks and that we discussed when comparing with HTTP sessions. Thanks Stephane _____ Stephane H. Maes, PhD, Director of Architecture - OCS & Mobile, Oracle Corporation. 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) = -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] On Behal= f Of Mark Crispin Sent: Tuesday, October 25, 2005 10:08 AM To: Arnt Gulbrandsen Cc: lemonade@ietf.org Subject: Re: [lemonade] Profile WG last call On Tue, 25 Oct 2005, Arnt Gulbrandsen wrote: > The question is then: Why? What counts against IDLE? I've implemented IDLE in my server but not in client code. The big issue with IDLE is that it doesn't work with NAT or any other mechanism which depends upon client activity to maintain connectivity. Verizon's 1xRTT service hangs up after a remarkably short period of inactivity, and then calls again when the client issues new activity. In order to make it usable for non-HTTP traffic, I end up running a ping in the background to keep it active, or I dial my ISP and deal with the lower performance of the analog step. I don't know if this affects LEMONADE issues. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Oct 25 13:54:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUSzu-0008Ac-0q; Tue, 25 Oct 2005 13:54:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUSzt-0008AU-0C for lemonade@megatron.ietf.org; Tue, 25 Oct 2005 13:54:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08872 for ; Tue, 25 Oct 2005 13:53:51 -0400 (EDT) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUTCr-0004FN-3s for lemonade@ietf.org; Tue, 25 Oct 2005 14:07:31 -0400 Received: from [172.16.2.179] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 25 Oct 2005 18:53:35 +0100 Message-ID: <435E711F.4000502@isode.com> Date: Tue, 25 Oct 2005 18:53:35 +0100 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: Arnt Gulbrandsen Subject: Re: [lemonade] Profile WG last call References: <085091CB2CA14E4B8B163FFC37C84E9D06D020B7@zcarhxm0.corp.nortel.com> In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="KOI8-R"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Arnt Gulbrandsen wrote: >> - the noted open issues > > I think literal+ examples, while perhaps desirable, aren't at all > important. RFC 2088 will do. Yes, I've deleted this from the editor's copy. There is a text in the document explaining how the existing example can be turned into "literal+" example. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Oct 25 14:04:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUTAJ-0005LT-GP; Tue, 25 Oct 2005 14:04:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUTAI-0005LO-4E for lemonade@megatron.ietf.org; Tue, 25 Oct 2005 14:04:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09652 for ; Tue, 25 Oct 2005 14:04:36 -0400 (EDT) Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUTNH-0004cw-Ck for lemonade@ietf.org; Tue, 25 Oct 2005 14:18:16 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 603D74ACBB for ; Tue, 25 Oct 2005 20:04:46 +0200 (CEST) Message-Id: Date: Tue, 25 Oct 2005 20:04:40 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Profile WG last call References: <085091CB2CA14E4B8B163FFC37C84E9D06D020B7@zcarhxm0.corp.nortel.com> <435E711F.4000502@isode.com> In-Reply-To: <435E711F.4000502@isode.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Alexey Melnikov writes: > Yes, I've deleted this from the editor's copy. There is a text in the > document explaining how the existing example can be turned into > "literal+" example. Oh... in that case, why not change it? Literal+ is mandatory in lemonade. I don't think it really makes sense to avoid mandatory features in an example. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Oct 25 14:44:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUTml-0003yQ-16; Tue, 25 Oct 2005 14:44:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUTmj-0003yA-IN for lemonade@megatron.ietf.org; Tue, 25 Oct 2005 14:44:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11851 for ; Tue, 25 Oct 2005 14:44:19 -0400 (EDT) Received: from dsl-217-155-137-62.zen.co.uk ([217.155.137.62] helo=gw2.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUTzi-0005na-Ud for lemonade@ietf.org; Tue, 25 Oct 2005 14:58:00 -0400 Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by gw2.dave.cridland.net (Postfix) with ESMTP id 3A785154009; Tue, 25 Oct 2005 18:44:12 +0000 (UTC) Date: Tue, 25 Oct 2005 19:44:11 +0100 Subject: Re: [lemonade] Profile WG last call References: <085091CB2CA14E4B8B163FFC37C84E9D06D020B7@zcarhxm0.corp.nortel.com> In-Reply-To: MIME-Version: 1.0 Message-Id: <9700.1130265852.128428@peirce.dave.cridland.net> From: Dave Cridland To: Mark Crispin Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Tue Oct 25 18:07:31 2005, Mark Crispin wrote: > On Tue, 25 Oct 2005, Arnt Gulbrandsen wrote: >> The question is then: Why? What counts against IDLE? > > I've implemented IDLE in my server but not in client code. > > The big issue with IDLE is that it doesn't work with NAT or any > other mechanism which depends upon client activity to maintain > connectivity. > > Agreed, but in those circumstances where either NAT timeouts are set to reasonable values, I think IDLE represents a big win, especially for mobile: 1) It cuts down the amount of transmission required for the GPRS radio in the handset. As I understand it, this is the number one battery killer. 2) It's immediately closer to the concept of "Push email". This isn't all that important in technical terms, but it does represent a strong marketing concept. If it were down to me, I'd require IDLE, but add a note to the effect that if a connection is entirely idle (as in, no data transmitted in either direction) for more than a certain, network dependent, length of time, then connections passing through NAT and certain stateful firewalls may be broken. This also makes me wonder whether a server-transmitted NOOP packet might be possible, whether in IMAP or TCP, which might "hold" the NAT connection state live. I don't know enough TCP to know whether such a thing exists, nor do I know the internals of NATs et al to know whether even if it does, it might help. 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 Oct 25 15:21:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUUMe-0004DL-Fd; Tue, 25 Oct 2005 15:21:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUUMd-0004DD-5F for lemonade@megatron.ietf.org; Tue, 25 Oct 2005 15:21:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13939 for ; Tue, 25 Oct 2005 15:21:24 -0400 (EDT) Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUUZb-0006st-30 for lemonade@ietf.org; Tue, 25 Oct 2005 15:35:06 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 6E0CD4ACBB for ; Tue, 25 Oct 2005 21:21:33 +0200 (CEST) Message-Id: Date: Tue, 25 Oct 2005 21:21:27 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Profile WG last call References: <085091CB2CA14E4B8B163FFC37C84E9D06D020B7@zcarhxm0.corp.nortel.com> <9700.1130265852.128428@peirce.dave.cridland.net> In-Reply-To: <9700.1130265852.128428@peirce.dave.cridland.net> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Dave Cridland writes: > This also makes me wonder whether a server-transmitted NOOP packet > might be possible, whether in IMAP or TCP, which might "hold" the NAT > connection state live. I don't know enough TCP to know whether such a > thing exists, nor do I know the internals of NATs et al to know > whether even if it does, it might help. Such a thing exists in TCP, it's called keepalive. If you can turn it on, which isn't always, it defeats the NATs. I think TLS has keepalives, too. That should be easy to enable from the application. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Oct 25 15:30:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUUV2-000749-QE; Tue, 25 Oct 2005 15:30:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUUV1-00073t-Tm for lemonade@megatron.ietf.org; Tue, 25 Oct 2005 15:30:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14461 for ; Tue, 25 Oct 2005 15:30:02 -0400 (EDT) Received: from mxout1.cac.washington.edu ([140.142.32.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUUhz-00078E-4k for lemonade@ietf.org; Tue, 25 Oct 2005 15:43:44 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout1.cac.washington.edu (8.13.4+UW05.04/8.13.4+UW05.09) with ESMTP id j9PJUARq019586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Oct 2005 12:30:10 -0700 X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.4+UW05.04/8.13.4+UW05.09) with ESMTP id j9PJU9jg014582 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 25 Oct 2005 12:30:10 -0700 Date: Tue, 25 Oct 2005 12:29:53 -0700 (Pacific Daylight Time) From: Mark Crispin To: Arnt Gulbrandsen Subject: Re: [lemonade] Profile WG last call In-Reply-To: Message-ID: References: <085091CB2CA14E4B8B163FFC37C84E9D06D020B7@zcarhxm0.corp.nortel.com> <9700.1130265852.128428@peirce.dave.cridland.net> 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='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Tue, 25 Oct 2005, Arnt Gulbrandsen wrote: >> This also makes me wonder whether a server-transmitted NOOP packet might be >> possible, whether in IMAP or TCP, which might "hold" the NAT connection >> state live. I don't know enough TCP to know whether such a thing exists, >> nor do I know the internals of NATs et al to know whether even if it does, >> it might help. > Such a thing exists in TCP, it's called keepalive. If you can turn it on, > which isn't always, it defeats the NATs. Well, uh,... Keepalives can also be deadly. I found that I can not reliably keep an ssh session to my server at work over NAT if the ssh server enables keepalive. AFAICT, the cause is that keepalives misinterpret a short-term outage as permanent. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Oct 25 15:52:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUUqv-0007aP-DN; Tue, 25 Oct 2005 15:52:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUUqY-0007KQ-Qy for lemonade@megatron.ietf.org; Tue, 25 Oct 2005 15:52:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15844 for ; Tue, 25 Oct 2005 15:52:20 -0400 (EDT) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUV3Y-0007xH-0B for lemonade@ietf.org; Tue, 25 Oct 2005 16:06:02 -0400 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 j9PJqHct010305 for ; Tue, 25 Oct 2005 14:52:18 -0500 (CDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 25 Oct 2005 14:52:17 -0500 Message-ID: <54E40201497DF142B06B27255953F79718F30D8E@il0015exch007u.ih.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: lemonade@ietf.org Subject: RE: [lemonade] Profile WG last call Date: Tue, 25 Oct 2005 14:52:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.6 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 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="===============1753585930==" Sender: lemonade-bounces@ietf.org 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. --===============1753585930== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D99D.98C1DA82" 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_001_01C5D99D.98C1DA82 Content-Type: text/plain I have the following comments after reviewing the latest version of the profile, 05. Last work in 2nd to last paragraph of Page 4 "server" => "Client or MUA". Server already has the fragments. Last paragraph of Page 4 introduces two new concepts without describing what they are '"forward without download" strategy' and 'variant'. Text saying "There are two use variants based on where the message assembly takes place . The first uses a succession of BURL and BDAT commands to submit and assemble through concatenation, message data from the client and external data fetched from the provided URL. The second uses the Catenate command to upload a template to the message store and cause the message assembly on the IMAP server." At least, that is what I think the authors were thinking but not stating. Along those lines, do we need an example of the first variant? The only text describing this variant is in section 2.5 explaining why chunking needs to be supported. Section 2.6, second paragraph. If I understand this, the client can't revoke the validity of the pawn-ticket. That revocation has to be done on and by the IMAP server itself. Is there an way for the client to request that a URLAUTH be invalidated? Section 2.7. A sentence or two about how to actually use catenate to solve the FCC problem would help. Is the solution to move the template into the "sent items" mailbox prior to requesting a URLAUTH? Do we need to discuss "sent items" conventions here? Section 3.1 "clients should pipeline" may be more completely worded "clients should pipeline SMTP commands when possible". Normative references section is missing RFC 2034 required in 3.4 Greg V. -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org]On Behalf Of Glenn Parsons Sent: Tuesday, October 25, 2005 11:22 AM To: lemonade@ietf.org Subject: [lemonade] Profile WG last call Folks, This message announces the commencement of the WG last call on the LEMONADE profile: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-profile-05.txt Please review this document paying special attention to: - the list of MUST implement features (note the editors suggest adding IDLE and $forward to the baseline we agreed in London) - the noted open issues Last call will end 9am on Nov 7th. Cheers, Glenn. ------_=_NextPart_001_01C5D99D.98C1DA82 Content-Type: text/html Profile WG last call
 
I have the following comments after reviewing the latest version of the profile, 05.
 
Last work in 2nd to last paragraph of Page 4  "server" => "Client or MUA".  Server already has the fragments.
 
Last paragraph of Page 4 introduces two new concepts without describing what they are '"forward without download" strategy' and 'variant'.  Text saying
 
    "There are two use variants based on where the message assembly takes place .  The first uses
     a succession of BURL and BDAT commands to submit and assemble through concatenation, 
     message data from the client and external data fetched from the provided URL. The second uses
     the Catenate command to upload a template to the message store and cause the message assembly
     on the IMAP server."  
 
At least, that is what I think the authors were thinking but not stating.    Along those lines, do we need an example of the first variant?  The only text describing this variant is in section 2.5 explaining why chunking needs to be supported.
 
 
 
Section 2.6, second paragraph.  If I understand this, the client can't revoke the validity of the pawn-ticket.  That revocation has to be done on and by the IMAP server itself.  Is there an way for the client to request that a URLAUTH be invalidated?  
 
 
Section 2.7.
 
A sentence or two about how to actually use catenate to solve the FCC problem would help.  Is the solution to move the template into the "sent items" mailbox prior to requesting a URLAUTH?   Do we need to discuss "sent items" conventions here? 
 
Section 3.1
 
"clients should pipeline" may be more completely worded "clients should pipeline SMTP commands when possible". 
 
Normative references section is missing RFC 2034 required in 3.4
 
Greg V.
 
 
 
-----Original Message-----
From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org]On Behalf Of Glenn Parsons
Sent: Tuesday, October 25, 2005 11:22 AM
To: lemonade@ietf.org
Subject: [lemonade] Profile WG last call

Folks,

This message announces the commencement of the WG last call on the LEMONADE profile:
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-profile-05.txt

Please review this document paying special attention to:
 - the list of MUST implement features
   (note the editors suggest adding IDLE and $forward to the
    baseline we agreed in London)
 - the noted open issues

Last call will end 9am on Nov 7th.

Cheers,
Glenn.



------_=_NextPart_001_01C5D99D.98C1DA82-- --===============1753585930== 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 --===============1753585930==-- From lemonade-bounces@ietf.org Tue Oct 25 16:29:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUVQI-0003S2-Cp; Tue, 25 Oct 2005 16:29:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUVQH-0003RY-0q for lemonade@megatron.ietf.org; Tue, 25 Oct 2005 16:29:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29390 for ; Tue, 25 Oct 2005 16:29:13 -0400 (EDT) Received: from dsl-217-155-137-62.zen.co.uk ([217.155.137.62] helo=gw2.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUVdE-0004cs-LP for lemonade@ietf.org; Tue, 25 Oct 2005 16:42:56 -0400 Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by gw2.dave.cridland.net (Postfix) with ESMTP id 1836F154009; Tue, 25 Oct 2005 20:29:14 +0000 (UTC) Date: Tue, 25 Oct 2005 21:29:13 +0100 Subject: Re: [lemonade] Profile WG last call References: <085091CB2CA14E4B8B163FFC37C84E9D06D020B7@zcarhxm0.corp.nortel.com> <9700.1130265852.128428@peirce.dave.cridland.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <9700.1130272154.028333@peirce.dave.cridland.net> From: Dave Cridland To: Arnt Gulbrandsen Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Tue Oct 25 20:21:27 2005, Arnt Gulbrandsen wrote: > Dave Cridland writes: >> This also makes me wonder whether a server-transmitted NOOP packet >> might be possible, whether in IMAP or TCP, which might "hold" the >> NAT connection state live. I don't know enough TCP to know whether >> such a thing exists, nor do I know the internals of NATs et al to >> know whether even if it does, it might help. > > Such a thing exists in TCP, it's called keepalive. If you can turn > it on, which isn't always, it defeats the NATs. > > I think TLS has keepalives, too. That should be easy to enable from > the application. Both are easy to do from the application, TCP keep alives are a socket option. The trouble is, they require an acknowledgement from the other side, so you're using up battery to send it. What's really needed here is to send some packet from the IMAP server which resets all the NAT timeouts, but doesn't require a corresponding transmission from the handset. Perhaps a duplicate ACK, for instance. (It's obviously a dirty hack, but the NAT people started it, as my son would say). 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 Oct 25 16:29:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUVQL-0003TV-Rb; Tue, 25 Oct 2005 16:29:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUVQJ-0003SY-Gh for lemonade@megatron.ietf.org; Tue, 25 Oct 2005 16:29:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29407 for ; Tue, 25 Oct 2005 16:29:15 -0400 (EDT) Received: from mxout5.cac.washington.edu ([140.142.32.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUVdI-0004eM-G4 for lemonade@ietf.org; Tue, 25 Oct 2005 16:42:57 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.13.4+UW05.04/8.13.4+UW05.09) with ESMTP id j9PKTNDX023506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Oct 2005 13:29:23 -0700 X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.4+UW05.04/8.13.4+UW05.09) with ESMTP id j9PKTNlG029617 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 25 Oct 2005 13:29:23 -0700 Date: Tue, 25 Oct 2005 13:28:58 -0700 (Pacific Daylight Time) From: Mark Crispin To: "Vaudreuil, Greg M (Greg)" Subject: RE: [lemonade] Profile WG last call In-Reply-To: <54E40201497DF142B06B27255953F79718F30D8E@il0015exch007u.ih.lucent.com> Message-ID: References: <54E40201497DF142B06B27255953F79718F30D8E@il0015exch007u.ih.lucent.com> 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='__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: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Tue, 25 Oct 2005, Vaudreuil, Greg M (Greg) wrote: > Section 2.6, second paragraph. If I understand this, the client can't > revoke the validity of the pawn-ticket. That revocation has to be done > on and by the IMAP server itself. Is there an way for the client to > request that a URLAUTH be invalidated? A client can revoke all URLAUTHs issued for that user by using RESETKEY. Individual revocation is not possible. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Oct 25 17:16:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUWAF-0004NS-0d; Tue, 25 Oct 2005 17:16:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUWAD-0004Mn-3R for lemonade@megatron.ietf.org; Tue, 25 Oct 2005 17:16:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15274 for ; Tue, 25 Oct 2005 17:16:41 -0400 (EDT) From: Corby.Wilson@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUWNE-0002Mz-M8 for lemonade@ietf.org; Tue, 25 Oct 2005 17:30:25 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9PLCxSa002216; Wed, 26 Oct 2005 00:13:13 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Oct 2005 00:16:52 +0300 Received: from bsebe101.NOE.Nokia.com ([172.19.160.235]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Oct 2005 16:16:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Profile WG last call Date: Tue, 25 Oct 2005 17:16:45 -0400 Message-ID: <4422475A1E8D0248B00251C20D968F888B7785@bsebe101.NOE.Nokia.com> Thread-Topic: [lemonade] Profile WG last call Thread-Index: AcXZpXaOANmQKb0MRheUNt55Yj02/AAA0TZw To: , X-OriginalArrivalTime: 25 Oct 2005 21:16:47.0423 (UTC) FILETIME=[686754F0:01C5D9A9] X-Spam-Score: 0.3 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org We have tried several things including keep alives and pings. We have found that socket level keep alives don't work because the carrier infrastructure doesn't reset the cells on keep alives in some areas. The best success we have had is by using app level pings (some random data packet that is discarded) from the server to the client which keeps the conneciton up. On no 3G network we were able to set this at about 7 minutes. On 3G networks things were much worse and we had to lower it to 3-4 minutes. In either case, the battery life was reduced, at a MINIMUM, by 50%. Typically this was much worse when the user was traveling since the power required by the radio increases with distance to the cell. The ideal mechanism would be an out-of-band system like SMS which takes no significant power loss from the terminal. SIP doesn't seem to help much since it is connection based as well. Sugestions are very wellcome here. At this point, battery life is at a permium and people will turn off their email application to prevent battery drain so they can continue to make/receive calls. Corby Wilson =20 =20 > -----Original Message----- > From: lemonade-bounces@ietf.org=20 > [mailto:lemonade-bounces@ietf.org] On Behalf Of ext Dave Cridland > Sent: Tuesday, October 25, 2005 16:29 PM > To: Arnt Gulbrandsen > Cc: lemonade@ietf.org > Subject: Re: [lemonade] Profile WG last call >=20 > On Tue Oct 25 20:21:27 2005, Arnt Gulbrandsen wrote: > > Dave Cridland writes: > >> This also makes me wonder whether a server-transmitted NOOP packet=20 > >> might be possible, whether in IMAP or TCP, which might "hold" the=20 > >> NAT connection state live. I don't know enough TCP to know whether=20 > >> such a thing exists, nor do I know the internals of NATs et al to=20 > >> know whether even if it does, it might help. > >=20 > > Such a thing exists in TCP, it's called keepalive. If you can turn=20 > > it on, which isn't always, it defeats the NATs. > >=20 > > I think TLS has keepalives, too. That should be easy to enable from=20 > > the application. >=20 > Both are easy to do from the application, TCP keep alives are a=20 > socket option. >=20 > The trouble is, they require an acknowledgement from the other side,=20 > so you're using up battery to send it. >=20 > What's really needed here is to send some packet from the IMAP server=20 > which resets all the NAT timeouts, but doesn't require a=20 > corresponding transmission from the handset. >=20 > Perhaps a duplicate ACK, for instance. (It's obviously a dirty hack,=20 > but the NAT people started it, as my son would say). >=20 > Dave. > --=20 > You see things; and you say "Why?" > But I dream things that never were; and I say "Why not?" > - George Bernard Shaw >=20 > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade >=20 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Oct 25 17:21:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUWEc-0008E9-3x; Tue, 25 Oct 2005 17:21:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUWEb-0008Cp-37 for lemonade@megatron.ietf.org; Tue, 25 Oct 2005 17:21:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15512 for ; Tue, 25 Oct 2005 17:21:13 -0400 (EDT) Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUWRa-0002Vl-14 for lemonade@ietf.org; Tue, 25 Oct 2005 17:34:57 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 4B6DF4AC78 for ; Tue, 25 Oct 2005 23:21:31 +0200 (CEST) Message-Id: Date: Tue, 25 Oct 2005 23:21:25 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Profile WG last call References: <085091CB2CA14E4B8B163FFC37C84E9D06D020B7@zcarhxm0.corp.nortel.com> <9700.1130265852.128428@peirce.dave.cridland.net> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Mark Crispin writes: > Keepalives can also be deadly. I found that I can not reliably keep > an ssh session to my server at work over NAT if the ssh server > enables keepalive. > > AFAICT, the cause is that keepalives misinterpret a short-term outage > as permanent. Depends. On linux, the outage currently has to last about 11 minutes. But yes, TCP keepalives have disadvantages. TLS keepalives seem better. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Oct 25 17:50:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUWgn-000560-Dq; Tue, 25 Oct 2005 17:50:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUWgl-00055A-Oy for lemonade@megatron.ietf.org; Tue, 25 Oct 2005 17:50:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17005 for ; Tue, 25 Oct 2005 17:50:20 -0400 (EDT) Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUWtk-0003Lc-Q3 for lemonade@ietf.org; Tue, 25 Oct 2005 18:04:04 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout2.cac.washington.edu (8.13.4+UW05.04/8.13.4+UW05.09) with ESMTP id j9PLoMnE030272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Oct 2005 14:50:23 -0700 X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.4+UW05.04/8.13.4+UW05.09) with ESMTP id j9PLoMGO019463 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 25 Oct 2005 14:50:22 -0700 Date: Tue, 25 Oct 2005 14:49:45 -0700 (Pacific Daylight Time) From: Mark Crispin To: Corby.Wilson@nokia.com Subject: RE: [lemonade] Profile WG last call In-Reply-To: <4422475A1E8D0248B00251C20D968F888B7785@bsebe101.NOE.Nokia.com> Message-ID: References: <4422475A1E8D0248B00251C20D968F888B7785@bsebe101.NOE.Nokia.com> 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='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: lemonade@ietf.org, arnt@gulbrandsen.priv.no X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Tue, 25 Oct 2005, Corby.Wilson@nokia.com wrote: > On no 3G network we were able to set this at about 7 minutes. On 3G > networks things were much worse and we had to lower it to 3-4 minutes. > In either case, the battery life was reduced, at a MINIMUM, by 50%. > Typically this was much worse when the user was traveling since the > power required by the radio increases with distance to the cell. My experience with 1xRTT was that I had a connection going for nearly an hour (with a background ping to keep it alive) and I hadn't eaten up my battery. That was about as long as I wanted to be online since I was paying voice minutes. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Oct 26 01:50:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUeBK-0007Ma-SY; Wed, 26 Oct 2005 01:50:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUeBH-0007ME-Qf for lemonade@megatron.ietf.org; Wed, 26 Oct 2005 01:50:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24923 for ; Wed, 26 Oct 2005 01:50:19 -0400 (EDT) Received: from agminet02.oracle.com ([141.146.126.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUeOL-0004At-Rr for lemonade@ietf.org; Wed, 26 Oct 2005 02:04:06 -0400 Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.186.112]) by agminet02.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9Q60VHi017250 for ; Wed, 26 Oct 2005 01:00:36 -0500 Received: from rgmgw3.us.oracle.com (localhost [127.0.0.1]) by rgmgw3.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j9Q5oIsu016406 for ; Tue, 25 Oct 2005 23:50:18 -0600 Received: from us.oracle.com (dhcp-apac-jp-csvpn-gw9-141-144-144-103.vpn.oracle.com [141.144.144.103]) by rgmgw3.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j9Q5oEo5016267 for ; Tue, 25 Oct 2005 23:50:17 -0600 From: "Stephane H. Maes" To: "lemonade@ietf.org" Subject: RE: [lemonade] Profile WG last call Date: Tue, 25 Oct 2005 22:50:01 -0700 In-Reply-To: <4422475A1E8D0248B00251C20D968F888B7785@bsebe101.NOE.Nokia.com> X-Sent-Folder-Path: Sent Items X-Mailer: Oracle Connector for Outlook 9.0.4.2.8 70113 (11.0.6359) Message-ID: <20051025225002259.00000000796@smaes-lap> 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: dbb8771284c7a36189745aa720dc20ab Content-Transfer-Encoding: quoted-printable X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Corby, Yes this also relates to the time out issue that we identified in draft-mae= s-lemonade-http-binding-03 and draft-smaes-lemonade-intermediary-challenges= -03. = Stability of the connection has user experience and battery life implicatio= ns. = Note that as we discussed in London, on HTTP the issue appeared much less p= roblematic... Stephane _____ Stephane H. Maes, PhD, Director of Architecture - OCS & Mobile, Oracle Corporation. 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) = -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] On Behal= f Of Corby.Wilson@nokia.com Sent: Tuesday, October 25, 2005 2:17 PM To: dave@cridland.net; arnt@gulbrandsen.priv.no Cc: lemonade@ietf.org Subject: RE: [lemonade] Profile WG last call We have tried several things including keep alives and pings. We have found that socket level keep alives don't work because the carrier infrastructure doesn't reset the cells on keep alives in some areas. The best success we have had is by using app level pings (some random data packet that is discarded) from the server to the client which keeps the conneciton up. On no 3G network we were able to set this at about 7 minutes. On 3G networks things were much worse and we had to lower it to 3-4 minutes. In either case, the battery life was reduced, at a MINIMUM, by 50%. Typically this was much worse when the user was traveling since the power required by the radio increases with distance to the cell. The ideal mechanism would be an out-of-band system like SMS which takes no significant power loss from the terminal. SIP doesn't seem to help much since it is connection based as well. Sugestions are very wellcome here. At this point, battery life is at a permium and people will turn off their email application to prevent battery drain so they can continue to make/receive calls. Corby Wilson = = > -----Original Message----- > From: lemonade-bounces@ietf.org = > [mailto:lemonade-bounces@ietf.org] On Behalf Of ext Dave Cridland > Sent: Tuesday, October 25, 2005 16:29 PM > To: Arnt Gulbrandsen > Cc: lemonade@ietf.org > Subject: Re: [lemonade] Profile WG last call > = > On Tue Oct 25 20:21:27 2005, Arnt Gulbrandsen wrote: > > Dave Cridland writes: > >> This also makes me wonder whether a server-transmitted NOOP packet = > >> might be possible, whether in IMAP or TCP, which might "hold" the = > >> NAT connection state live. I don't know enough TCP to know whether = > >> such a thing exists, nor do I know the internals of NATs et al to = > >> know whether even if it does, it might help. > > = > > Such a thing exists in TCP, it's called keepalive. If you can turn = > > it on, which isn't always, it defeats the NATs. > > = > > I think TLS has keepalives, too. That should be easy to enable from = > > the application. > = > Both are easy to do from the application, TCP keep alives are a = > socket option. > = > The trouble is, they require an acknowledgement from the other side, = > so you're using up battery to send it. > = > What's really needed here is to send some packet from the IMAP server = > which resets all the NAT timeouts, but doesn't require a = > corresponding transmission from the handset. > = > Perhaps a duplicate ACK, for instance. (It's obviously a dirty hack, = > but the NAT people started it, as my son would say). > = > 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 > = _______________________________________________ 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 Oct 26 01:53:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUeE5-00088o-UV; Wed, 26 Oct 2005 01:53:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUeE4-00088b-HP for lemonade@megatron.ietf.org; Wed, 26 Oct 2005 01:53:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25044 for ; Wed, 26 Oct 2005 01:53:14 -0400 (EDT) Received: from rgminet02.oracle.com ([148.87.122.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUeR7-0004Fp-34 for lemonade@ietf.org; Wed, 26 Oct 2005 02:06:58 -0400 Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.186.111]) by rgminet02.oracle.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id j9Q5rESM009231 for ; Tue, 25 Oct 2005 23:53:14 -0600 Received: from rgmgw2.us.oracle.com (localhost [127.0.0.1]) by rgmgw2.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j9Q5rEhW027815 for ; Tue, 25 Oct 2005 23:53:14 -0600 Received: from us.oracle.com (dhcp-apac-jp-csvpn-gw9-141-144-144-103.vpn.oracle.com [141.144.144.103]) by rgmgw2.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j9Q5rAhr027720 for ; Tue, 25 Oct 2005 23:53:13 -0600 From: "Stephane H. Maes" To: "lemonade@ietf.org" Subject: RE: [lemonade] Profile WG last call Date: Tue, 25 Oct 2005 22:52:57 -0700 In-Reply-To: X-Sent-Folder-Path: Sent Items X-Mailer: Oracle Connector for Outlook 9.0.4.2.8 70113 (11.0.6359) Message-ID: <20051025225258002.00000000796@smaes-lap> 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: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org BTW, I think that when we decided to put IDLE in Lemonade profile phase 2 it was= for consistency because we plan to discuss push / server to client notific= ation in phase 2. I do not believe that it was because we perceived a probl= em requiring IDLE. Stephane _____ Stephane H. Maes, PhD, Director of Architecture - OCS & Mobile, Oracle Corporation. 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) = -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] On Behal= f Of Arnt Gulbrandsen Sent: Tuesday, October 25, 2005 9:46 AM To: lemonade@ietf.org Subject: Re: [lemonade] Profile WG last call Glenn Parsons writes: > Folks, > > This message announces the commencement of the WG last call on the > LEMONADE profile: > http://www.ietf.org/internet-drafts/draft-ietf-lemonade-profile-05.txt > > Please review this document paying special attention to: > - the list of MUST implement features > (note the editors suggest adding IDLE and $forward to the > baseline we agreed in London) I have a question about this. Since it's a suggestion not done yet, I assume there are people who don't want to implement IDLE. I further assume that these are clueful people. The question is then: Why? What counts against IDLE? (IMO the list is fine, although I'd prefer adding IDLE and $forward. We'll implement everything on the list.) > - the noted open issues I think literal+ examples, while perhaps desirable, aren't at all important. RFC 2088 will do. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Oct 26 03:43:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUfwo-0005VY-KF; Wed, 26 Oct 2005 03:43:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUfwm-0005SF-Oy for lemonade@megatron.ietf.org; Wed, 26 Oct 2005 03:43:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01109 for ; Wed, 26 Oct 2005 03:43:29 -0400 (EDT) Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUg9t-0007qI-4Y for lemonade@ietf.org; Wed, 26 Oct 2005 03:57:18 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 04F374ACC0 for ; Wed, 26 Oct 2005 09:43:45 +0200 (CEST) Message-Id: Date: Wed, 26 Oct 2005 09:43:42 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Profile WG last call References: <4422475A1E8D0248B00251C20D968F888B7785@bsebe101.NOE.Nokia.com> In-Reply-To: <4422475A1E8D0248B00251C20D968F888B7785@bsebe101.NOE.Nokia.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org So if I understand this correctly, there aren't actually any arguments against IDLE as such. It's just that it's less use than on real networks, because a lot of networks discard TCP connections after some idleness, and keepalives cannot be used. Two specific comments: Corby.Wilson@nokia.com writes: > The best success we have had is by using app level pings (some random > data packet that is discarded) from the server to the client which > keeps the conneciton up. This should be similar to TLS keepalives. (IIRC a TLS keepalive is just a packet with zero bytes plaintext and 16 bytes padding, all encrypted and sent to the peer.) > Sugestions are very wellcome here. At this point, battery life is at a > permium and people will turn off their email application to prevent > battery drain so they can continue to make/receive calls. Will carriers configure their networks to permit longer-lasting idleness so customers can use email effectively? The issue isn't specific to IDLE. IDLE makes it show up clearly, but so does a complex SEARCH on a big mailbox. And of course IMAP permits a client to leave the connection idle without issuing IDLE. I think LEMONADE will eventually have to specify something like "carrier cannot discard TCP connections until at least x minutes have passed" or refer to the autlogout part of 3501. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Oct 26 06:33:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUib5-0005z3-GN; Wed, 26 Oct 2005 06:33:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUib3-0005yy-U9 for lemonade@megatron.ietf.org; Wed, 26 Oct 2005 06:33:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10295 for ; Wed, 26 Oct 2005 06:33:13 -0400 (EDT) Received: from dsl-217-155-137-62.zen.co.uk ([217.155.137.62] helo=gw2.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUioB-0004fZ-N4 for lemonade@ietf.org; Wed, 26 Oct 2005 06:47:05 -0400 Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by gw2.dave.cridland.net (Postfix) with ESMTP id 06BE0154009; Wed, 26 Oct 2005 10:33:12 +0000 (UTC) Date: Wed, 26 Oct 2005 11:33:12 +0100 Subject: Re: [lemonade] Profile WG last call References: <4422475A1E8D0248B00251C20D968F888B7785@bsebe101.NOE.Nokia.com> In-Reply-To: MIME-Version: 1.0 Message-Id: <12562.1130322792.901501@peirce.dave.cridland.net> From: Dave Cridland To: Arnt Gulbrandsen Content-Type: text/plain; charset="iso-8859-1"; format="flowed" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Wed Oct 26 08:43:42 2005, Arnt Gulbrandsen wrote: > So if I understand this correctly, there aren't actually any=20 > arguments against IDLE as such. It's just that it's less use than=20 > on real networks, because a lot of networks discard TCP connections=20 > after some idleness, and keepalives cannot be used. >=20 >=20 Exactly. > Two specific comments: >=20 > Corby.Wilson@nokia.com writes: >> The best success we have had is by using app level pings (some=20 >> random data packet that is discarded) from the server to the=20 >> client which keeps the conneciton up. >=20 > This should be similar to TLS keepalives. (IIRC a TLS keepalive is=20 > just a packet with zero bytes plaintext and 16 bytes padding, all=20 > encrypted and sent to the peer.) >=20 >=20 Sure, but this requires at the very least an ACK at the TCP level. >> Sugestions are very wellcome here. At this point, battery life is=20 >> at a permium and people will turn off their email application to=20 >> prevent battery drain so they can continue to make/receive calls. >=20 > Will carriers configure their networks to permit longer-lasting=20 > idleness so customers can use email effectively? The distinct impression I came away with from St=E9phane's discussions=20 at the Interim meeting was that the carriers won't fix, perhaps=20 partly because they're unclear what the problem actually is. Moreover, this problem affects more than just mobile networks, it=20 affects most of the installed base of NAT, and some stateful=20 inspection firewalls, too. While I'd like to see people configuring such devices properly,=20 ideally we need a solution that works now. For non-mobile=20 environments, where transmission isn't so costly, TLS keepalives work=20 fine. It's how to avoid transmissions on the part of the client=20 that's the problem here. 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 From lemonade-bounces@ietf.org Wed Oct 26 06:43:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUikH-0000KZ-U7; Wed, 26 Oct 2005 06:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUikF-0000JF-Q9 for lemonade@megatron.ietf.org; Wed, 26 Oct 2005 06:42:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10789 for ; Wed, 26 Oct 2005 06:42:43 -0400 (EDT) From: Corby.Wilson@nokia.com Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUixN-0004yB-NM for lemonade@ietf.org; Wed, 26 Oct 2005 06:56:35 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9QAgsQv005670; Wed, 26 Oct 2005 13:42:55 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Oct 2005 13:42:49 +0300 Received: from bsebe101.NOE.Nokia.com ([172.19.160.235]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Oct 2005 05:42:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Profile WG last call Date: Wed, 26 Oct 2005 06:42:44 -0400 Message-ID: <4422475A1E8D0248B00251C20D968F888B783D@bsebe101.NOE.Nokia.com> Thread-Topic: [lemonade] Profile WG last call Thread-Index: AcXaATYbfkuJNtzdR9ak/2wZ8Af3VgAGHqfQ To: , X-OriginalArrivalTime: 26 Oct 2005 10:42:46.0498 (UTC) FILETIME=[00A89420:01C5DA1A] X-Spam-Score: 0.3 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org IDLE works really well for wired and WLAN terminals, so IDLE is still something we want. IDLE would be a great first step, but we need to keep in mind that we will want to offer alternate signalign methods for low-resource devices. One option is to allow OMA/3GPP networks to define their own signaling methods from a border controller or signaling server. We discussed this before and SIEVE seems to be taking this into account. Make the signal transport generic and allow border controllers to select the appropriate transport for the network. Corby Wilson =20 =20 > -----Original Message----- > From: lemonade-bounces@ietf.org=20 > [mailto:lemonade-bounces@ietf.org] On Behalf Of ext Arnt Gulbrandsen > Sent: Wednesday, October 26, 2005 03:44 AM > To: lemonade@ietf.org > Subject: Re: [lemonade] Profile WG last call >=20 > So if I understand this correctly, there aren't actually any=20 > arguments=20 > against IDLE as such. It's just that it's less use than on real=20 > networks, because a lot of networks discard TCP connections=20 > after some=20 > idleness, and keepalives cannot be used. >=20 > Two specific comments: >=20 > Corby.Wilson@nokia.com writes: > > The best success we have had is by using app level pings=20 > (some random=20 > > data packet that is discarded) from the server to the client which=20 > > keeps the conneciton up. >=20 > This should be similar to TLS keepalives. (IIRC a TLS=20 > keepalive is just=20 > a packet with zero bytes plaintext and 16 bytes padding, all=20 > encrypted=20 > and sent to the peer.) >=20 > > Sugestions are very wellcome here. At this point, battery=20 > life is at a=20 > > permium and people will turn off their email application to prevent=20 > > battery drain so they can continue to make/receive calls. >=20 > Will carriers configure their networks to permit=20 > longer-lasting idleness=20 > so customers can use email effectively? >=20 > The issue isn't specific to IDLE. IDLE makes it show up=20 > clearly, but so=20 > does a complex SEARCH on a big mailbox. And of course IMAP permits a=20 > client to leave the connection idle without issuing IDLE. I think=20 > LEMONADE will eventually have to specify something like=20 > "carrier cannot=20 > discard TCP connections until at least x minutes have passed"=20 > or refer=20 > to the autlogout part of 3501. >=20 > Arnt >=20 > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade >=20 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Oct 26 10:31:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUmJf-0000wa-9G; Wed, 26 Oct 2005 10:31:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUmJe-0000wV-EL for lemonade@megatron.ietf.org; Wed, 26 Oct 2005 10:31:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23501 for ; Wed, 26 Oct 2005 10:31:31 -0400 (EDT) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUmWo-0003iC-EM for lemonade@ietf.org; Wed, 26 Oct 2005 10:45:23 -0400 Received: from [172.16.2.193] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 26 Oct 2005 15:31:25 +0100 Message-ID: <435F933D.6010806@isode.com> Date: Wed, 26 Oct 2005 15:31:25 +0100 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 MIME-Version: 1.0 To: Arnt Gulbrandsen Subject: Re: [lemonade] Profile WG last call References: <4422475A1E8D0248B00251C20D968F888B7785@bsebe101.NOE.Nokia.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Arnt Gulbrandsen wrote: > So if I understand this correctly, there aren't actually any arguments > against IDLE as such. It's just that it's less use than on real > networks, because a lot of networks discard TCP connections after some > idleness, and keepalives cannot be used. As Stephane has mentioned IDLE is more logically grouped with filtering and notifications, which is in phase 2. I just thought that we add IDLE to profile 1 we bundle too many extensions together so that people will be reluctant to implement then in servers. I hope I am wrong. (And personally I don't care, we've just added IDLE to Isode server ;-)). Alexey _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Oct 26 10:39:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUmRM-0004rK-5V; Wed, 26 Oct 2005 10:39:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUmRK-0004rC-7u for lemonade@megatron.ietf.org; Wed, 26 Oct 2005 10:39:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23999 for ; Wed, 26 Oct 2005 10:39:26 -0400 (EDT) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUmeU-0003zZ-5i for lemonade@ietf.org; Wed, 26 Oct 2005 10:53:19 -0400 Received: from [172.16.2.193] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 26 Oct 2005 15:39:21 +0100 Message-ID: <435F951A.7040601@isode.com> Date: Wed, 26 Oct 2005 15:39:22 +0100 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 MIME-Version: 1.0 To: "Vaudreuil, Greg M (Greg)" Subject: Re: [lemonade] Profile WG last call References: <54E40201497DF142B06B27255953F79718F30D8E@il0015exch007u.ih.lucent.com> In-Reply-To: <54E40201497DF142B06B27255953F79718F30D8E@il0015exch007u.ih.lucent.com> X-Spam-Score: 0.8 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0414267551==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --===============0414267551== Content-Type: multipart/alternative; boundary="------------090402030308010408020002" --------------090402030308010408020002 Content-type: text/plain; charset="KOI8-R"; format="flowed" Content-Transfer-Encoding: 7bit Hi Greg, Thanks for the comments. I've replying to the obvious comments first. Vaudreuil, Greg M (Greg) wrote: > I have the following comments after reviewing the latest version of > the profile, 05. > > Last work in 2nd to last paragraph of Page 4 "server" => "Client or > MUA". Server already has the fragments. Fixed, thanks. > Section 3.1 > > "clients should pipeline" may be more completely worded "clients > should pipeline SMTP commands when possible". Changed. > Normative references section is missing RFC 2034 required in 3.4 I see such reference in the posted document? --------------090402030308010408020002 Content-type: text/html; charset="KOI8-R" X-Encoded: Changed encoding from 8bit for 7bit transmission Content-Transfer-Encoding: quoted-printable Hi Greg,
Thanks for the comments.
I've replying to the obvious comments first.

Vaudreuil, Greg M (Greg) wrote:
Profile WG last call I have the following comments after reviewing the latest version of the profile, 05.
=9A
Last work in 2nd to last paragraph of Page 4=9A "server" =3D> "Client or MUA".=9A Server already has the fragments.=
Fixed, thanks. =9A
Section 3.1
=9A
"clients should pipeline" may be more completely worded "clients should pipeline=9ASMTP commands when possible".
Changed.=9A
Normative references section is missing RFC 2034 required in 3.4
I see such reference in the posted document?

--------------090402030308010408020002-- --===============0414267551== 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 --===============0414267551==-- From lemonade-bounces@ietf.org Wed Oct 26 18:52:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUu87-0001J5-LU; Wed, 26 Oct 2005 18:52:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUu5y-0000Vs-NZ; Wed, 26 Oct 2005 18:50:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02362; Wed, 26 Oct 2005 18:49:53 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUuJ7-0008HS-7o; Wed, 26 Oct 2005 19:03:48 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EUu5q-0005cq-Pr; Wed, 26 Oct 2005 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 26 Oct 2005 18:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-futuredelivery-03.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org 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-03.txt Pages : 12 Date : 2005-10-26 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-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-futuredelivery-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-futuredelivery-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-26181338.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-futuredelivery-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-futuredelivery-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-26181338.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 Oct 28 10:38:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVVMw-0005b5-NV; Fri, 28 Oct 2005 10:38:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVVMw-0005b0-1v for lemonade@megatron.ietf.org; Fri, 28 Oct 2005 10:38:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20610 for ; Fri, 28 Oct 2005 10:37:53 -0400 (EDT) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVVaV-0007hV-G8 for lemonade@ietf.org; Fri, 28 Oct 2005 10:52:12 -0400 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 j9SEbwLB019489; Fri, 28 Oct 2005 09:37:58 -0500 (CDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 28 Oct 2005 09:37:58 -0500 Message-ID: <54E40201497DF142B06B27255953F797190B0729@il0015exch007u.ih.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: Alexey Melnikov Subject: RE: [lemonade] Profile WG last call Date: Fri, 28 Oct 2005 09:37:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.8 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1605775561==" Sender: lemonade-bounces@ietf.org 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. --===============1605775561== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5DBCD.2E353628" 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_001_01C5DBCD.2E353628 Content-Type: text/plain; charset="koi8-r" I see my confusion on the RFC2034 reference. I was expecting a reference to 3463, "Enhanced Mail System Status Codes". However, because RFC2034 depends upon it we are covered. I did not see responses from you or Stephane on the balance of my comments. Greg V. ------_=_NextPart_001_01C5DBCD.2E353628 Content-Type: text/html; charset="koi8-r"

I see my confusion on the RFC2034 reference.  I was expecting a reference to 3463, "Enhanced Mail System Status Codes".  However, because  RFC2034 depends upon it we are covered.
 
I did not see responses from you or Stephane on the balance of my comments.
 
Greg V.
------_=_NextPart_001_01C5DBCD.2E353628-- --===============1605775561== 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 --===============1605775561==-- From lemonade-bounces@ietf.org Fri Oct 28 10:53:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVVbx-0006mJ-Br; Fri, 28 Oct 2005 10:53:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVVbw-0006mE-Jh for lemonade@megatron.ietf.org; Fri, 28 Oct 2005 10:53:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22411 for ; Fri, 28 Oct 2005 10:53:24 -0400 (EDT) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVVpV-0008Fm-Vc for lemonade@ietf.org; Fri, 28 Oct 2005 11:07:43 -0400 Received: from [172.16.2.167] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Fri, 28 Oct 2005 15:53:06 +0100 Message-ID: <43623B50.2070307@isode.com> Date: Fri, 28 Oct 2005 15:53:04 +0100 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: "Vaudreuil, Greg M (Greg)" Subject: Re: [lemonade] Profile WG last call References: <54E40201497DF142B06B27255953F79718F30D8E@il0015exch007u.ih.lucent.com> In-Reply-To: <54E40201497DF142B06B27255953F79718F30D8E@il0015exch007u.ih.lucent.com> MIME-version: 1.0 Content-type: text/plain; charset="KOI8-R"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Vaudreuil, Greg M (Greg) wrote: > Last paragraph of Page 4 introduces two new concepts without > describing what they are '"forward without download" strategy' and > 'variant'. Text saying > > "There are two use variants based on where the message assembly > takes place . The first uses > a succession of BURL and BDAT commands to submit and assemble > through concatenation, > message data from the client and external data fetched from the > provided URL. The second uses > the Catenate command to upload a template to the message store > and cause the message assembly > on the IMAP server." > > At least, that is what I think the authors were thinking but not > stating. Along those lines, do we need an example of the first > variant? The only text describing this variant is in section 2.5 > explaining why chunking needs to be supported. The original text was taken from Mark's document about different pull variants. So it has to be rewritten. One way of rewriting would be to add something like the text you've suggested and add another example. Let's discuss this during the upcoming Lemonade WG meeting. > Section 2.7. > > A sentence or two about how to actually use catenate to solve the FCC > problem would help. Sure. > Is the solution to move the template into the "sent items" mailbox > prior to requesting a URLAUTH? The solution is to catenate the final message to the "sent items" mailbox. > Do we need to discuss "sent items" conventions here? We can get away without such discussion by saying that the sent items mailbox is "a mailbox where you want to have your final message". However, one can have a per-user annotation or a NAMESPACE command extension to specify the default "sent items" mailbox, so that users can have consistent behavior across multiple mail clients. Is it something that people want to pursue for Phase 1 or in general? Just my opinion. Alexey _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Oct 28 14:50:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVZJ1-0006mo-Dq; Fri, 28 Oct 2005 14:50:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVZJ0-0006kW-GG for lemonade@megatron.ietf.org; Fri, 28 Oct 2005 14:50:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02916 for ; Fri, 28 Oct 2005 14:50:04 -0400 (EDT) Received: from dsl-217-155-137-62.zen.co.uk ([217.155.137.62] helo=gw2.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVZWc-0006IG-33 for lemonade@ietf.org; Fri, 28 Oct 2005 15:04:27 -0400 Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by gw2.dave.cridland.net (Postfix) with ESMTP id 4B49F154009 for ; Fri, 28 Oct 2005 18:49:59 +0000 (UTC) Date: Fri, 28 Oct 2005 19:49:57 +0100 Subject: Re: [lemonade] Profile WG last call References: <085091CB2CA14E4B8B163FFC37C84E9D06D020B7@zcarhxm0.corp.nortel.com> In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D06D020B7@zcarhxm0.corp.nortel.com> MIME-Version: 1.0 Message-Id: <27080.1130525399.201020@peirce.dave.cridland.net> From: Dave Cridland To: Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Tue Oct 25 16:22:13 2005, Glenn Parsons wrote: > Please review this document paying special attention to: > - the list of MUST implement features > (note the editors suggest adding IDLE and $forward to the > baseline we agreed in London) I was going to raise an issue about quality of implementation with IMAP BINARY, but then noticed that the IMAP BINARY extension isn't actually part of the profile at all. Given that, for base64 encoded message parts, it represents a saving of 25%, I think it should be. Many IMAP servers already implement it, and although the base64 growth is somewhat mitigated by some form of compression, transmission in binary is going to be better. With gzip, for instance, a 145k JPEG compresses to 144k, but encoded in base64 is 196k, which compresses to 148k. Comparing gzip with BINARY, then, the phone has had to transmit an extra 3k of data, which has been encoded twice instead of not at all, presumably a waste of CPU resources. My point was going to be that since one of the more bandwidth-saving uses of BINARY in Lemonade is likely to be in sending images from camera phones, we need to additionally mandate that APPEND with binary content MUST be implemented - some implementations only support FETCH ... BINARY, and issue a NO [UNKNOWN-CTE] if they see binary content being uploaded. 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 Oct 28 16:40:35 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVb1f-0002vq-1x; Fri, 28 Oct 2005 16:40:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVb1d-0002vi-7u for lemonade@megatron.ietf.org; Fri, 28 Oct 2005 16:40:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17958 for ; Fri, 28 Oct 2005 16:40:16 -0400 (EDT) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVbFF-0004KF-P2 for lemonade@ietf.org; Fri, 28 Oct 2005 16:54:39 -0400 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 j9SKeJc0002578; Fri, 28 Oct 2005 15:40:20 -0500 (CDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 28 Oct 2005 15:40:19 -0500 Message-ID: <54E40201497DF142B06B27255953F797190B0CF5@il0015exch007u.ih.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: Dave Cridland , lemonade@ietf.org Subject: RE: [lemonade] Profile WG last call Date: Fri, 28 Oct 2005 15:40:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org I have overlooked this omission in London. I had expected to see IMAP binary as an essential part of the profile, especially since we do not specify compression in Phase-1 of the profile. I support adding IMAP binary into phase-1. It is a stable reference, the primary criteria we adopted. Greg V. -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org]On Behalf Of Dave Cridland Sent: Friday, October 28, 2005 2:50 PM To: lemonade@ietf.org Subject: Re: [lemonade] Profile WG last call On Tue Oct 25 16:22:13 2005, Glenn Parsons wrote: > Please review this document paying special attention to: > - the list of MUST implement features > (note the editors suggest adding IDLE and $forward to the > baseline we agreed in London) I was going to raise an issue about quality of implementation with IMAP BINARY, but then noticed that the IMAP BINARY extension isn't actually part of the profile at all. Given that, for base64 encoded message parts, it represents a saving of 25%, I think it should be. Many IMAP servers already implement it, and although the base64 growth is somewhat mitigated by some form of compression, transmission in binary is going to be better. With gzip, for instance, a 145k JPEG compresses to 144k, but encoded in base64 is 196k, which compresses to 148k. Comparing gzip with BINARY, then, the phone has had to transmit an extra 3k of data, which has been encoded twice instead of not at all, presumably a waste of CPU resources. My point was going to be that since one of the more bandwidth-saving uses of BINARY in Lemonade is likely to be in sending images from camera phones, we need to additionally mandate that APPEND with binary content MUST be implemented - some implementations only support FETCH ... BINARY, and issue a NO [UNKNOWN-CTE] if they see binary content being uploaded. 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 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Oct 28 16:52:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVbD7-0001En-1e; Fri, 28 Oct 2005 16:52:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV9Pe-0003IY-Nf for lemonade@megatron.ietf.org; Thu, 27 Oct 2005 11:11:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09337 for ; Thu, 27 Oct 2005 11:11:14 -0400 (EDT) Received: from darius.cyrusoft.com ([63.163.82.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV9d0-0006g3-NQ for lemonade@ietf.org; Thu, 27 Oct 2005 11:25:20 -0400 Received: from [10.0.1.2] (pool-71-240-26-158.pitt.east.verizon.net [71.240.26.158]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j9RF3QuG014620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 27 Oct 2005 11:03:28 -0400 Date: Thu, 27 Oct 2005 11:11:14 -0400 From: Cyrus Daboo To: lemonade@ietf.org Message-ID: <5C85F6C599780EA232ADD780@ninevah.local> 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-Status: No, hits=0.0 tests=none X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 28 Oct 2005 16:52:23 -0400 Subject: [lemonade] futuredelivery: client/server time sync problems X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Hi folks, The issue of client and server times being out-of-sync has been discussed before wrt FUTURERELEASE (aka FUTUREDELIVERY). That is a problem if the client wants to 'until' option and specify a UTC time. Often client machines are not setup correctly with the proper local time info so that UTC calculation on the client side made be incorrect. One simple solution to this would be to have the server return its current UTC time in the FUTURERELEASE EHLO response. This would allow clients to use a UTC time based on the server's value rather than its own. Or at the very least throw up a warning to the user if the client and server times are significantly different. Note that having the server provide its value of UTC may eliminate the need to have two release methods as described in section 4.1 of the current draft. -- Cyrus Daboo _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Oct 28 17:23:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVbhN-0008KR-Tt; Fri, 28 Oct 2005 17:23:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVbhM-0008KH-4s for lemonade@megatron.ietf.org; Fri, 28 Oct 2005 17:23:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20697 for ; Fri, 28 Oct 2005 17:23:22 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVbuy-0005gQ-83 for lemonade@ietf.org; Fri, 28 Oct 2005 17:37:45 -0400 Received: from fe-amer-10.sun.com ([192.18.108.184]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j9SLNa3F022127 for ; Fri, 28 Oct 2005 15:23:36 -0600 (MDT) 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 <0IP300D01A17RC00@mail-amer.sun.com> (original mail from Anil.Srivastava@Sun.COM) for lemonade@ietf.org; Fri, 28 Oct 2005 15:23:36 -0600 (MDT) Received: from [192.18.127.162] (host-162-127-18-192.iplanet.com [192.18.127.162]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IP300DZGA3BYNE0@mail-amer.sun.com>; Fri, 28 Oct 2005 15:23:36 -0600 (MDT) Date: Fri, 28 Oct 2005 14:22:58 -0700 (Pacific Daylight Time) From: Anil SRIVASTAVA Subject: Re: [lemonade] Profile WG last call In-reply-to: <43623B50.2070307@isode.com> To: Alexey Melnikov Message-id: Organization: Sun Microsystems [http://www.sun.com] MIME-version: 1.0 X-Mailer: Pine 4.63 - Got Pine? Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Accept-Language: English; en X-Message-Class: normal X-Endorsement: This message brought to you by Sun Java System Messaging Server 6.2 References: <54E40201497DF142B06B27255953F79718F30D8E@il0015exch007u.ih.lucent.com> <43623B50.2070307@isode.com> X-Message-flag: Outlook: the best virus distribution system around X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7BIT Cc: lemonade@ietf.org, "Vaudreuil, Greg M \(Greg\)" 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On 2005-10-28/15:53 [+0100], alexey.melnikov@isode.com [Alexey Melnikov] wrote: > Vaudreuil, Greg M (Greg) wrote: > > > Is the solution to move the template into the "sent items" mailbox > > prior to requesting a URLAUTH? > > The solution is to catenate the final message to the "sent items" > mailbox. > > > Do we need to discuss "sent items" conventions here? > > We can get away without such discussion by saying that the sent items > mailbox is "a mailbox where you want to have your final message". > > However, one can have a per-user annotation or a NAMESPACE command > extension to specify the default "sent items" mailbox, so that users > can have consistent behavior across multiple mail clients. Is it > something that people want to pursue for Phase 1 or in general? > I would like to see us pursue this in general (and maybe phase 2 of the profile). Having 'sent items' and 'draft' mailboxes specified as a NAMESPACE command extension make sense. > Just my opinion. > > Alexey > _______________ Anil SRIVASTAVA anil.srivastava@Sun.COM _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Oct 28 17:46:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVc3a-000214-Hm; Fri, 28 Oct 2005 17:46:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVc3Y-00020z-3w for lemonade@megatron.ietf.org; Fri, 28 Oct 2005 17:46:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21743 for ; Fri, 28 Oct 2005 17:46:19 -0400 (EDT) Received: from mxout7.cac.washington.edu ([140.142.32.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVcHA-0006GB-1c for lemonade@ietf.org; Fri, 28 Oct 2005 18:00:42 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout7.cac.washington.edu (8.13.4+UW05.04/8.13.4+UW05.09) with ESMTP id j9SLkTsY029020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Oct 2005 14:46:29 -0700 X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id j9SLkT03003236 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 28 Oct 2005 14:46:29 -0700 Date: Fri, 28 Oct 2005 14:46:28 -0700 (Pacific Daylight Time) From: Mark Crispin To: Anil SRIVASTAVA Subject: Re: [lemonade] Profile WG last call In-Reply-To: Message-ID: References: <54E40201497DF142B06B27255953F79718F30D8E@il0015exch007u.ih.lucent.com> <43623B50.2070307@isode.com> 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='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: lemonade@ietf.org, Alexey Melnikov , "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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Fri, 28 Oct 2005, Anil SRIVASTAVA wrote: > I would like to see us pursue this in general (and maybe phase 2 of the > profile). Having 'sent items' and 'draft' mailboxes specified as a > NAMESPACE command extension make sense. Swamp. Slippery slope. Quagmire. I do not think that it would be wise to step into this. There are many stakeholders to the concepts of "sent items" and "draft" whose interests would be threatened by an attempt to bless one particular scheme of these concepts. If the chosen scheme is incompatible with their installed base, it is safe to assume that they will protest. Unfortunately, it is unlikely that any one scheme can be chosen which will be compatible with what all of these stakeholders are doing. Something done with annotations, or preferably ACAP, would probably not trigger such objections. In that case, however, I think that there should be a specific LEMONADE (not IMAP) definition of "sent items" and "drafts". This removes the threat, while still creating an incentive. To be specific: the threat is an ex post facto declaration that you are not IMAP-compliant, whereas the incentive is to become LEMONADE-compliant. It doesn't matter that it would be an extension to NAMESPACE; it would still have the effect of creating be "an IMAP definition" which renders existing clients non-compatible. By being in NAMESPACE, it brings the IMAP server into the issue. Hence the alternative of a LEMONADE definition, which is mandatory for LEMONADE clients and which other clients *may* adopt. Ideally, the IMAP server is not brought in to the equation. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Oct 28 19:56:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVe4v-0002dg-UJ; Fri, 28 Oct 2005 19:56:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVe4u-0002dS-82 for lemonade@megatron.ietf.org; Fri, 28 Oct 2005 19:56:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27875 for ; Fri, 28 Oct 2005 19:55:50 -0400 (EDT) Received: from mxout4.cac.washington.edu ([140.142.33.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVeIW-00019a-47 for lemonade@ietf.org; Fri, 28 Oct 2005 20:10:15 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout4.cac.washington.edu (8.13.4+UW05.04/8.13.4+UW05.09) with ESMTP id j9SNu0fZ028529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Oct 2005 16:56:00 -0700 X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id j9SNu0WN025984 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 28 Oct 2005 16:56:00 -0700 Date: Fri, 28 Oct 2005 16:55:59 -0700 (Pacific Daylight Time) From: Mark Crispin To: Cyrus Daboo Subject: Re: [lemonade] futuredelivery: client/server time sync problems In-Reply-To: <5C85F6C599780EA232ADD780@ninevah.local> Message-ID: References: <5C85F6C599780EA232ADD780@ninevah.local> 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='__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: 0a7aa2e6e558383d84476dc338324fab Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Thu, 27 Oct 2005, Cyrus Daboo wrote: > The issue of client and server times being out-of-sync has been discussed > before wrt FUTURERELEASE (aka FUTUREDELIVERY). That is a problem if the > client wants to 'until' option and specify a UTC time. Often client machines > are not setup correctly with the proper local time info so that UTC > calculation on the client side made be incorrect. The presumption with this problem statement is that the desire is to delay for an interval. If I want to delay until a specific time, it is of no consequence what the setting is of the mobile device's time. There is one possible exception: If I, as the user, say "send this after 6PM Seattle time", then my mobile device needs to know what "Seattle time" means. Many mobile devices have a "world clock" feature that can do this; however there's a question of current summer time phase. If the "world clock" knows the summer time rules, then the mobile device must know the day accurately (or at least within the current phase). Most "world clocks" require the summer time phase to be set manually by the user. > One simple solution to this would be to have the server return its > current UTC time in the FUTURERELEASE EHLO response. This begs the question of what should happen when (not if) this time fails to match: . the mobile phone network's time . the time obtainable from credible NTP servers . the time obtained from GPS We can simplify matters by saying that GPS time always overrides time from an Internet time server. We can also say that in the case of GSM networks, mobile phone network time is always disregarded in favor of GPS time or NTP time; unfortunately we can't do that in the case of a CDMA network. However, no matter how we look at it, there's at least two, possibly three, times that the device must keep track of. I'm not sure that the extra complexity is worth it. I also don't see how it's significantly better to synchronize with the submission server instead of requiring that both client and server synchronize with GPS or NTP. In particular, we should stipulate that the client MUST synchronize with GPS or NTP and not use a mobile phone network time that may have been set from some operator's watch. Even a CDMA network may have bogus time (especially if it's in an island with no other network). > Note that having the server provide its value of UTC may eliminate the need > to have two release methods as described in section 4.1 of the current draft. Not unless you force the client to synchronize with the server. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Oct 31 22:17:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWmeb-0000AF-T6; Mon, 31 Oct 2005 22:17:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWmeb-0000A9-0t for lemonade@megatron.ietf.org; Mon, 31 Oct 2005 22:17:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05990 for ; Mon, 31 Oct 2005 22:17:20 -0500 (EST) Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWmss-00018g-TG for lemonade@ietf.org; Mon, 31 Oct 2005 22:32:28 -0500 X-IronPort-AV: i="3.97,271,1125892800"; d="scan'208"; a="22094910:sNHT54333720" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 31 Oct 2005 22:17:30 -0500 Message-ID: <330A23D8336C0346B5C1A5BB1966664701794C73@ATLANTIS.Brooktrout.com> Thread-Topic: Submission of New Liaison Statement, "OMA MWG-MEM SWG Liaison on Mobile e-mail to the IETF LEMONADE WG" Thread-Index: AcXeYCurb8kGlGESSgO2DEvtho2rXAAMnydQ From: "Eric Burger" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Subject: [lemonade] FW: Submission of New Liaison Statement, "OMA MWG-MEM SWG Liaison on Mobile e-mail to the IETF LEMONADE WG" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org The full liaison statement and PDF copies of the OMA Mobile E-Mail Requirements and Architecture Documents are at the supplemental web site, under liaisons: http://flyingfox.snowshore.com/i-d/lemonade -----Original Message----- From: Apache [mailto:apache@newodin.ietf.org] On Behalf Of Dean Willis(OMA) Sent: Monday, October 31, 2005 4:15 PM To: gparsons@nortel.com; Eric Burger Cc: jerry.weingarten@comverse.com; jerry.weingarten@comverse.com; statements@ietf.org Subject: Submission of New Liaison Statement, "OMA MWG-MEM SWG Liaison on Mobile e-mail to the IETF LEMONADE WG"=20 Title: OMA MWG-MEM SWG Liaison on Mobile e-mail to the IETF LEMONADE WG Submission Date: 2005-10-31 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=3D143=20 From: Dean Willis(OMA) To: IETF LEMONADE Working Group(gparsons@nortel.com, eburger@brooktrout.com) Cc:=20 Reponse Contact: jerry.weingarten@comverse.com Technical Contact: jerry.weingarten@comverse.com Purpose: For information=20 Body: 1 Overview This liaison is to inform IETF LEMONADE of the status of the RD. 2 Proposal The OMA MWG-MEM wishes to thank the IETF LEMONADE WG for our ongoing collaboration. =20 We would like to inform you that we have received candidate approval of the MEM RD (Requirements Document). =20 The draft is available here: http://www.openmobilealliance.org/ftp/TP/ID/05/OMA-TP-2005-0320-Mobile_E mail_RD_for_approval.zip The RD will be permanently available on the OMA website under Release Programs: http://www.openmobilealliance.org/release_program/index.html OMA MWG-MEM will hold its next meeting on December 12-16 in Athens, Greece. 3 Requested Action(s) We suggest that the IETF LEMONADE WG review the RD for your information. Attachment(s): OMA MWG-MEM SWG Liaison on Mobile e-mail to the IETF LEMONADE WG (https://datatracker.ietf.org/documents/LIAISON/file201.doc) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade