From lemonade-bounces@ietf.org Sun Apr 02 12:57:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQ5tH-00082O-9R; Sun, 02 Apr 2006 12:57:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQ5tF-00082J-V0 for lemonade@ietf.org; Sun, 02 Apr 2006 12:57:25 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQ5tB-0008Ni-7P for lemonade@ietf.org; Sun, 02 Apr 2006 12:57:25 -0400 Received: from [10.0.1.4] (bb-87-80-192-157.ukonline.co.uk [87.80.192.157]) by rufus.isode.com via TCP (submission) with ESMTPA; Sun, 2 Apr 2006 17:56:46 +0100 Message-ID: <442F466E.9050907@isode.com> Date: Sat, 01 Apr 2006 19:35:10 -0800 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Crispin Subject: Re: [lemonade] confusion on syntax of the access portion of the URLAUTH References: <13fb01c65438$b5793880$d3219681@Tundra> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: lemonade@ietf.org, Peter Coates X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Mark Crispin wrote: > I think that we decided that iauth wasn't meaningful in IMAP URLs that > use URLAUTH, because we don't allow relative IMAP URLs with URLAUTH. > > But I forget why we used the iuserauth instead of the enc_user rule. > > Should we fix this? Yes. Note that in Dallas the consensus of the WG was to fold the URL part of URLAUTH document into draft-ietf-lemonade-rfc2192bis-XX.txt, so I will update and fix ABNF in this draft as well. > Can I get away with doing so during AUTH48? I hope Ted will treat this as editorial change, as inclusion of ";auth=xxx" was certainly not the intent of the WG. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Apr 03 14:05:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQTQV-0008Hg-IC; Mon, 03 Apr 2006 14:05:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQTQT-0008HG-LJ for lemonade@ietf.org; Mon, 03 Apr 2006 14:05:17 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQTQT-0005aF-AC for lemonade@ietf.org; Mon, 03 Apr 2006 14:05:17 -0400 Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k33I5Guf025665 for ; Mon, 3 Apr 2006 12:05:16 -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 <0IX500M01R6JBP00@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Mon, 03 Apr 2006 12:05:16 -0600 (MDT) Received: from Tundra ([129.150.35.226]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IX50037TRKQQCV3@mail-amer.sun.com> for lemonade@ietf.org; Mon, 03 Apr 2006 12:05:16 -0600 (MDT) Date: Mon, 03 Apr 2006 11:05:12 -0700 From: Peter Coates To: lemonade@ietf.org Message-id: <172a01c65749$28693350$d3219681@Tundra> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcZXSSb9mwA2g+gQSdKwhmDfvsJPdw== X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [lemonade] responses to GENURLAUTH in URLAUTH X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1786731176==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============1786731176== Content-type: multipart/alternative; boundary="Boundary_(ID_lG+boRdE5oWMwSLBWTGN3w)" This is a multi-part message in MIME format. --Boundary_(ID_lG+boRdE5oWMwSLBWTGN3w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT It may me me being not very clever, but I am not certain what the specifications expects me to do if a GENURLAUTH command carries 2 or more URL/mechanism pairs, and some are good and some are bad. The specification seems to suggest that the error response is a tagged response, but the error is per URL. I see several ways to interpret the spec. The way I like is to allow the server to sent untagged GENURLAUTH for each good URL/mechanism pairs, then a tagged BAD for the first URL/mechanism in error. But then I'm a server guy, not a client guy. From a client point of view, the preferred solution is a mechanism by which the error response indicates which URL was in error. Peter --Boundary_(ID_lG+boRdE5oWMwSLBWTGN3w) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
It may me me being not very clever, but I am not certain what the specifications expects me to do if a GENURLAUTH command carries 2 or more URL/mechanism pairs, and some are good and some are bad.  The specification seems to suggest that the error response is a tagged response, but the error is per URL.  I see several ways to interpret the spec.  The way I like is to allow the server to sent untagged GENURLAUTH for each good URL/mechanism pairs, then a tagged BAD for the first URL/mechanism in error.  But then I'm a server guy, not a client guy.  From a client point of view, the preferred solution is a mechanism by which the error response indicates which URL was in error.
 
Peter
 
 
--Boundary_(ID_lG+boRdE5oWMwSLBWTGN3w)-- --===============1786731176== 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 --===============1786731176==-- From lemonade-bounces@ietf.org Mon Apr 03 14:17:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQTcT-0007pZ-T2; Mon, 03 Apr 2006 14:17:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQTcS-0007pU-TW for lemonade@ietf.org; Mon, 03 Apr 2006 14:17:40 -0400 Received: from mxout1.cac.washington.edu ([140.142.32.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQTcR-0005wm-IM for lemonade@ietf.org; Mon, 03 Apr 2006 14:17:40 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout1.cac.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k33IHcFA003255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 3 Apr 2006 11:17:38 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k33IHaBb024440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Apr 2006 11:17:37 -0700 Date: Mon, 3 Apr 2006 11:17:36 -0700 (PDT) From: Mark Crispin To: Peter Coates Subject: Re: [lemonade] responses to GENURLAUTH in URLAUTH In-Reply-To: <172a01c65749$28693350$d3219681@Tundra> Message-ID: References: <172a01c65749$28693350$d3219681@Tundra> MIME-Version: 1.0 Content-Type: TEXT/Plain; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org If something generates a BAD response, then it is a syntax error that was detected during command processing. Full stop. Do nothing. This is basic to the IMAP architecture. IMAP is a little bit more generous with NO responses; but even then the protocol strongly discourages partial success behavior. For example, COPY and multi-APPEND aren't allowed to do some messages but not others. Put another way, since GENURLAUTH's validation is defined as returning BAD instead of NO upon failure, this is a syntax validation. Therefore, the list of URLs must be collected and validated prior to generating any responses. A debugged client should never get a BAD from GENURLAUTH. Like other BAD responses, this is not something that software-based error analysis can fix; this is something that is remedied by fixing the broken code that sent the command that led to the BAD response. On Mon, 3 Apr 2006, Peter Coates wrote: > It may me me being not very clever, but I am not certain what the > specifications expects me to do if a GENURLAUTH command carries 2 or more > URL/mechanism pairs, and some are good and some are bad. The specification > seems to suggest that the error response is a tagged response, but the error > is per URL. I see several ways to interpret the spec. The way I like is to > allow the server to sent untagged GENURLAUTH for each good URL/mechanism > pairs, then a tagged BAD for the first URL/mechanism in error. But then I'm > a server guy, not a client guy. From a client point of view, the preferred > solution is a mechanism by which the error response indicates which URL was > in error. -- 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 Apr 03 14:26:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQTlQ-00052O-9Q; Mon, 03 Apr 2006 14:26:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQTlP-00052J-4O for lemonade@ietf.org; Mon, 03 Apr 2006 14:26:55 -0400 Received: from mxout4.cac.washington.edu ([140.142.33.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQTlN-0006NJ-Ow for lemonade@ietf.org; Mon, 03 Apr 2006 14:26:55 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout4.cac.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k33IQqiW001702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 3 Apr 2006 11:26:52 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k33IQpsB014218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Apr 2006 11:26:52 -0700 Date: Mon, 3 Apr 2006 11:26:50 -0700 (PDT) From: Mark Crispin To: Peter Coates Subject: Re: [lemonade] responses to GENURLAUTH in URLAUTH In-Reply-To: Message-ID: References: <172a01c65749$28693350$d3219681@Tundra> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Mon, 3 Apr 2006, Mark Crispin wrote: > If something generates a BAD response, then it is a syntax error that was > detected during command processing. Full stop. Do nothing. This is basic > to the IMAP architecture. > IMAP is a little bit more generous with NO responses; but even then the > protocol strongly discourages partial success behavior. For example, COPY > and multi-APPEND aren't allowed to do some messages but not others. There is a corrolary to all this. If it is intended that, for a particular error condition: 1) the client should be able to analyze the error and determine what is wrong OR 2) the command may partially execute and have some side effect even though overall it fails then the specification for that command MUST define that this condition generates a NO response and MUST NOT define that it uses a BAD response. The difference between NO and BAD is not cosmetic. It has a definite purpose: segregating operational errors from buggy protocol. If it is felt that that failed validation of GENURLAUTH is an operational error rather than a protocol syntax error, then we need to change that BAD response to a NO and probably also define some sort of error reporting mechanism. I don't think that it's an operational error. It seems to me that a client is fully capable of preventing the error condition. -- 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 Apr 03 14:37:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQTvH-0006r9-SR; Mon, 03 Apr 2006 14:37:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQTvF-0006qq-QR for lemonade@ietf.org; Mon, 03 Apr 2006 14:37:05 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQTvE-0006sZ-Bv for lemonade@ietf.org; Mon, 03 Apr 2006 14:37:05 -0400 Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k33Ib2Qj024434 for ; Mon, 3 Apr 2006 12:37:03 -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 <0IX500401SZWTS00@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Mon, 03 Apr 2006 12:37:02 -0600 (MDT) Received: from Tundra ([129.150.35.226]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IX5001WST1O4MZ2@mail-amer.sun.com>; Mon, 03 Apr 2006 12:37:02 -0600 (MDT) Date: Mon, 03 Apr 2006 11:36:58 -0700 From: Peter Coates Subject: RE: [lemonade] responses to GENURLAUTH in URLAUTH In-reply-to: To: "'Mark Crispin'" Message-id: <172f01c6574d$98584da0$d3219681@Tundra> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcZXTDVM0vndTJnCTWi46yUcpuG7dgAAHKUQ X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org That is all very well, and in in accord with my understanding of the protocol. But it is a pain in this instance. Further, if the server chooses to implement the check (4) the server MAY also verify that the Message-ID and/or second components (if present) are valid. Then it is not necessarily a client error if the URL is incorrect. That then requires a NO response, and I'd say it was perfectly valid to send the untagged success responses to earlier good URLs. (the spec says that this case requires a BAD response) Further, sending untagged GENURLAUTH to good URLs before finding a URL that is unsatisfactory in some way is not an action that changes the state of either the server. It ought, in that case, to be an acceptable action. Peter -----Original Message----- From: mrc@pangtzu.panda.com [mailto:mrc@pangtzu.panda.com] On Behalf Of Mark Crispin Sent: April 3, 2006 11:27 To: Peter Coates Cc: lemonade@ietf.org Subject: Re: [lemonade] responses to GENURLAUTH in URLAUTH On Mon, 3 Apr 2006, Mark Crispin wrote: > If something generates a BAD response, then it is a syntax error that > was detected during command processing. Full stop. Do nothing. This > is basic to the IMAP architecture. > IMAP is a little bit more generous with NO responses; but even then > the protocol strongly discourages partial success behavior. For > example, COPY and multi-APPEND aren't allowed to do some messages but not others. There is a corrolary to all this. If it is intended that, for a particular error condition: 1) the client should be able to analyze the error and determine what is wrong OR 2) the command may partially execute and have some side effect even though overall it fails then the specification for that command MUST define that this condition generates a NO response and MUST NOT define that it uses a BAD response. The difference between NO and BAD is not cosmetic. It has a definite purpose: segregating operational errors from buggy protocol. If it is felt that that failed validation of GENURLAUTH is an operational error rather than a protocol syntax error, then we need to change that BAD response to a NO and probably also define some sort of error reporting mechanism. I don't think that it's an operational error. It seems to me that a client is fully capable of preventing the error condition. -- 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 Apr 03 14:57:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQUFB-00063M-37; Mon, 03 Apr 2006 14:57:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQUF9-00063H-Ey for lemonade@ietf.org; Mon, 03 Apr 2006 14:57:39 -0400 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQUF7-0007SE-0N for lemonade@ietf.org; Mon, 03 Apr 2006 14:57:39 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1FQUF3-0001N9-9B; Mon, 03 Apr 2006 18:57:33 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 5FC66498003; Mon, 3 Apr 2006 20:03:03 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16999-02; Mon, 3 Apr 2006 20:02:53 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 945C0498002; Mon, 3 Apr 2006 20:02:51 +0100 (BST) Date: Mon, 03 Apr 2006 19:57:20 +0100 Subject: RE: [lemonade] responses to GENURLAUTH in URLAUTH References: <172f01c6574d$98584da0$d3219681@Tundra> In-Reply-To: <172f01c6574d$98584da0$d3219681@Tundra> MIME-Version: 1.0 Message-Id: <27924.1144090640.954773@peirce.dave.cridland.net> From: Dave Cridland To: Peter Coates Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Pythagoras-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Enhancements to Internet email to support diverse service enivronments , Mark Crispin X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Mon Apr 3 19:36:58 2006, Peter Coates wrote: > That is all very well, and in in accord with my understanding of the > protocol. Indeed - Mark's summary made for good reading. > But it is a pain in this instance. Further, if the server > chooses to implement the check > (4) the server MAY also verify that the Message-ID and/or > second components (if present) are valid. Is this text actually meant to be this way? Is "Message-ID" intended to read "message", and "second" intended to read "section"? Or am I missing something? > Then it is not necessarily a client error if the URL is incorrect. > That > then requires a NO response, and I'd say it was perfectly valid to > send the > untagged success responses to earlier good URLs. (the spec says > that this > case requires a BAD response) > > Yes, a BAD response cannot happen after the server has accepted the command. If you cannot reasonably accept the command until after check 4, then don't perform check 4. (In particular, you can choose to only perform check 4 when the client has the mailbox selected, when a failure of check 4 does indeed mean a client error). > Further, sending untagged GENURLAUTH to good URLs before finding a > URL that > is unsatisfactory in some way is not an action that changes the > state of > either the server. It ought, in that case, to be an acceptable > action. Ah, but here's a curiosity for you. BAD indicates that the command was not processed at all - therefore you cannot, technically, emit EXPUNGE messages, and any GENURLAUTH messages must be assumed by the client to be unilaterally sent. Moreover, whilst it's likely that existing URLAUTH mechanisms don't have side-effects, that may not always be the case. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Apr 03 15:09:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQUQW-000567-3N; Mon, 03 Apr 2006 15:09:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQUQU-000562-LP for lemonade@ietf.org; Mon, 03 Apr 2006 15:09:22 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQUQT-0007vd-6f for lemonade@ietf.org; Mon, 03 Apr 2006 15:09:22 -0400 Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k33J9K8u006783 for ; Mon, 3 Apr 2006 13:09:20 -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 <0IX500B01U3MAC00@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Mon, 03 Apr 2006 13:09:20 -0600 (MDT) Received: from Tundra ([129.150.35.226]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IX500EZYUJHRR75@mail-amer.sun.com>; Mon, 03 Apr 2006 13:09:20 -0600 (MDT) Date: Mon, 03 Apr 2006 12:09:16 -0700 From: Peter Coates Subject: RE: [lemonade] responses to GENURLAUTH in URLAUTH In-reply-to: <27924.1144090640.954773@peirce.dave.cridland.net> To: "'Dave Cridland'" Message-id: <173001c65752$1b5f8f20$d3219681@Tundra> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcZXUIgovwuECXBwRw+hRqDp/d6GnwAAIekA X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: 'Enhancements to Internet email to support diverse service enivronments' , 'Mark Crispin' X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I accept most of your points. I'm not sure I agree about a failure under check 4. There is nothing to stop a message being deleted and expunged in some other session unbeknownst to the poor client. This really feels like a "NO" case rather than a "BAD" case. Either the protocol should allow for a "NO" response or check 4 be precluded. And it is a good indicator of my proof reading ability that I missed the errors in the wording for check (4). -----Original Message----- From: Dave Cridland [mailto:dave@cridland.net] Sent: April 3, 2006 11:57 To: Peter Coates Cc: Enhancements to Internet email to support diverse service enivronments; Mark Crispin Subject: RE: [lemonade] responses to GENURLAUTH in URLAUTH On Mon Apr 3 19:36:58 2006, Peter Coates wrote: > That is all very well, and in in accord with my understanding of the > protocol. Indeed - Mark's summary made for good reading. > But it is a pain in this instance. Further, if the server chooses > to implement the check > (4) the server MAY also verify that the Message-ID and/or > second components (if present) are valid. Is this text actually meant to be this way? Is "Message-ID" intended to read "message", and "second" intended to read "section"? Or am I missing something? > Then it is not necessarily a client error if the URL is incorrect. > That > then requires a NO response, and I'd say it was perfectly valid to > send the > untagged success responses to earlier good URLs. (the spec says > that this > case requires a BAD response) > > Yes, a BAD response cannot happen after the server has accepted the command. If you cannot reasonably accept the command until after check 4, then don't perform check 4. (In particular, you can choose to only perform check 4 when the client has the mailbox selected, when a failure of check 4 does indeed mean a client error). > Further, sending untagged GENURLAUTH to good URLs before finding a > URL that > is unsatisfactory in some way is not an action that changes the > state of > either the server. It ought, in that case, to be an acceptable > action. Ah, but here's a curiosity for you. BAD indicates that the command was not processed at all - therefore you cannot, technically, emit EXPUNGE messages, and any GENURLAUTH messages must be assumed by the client to be unilaterally sent. Moreover, whilst it's likely that existing URLAUTH mechanisms don't have side-effects, that may not always be the case. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Apr 03 15:20:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQUav-0002bQ-0M; Mon, 03 Apr 2006 15:20:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQUas-0002Zi-Uk for lemonade@ietf.org; Mon, 03 Apr 2006 15:20:06 -0400 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQUap-0008Tu-H2 for lemonade@ietf.org; Mon, 03 Apr 2006 15:20:06 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1FQUao-0004SD-RT; Mon, 03 Apr 2006 19:20:02 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 6FE36498003; Mon, 3 Apr 2006 20:25:33 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17161-02; Mon, 3 Apr 2006 20:25:29 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id BB3AD498002; Mon, 3 Apr 2006 20:25:26 +0100 (BST) Date: Mon, 03 Apr 2006 20:19:55 +0100 Subject: RE: [lemonade] responses to GENURLAUTH in URLAUTH References: <173001c65752$1b5f8f20$d3219681@Tundra> In-Reply-To: <173001c65752$1b5f8f20$d3219681@Tundra> MIME-Version: 1.0 Message-Id: <27924.1144091995.933916@peirce.dave.cridland.net> From: Dave Cridland To: Peter Coates Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Pythagoras-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Enhancements to Internet email to support diverse service enivronments , Mark Crispin X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Mon Apr 3 20:09:16 2006, Peter Coates wrote: > I accept most of your points. I'm not sure I agree about a failure > under > check 4. There is nothing to stop a message being deleted and > expunged in > some other session unbeknownst to the poor client. This really > feels like a > "NO" case rather than a "BAD" case. Either the protocol should > allow for a > "NO" response or check 4 be precluded. > > It's only a MAY. For sections, I think a client basically has to know that the section exists before trying to do anything with the signed URL, and even in my more nefarious moments, I can't think of a use for using GENURLAUTH on sections which don't exist, or even on sections I simply haven't verified the existence of. For the message itself, it depends on how your store works, and, in particular, whether an EXPUNGE in another session causes the message data to be unavailable immediately to concurrent sessions, or whether other sessions still have access. The client certainly believes the message not only exists, but will remain in existence for a substantial amount of time. As an asmuing aside, you can't tell the client about the expunge until after accepting the command, incidentally - that is, you can't say "* 14 EXPUNGE", followed by a tagged BAD, because you can't send an EXPUNGE unless there's a command in progress, and by issuing a tagged BAD, you're indicating that the command was never accepted. > And it is a good indicator of my proof reading ability that I > missed the > errors in the wording for check (4). > > Yes, I only noticed it halfway through typing my response - I wanted to match the terms Mark used, and realised it didn't make sense. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Apr 03 15:28:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQUj8-00068p-1U; Mon, 03 Apr 2006 15:28:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQUj6-00066U-IB for lemonade@ietf.org; Mon, 03 Apr 2006 15:28:36 -0400 Received: from mxout7.cac.washington.edu ([140.142.32.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQUj5-0000lP-7P for lemonade@ietf.org; Mon, 03 Apr 2006 15:28:36 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout7.cac.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k33JSWHq002738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 3 Apr 2006 12:28:33 -0700 X-Auth-Received: from Shimo-Tomobiki.panda.com ([65.122.177.186]) (authenticated authid=mrc) by smtp.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k33JSUSj013857 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 3 Apr 2006 12:28:32 -0700 Date: Mon, 3 Apr 2006 12:28:25 -0700 From: Mark Crispin To: Peter Coates Subject: RE: [lemonade] responses to GENURLAUTH in URLAUTH In-Reply-To: <173001c65752$1b5f8f20$d3219681@Tundra> Message-ID: References: <173001c65752$1b5f8f20$d3219681@Tundra> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: 'Enhancements to Internet email to support diverse service enivronments' X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Mon, 3 Apr 2006, Peter Coates wrote: > There is nothing to stop a message being deleted and expunged in > some other session unbeknownst to the poor client. Yes there is. Until the expunge is announced with an untagged EXPUNGE response, the message still exists as far as the server is concerned; and an untagged EXPUNGE in turn can't be sent except at certain well-documented points in the session. -- 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 Apr 03 15:31:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQUlT-0000X0-HP; Mon, 03 Apr 2006 15:31:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQUlR-0000Te-9b for lemonade@ietf.org; Mon, 03 Apr 2006 15:31:01 -0400 Received: from mxout3.cac.washington.edu ([140.142.32.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQUlP-0000se-VB for lemonade@ietf.org; Mon, 03 Apr 2006 15:31:01 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout3.cac.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k33JUvsQ018682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 3 Apr 2006 12:30:57 -0700 X-Auth-Received: from Shimo-Tomobiki.panda.com ([65.122.177.186]) (authenticated authid=mrc) by smtp.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k33JUtwn002513 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 3 Apr 2006 12:30:56 -0700 Date: Mon, 3 Apr 2006 12:30:50 -0700 From: Mark Crispin To: Dave Cridland Subject: RE: [lemonade] responses to GENURLAUTH in URLAUTH In-Reply-To: <27924.1144091995.933916@peirce.dave.cridland.net> Message-ID: References: <173001c65752$1b5f8f20$d3219681@Tundra> <27924.1144091995.933916@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='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Enhancements to Internet email to support diverse service enivronments , Peter Coates X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Mon, 3 Apr 2006, Dave Cridland wrote: > For the message itself, it depends on how your store works, and, in > particular, whether an EXPUNGE in another session causes the message data to > be unavailable immediately to concurrent sessions, or whether other sessions > still have access. I never, ever, approved of the former behavior. Such behavior is wrong from an architectural standpoint -- and equally importantly is proven to break clients. > The client certainly believes the message not only exists, > but will remain in existence for a substantial amount of time. Correct. -- 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 Apr 03 19:05:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQY6f-0007Bd-Iz; Mon, 03 Apr 2006 19:05:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQY6e-00078a-Db for lemonade@ietf.org; Mon, 03 Apr 2006 19:05:08 -0400 Received: from mxout1.cac.washington.edu ([140.142.32.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQY6d-0002lS-1V for lemonade@ietf.org; Mon, 03 Apr 2006 19:05:08 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout1.cac.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k33N55Ot013034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 3 Apr 2006 16:05:06 -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.6+UW06.03/8.13.5+UW06.03) with ESMTP id k33N55uk002063 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 3 Apr 2006 16:05:05 -0700 Date: Mon, 3 Apr 2006 16:07:09 -0700 (Pacific Daylight Time) From: Mark Crispin To: Alexey Melnikov Subject: Re: [lemonade] confusion on syntax of the access portion of the URLAUTH In-Reply-To: <442F466E.9050907@isode.com> Message-ID: References: <13fb01c65438$b5793880$d3219681@Tundra> <442F466E.9050907@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='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: lemonade@ietf.org, Peter Coates X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Sat, 1 Apr 2006, Alexey Melnikov wrote: >> I think that we decided that iauth wasn't meaningful in IMAP URLs that use >> URLAUTH, because we don't allow relative IMAP URLs with URLAUTH. >> But I forget why we used the iuserauth instead of the enc_user rule. >> Should we fix this? > Yes. I'm not sure how to fix this. Either I have to reference enc_user (which has the now-disallowed underscore), or I have to change URLAUTH to use RFC2192bis as normative. -- 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 Apr 04 08:32:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQkiL-0005ak-1E; Tue, 04 Apr 2006 08:32:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQkiK-0005aJ-0U for lemonade@ietf.org; Tue, 04 Apr 2006 08:32:52 -0400 Received: from smtp.andrew.cmu.edu ([128.2.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQkiF-0003FF-TQ for lemonade@ietf.org; Tue, 04 Apr 2006 08:32:51 -0400 Received: from [192.168.137.22] (69-171-17-197.kntnny.adelphia.net [69.171.17.197]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.5/8.13.6) with ESMTP id k34CWR53021010 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 4 Apr 2006 08:32:36 -0400 Message-ID: <4432675A.6020601@andrew.cmu.edu> Date: Tue, 04 Apr 2006 08:32:26 -0400 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Thunderbird 1.5 (X11/20060313) MIME-Version: 1.0 To: Mark Crispin Subject: Re: [lemonade] confusion on syntax of the access portion of the URLAUTH References: <13fb01c65438$b5793880$d3219681@Tundra> <442F466E.9050907@isode.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: lemonade@ietf.org, Alexey Melnikov , Peter Coates X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Mark Crispin wrote: > On Sat, 1 Apr 2006, Alexey Melnikov wrote: >>> I think that we decided that iauth wasn't meaningful in IMAP URLs >>> that use URLAUTH, because we don't allow relative IMAP URLs with >>> URLAUTH. >>> But I forget why we used the iuserauth instead of the enc_user rule. >>> Should we fix this? >> Yes. > > I'm not sure how to fix this. > > Either I have to reference enc_user (which has the now-disallowed > underscore), or I have to change URLAUTH to use RFC2192bis as normative. As distasteful as it might be, I wouldn't be upset if we use 2192bis as normative. We'd then get support for partial fetch in URLAUTH for free (which might be reason enough to NOT use 2192bis). -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Apr 04 08:40:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQkpt-00016q-UV; Tue, 04 Apr 2006 08:40:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQkpt-00016l-0s for lemonade@ietf.org; Tue, 04 Apr 2006 08:40:41 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQkpr-0003S2-Jl for lemonade@ietf.org; Tue, 04 Apr 2006 08:40:41 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Tue, 4 Apr 2006 13:40:26 +0100 Message-ID: <44326939.9000402@isode.com> Date: Tue, 04 Apr 2006 13:40:25 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Crispin Subject: Re: [lemonade] confusion on syntax of the access portion of the URLAUTH References: <13fb01c65438$b5793880$d3219681@Tundra> <442F466E.9050907@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: 7655788c23eb79e336f5f8ba8bce7906 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Mark Crispin wrote: > On Sat, 1 Apr 2006, Alexey Melnikov wrote: > >>> I think that we decided that iauth wasn't meaningful in IMAP URLs >>> that use URLAUTH, because we don't allow relative IMAP URLs with >>> URLAUTH. >>> But I forget why we used the iuserauth instead of the enc_user rule. >>> Should we fix this? >> >> Yes. > > I'm not sure how to fix this. > > Either I have to reference enc_user (which has the now-disallowed > underscore), Yout mean in the name? You can define "enc-user" in URLAUTH. > or I have to change URLAUTH to use RFC2192bis as normative. That would be fine with me as well. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Apr 04 11:53:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQnqL-0000RG-Gh; Tue, 04 Apr 2006 11:53:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQkmg-0000X3-Ls for lemonade@ietf.org; Tue, 04 Apr 2006 08:37:22 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQkmf-0003L9-9B for lemonade@ietf.org; Tue, 04 Apr 2006 08:37:22 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.34) id 1FQkmY-0001uN-Tq; Tue, 04 Apr 2006 12:37:15 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id DED28498003; Tue, 4 Apr 2006 13:42:52 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20974-03; Tue, 4 Apr 2006 13:42:48 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 678BD498002; Tue, 4 Apr 2006 13:42:45 +0100 (BST) Date: Tue, 04 Apr 2006 13:37:06 +0100 Subject: Re: [lemonade] confusion on syntax of the access portion of the URLAUTH References: <13fb01c65438$b5793880$d3219681@Tundra> <442F466E.9050907@isode.com> <4432675A.6020601@andrew.cmu.edu> In-Reply-To: <4432675A.6020601@andrew.cmu.edu> MIME-Version: 1.0 Message-Id: <31081.1144154227.226281@peirce.dave.cridland.net> From: Dave Cridland To: Ken Murchison Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Rutherford-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-Mailman-Approved-At: Tue, 04 Apr 2006 11:53:20 -0400 Cc: Enhancements to Internet email to support diverse service enivronments , Alexey Melnikov , Peter Coates , Mark Crispin X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue Apr 4 13:32:26 2006, Ken Murchison wrote: > Mark Crispin wrote: >> On Sat, 1 Apr 2006, Alexey Melnikov wrote: >>>> I think that we decided that iauth wasn't meaningful in IMAP >>>> URLs that use URLAUTH, because we don't allow relative IMAP URLs >>>> with URLAUTH. >>>> But I forget why we used the iuserauth instead of the enc_user >>>> rule. >>>> Should we fix this? >>> Yes. >> >> I'm not sure how to fix this. >> >> Either I have to reference enc_user (which has the now-disallowed >> underscore), or I have to change URLAUTH to use RFC2192bis as >> normative. > > As distasteful as it might be, I wouldn't be upset if we use > 2192bis as normative. We'd then get support for partial fetch in > URLAUTH for free (which might be reason enough to NOT use 2192bis). If partial fetch support ends up in URLAUTH, then it ought to end up in CATENATE too... And in that case, CATENATE might as well have the literal8 bits added, since all the implementations I know of support that. 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 Apr 04 16:35:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQsEu-00041n-Sa; Tue, 04 Apr 2006 16:35:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQsEt-00040j-HJ for lemonade@ietf.org; Tue, 04 Apr 2006 16:34:59 -0400 Received: from mxout5.cac.washington.edu ([140.142.32.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQsEs-0000E2-6H for lemonade@ietf.org; Tue, 04 Apr 2006 16:34:59 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k34KYuKo005901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 4 Apr 2006 13:34:57 -0700 X-Auth-Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.37.171]) (authenticated authid=mrc) by smtp.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k34KYu2A015412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 4 Apr 2006 13:34:56 -0700 Date: Tue, 4 Apr 2006 13:34:56 -0700 (PDT) From: Mark Crispin To: lemonade@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: [lemonade] URLAUTH edits to be made during AUTH48 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Here's the set of edits that I propose to make during AUTH48 for URLAUTH. Note that this is strictly for bug fixes. 73c73 < that it only supports authentication, and confuses the concepts --- > that it only supports authentication, and confuses the concepts of 78c78 < conveys authorization in the URL name itself, and reuses a portion of --- > conveys authorization in the URL string itself, and reuses a portion of 195c195 < [IMAPURL] is extended by allowing the addition of ;EXPIRE=" --- > [IMAPURL] is extended by allowing the addition of ";EXPIRE=" 416,417c416,417 < As a consequence, the iserver rule of [IMAPURL] is modified < so that iuserauth is mandatory. --- > As a consequence, relative URLs are not permitted, and > enc-user is mandatory, in URLAUTH authorized URLs. 424,425c424,425 < (4) the server MAY also verify that the Message-ID and/or < second components (if present) are valid. --- > (4) the server MAY also verify that the iuid and/or isection > components (if present) are valid. 626c626,628 < authimapurl = "imap://" iuserauth "@" hostport "/" imessagepart --- > authimapurl = "imap://" enc-user "@" hostport "/" imessagepart > ; replaces "imapurl" and "iserver" rules for URLAUTH > ; authorized URLs 633a636,638 > enc-user = 1*achar > ; same as "enc_user" in RFC 2192 > 638c643 < access = ("submit+" iuserauth) / ("user+" iuserauth) / --- > access = ("submit+" enc-user) / ("user+" enc-user) / 719,720c724 < Specifications: ABNF", draft-crocker-abnf-rfc2234bis (work < in progress). --- > Specifications: ABNF", RFC 4234, October 2005. 723c727 < draft-newman-lemonade-burl (work in progress). --- > draft-ietf-lemonade-burl (work in progress). -- 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 Apr 04 16:43:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQsNG-0003Dm-JA; Tue, 04 Apr 2006 16:43:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQsNF-0003Dc-GJ for lemonade@ietf.org; Tue, 04 Apr 2006 16:43:37 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQsNC-0000M0-1L for lemonade@ietf.org; Tue, 04 Apr 2006 16:43:37 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Tue, 4 Apr 2006 21:43:25 +0100 Message-ID: <4432DA6B.4050904@isode.com> Date: Tue, 04 Apr 2006 21:43:23 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Mark Crispin Subject: Re: [lemonade] URLAUTH edits to be made during AUTH48 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: 08170828343bcf1325e4a0fb4584481c Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Mark Crispin wrote: > 626c626,628 > < authimapurl = "imap://" iuserauth "@" hostport "/" imessagepart > --- > >> authimapurl = "imap://" enc-user "@" hostport "/" imessagepart >> ; replaces "imapurl" and "iserver" rules for URLAUTH >> ; authorized URLs > You should still use iuserauth above, as something like "joe;auth=digest-md5" would be allowed here. The rest of your diff looks fine to me. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Apr 04 16:48:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQsRg-00054B-UJ; Tue, 04 Apr 2006 16:48:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQsRg-000546-9r for lemonade@ietf.org; Tue, 04 Apr 2006 16:48:12 -0400 Received: from mxout4.cac.washington.edu ([140.142.33.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQsRe-0000UA-Vx for lemonade@ietf.org; Tue, 04 Apr 2006 16:48:12 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout4.cac.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k34Km9nW029991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Apr 2006 13:48:09 -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.6+UW06.03/8.13.5+UW06.03) with ESMTP id k34Km9CT019333 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 4 Apr 2006 13:48:09 -0700 Date: Tue, 4 Apr 2006 13:50:13 -0700 (Pacific Daylight Time) From: Mark Crispin To: Alexey Melnikov Subject: Re: [lemonade] URLAUTH edits to be made during AUTH48 In-Reply-To: <4432DA6B.4050904@isode.com> Message-ID: References: <4432DA6B.4050904@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='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue, 4 Apr 2006, Alexey Melnikov wrote: > You should still use iuserauth above, as something like "joe;auth=digest-md5" > would be allowed here. Allowed in IMAPURLs? Then it looks like I need to redefine iuserauth... -- 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 Apr 04 17:08:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQslT-0000YS-8p; Tue, 04 Apr 2006 17:08:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQslR-0000TW-7n for lemonade@ietf.org; Tue, 04 Apr 2006 17:08:37 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQslP-0001Bi-Uj for lemonade@ietf.org; Tue, 04 Apr 2006 17:08:37 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k34L8XY20265 for ; Tue, 4 Apr 2006 17:08:33 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 4 Apr 2006 17:08:16 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D09626ED8@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LEMONADE interim poll Thread-Index: AcZYK+SVKJkrJxb5QSa8BrMAzmPRtA== From: "Glenn Parsons" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Subject: [lemonade] LEMONADE interim poll X-BeenThere: lemonade@ietf.org X-Mailman-Version: 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="===============1414526513==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============1414526513== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6582B.E58F762F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6582B.E58F762F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, I got the sense in Dallas that an interim meeting to finalize all the drafts including LEMONADE profile-bis was in order. On consulting the calendar, the chairs are proposing May 31 and June 1. Given no one approached the chairs with an offer this time, I am proposing that Nortel will host this meeting in Ottawa, Canada. I would like to confirm how many people would attend the proposed interim. Please respond to me answering the following questions: Will you attend the interim meeting? 1a. Yes 1b. No Are the proposed dates OK? 2a. Agree to May 31/June 1 2b. Suggest another date Is the proposed location OK? 3a. Agree to Nortel hosting in Ottawa 3b. Offer to host in ??? Thanks, Glenn. ------_=_NextPart_001_01C6582B.E58F762F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable LEMONADE interim poll

Folks,

I got the sense in Dallas that an = interim meeting to finalize all the drafts including LEMONADE = profile-bis was in order.

On consulting the calendar, the chairs = are proposing May 31 and June 1.

Given no one approached the chairs with = an offer this time, I am proposing that Nortel will host this meeting in = Ottawa, Canada.

I would like to confirm how many people = would attend the proposed interim.

Please respond to me answering the = following questions:

Will you attend the interim = meeting?

    1a. Yes
    1b. No

Are the proposed dates OK?

    2a. Agree to May 31/June 1
    2b. Suggest another date

Is the proposed location OK?

    3a. Agree to Nortel hosting in = Ottawa
    3b. Offer to host in ???

Thanks,
Glenn.

------_=_NextPart_001_01C6582B.E58F762F-- --===============1414526513== 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 --===============1414526513==-- From lemonade-bounces@ietf.org Tue Apr 04 19:31:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQuzW-0002Nr-IN; Tue, 04 Apr 2006 19:31:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQuzV-0002NG-Vh for lemonade@ietf.org; Tue, 04 Apr 2006 19:31:17 -0400 Received: from mxout3.cac.washington.edu ([140.142.32.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQuzU-0007Wc-LO for lemonade@ietf.org; Tue, 04 Apr 2006 19:31:17 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout3.cac.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k34NVFUX012688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Apr 2006 16:31:15 -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.6+UW06.03/8.13.5+UW06.03) with ESMTP id k34NVF9B004304 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 4 Apr 2006 16:31:15 -0700 Date: Tue, 4 Apr 2006 16:33:19 -0700 (Pacific Daylight Time) From: Mark Crispin To: Alexey Melnikov Subject: Re: [lemonade] URLAUTH edits to be made during AUTH48 In-Reply-To: <4432DA6B.4050904@isode.com> Message-ID: References: <4432DA6B.4050904@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='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue, 4 Apr 2006, Alexey Melnikov wrote: > Mark Crispin wrote: >> 626c626,628 >> < authimapurl = "imap://" iuserauth "@" hostport "/" imessagepart >> --- >>> authimapurl = "imap://" enc-user "@" hostport "/" imessagepart >>> ; replaces "imapurl" and "iserver" rules for URLAUTH >>> ; authorized URLs > You should still use iuserauth above, as something like "joe;auth=digest-md5" > would be allowed here. I'm not sure that I understand. Is ;AUTH= allowed with no userid? By the way, I just got the AUTH48. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Apr 04 21:00:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQwNO-0007iT-SS; Tue, 04 Apr 2006 21:00:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQwNN-0007iI-2H for lemonade@ietf.org; Tue, 04 Apr 2006 21:00:01 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQwNL-0002fX-Nl for lemonade@ietf.org; Tue, 04 Apr 2006 21:00:00 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k350xuD25737 for ; Tue, 4 Apr 2006 20:59:56 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 4 Apr 2006 20:59:39 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D09627019@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Trio in AUTH48 Thread-Index: AcZYTDd/FwsNquPjTIOUM3OdGHgFWQ== From: "Glenn Parsons" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Subject: [lemonade] Trio in AUTH48 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 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="===============0156131700==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============0156131700== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6584C.38769EDF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6584C.38769EDF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, The trio is now in AUTH48 ... but I sense there is an issue with the ABNF that we probably need some consensus on... The options as I see it are: 1. Stop AUTH48. Include RFC2192bis as a mandatory reference. Get IESG re-approval and then resume AUTH48. But what changes will we add? Will we include partial support now? We need concrete text proposals if we want to do this... 2. Make the 'bug fix' changes Mark has proposed earlier today (with tweaks as appropriate) 3. Change nothing. It doesn't matter since we will fix all this in RFC2192bis and Profile-bis What do folks think? Cheers, Glenn. ------_=_NextPart_001_01C6584C.38769EDF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Trio in AUTH48

Folks,

The trio is now in AUTH48 … but I = sense there is an issue with the ABNF that we probably need some = consensus on…

The options as I see it are:

1. Stop AUTH48.  Include = RFC2192bis as a mandatory reference.  Get IESG re-approval and then = resume AUTH48.  But what changes will we add?  Will we include = partial support now?  We need concrete text proposals if we want to = do this...

2.  Make the 'bug fix' changes = Mark has proposed earlier today (with tweaks as appropriate)

3.  Change nothing.  It = doesn't matter since we will fix all this in RFC2192bis and = Profile-bis

What do folks think?

Cheers,
Glenn.

------_=_NextPart_001_01C6584C.38769EDF-- --===============0156131700== 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 --===============0156131700==-- From lemonade-bounces@ietf.org Tue Apr 04 21:39:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQx01-0005m3-Ep; Tue, 04 Apr 2006 21:39:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQx00-0005ly-9j for lemonade@ietf.org; Tue, 04 Apr 2006 21:39:56 -0400 Received: from mxout5.cac.washington.edu ([140.142.32.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQwzy-0004Fx-Vg for lemonade@ietf.org; Tue, 04 Apr 2006 21:39:56 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout5.cac.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k351drUp030136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Apr 2006 18:39:53 -0700 X-Auth-Received: from Shimo-Tomobiki.panda.com ([65.122.177.186]) (authenticated authid=mrc) by smtp.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k351dmn7022493 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 4 Apr 2006 18:39:50 -0700 Date: Tue, 4 Apr 2006 18:39:41 -0700 From: Mark Crispin To: Glenn Parsons Subject: Re: [lemonade] Trio in AUTH48 In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D09627019@zcarhxm0.corp.nortel.com> Message-ID: References: <085091CB2CA14E4B8B163FFC37C84E9D09627019@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='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue, 4 Apr 2006, Glenn Parsons wrote: > What do folks think? The AUTH48 has already been stopped. The only question is whether that stop gets revoked. There was no consultation to the WG, the document editor, or the chair to stop the AUTH48. It was just done. All because of a simple matter about a hyphen vs. an underscore. -- 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 Apr 05 06:06:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR4ua-0003Vr-IZ; Wed, 05 Apr 2006 06:06:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR4ua-0003Vm-B7 for lemonade@ietf.org; Wed, 05 Apr 2006 06:06:52 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR4uY-0006WM-Ug for lemonade@ietf.org; Wed, 05 Apr 2006 06:06:52 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Wed, 5 Apr 2006 11:06:44 +0100 Message-ID: <443396B1.1080704@isode.com> Date: Wed, 05 Apr 2006 11:06:41 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Mark Crispin Subject: Re: [lemonade] URLAUTH edits to be made during AUTH48 References: <4432DA6B.4050904@isode.com> In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Mark Crispin wrote: > On Tue, 4 Apr 2006, Alexey Melnikov wrote: > >> Mark Crispin wrote: >> >>> 626c626,628 >>> < authimapurl = "imap://" iuserauth "@" hostport "/" imessagepart >>> --- >>> >>>> authimapurl = "imap://" enc-user "@" hostport "/" imessagepart >>>> ; replaces "imapurl" and "iserver" rules for >>>> URLAUTH >>>> ; authorized URLs >>> >> You should still use iuserauth above, as something like >> "joe;auth=digest-md5" would be allowed here. > > I'm not sure that I understand. Is ;AUTH= allowed with no userid? Yes. You want to prohibit it for URLAUTH URLs only. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Apr 05 06:08:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR4vt-00041Y-1v; Wed, 05 Apr 2006 06:08:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR4vr-00040d-Oo for lemonade@ietf.org; Wed, 05 Apr 2006 06:08:11 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR4vq-0006Xr-A5 for lemonade@ietf.org; Wed, 05 Apr 2006 06:08:11 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Wed, 5 Apr 2006 11:07:49 +0100 Message-ID: <443396F3.3010605@isode.com> Date: Wed, 05 Apr 2006 11:07:47 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Crispin Subject: Re: [lemonade] URLAUTH edits to be made during AUTH48 References: <4432DA6B.4050904@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: 08170828343bcf1325e4a0fb4584481c Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Mark Crispin wrote: > On Tue, 4 Apr 2006, Alexey Melnikov wrote: > >> You should still use iuserauth above, as something like >> "joe;auth=digest-md5" would be allowed here. > > Allowed in IMAPURLs? Yes. > Then it looks like I need to redefine iuserauth... I guess you should. I will rewrite the whole ABNF in 2192bis. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Apr 05 10:10:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR8iR-0007ae-UA; Wed, 05 Apr 2006 10:10:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR8iP-0007Xb-Vr for lemonade@ietf.org; Wed, 05 Apr 2006 10:10:33 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR8iO-0007fz-KQ for lemonade@ietf.org; Wed, 05 Apr 2006 10:10:33 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k35EAEqj014302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Apr 2006 07:10:15 -0700 Received: from [10.0.1.4] (vpn-10-50-16-73.qualcomm.com [10.50.16.73]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k35EACT8026451; Wed, 5 Apr 2006 07:10:13 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <085091CB2CA14E4B8B163FFC37C84E9D09627019@zcarhxm0.corp.nortel.com> Date: Wed, 5 Apr 2006 07:10:11 -0700 To: Mark Crispin , Glenn Parsons From: Ted Hardie Subject: Re: [lemonade] Trio in AUTH48 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 6:39 PM -0700 4/4/06, Mark Crispin wrote: >On Tue, 4 Apr 2006, Glenn Parsons wrote: >>What do folks think? > >The AUTH48 has already been stopped. The only question is whether that stop gets revoked. > >There was no consultation to the WG, the document editor, or the chair to stop the AUTH48. It was just done. > >All because of a simple matter about a hyphen vs. an underscore. > >-- Mark -- Just to clarify this, the AUTH48 period is not being stopped. The working group chairs and AD are cc'ed on all AUTH48 notes from the RFC Editor. When the URLAUTH one came through, I let the RFC Editor know that WG had been discussing a change, and that I think the WG chairs needed to call consensus on the change. Here's the text I sent: >Dear RFC Editors, > There is currently discussion in the working group on whether the draft >ought to be updated to refer to the ABNF productions in draft-ietf-lemonade-rfc2192bis-01.txt. The chairs will need to call consensus in the working group on that issue and an >underlying ABNF issue. I would prefer that they make an explicit approval if that text >needs to be added to this RFC-to-be, as they will be better able to manage the timing >than I will. If they believe that the better path would be to get IESG approval of >the change, I will, naturally, be available to shepherd that question in the IESG. > thanks, > Ted Hardie This is not to say that I believe they need to run a WGLC on the issue; if they are satisfied now that the working group has come to consensus on the approach, they can simply notify the RFC Editor. If they feel that the working group needs to make a more declarative statement, then they need to set the bounds for that. The RFC-to-be doesn't leave AUTH48 for that. If they feel the change is substantive and that the IESG needs to re-approve, I will arrange for that, but I'm not starting from the point that this is needed. regards, Ted > >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 Wed Apr 05 10:10:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR8ie-0007s8-6Q; Wed, 05 Apr 2006 10:10:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR8id-0007s3-2x for lemonade@ietf.org; Wed, 05 Apr 2006 10:10:47 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR8ib-0007g8-MA for lemonade@ietf.org; Wed, 05 Apr 2006 10:10:47 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Wed, 5 Apr 2006 15:10:34 +0100 Message-ID: <4433CFD3.6050404@isode.com> Date: Wed, 05 Apr 2006 15:10:27 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Glenn Parsons Subject: Re: [lemonade] Trio in AUTH48 References: <085091CB2CA14E4B8B163FFC37C84E9D09627019@zcarhxm0.corp.nortel.com> In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D09627019@zcarhxm0.corp.nortel.com> MIME-version: 1.0 Content-type: text/plain; charset="windows-1252"; format="flowed" Content-Transfer-Encoding: quoted-printable X-Encoded: Changed encoding from 8bit for 7bit transmission X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Glenn Parsons wrote: > Folks, > > The trio is now in AUTH48 =85 but I sense there is an issue with the = > ABNF that we probably need some consensus on=85 > > The options as I see it are: > > 1. Stop AUTH48. Include RFC2192bis as a mandatory reference. Get IESG = > re-approval and then resume AUTH48. But what changes will we add? Will = > we include partial support now? We need concrete text proposals if we = > want to do this... > > 2. Make the 'bug fix' changes Mark has proposed earlier today (with = > tweaks as appropriate) > > 3. Change nothing. It doesn't matter since we will fix all this in = > RFC2192bis and Profile-bis > > What do folks think? > I don't like 3, I am happy with both 1 and 2. But # 1 will mean that we = need to publish 2192bis asap, so it will need reviews and specific = suggestions about text. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Apr 05 12:22:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRAm4-0005Na-7z; Wed, 05 Apr 2006 12:22:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRAm2-0005N6-UA for lemonade@ietf.org; Wed, 05 Apr 2006 12:22:26 -0400 Received: from mxout3.cac.washington.edu ([140.142.32.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRAm1-0006T6-IC for lemonade@ietf.org; Wed, 05 Apr 2006 12:22:26 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout3.cac.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k35GMOe3014548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Apr 2006 09:22:24 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k35GMEJx029644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 5 Apr 2006 09:22:23 -0700 Date: Wed, 5 Apr 2006 09:22:14 -0700 (PDT) From: Mark Crispin To: Ted Hardie Subject: Re: [lemonade] Trio in AUTH48 In-Reply-To: Message-ID: References: <085091CB2CA14E4B8B163FFC37C84E9D09627019@zcarhxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: lemonade@ietf.org, Glenn Parsons X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed, 5 Apr 2006, Ted Hardie wrote: > Just to clarify this, the AUTH48 period is not being stopped. The message that you sent to the RFC editor sure looks like a stop to me. It was sufficient to block my intended work on the fixes last night. There was no prior consultation with the chair, the document editor, or 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 Wed Apr 05 12:57:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRBK8-0000iF-2k; Wed, 05 Apr 2006 12:57:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRBK7-0000e5-6d for lemonade@ietf.org; Wed, 05 Apr 2006 12:57:39 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRBK5-0007i3-QM for lemonade@ietf.org; Wed, 05 Apr 2006 12:57:39 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k35GvZx7030704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Apr 2006 09:57:36 -0700 Received: from [10.0.1.4] (vpn-10-50-16-73.qualcomm.com [10.50.16.73]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k35GvRfD005696; Wed, 5 Apr 2006 09:57:33 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <085091CB2CA14E4B8B163FFC37C84E9D09627019@zcarhxm0.corp.nortel.com> Date: Wed, 5 Apr 2006 09:57:27 -0700 To: Mark Crispin From: Ted Hardie Subject: Re: [lemonade] Trio in AUTH48 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: lemonade@ietf.org, Glenn Parsons X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 9:22 AM -0700 4/5/06, Mark Crispin wrote: >On Wed, 5 Apr 2006, Ted Hardie wrote: >>Just to clarify this, the AUTH48 period is not being stopped. > >The message that you sent to the RFC editor sure looks like a stop to me. It was sufficient to block my intended work on the fixes last night. Mark, I am sorry for any confusion; any other work you need to do for the AUTH48 can certainly go forward. But, as I said in my earlier message, I believe the chairs need to call consensus on the resolution to the syntax discussion. That shouldn't go into the document until that consensus has been called. Glenn's message has three proposals, only one of which would stop AUTH48 to get IESG approval of a set of changes; if that one is the one the working group decides on, then we can get that approval and move on. None of the other work on the AUTH48 document would be lost even in that case; the RFC Editor would apply those deltas to the work already done. regards, Ted >There was no prior consultation with the chair, the document editor, or 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 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Apr 05 14:01:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRCJn-0004nM-Na; Wed, 05 Apr 2006 14:01:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR9Vo-0001bf-Vu for lemonade@ietf.org; Wed, 05 Apr 2006 11:01:36 -0400 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 1FR9Vn-0001pt-NC for lemonade@ietf.org; Wed, 05 Apr 2006 11:01:36 -0400 Received: from [216.43.25.67] (127.0.0.1) by episteme-software.com with ESMTP (EIMS X 3.3d17); Wed, 5 Apr 2006 10:01:26 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: <31081.1144154227.226281@peirce.dave.cridland.net> References: <13fb01c65438$b5793880$d3219681@Tundra> <442F466E.9050907@isode.com> <4432675A.6020601@andrew.cmu.edu> <31081.1144154227.226281@peirce.dave.cridland.net> X-Mailer: Eudora [Macintosh version 7.0a12] Date: Wed, 5 Apr 2006 10:01:25 -0500 To: Dave Cridland From: Pete Resnick Subject: Re: [lemonade] confusion on syntax of the access portion of the URLAUTH Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-Mailman-Approved-At: Wed, 05 Apr 2006 14:01:22 -0400 Cc: Enhancements to Internet email to support diverse service enivronments , Alexey Melnikov , Peter Coates , Mark Crispin X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On 4/4/06 at 1:37 PM +0100, Dave Cridland wrote: >On Tue Apr 4 13:32:26 2006, Ken Murchison wrote: >>As distasteful as it might be, I wouldn't be upset if we use >>2192bis as normative. We'd then get support for partial fetch in >>URLAUTH for free (which might be reason enough to NOT use 2192bis). > >If partial fetch support ends up in URLAUTH, then it ought to end up >in CATENATE too... For me, this is just a reference change, and perhaps adding an example. I guess the question is: Would we have to make a "CATENATE2" capability just for the addition of the 2192bis syntax? >And in that case, CATENATE might as well have the literal8 bits >added, since all the implementations I know of support that. If BINARY is going to be updated soon, I see no need to hold up CATENATE. BINARY can simply update the syntax: text-literal =/ "TEXT" SP literal8 It's actually a bit more complicated for me to change it. pr -- Pete Resnick QUALCOMM Incorporated _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Apr 05 14:35:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRCqQ-0008AC-LG; Wed, 05 Apr 2006 14:35:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRCqP-0008A2-8a for lemonade@ietf.org; Wed, 05 Apr 2006 14:35:05 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRCqM-0003R5-Os for lemonade@ietf.org; Wed, 05 Apr 2006 14:35:05 -0400 Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k35IZ2Sa023537 for ; Wed, 5 Apr 2006 12:35:02 -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 <0IX900101HX55000@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Wed, 05 Apr 2006 12:35:02 -0600 (MDT) Received: from Tundra ([129.150.33.102]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IX900E6NIABRRI5@mail-amer.sun.com> for lemonade@ietf.org; Wed, 05 Apr 2006 12:35:01 -0600 (MDT) Date: Wed, 05 Apr 2006 11:34:57 -0700 From: Peter Coates To: lemonade@ietf.org Message-id: <001601c658df$a4fb6d10$66219681@Tundra> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcZY36OPMZZYYD0+T26NWdE3HryCSg== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [lemonade] URLAUTH and GENURLAUTH X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org There are 3 possibilities (1) I'm blind (2) I'm stupid (3) the URLAUTH spec is missing something important. I tend toward 1 or 2. But just in case, here goes. First, let me verify that I have things straight. In issuing a GENURLAUTH request, the client is asking the server to generate a token so that the a user can grant (temporary) access to a particular message pr message fragment to a particular user/any authorised user/whatever. And the URL fetch command allows a user to access a message to which they might otherwise not have access based on this generated token. I believe that to be the theory. In which case, the server MUST check that the user issuing the GENURLAUTH request has read permission on the mailbox(es) in the URL(s) given. Otherwise anyone with any access could generate URLs for access to anything. Now maybe I'm just stupid, and to anyone who is a bit cleverer than me this would be quite obvious. But I really think that this check, "does the current user have read access to the mailbox specified mailbox" ought to be called out in the list of checks to be performed: The server MUST validate each supplied URL as follows: (1) the mailbox component of the URL MUST refer to an existing mailbox. --> (1a) the current user authorised for this session MUST have read permission on this mailbox. (2) the server component of the URL MUST contain a valid userid that identifies the owner of the mailbox access key table that will be used to generate the URLAUTH authorized URL. As a consequence, the iserver rule of [IMAPURL] is modified so that iuserauth is mandatory. (3) there is a valid access identifier which, in the case of "submit+" and "user+", will contain a valid userid. This userid is not necessarily the same as the owner userid described in (2). (4) the server MAY also verify that the Message-ID and/or second components (if present) are valid. Or course it is always possible that I have this completely wrong... Peter _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Apr 05 15:43:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRDv3-0006Lj-8d; Wed, 05 Apr 2006 15:43:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRDv2-0006Le-EM for lemonade@ietf.org; Wed, 05 Apr 2006 15:43:56 -0400 Received: from mxout4.cac.washington.edu ([140.142.33.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRDv0-00078V-2U for lemonade@ietf.org; Wed, 05 Apr 2006 15:43:56 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout4.cac.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k35JhqN3023125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Apr 2006 12:43:52 -0700 X-Auth-Received: from Shimo-Tomobiki.panda.com ([65.122.177.186]) (authenticated authid=mrc) by smtp.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k35Jhm9e030339 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 5 Apr 2006 12:43:51 -0700 Date: Wed, 5 Apr 2006 12:43:41 -0700 From: Mark Crispin To: Peter Coates Subject: Re: [lemonade] URLAUTH and GENURLAUTH In-Reply-To: <001601c658df$a4fb6d10$66219681@Tundra> Message-ID: References: <001601c658df$a4fb6d10$66219681@Tundra> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed, 5 Apr 2006, Peter Coates wrote: > There are 3 possibilities (4) None of the above. It's a valid point, but one which does not matter. > First, let me verify that I have things straight. In issuing a GENURLAUTH > request, the client is asking the server to generate a token so that the a > user can grant (temporary) access to a particular message pr message > fragment to a particular user/any authorised user/whatever. And the URL > fetch command allows a user to access a message to which they might > otherwise not have access based on this generated token. Remember, however, that the URLFETCH command effectively executes with the access of the user who issued the GENURLAUTH. Put another way, the token does NOT grant you access to the data; it grants you the issuing user's access to the token (whatever that may be). Whether that grants you access to the token all depends upon the issuing user's access. Consider this case: joe generates a token to data owned by sally and gives it to pete. Between the time that joe generates the token, and pete uses it, sally revokes joe's access to the data. That has the instantaneous and automatic effect of invalidating the token that joe generated. > I believe that to be the theory. In which case, the server MUST check that > the user issuing the GENURLAUTH request has read permission on the > mailbox(es) in the URL(s) given. Otherwise anyone with any access could > generate URLs for access to anything. Hopefully, you now understand that it doesn't matter. The check that you propose is unnecessary, since the check that counts will take place during the URLFETCH. What's more, the check that you propose may be detrimental. Why shouldn't it be possible for joe to generate the token for pete even if he doesn't have access to it right now? Suppose he gives it to pete now, along with a "I'm leaving a note to sally to ask her change the protections, so hold off on using it until after 10AM when she gets in the office. I'm now getting on the plane for Tokyo, so I'll be offline for the next 12 hours." -- 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 Apr 05 15:47:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRDyr-0007PI-2I; Wed, 05 Apr 2006 15:47:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRDyq-0007PD-DY for lemonade@ietf.org; Wed, 05 Apr 2006 15:47:52 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRDyn-0007Ke-1m for lemonade@ietf.org; Wed, 05 Apr 2006 15:47:52 -0400 Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k35JlmSa011773 for ; Wed, 5 Apr 2006 13:47:48 -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 <0IX900001L8N1V00@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Wed, 05 Apr 2006 13:47:48 -0600 (MDT) Received: from Tundra ([199.247.232.254]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IX9002SNLNM7LU2@mail-amer.sun.com>; Wed, 05 Apr 2006 13:47:48 -0600 (MDT) Date: Wed, 05 Apr 2006 12:47:44 -0700 From: Peter Coates Subject: RE: [lemonade] URLAUTH and GENURLAUTH In-reply-to: To: "'Mark Crispin'" Message-id: <002501c658e9$cfe603a0$66219681@Tundra> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcZY6U0NBsQdVGMqRxyLmwwG5R9dkwAADQgw X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Thanks. Suddenly obvious. -----Original Message----- From: mrc@ndcms.cac.washington.edu [mailto:mrc@ndcms.cac.washington.edu] On Behalf Of Mark Crispin Sent: April 5, 2006 12:44 To: Peter Coates Cc: lemonade@ietf.org Subject: Re: [lemonade] URLAUTH and GENURLAUTH On Wed, 5 Apr 2006, Peter Coates wrote: > There are 3 possibilities (4) None of the above. It's a valid point, but one which does not matter. > First, let me verify that I have things straight. In issuing a > GENURLAUTH request, the client is asking the server to generate a > token so that the a user can grant (temporary) access to a particular > message pr message fragment to a particular user/any authorised > user/whatever. And the URL fetch command allows a user to access a > message to which they might otherwise not have access based on this generated token. Remember, however, that the URLFETCH command effectively executes with the access of the user who issued the GENURLAUTH. Put another way, the token does NOT grant you access to the data; it grants you the issuing user's access to the token (whatever that may be). Whether that grants you access to the token all depends upon the issuing user's access. Consider this case: joe generates a token to data owned by sally and gives it to pete. Between the time that joe generates the token, and pete uses it, sally revokes joe's access to the data. That has the instantaneous and automatic effect of invalidating the token that joe generated. > I believe that to be the theory. In which case, the server MUST check > that the user issuing the GENURLAUTH request has read permission on > the > mailbox(es) in the URL(s) given. Otherwise anyone with any access > could generate URLs for access to anything. Hopefully, you now understand that it doesn't matter. The check that you propose is unnecessary, since the check that counts will take place during the URLFETCH. What's more, the check that you propose may be detrimental. Why shouldn't it be possible for joe to generate the token for pete even if he doesn't have access to it right now? Suppose he gives it to pete now, along with a "I'm leaving a note to sally to ask her change the protections, so hold off on using it until after 10AM when she gets in the office. I'm now getting on the plane for Tokyo, so I'll be offline for the next 12 hours." -- 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 Apr 05 16:29:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FREcz-0003Er-Ob; Wed, 05 Apr 2006 16:29:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FREcz-0003Eh-8a for lemonade@ietf.org; Wed, 05 Apr 2006 16:29:21 -0400 Received: from out1.smtp.messagingengine.com ([66.111.4.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FREcy-0003IJ-2e for lemonade@ietf.org; Wed, 05 Apr 2006 16:29:21 -0400 Received: from frontend2.internal (frontend2.internal [10.202.2.151]) by frontend1.messagingengine.com (Postfix) with ESMTP id DA084D471BE; Wed, 5 Apr 2006 16:29:18 -0400 (EDT) Received: from frontend3.messagingengine.com ([10.202.2.152]) by frontend2.internal (MEProxy); Wed, 05 Apr 2006 16:29:09 -0400 X-Sasl-enc: OUGEYHBG0H0Ddyssys+Qrwi1+838+8P6GNbk/xp9COCi 1144268949 Received: from [17.101.35.110] (unknown [17.101.35.110]) by www.fastmail.fm (Postfix) with ESMTP id D9F516AD; Wed, 5 Apr 2006 16:29:07 -0400 (EDT) Date: Wed, 05 Apr 2006 16:29:36 -0400 From: Cyrus Daboo To: Peter Coates , 'Mark Crispin' Subject: RE: [lemonade] URLAUTH and GENURLAUTH Message-ID: In-Reply-To: <002501c658e9$cfe603a0$66219681@Tundra> References: <002501c658e9$cfe603a0$66219681@Tundra> X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi, --On April 5, 2006 12:47:44 PM -0700 Peter Coates wrote: > Thanks. Suddenly obvious. If its only obvious after additional explanation, then the draft is deficient - particularly when dealing with a security issue. Having re-read it just now I too am somewhat confused as to what is the appropriate context for determining access to the actual data at URLFETCH time. I think there needs to be some statement somewhere to make it clear that: "access to the actual data referenced by the URL is ultimately governed by the access privileges of the user that 'owns' the mailbox access key used to generate the URLAUTH" I don't think that is explicitly spelled out and I think it should be. -- Cyrus Daboo _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Apr 05 17:07:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRFE7-0004XE-4v; Wed, 05 Apr 2006 17:07:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRFE6-0004X9-2W for lemonade@ietf.org; Wed, 05 Apr 2006 17:07:42 -0400 Received: from mxout1.cac.washington.edu ([140.142.32.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRFE4-00055r-Oc for lemonade@ietf.org; Wed, 05 Apr 2006 17:07:42 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout1.cac.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k35L7csO031780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Apr 2006 14:07:38 -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.6+UW06.03/8.13.5+UW06.03) with ESMTP id k35L7bcB001548 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 5 Apr 2006 14:07:38 -0700 Date: Wed, 5 Apr 2006 14:09:41 -0700 (Pacific Daylight Time) From: Mark Crispin To: Cyrus Daboo Subject: RE: [lemonade] URLAUTH and GENURLAUTH In-Reply-To: Message-ID: References: <002501c658e9$cfe603a0$66219681@Tundra> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: lemonade@ietf.org, Peter Coates X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed, 5 Apr 2006, Cyrus Daboo wrote: > I don't think that is explicitly spelled out and I think it should be. And this did not come up during Last Call because...? -- 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 Apr 05 17:10:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRFGK-0007fO-Ma; Wed, 05 Apr 2006 17:10:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRFGG-0007fJ-3E for lemonade@ietf.org; Wed, 05 Apr 2006 17:09:56 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRFGB-00059j-HE for lemonade@ietf.org; Wed, 05 Apr 2006 17:09:56 -0400 Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k35L9pFu003717 for ; Wed, 5 Apr 2006 15:09:51 -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 <0IX900401OYH4S00@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Wed, 05 Apr 2006 15:09:51 -0600 (MDT) Received: from Tundra ([199.247.232.254]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IX90051EPGCNI05@mail-amer.sun.com>; Wed, 05 Apr 2006 15:09:50 -0600 (MDT) Date: Wed, 05 Apr 2006 14:09:46 -0700 From: Peter Coates Subject: RE: [lemonade] URLAUTH and GENURLAUTH In-reply-to: To: "'Mark Crispin'" , "'Cyrus Daboo'" Message-id: <003e01c658f5$45e97f40$66219681@Tundra> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcZY9PwDy6EdR7RAR0C/l5R4j8a41QAADGrQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Because few people reading this was as slow on the uptake as I am? -----Original Message----- From: mrc@ndcms.cac.washington.edu [mailto:mrc@ndcms.cac.washington.edu] On Behalf Of Mark Crispin Sent: April 5, 2006 14:10 To: Cyrus Daboo Cc: Peter Coates; lemonade@ietf.org Subject: RE: [lemonade] URLAUTH and GENURLAUTH On Wed, 5 Apr 2006, Cyrus Daboo wrote: > I don't think that is explicitly spelled out and I think it should be. And this did not come up during Last Call because...? -- 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 Apr 05 17:12:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRFJ1-0002Fk-M6; Wed, 05 Apr 2006 17:12:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRFJ0-0002Dv-UB for lemonade@ietf.org; Wed, 05 Apr 2006 17:12:46 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FREWW-0002yd-Ev for lemonade@ietf.org; Wed, 05 Apr 2006 16:22:40 -0400 Received: from mxout3.cac.washington.edu ([140.142.32.166]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FREQM-00068t-N4 for lemonade@ietf.org; Wed, 05 Apr 2006 16:16:21 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout3.cac.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k35KGH6U031902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Apr 2006 13:16:17 -0700 X-Auth-Received: from Shimo-Tomobiki.panda.com (D-128-95-135-163.dhcp4.washington.edu [128.95.135.163]) (authenticated authid=mrc) by smtp.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k35KGGId019505 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 5 Apr 2006 13:16:17 -0700 Date: Wed, 5 Apr 2006 13:16:10 -0700 From: Mark Crispin To: Peter Coates Subject: RE: [lemonade] URLAUTH and GENURLAUTH In-Reply-To: <002601c658ec$a5c22c90$66219681@Tundra> Message-ID: References: <002601c658ec$a5c22c90$66219681@Tundra> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: -2.6 (--) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed, 5 Apr 2006, Peter Coates wrote: > This implies either that the userid must match the userid used to > authenticate the imap session, or at least that the current user has > access to the key table of the user specified in the iserver part of the > URL. I'm guessing that in practice the former is going to be true. I agree. I don't think that most implementations will consider the latter case. -- 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 Apr 05 17:17:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRFNC-0004Hx-Vv; Wed, 05 Apr 2006 17:17:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRFNB-0004Hl-DU for lemonade@ietf.org; Wed, 05 Apr 2006 17:17:05 -0400 Received: from out3.smtp.messagingengine.com ([66.111.4.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRFNA-0005bK-7S for lemonade@ietf.org; Wed, 05 Apr 2006 17:17:05 -0400 Received: from frontend2.internal (frontend2.internal [10.202.2.151]) by frontend1.messagingengine.com (Postfix) with ESMTP id F3359D45939; Wed, 5 Apr 2006 17:17:02 -0400 (EDT) Received: from frontend3.messagingengine.com ([10.202.2.152]) by frontend2.internal (MEProxy); Wed, 05 Apr 2006 17:16:53 -0400 X-Sasl-enc: QOchA5JsL5XwR86D0YHoDsNr9qbBLQludkceAWnQnYor 1144271813 Received: from [17.101.35.110] (unknown [17.101.35.110]) by www.fastmail.fm (Postfix) with ESMTP id 66AE020B0; Wed, 5 Apr 2006 17:16:49 -0400 (EDT) Date: Wed, 05 Apr 2006 17:17:18 -0400 From: Cyrus Daboo To: Mark Crispin Subject: RE: [lemonade] URLAUTH and GENURLAUTH Message-ID: In-Reply-To: References: <002501c658e9$cfe603a0$66219681@Tundra> X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: lemonade@ietf.org, Peter Coates X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Mark, --On April 5, 2006 2:09:41 PM -0700 Mark Crispin wrote: >> I don't think that is explicitly spelled out and I think it should be. > > > > And this did not come up during Last Call because...? > > Sometimes things get missed, or don't get spotted until someone actually starts delving into doing an implementation - its a fact of life. That said I will admit that I did not review the document myself during last call, and am only reacting to Peter's comment which drew my attention. I'm not really bothered as to whether we do anything about it now or not given how close to publication the documents are. If you want, just put this on the list for some future revision of the document. -- Cyrus Daboo _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Apr 05 18:07:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRG9s-0004Zz-6g; Wed, 05 Apr 2006 18:07:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRG9r-0004Zu-Fr for lemonade@ietf.org; Wed, 05 Apr 2006 18:07:23 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FREWd-0002yd-0I for lemonade@ietf.org; Wed, 05 Apr 2006 16:22:47 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FREIR-000645-4F for lemonade@ietf.org; Wed, 05 Apr 2006 16:08:12 -0400 Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k35K86Gp025512 for ; Wed, 5 Apr 2006 14:08:06 -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 <0IX900201M8WNB00@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Wed, 05 Apr 2006 14:08:06 -0600 (MDT) Received: from Tundra ([199.247.232.254]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IX9001LLMLG4KB4@mail-amer.sun.com>; Wed, 05 Apr 2006 14:08:06 -0600 (MDT) Date: Wed, 05 Apr 2006 13:08:02 -0700 From: Peter Coates Subject: RE: [lemonade] URLAUTH and GENURLAUTH In-reply-to: To: "'Mark Crispin'" Message-id: <002601c658ec$a5c22c90$66219681@Tundra> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcZY6U0NBsQdVGMqRxyLmwwG5R9dkwAAtYHg X-Spam-Score: -2.6 (--) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org OK so the answer is in this paragraph. This implies either that the userid must match the userid used to authenticate the imap session, or at least that the current user has access to the key table of the user specified in the iserver part of the URL. I'm guessing that in practice the former is going to be true. (2) the server component of the URL MUST contain a valid userid that identifies the owner of the mailbox access key table that will be used to generate the URLAUTH authorized URL. As a consequence, the iserver rule of [IMAPURL] is modified so that iuserauth is mandatory. Peter -----Original Message----- From: mrc@ndcms.cac.washington.edu [mailto:mrc@ndcms.cac.washington.edu] On Behalf Of Mark Crispin Sent: April 5, 2006 12:44 To: Peter Coates Cc: lemonade@ietf.org Subject: Re: [lemonade] URLAUTH and GENURLAUTH On Wed, 5 Apr 2006, Peter Coates wrote: > There are 3 possibilities (4) None of the above. It's a valid point, but one which does not matter. > First, let me verify that I have things straight. In issuing a > GENURLAUTH request, the client is asking the server to generate a > token so that the a user can grant (temporary) access to a particular > message pr message fragment to a particular user/any authorised > user/whatever. And the URL fetch command allows a user to access a > message to which they might otherwise not have access based on this generated token. Remember, however, that the URLFETCH command effectively executes with the access of the user who issued the GENURLAUTH. Put another way, the token does NOT grant you access to the data; it grants you the issuing user's access to the token (whatever that may be). Whether that grants you access to the token all depends upon the issuing user's access. Consider this case: joe generates a token to data owned by sally and gives it to pete. Between the time that joe generates the token, and pete uses it, sally revokes joe's access to the data. That has the instantaneous and automatic effect of invalidating the token that joe generated. > I believe that to be the theory. In which case, the server MUST check > that the user issuing the GENURLAUTH request has read permission on > the > mailbox(es) in the URL(s) given. Otherwise anyone with any access > could generate URLs for access to anything. Hopefully, you now understand that it doesn't matter. The check that you propose is unnecessary, since the check that counts will take place during the URLFETCH. What's more, the check that you propose may be detrimental. Why shouldn't it be possible for joe to generate the token for pete even if he doesn't have access to it right now? Suppose he gives it to pete now, along with a "I'm leaving a note to sally to ask her change the protections, so hold off on using it until after 10AM when she gets in the office. I'm now getting on the plane for Tokyo, so I'll be offline for the next 12 hours." -- 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 Apr 05 18:11:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRGDa-0004sI-7J; Wed, 05 Apr 2006 18:11:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRGDY-0004sD-MX for lemonade@ietf.org; Wed, 05 Apr 2006 18:11:12 -0400 Received: from mxout5.cac.washington.edu ([140.142.32.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRGDW-00008c-BV for lemonade@ietf.org; Wed, 05 Apr 2006 18:11:12 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k35MB9ni024072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Apr 2006 15:11:09 -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.6+UW06.03/8.13.5+UW06.03) with ESMTP id k35MB84i009497 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 5 Apr 2006 15:11:09 -0700 Date: Wed, 5 Apr 2006 15:13:13 -0700 (Pacific Daylight Time) From: Mark Crispin To: Ted Hardie Subject: Re: [lemonade] Trio in AUTH48 In-Reply-To: Message-ID: References: <085091CB2CA14E4B8B163FFC37C84E9D09627019@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='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: lemonade@ietf.org, Glenn Parsons X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed, 5 Apr 2006, Ted Hardie wrote: > But, as I said in my earlier message, > I believe the chairs need to call consensus on the resolution to the syntax > discussion. That shouldn't go into the document until that consensus has been > called. The silence has been deafening in response to the message from the chair. Since the Working Group refuses to give guidance, shall we abandon the trio and tell the RFC Editor to cancel publication of these documents? Ted Hardie made it abundantly clear that I can not be trusted to figure out for myself how to resolve something as simple and stupid as whether or not a syntax rule name has an underscore or a hyphen. -- 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 Apr 05 19:33:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRHVE-00013y-3I; Wed, 05 Apr 2006 19:33:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRHVD-00013t-RL for lemonade@ietf.org; Wed, 05 Apr 2006 19:33:31 -0400 Received: from out3.smtp.messagingengine.com ([66.111.4.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRHVC-0002qc-LG for lemonade@ietf.org; Wed, 05 Apr 2006 19:33:31 -0400 Received: from frontend2.internal (frontend2.internal [10.202.2.151]) by frontend1.messagingengine.com (Postfix) with ESMTP id 4D38CD473B4; Wed, 5 Apr 2006 19:33:28 -0400 (EDT) Received: from frontend3.messagingengine.com ([10.202.2.152]) by frontend2.internal (MEProxy); Wed, 05 Apr 2006 19:33:18 -0400 X-Sasl-enc: I8rFkUSCrBF1wcs0i6c0SUtCZ+tbOTbSRucNqYjpG2M/ 1144279998 Received: from [10.0.1.4] (pool-71-253-41-56.pitbpa.east.verizon.net [71.253.41.56]) by www.fastmail.fm (Postfix) with ESMTP id AC8DC20B0; Wed, 5 Apr 2006 19:33:16 -0400 (EDT) Date: Wed, 05 Apr 2006 19:33:25 -0400 From: Cyrus Daboo To: Alexey Melnikov , Mark Crispin Subject: Re: [lemonade] URLAUTH edits to be made during AUTH48 Message-ID: <00E7765AA43EFD1ACA79580A@ninevah.local> In-Reply-To: <443396B1.1080704@isode.com> References: <4432DA6B.4050904@isode.com> <443396B1.1080704@isode.com> X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Alexey, --On April 5, 2006 11:06:41 AM +0100 Alexey Melnikov wrote: >>>>> authimapurl = "imap://" enc-user "@" hostport "/" imessagepart >>>>> ; replaces "imapurl" and "iserver" rules for >>>>> URLAUTH >>>>> ; authorized URLs >>>> >>> You should still use iuserauth above, as something like >>> "joe;auth=digest-md5" would be allowed here. >> >> I'm not sure that I understand. Is ;AUTH= allowed with no userid? > > Yes. You want to prohibit it for URLAUTH URLs only. So the following would work then: authimapurl = "imap://" enc-user [iauth] "@" hostport "/" imessagepart ; replaces "imapurl" and "iserver" rules for URLAUTH ; authorized URLs -- Cyrus Daboo _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Apr 05 19:34:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRHWO-0001ke-JW; Wed, 05 Apr 2006 19:34:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRHWN-0001kZ-MJ for lemonade@ietf.org; Wed, 05 Apr 2006 19:34:43 -0400 Received: from out3.smtp.messagingengine.com ([66.111.4.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRHWN-0002xZ-Gi for lemonade@ietf.org; Wed, 05 Apr 2006 19:34:43 -0400 Received: from frontend2.internal (frontend2.internal [10.202.2.151]) by frontend1.messagingengine.com (Postfix) with ESMTP id 50651D43ED2; Wed, 5 Apr 2006 19:34:42 -0400 (EDT) Received: from frontend3.messagingengine.com ([10.202.2.152]) by frontend2.internal (MEProxy); Wed, 05 Apr 2006 19:34:32 -0400 X-Sasl-enc: 5E79npAjtfTPJQVbLYjq3QTDpc2m9rVxZPpvdGtE5OLT 1144280072 Received: from [10.0.1.4] (pool-71-253-41-56.pitbpa.east.verizon.net [71.253.41.56]) by www.fastmail.fm (Postfix) with ESMTP id 2222573F; Wed, 5 Apr 2006 19:34:31 -0400 (EDT) Date: Wed, 05 Apr 2006 19:34:41 -0400 From: Cyrus Daboo To: Glenn Parsons , lemonade@ietf.org Subject: Re: [lemonade] Trio in AUTH48 Message-ID: <6520988846339E61F855CA17@ninevah.local> In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D09627019@zcarhxm0.corp.nortel.com> References: <085091CB2CA14E4B8B163FFC37C84E9D09627019@zcarhxm0.corp.nortel.c om> X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Glenn, --On April 4, 2006 8:59:39 PM -0400 Glenn Parsons wrote: > 1. Stop AUTH48. Include RFC2192bis as a mandatory reference. Get IESG > re-approval and then resume AUTH48. But what changes will we add? Will > we include partial support now? We need concrete text proposals if we > want to do this... > > 2. Make the 'bug fix' changes Mark has proposed earlier today (with > tweaks as appropriate) > > 3. Change nothing. It doesn't matter since we will fix all this in > RFC2192bis and Profile-bis I think (2) makes the most sense as this can be done quickly and the documents published without causing any problems in the future. -- Cyrus Daboo _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Apr 06 02:47:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FROGM-0001Pc-7J; Thu, 06 Apr 2006 02:46:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FROGL-0001PX-37 for lemonade@ietf.org; Thu, 06 Apr 2006 02:46:37 -0400 Received: from mxout4.cac.washington.edu ([140.142.33.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FROGG-0002ae-Mz for lemonade@ietf.org; Thu, 06 Apr 2006 02:46:37 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout4.cac.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k366kPpt005841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Apr 2006 23:46:25 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k366kN43011245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 5 Apr 2006 23:46:24 -0700 Date: Wed, 5 Apr 2006 23:46:23 -0700 (PDT) From: Mark Crispin To: Cyrus Daboo Subject: Re: [lemonade] Trio in AUTH48 In-Reply-To: <6520988846339E61F855CA17@ninevah.local> Message-ID: References: <085091CB2CA14E4B8B163FFC37C84E9D09627019@zcarhxm0.corp.nortel.c om> <6520988846339E61F855CA17@ninevah.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: lemonade@ietf.org, Glenn Parsons X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed, 5 Apr 2006, Cyrus Daboo wrote: >> 2. Make the 'bug fix' changes Mark has proposed earlier today (with >> tweaks as appropriate) > > I think (2) makes the most sense as this can be done quickly and the > documents published without causing any problems in the future. Most of these changes are things that were agreed to several months ago. -- 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 Thu Apr 06 06:29:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRRkE-0005ET-Mc; Thu, 06 Apr 2006 06:29:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRRkD-0005Dv-29 for lemonade@ietf.org; Thu, 06 Apr 2006 06:29:41 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRRkB-0002FA-LH for lemonade@ietf.org; Thu, 06 Apr 2006 06:29:41 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Thu, 6 Apr 2006 11:29:30 +0100 Message-ID: <4434ED87.9020207@isode.com> Date: Thu, 06 Apr 2006 11:29:27 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Cyrus Daboo Subject: Re: [lemonade] URLAUTH edits to be made during AUTH48 References: <4432DA6B.4050904@isode.com> <443396B1.1080704@isode.com> <00E7765AA43EFD1ACA79580A@ninevah.local> In-Reply-To: <00E7765AA43EFD1ACA79580A@ninevah.local> 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: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: lemonade@ietf.org, Mark Crispin X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Cyrus Daboo wrote: > Hi Alexey, > > --On April 5, 2006 11:06:41 AM +0100 Alexey Melnikov > wrote: > >>>>>> authimapurl = "imap://" enc-user "@" hostport "/" imessagepart >>>>>> ; replaces "imapurl" and "iserver" rules for >>>>>> URLAUTH >>>>>> ; authorized URLs >>>>> >>>> You should still use iuserauth above, as something like >>>> "joe;auth=digest-md5" would be allowed here. >>> >>> I'm not sure that I understand. Is ;AUTH= allowed with no userid? >> >> Yes. You want to prohibit it for URLAUTH URLs only. > > So the following would work then: > > authimapurl = "imap://" enc-user [iauth] "@" hostport "/" > imessagepart > ; replaces "imapurl" and "iserver" rules for URLAUTH > ; authorized URLs Yes, this would work. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Apr 06 14:09:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRYv1-0004kn-Rp; Thu, 06 Apr 2006 14:09:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRYv0-0004ki-62 for lemonade@ietf.org; Thu, 06 Apr 2006 14:09:18 -0400 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 1FRYuy-0001en-Tr for lemonade@ietf.org; Thu, 06 Apr 2006 14:09:18 -0400 Received: from [216.43.25.67] (127.0.0.1) by episteme-software.com with ESMTP (EIMS X 3.3d17); Thu, 6 Apr 2006 13:09:15 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: <6520988846339E61F855CA17@ninevah.local> References: <085091CB2CA14E4B8B163FFC37C84E9D09627019@zcarhxm0.corp.nortel.c om> <6520988846339E61F855CA17@ninevah.local> X-Mailer: Eudora [Macintosh version 7.0a12] Date: Thu, 6 Apr 2006 13:09:13 -0500 To: Cyrus Daboo From: Pete Resnick Subject: Re: [lemonade] Trio in AUTH48 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: lemonade@ietf.org, Glenn Parsons X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On 4/5/06 at 7:34 PM -0400, Cyrus Daboo wrote: >Hi Glenn, > >--On April 4, 2006 8:59:39 PM -0400 Glenn Parsons wrote: > >>1. Stop AUTH48. Include RFC2192bis as a mandatory reference. Get IESG >>re-approval and then resume AUTH48. But what changes will we add? Will >>we include partial support now? We need concrete text proposals if we >>want to do this... >> >>2. Make the 'bug fix' changes Mark has proposed earlier today (with >>tweaks as appropriate) >> >>3. Change nothing. It doesn't matter since we will fix all this in >>RFC2192bis and Profile-bis > >I think (2) makes the most sense as this can be done quickly and the >documents published without causing any problems in the future. Agreed. This does mean when 2192bis gets published, it will probably need to add some sort of CAPABILITY so that BURL and CATENATE can use the new forms. pr -- Pete Resnick QUALCOMM Incorporated _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Apr 06 14:46:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRZUz-0005qL-Pd; Thu, 06 Apr 2006 14:46:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRZUy-0005qG-16 for lemonade@ietf.org; Thu, 06 Apr 2006 14:46:28 -0400 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRZUw-0002wS-IP for lemonade@ietf.org; Thu, 06 Apr 2006 14:46:28 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1FRZUv-0007Po-9v; Thu, 06 Apr 2006 18:46:25 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 30731498002; Thu, 6 Apr 2006 19:52:26 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02613-10; Thu, 6 Apr 2006 19:52:17 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 79F63498003; Thu, 6 Apr 2006 19:52:15 +0100 (BST) Date: Thu, 06 Apr 2006 19:46:13 +0100 Subject: Re: [lemonade] Trio in AUTH48 References: <085091CB2CA14E4B8B163FFC37C84E9D09627019@zcarhxm0.corp.nortel.c om> <6520988846339E61F855CA17@ninevah.local> In-Reply-To: MIME-Version: 1.0 Message-Id: <15575.1144349174.245128@peirce.dave.cridland.net> From: Dave Cridland To: Pete Resnick Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Heisenberg-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu Apr 6 19:09:13 2006, Pete Resnick wrote: > On 4/5/06 at 7:34 PM -0400, Cyrus Daboo wrote: >> --On April 4, 2006 8:59:39 PM -0400 Glenn Parsons >> wrote: >> >>> 1. Stop AUTH48. Include RFC2192bis as a mandatory reference. >>> Get IESG >>> re-approval and then resume AUTH48. But what changes will we >>> add? Will >>> we include partial support now? We need concrete text proposals >>> if we >>> want to do this... >>> >>> 2. Make the 'bug fix' changes Mark has proposed earlier today >>> (with >>> tweaks as appropriate) >>> >>> 3. Change nothing. It doesn't matter since we will fix all this >>> in >>> RFC2192bis and Profile-bis >> >> I think (2) makes the most sense as this can be done quickly and >> the documents published without causing any problems in the future. > > Agreed. This does mean when 2192bis gets published, it will > probably need to add some sort of CAPABILITY so that BURL and > CATENATE can use the new forms. I think that's the best solution. Although I was secretly hoping for CATENATELESS. ;-) 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 Apr 07 11:55:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRtIv-0007sw-0z; Fri, 07 Apr 2006 11:55:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRtIt-0007sr-IQ for lemonade@ietf.org; Fri, 07 Apr 2006 11:55:19 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRtIq-0001Ex-5g for lemonade@ietf.org; Fri, 07 Apr 2006 11:55:19 -0400 Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k37FtFZe007778 for ; Fri, 7 Apr 2006 09:55:15 -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 <0IXD00E0105S2A00@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Fri, 07 Apr 2006 09:55:15 -0600 (MDT) Received: from Tundra ([199.247.232.254]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IXD001MA08056O3@mail-amer.sun.com> for lemonade@ietf.org; Fri, 07 Apr 2006 09:55:15 -0600 (MDT) Date: Fri, 07 Apr 2006 08:55:11 -0700 From: Peter Coates To: lemonade@ietf.org Message-id: <000701c65a5b$a818f710$6501a8c0@Tundra> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcZaW6a/VyHvYKvFR9Gv86gkSKOYyA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Subject: [lemonade] problems implementing RESETKEY GENURLAUTH and URLFETCH X-BeenThere: lemonade@ietf.org X-Mailman-Version: 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="===============1911748420==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============1911748420== Content-type: multipart/alternative; boundary="Boundary_(ID_+Su0MTunwoupwnCeeVp12w)" This is a multi-part message in MIME format. --Boundary_(ID_+Su0MTunwoupwnCeeVp12w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT I have problems with all three of these commands as they currently exist. These are surmountable problems, but it is very ugly. The problem stems from the architecture of our server as deployed in large installations. users and their mail stores are distributed over a number of servers. users (generally) connect to their home server. If they select a folder which is on another server, the commands are proxied across to the hosting server. All commands are either executed locally (the normal case) or proxied in their entirety. There are some cases where the local server issues a command to a remote server. There is no case where a command is partially proxied. GENURLAUTH and URLFETCH can carry several URLs. these URLs can be unrelated. this requires that parts of the command be proxied. this is pretty ugly I don't suppose that it is possible to put in a restriction that the URLs in these commands be restricted so that they all must refer to the same user/mailbox... It would be nice. RESETKEY poses a problem of another kind. the RESETKEY mailbox form of the command is not a problem. The bare RESETKEY command is. It may require the local server to send the RESETKEY to all the other hosts to reset their keys. That is not very pretty. I suspect I have even less chance of persuading people that the the bare RESETKEY is a poor idea. Peter Just trying to make my own life easier. --Boundary_(ID_+Su0MTunwoupwnCeeVp12w) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
I have problems with all three of these commands as they currently exist.  These are surmountable problems, but it is very ugly.
 
The problem stems from the architecture of our server as deployed in large installations.
 
users and their mail stores are distributed over a number of servers.  users (generally) connect to their home server.  If they select a folder which is on another server, the commands are proxied across to the hosting server.  All commands are either executed locally (the normal case) or proxied in their entirety.  There are some cases where the local server issues a command to a remote server.  There is no case where a command is partially proxied.
 
GENURLAUTH and URLFETCH can carry several URLs.  these URLs can be unrelated.  this requires that parts of the command be proxied.  this is pretty ugly  I don't suppose that it is possible to put in a restriction that the URLs in these commands be restricted so that they all must refer to the same user/mailbox...  It would be nice.
 
RESETKEY poses a problem of another kind.
 
the RESETKEY mailbox form of the command is not a problem.  The bare RESETKEY command is.  It may require the local server to send the RESETKEY to all the other hosts to reset their keys.  That is not very pretty.  I suspect I have even less chance of persuading people that the the bare RESETKEY is a poor idea.
 
Peter
 
Just trying to make my own life easier.
--Boundary_(ID_+Su0MTunwoupwnCeeVp12w)-- --===============1911748420== 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 --===============1911748420==-- From lemonade-bounces@ietf.org Fri Apr 07 12:10:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRtXy-00015v-Cd; Fri, 07 Apr 2006 12:10:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRtXw-00015q-Gw for lemonade@ietf.org; Fri, 07 Apr 2006 12:10:52 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRtXs-00022L-AO for lemonade@ietf.org; Fri, 07 Apr 2006 12:10:52 -0400 Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k37GAl3d021243 for ; Fri, 7 Apr 2006 10:10:47 -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 <0IXD00K010HFO600@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Fri, 07 Apr 2006 10:10:47 -0600 (MDT) Received: from Tundra ([199.247.232.254]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IXD002YE0XW7LW2@mail-amer.sun.com> for lemonade@ietf.org; Fri, 07 Apr 2006 10:10:47 -0600 (MDT) Date: Fri, 07 Apr 2006 09:10:43 -0700 From: Peter Coates In-reply-to: To: "'Peter Coates'" , lemonade@ietf.org Message-id: <000c01c65a5d$d35fb100$6501a8c0@Tundra> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcZaW6a/VyHvYKvFR9Gv86gkSKOYyAAAbccw X-Spam-Score: 0.1 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: Subject: [lemonade] RE: problems implementing RESETKEY GENURLAUTH and URLFETCH X-BeenThere: lemonade@ietf.org X-Mailman-Version: 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="===============1712599062==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============1712599062== Content-type: multipart/alternative; boundary="Boundary_(ID_VbCrQMEQOOOZYs/ERe8Tbw)" This is a multi-part message in MIME format. --Boundary_(ID_VbCrQMEQOOOZYs/ERe8Tbw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Actually the problem with GENURLAUTH is worse that I suggested. It requires that for each URL listed that is not hosted locally the server issue a command to the hosting server to verify that the mailbox in question exists. this is during the validation phase of the command. then the URLs may individually have to be proxied across. I would like to be persuaded of the usefulness of allowing multiple unrelated URLs in these commands before I go and do evil things to the code. Peter _____ From: Peter Coates [mailto:peter.coates@sun.com] Sent: April 7, 2006 08:55 To: 'lemonade@ietf.org' Subject: problems implementing RESETKEY GENURLAUTH and URLFETCH I have problems with all three of these commands as they currently exist. These are surmountable problems, but it is very ugly. The problem stems from the architecture of our server as deployed in large installations. users and their mail stores are distributed over a number of servers. users (generally) connect to their home server. If they select a folder which is on another server, the commands are proxied across to the hosting server. All commands are either executed locally (the normal case) or proxied in their entirety. There are some cases where the local server issues a command to a remote server. There is no case where a command is partially proxied. GENURLAUTH and URLFETCH can carry several URLs. these URLs can be unrelated. this requires that parts of the command be proxied. this is pretty ugly I don't suppose that it is possible to put in a restriction that the URLs in these commands be restricted so that they all must refer to the same user/mailbox... It would be nice. RESETKEY poses a problem of another kind. the RESETKEY mailbox form of the command is not a problem. The bare RESETKEY command is. It may require the local server to send the RESETKEY to all the other hosts to reset their keys. That is not very pretty. I suspect I have even less chance of persuading people that the the bare RESETKEY is a poor idea. Peter Just trying to make my own life easier. --Boundary_(ID_VbCrQMEQOOOZYs/ERe8Tbw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
Actually the problem with GENURLAUTH is worse that I suggested.  It requires that for each URL listed that is not hosted locally the server issue a command to the hosting server to verify that the mailbox in question exists.  this is during the validation phase of the command.  then the URLs may individually have to be proxied across.
 
I would like to be persuaded of the usefulness of allowing multiple unrelated URLs in these commands before I go and do evil things to the code.
 
Peter

From: Peter Coates [mailto:peter.coates@sun.com]
Sent: April 7, 2006 08:55
To: 'lemonade@ietf.org'
Subject: problems implementing RESETKEY GENURLAUTH and URLFETCH

I have problems with all three of these commands as they currently exist.  These are surmountable problems, but it is very ugly.
 
The problem stems from the architecture of our server as deployed in large installations.
 
users and their mail stores are distributed over a number of servers.  users (generally) connect to their home server.  If they select a folder which is on another server, the commands are proxied across to the hosting server.  All commands are either executed locally (the normal case) or proxied in their entirety.  There are some cases where the local server issues a command to a remote server.  There is no case where a command is partially proxied.
 
GENURLAUTH and URLFETCH can carry several URLs.  these URLs can be unrelated.  this requires that parts of the command be proxied.  this is pretty ugly  I don't suppose that it is possible to put in a restriction that the URLs in these commands be restricted so that they all must refer to the same user/mailbox...  It would be nice.
 
RESETKEY poses a problem of another kind.
 
the RESETKEY mailbox form of the command is not a problem.  The bare RESETKEY command is.  It may require the local server to send the RESETKEY to all the other hosts to reset their keys.  That is not very pretty.  I suspect I have even less chance of persuading people that the the bare RESETKEY is a poor idea.
 
Peter
 
Just trying to make my own life easier.
--Boundary_(ID_VbCrQMEQOOOZYs/ERe8Tbw)-- --===============1712599062== 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 --===============1712599062==-- From lemonade-bounces@ietf.org Fri Apr 07 20:31:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FS1MD-0005dd-0k; Fri, 07 Apr 2006 20:31:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FS1MB-0005Wc-7x for lemonade@ietf.org; Fri, 07 Apr 2006 20:31:15 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FS1M9-0003zF-UK for lemonade@ietf.org; Fri, 07 Apr 2006 20:31:15 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k380VCcW018436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 7 Apr 2006 17:31:13 -0700 Received: from [192.168.1.13] (loud.qualcomm.com [129.46.172.15]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k380VBf9029742 for ; Fri, 7 Apr 2006 17:31:12 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <002501c658e9$cfe603a0$66219681@Tundra> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Fri, 7 Apr 2006 17:31:15 -0700 To: lemonade@ietf.org From: Randall Gellens Subject: RE: [lemonade] URLAUTH and GENURLAUTH Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 5:17 PM -0400 4/5/06, Cyrus Daboo wrote: > I'm not really bothered as to whether we do anything about it now > or not given how close to publication the documents are. If you > want, just put this on the list for some future revision of the > document. I think it would be better to add the clarifying text during AUTH48. It in no way makes a technical change to the document; it is an informative sentence which simply adds clarity, which I think is better done now rather than putting it off for a future revision. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- I hope we shall...crush in its birth the aristocracy of our moneyed corporations, which dare already to challenge our government to a trial of strength, and bid defiance to the laws of our country. --Thomas Jefferson? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Apr 07 20:37:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FS1SY-00070V-B9; Fri, 07 Apr 2006 20:37:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FS1SW-00070Q-SU for lemonade@ietf.org; Fri, 07 Apr 2006 20:37:48 -0400 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FS1SV-00046K-JV for lemonade@ietf.org; Fri, 07 Apr 2006 20:37:48 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1FS1SM-0003X6-Jj; Sat, 08 Apr 2006 00:37:38 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 1B0EA498003; Sat, 8 Apr 2006 01:43:52 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10673-02; Sat, 8 Apr 2006 01:43:43 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 7AC50498002; Sat, 8 Apr 2006 01:43:41 +0100 (BST) Date: Sat, 08 Apr 2006 01:37:26 +0100 Subject: RE: [lemonade] URLAUTH and GENURLAUTH References: <002501c658e9$cfe603a0$66219681@Tundra> In-Reply-To: MIME-Version: 1.0 Message-Id: <21242.1144456647.570180@peirce.dave.cridland.net> From: Dave Cridland To: Randall Gellens Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Heisenberg-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Sat Apr 8 01:31:15 2006, Randall Gellens wrote: > At 5:17 PM -0400 4/5/06, Cyrus Daboo wrote: > >> I'm not really bothered as to whether we do anything about it now >> or not given how close to publication the documents are. If you >> want, just put this on the list for some future revision of the >> document. > > I think it would be better to add the clarifying text during > AUTH48. It in no way makes a technical change to the document; it > is an informative sentence which simply adds clarity, which I think > is better done now rather than putting it off for a future revision. I'd agree - the explanation Mark gave Peter was particularly good, clear text, it seems a terrible shame to waste it by not including it in the document while we can. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Apr 08 08:23:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSCTS-0004Le-Mp; Sat, 08 Apr 2006 08:23:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSCTR-0004LZ-Mc for lemonade@ietf.org; Sat, 08 Apr 2006 08:23:29 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSCTQ-0002Bx-9x for lemonade@ietf.org; Sat, 08 Apr 2006 08:23:29 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Sat, 8 Apr 2006 13:23:15 +0100 Message-ID: <4437AB2F.9050701@isode.com> Date: Sat, 08 Apr 2006 13:23:11 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Randall Gellens Subject: Re: [lemonade] URLAUTH and GENURLAUTH References: <002501c658e9$cfe603a0$66219681@Tundra> 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: 08170828343bcf1325e4a0fb4584481c Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Randall Gellens wrote: > At 5:17 PM -0400 4/5/06, Cyrus Daboo wrote: > >> I'm not really bothered as to whether we do anything about it now or >> not given how close to publication the documents are. If you want, >> just put this on the list for some future revision of the document. > > I think it would be better to add the clarifying text during AUTH48. > It in no way makes a technical change to the document; it is an > informative sentence which simply adds clarity, which I think is > better done now rather than putting it off for a future revision. I agree. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Apr 08 23:17:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSQQM-00084m-UA; Sat, 08 Apr 2006 23:17:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSQQM-00084e-4O for lemonade@ietf.org; Sat, 08 Apr 2006 23:17:14 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSQQK-0004kA-VA for lemonade@ietf.org; Sat, 08 Apr 2006 23:17:14 -0400 X-IronPort-AV: i="4.04,103,1144036800"; d="scan'208"; a="31175394:sNHT26185872" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 8 Apr 2006 23:17:12 -0400 Message-ID: <330A23D8336C0346B5C1A5BB19666647029F55A9@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DRAFT Minutes Posted Thread-Index: AcZbhBgKJNzZL1HyTMm0mZc2dksAuA== From: "Burger, Eric" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Subject: [lemonade] DRAFT Minutes Posted X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org See http://www3.ietf.org/proceedings/06mar/minutes/lemonade.txt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Apr 10 07:14:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSuLz-0000aI-Jj; Mon, 10 Apr 2006 07:14:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSuLy-0000aD-Ra for lemonade@ietf.org; Mon, 10 Apr 2006 07:14:42 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSuLw-0004Vp-SH for lemonade@ietf.org; Mon, 10 Apr 2006 07:14:42 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Mon, 10 Apr 2006 12:14:15 +0100 Message-ID: <443838A3.9070303@isode.com> Date: Sat, 08 Apr 2006 23:26:43 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Crispin Subject: Re: [lemonade] responses to GENURLAUTH in URLAUTH References: <173001c65752$1b5f8f20$d3219681@Tundra> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: support diverse service enivronments' , Peter Coates , 'Enhancements X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Mark Crispin wrote: > On Mon, 3 Apr 2006, Peter Coates wrote: > >> There is nothing to stop a message being deleted and expunged in >> some other session unbeknownst to the poor client. > > Yes there is. > > Until the expunge is announced with an untagged EXPUNGE response, the > message still exists as far as the server is concerned; and an > untagged EXPUNGE in turn can't be sent except at certain > well-documented points in the session. This only works if the client that requested generation of URLAUTH URLs is the same client as the one who is using URLFETCH. (And even this might not work for offline clients) This is not the case for BURL capable submission server retrieving messages using URLAUTH URLs. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Apr 10 08:34:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSvam-0007DC-9I; Mon, 10 Apr 2006 08:34:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSval-0007D2-7K for lemonade@ietf.org; Mon, 10 Apr 2006 08:34:03 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSvaj-0007l8-Oq for lemonade@ietf.org; Mon, 10 Apr 2006 08:34:03 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Mon, 10 Apr 2006 13:33:57 +0100 Message-ID: <443A50B2.9090800@isode.com> Date: Mon, 10 Apr 2006 13:33:54 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: lemonade@ietf.org Subject: Re: [lemonade] responses to GENURLAUTH in URLAUTH References: <173001c65752$1b5f8f20$d3219681@Tundra> <443838A3.9070303@isode.com> In-Reply-To: <443838A3.9070303@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Alexey Melnikov wrote: > Mark Crispin wrote: > >> On Mon, 3 Apr 2006, Peter Coates wrote: >> >>> There is nothing to stop a message being deleted and expunged in >>> some other session unbeknownst to the poor client. >> >> Yes there is. >> >> Until the expunge is announced with an untagged EXPUNGE response, the >> message still exists as far as the server is concerned; and an >> untagged EXPUNGE in turn can't be sent except at certain >> well-documented points in the session. > > This only works if the client that requested generation of URLAUTH > URLs is the same client as the one who is using URLFETCH. (And even > this might not work for offline clients) > This is not the case for BURL capable submission server retrieving > messages using URLAUTH URLs. Never mind, I was thinking about URLFETCH. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Apr 10 10:02:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSwym-000067-AS; Mon, 10 Apr 2006 10:02:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSwyk-000062-Lh for lemonade@ietf.org; Mon, 10 Apr 2006 10:02:54 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSwyk-0002ez-9y for lemonade@ietf.org; Mon, 10 Apr 2006 10:02:54 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k3AE2pX29735 for ; Mon, 10 Apr 2006 10:02:51 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [lemonade] Trio in AUTH48 Date: Mon, 10 Apr 2006 10:00:52 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D097C606D@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Trio in AUTH48 Thread-Index: AcZYTDd/FwsNquPjTIOUM3OdGHgFWQEWegUw From: "Glenn Parsons" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b X-BeenThere: lemonade@ietf.org X-Mailman-Version: 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="===============1654713826==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============1654713826== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65CA7.5B73D4D6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65CA7.5B73D4D6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, =20 I sense the group closing in on option 2. =20 So to confirm this, Mark could you summarize the revised list of proposed AUTH48 changes to URLAUTH? =20 Thanks, Glenn. =20 ________________________________ From: Parsons, Glenn [CAR:1A14:EXCH]=20 Sent: Tuesday, April 04, 2006 9:00 PM To: lemonade@ietf.org Subject: [lemonade] Trio in AUTH48 Folks,=20 The trio is now in AUTH48 ... but I sense there is an issue with the ABNF that we probably need some consensus on...=20 The options as I see it are:=20 1. Stop AUTH48. Include RFC2192bis as a mandatory reference. Get IESG re-approval and then resume AUTH48. But what changes will we add? Will we include partial support now? We need concrete text proposals if we want to do this... 2. Make the 'bug fix' changes Mark has proposed earlier today (with tweaks as appropriate)=20 3. Change nothing. It doesn't matter since we will fix all this in RFC2192bis and Profile-bis=20 What do folks think?=20 Cheers,=20 Glenn.=20 ------_=_NextPart_001_01C65CA7.5B73D4D6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Trio in AUTH48
Folks,
 
I sense the group closing in on option=20 2.
 
So to confirm this, Mark could you summarize = the=20 revised list of proposed AUTH48 changes to URLAUTH?
 
Thanks,
Glenn.
 

From: Parsons, Glenn [CAR:1A14:EXCH] =
Sent: Tuesday, April 04, 2006 9:00 PM
To:=20 lemonade@ietf.org
Subject: [lemonade] Trio in=20 AUTH48

Folks,

The trio is now in AUTH48 … but I = sense there is an=20 issue with the ABNF that we probably need some consensus = on…

The options as I see it are:

1. Stop AUTH48.  Include RFC2192bis = as a=20 mandatory reference.  Get IESG re-approval and then resume = AUTH48. =20 But what changes will we add?  Will we include partial support = now? =20 We need concrete text proposals if we want to do this...

2.  Make the 'bug fix' changes Mark = has proposed=20 earlier today (with tweaks as appropriate)

3.  Change nothing.  It doesn't = matter=20 since we will fix all this in RFC2192bis and Profile-bis

What do folks think?

Cheers,
Glenn.

------_=_NextPart_001_01C65CA7.5B73D4D6-- --===============1654713826== 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 --===============1654713826==-- From lemonade-bounces@ietf.org Mon Apr 10 20:05:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT6O6-0006Ct-8v; Mon, 10 Apr 2006 20:05:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT6O5-0006Co-9l for lemonade@ietf.org; Mon, 10 Apr 2006 20:05:41 -0400 Received: from mxout3.cac.washington.edu ([140.142.32.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT6O3-0003gP-VZ for lemonade@ietf.org; Mon, 10 Apr 2006 20:05:41 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout3.cac.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k3B05cFl000738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Apr 2006 17:05:39 -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.6+UW06.03/8.13.5+UW06.03) with ESMTP id k3B05cml005120 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 10 Apr 2006 17:05:38 -0700 Date: Mon, 10 Apr 2006 17:03:36 -0700 (Pacific Daylight Time) From: Mark Crispin To: Peter Coates Subject: Re: [lemonade] problems implementing RESETKEY GENURLAUTH and URLFETCH In-Reply-To: <000701c65a5b$a818f710$6501a8c0@Tundra> Message-ID: References: <000701c65a5b$a818f710$6501a8c0@Tundra> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hello Peter. I am confused by your messages. Is the client expected to access the other servers (that is, does your server issue referrals)? If your server does not issue referrals, then from the user's (and client's) point of view there is just one server. What happens internally in your server farm is not a concern of the user, the client, or the protocol. I think that the ability to forward multiple messages, from perhaps multiple sources, is a benefit. I would like to hear a better argument for removing this capability than "it inconveniences one server implementation's way of distributing mailboxes across different servers." -- 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 Apr 10 20:19:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT6bU-0002px-VA; Mon, 10 Apr 2006 20:19:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT6bT-0002ps-TE for lemonade@ietf.org; Mon, 10 Apr 2006 20:19:31 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT6bS-00045l-AD for lemonade@ietf.org; Mon, 10 Apr 2006 20:19:31 -0400 Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k3B0JSmU004452 for ; Mon, 10 Apr 2006 18:19:29 -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 <0IXJ002017K1YI00@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Mon, 10 Apr 2006 18:19:27 -0600 (MDT) Received: from Tundra ([129.150.34.31]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IXJ005RV7KDNI85@mail-amer.sun.com>; Mon, 10 Apr 2006 18:19:27 -0600 (MDT) Date: Mon, 10 Apr 2006 17:19:25 -0700 From: Peter Coates Subject: RE: [lemonade] problems implementing RESETKEY GENURLAUTH and URLFETCH In-reply-to: To: "'Mark Crispin'" Message-id: <000101c65cfd$97e29cd0$1f229681@Tundra> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcZc+6+kJ2OtCO6LQ/aym8gMyKulNgAAJVfw X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Our server spreads users over multiple back ends, and if joe shares any of his folders with sue, then the server sue is directed to will have to proxy some requests to joe's machine. This is an entirely reasonable approach. This can be made to work reasonably with all IMAP commands to date, and resetkey, and urlfetch can also be made to work. Genurlauth is nastier because it works in two phases, a validation phase and an operation phase. For the internal mechanism it can be made to work by proxying the commands across during the validation phase and holding the results until the operational phase. This is OK because the internal mechanism has no side effects. But it is very ugly. It is not clear to me what is actually gained by clients by being able to collect together in one command a set of URLs that are only slightly related. You would not expect the command 1 URLFETCH imap://joe@xyz.com/inbox/;uid=10... Imap:/fred@abc.com/inbox/;uid=42... To return anything really useful. Why is it so imperative that 1 URLFETCH imap://joe@xyz.com/inbox/;uid=10... Imap:/fred@xyz.com/inbox/;uid=42... Work? And similarly for genurlauth Peter -----Original Message----- From: mrc@ndcms.cac.washington.edu [mailto:mrc@ndcms.cac.washington.edu] On Behalf Of Mark Crispin Sent: April 10, 2006 17:04 To: Peter Coates Cc: lemonade@ietf.org Subject: Re: [lemonade] problems implementing RESETKEY GENURLAUTH and URLFETCH Hello Peter. I am confused by your messages. Is the client expected to access the other servers (that is, does your server issue referrals)? If your server does not issue referrals, then from the user's (and client's) point of view there is just one server. What happens internally in your server farm is not a concern of the user, the client, or the protocol. I think that the ability to forward multiple messages, from perhaps multiple sources, is a benefit. I would like to hear a better argument for removing this capability than "it inconveniences one server implementation's way of distributing mailboxes across different servers." -- 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 Apr 10 20:30:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT6li-0006fU-H6; Mon, 10 Apr 2006 20:30:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT6lh-0006fP-Uf for lemonade@ietf.org; Mon, 10 Apr 2006 20:30:05 -0400 Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT6lg-0004N3-Jf for lemonade@ietf.org; Mon, 10 Apr 2006 20:30:05 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout2.cac.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k3B0U3jb026273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Apr 2006 17:30:03 -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.6+UW06.03/8.13.5+UW06.03) with ESMTP id k3B0U3aW008607 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 10 Apr 2006 17:30:03 -0700 Date: Mon, 10 Apr 2006 17:28:00 -0700 (Pacific Daylight Time) From: Mark Crispin To: Peter Coates Subject: RE: [lemonade] problems implementing RESETKEY GENURLAUTH and URLFETCH In-Reply-To: <000101c65cfd$97e29cd0$1f229681@Tundra> Message-ID: References: <000101c65cfd$97e29cd0$1f229681@Tundra> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Mon, 10 Apr 2006, Peter Coates wrote: > Our server spreads users over multiple back ends, and if joe shares any of > his folders with sue, then the server sue is directed to will have to proxy > some requests to joe's machine. This is an entirely reasonable approach. And thus IMAP has a mechanism, called "referrals", to support this. You seem to have chosen not to use referrals. > You would not expect the command > > 1 URLFETCH imap://joe@xyz.com/inbox/;uid=10... > Imap:/fred@abc.com/inbox/;uid=42... > > To return anything really useful. That's because the domain identified in the URL is the domain of the IMAP server. Thus it can not work unless xyz.com and abc.com are nicknames for the same machine. > Why is it so imperative that > > 1 URLFETCH imap://joe@xyz.com/inbox/;uid=10... > Imap:/fred@xyz.com/inbox/;uid=42... > > Work? That's the wrong question. Why shouldn't it work? How does that differ from 1 URLFETCH imap://joe@xyz.com/inbox/;uid=10... imap:/joe@xyz.com/vacation/;uid=42... Why shouldn't that be allowed? > And similarly for genurlauth If my client needs multiple URLs generated, why should it have to go through multiple RTTs to do it? -- 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 Apr 10 21:10:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT7P3-0003ML-4N; Mon, 10 Apr 2006 21:10:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT7P1-0003LP-49 for lemonade@ietf.org; Mon, 10 Apr 2006 21:10:43 -0400 Received: from ppsw-9.csi.cam.ac.uk ([131.111.8.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT7Oz-0007FK-RD for lemonade@ietf.org; Mon, 10 Apr 2006 21:10:43 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:53343) by ppsw-9.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1FT7Os-0001Z0-Tf (Exim 4.54) (return-path ); Tue, 11 Apr 2006 02:10:34 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1FT7Os-00039H-59 (Exim 4.53) (return-path ); Tue, 11 Apr 2006 02:10:34 +0100 Date: Tue, 11 Apr 2006 02:10:34 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Mark Crispin Subject: RE: [lemonade] problems implementing RESETKEY GENURLAUTH and URLFETCH In-Reply-To: Message-ID: References: <000101c65cfd$97e29cd0$1f229681@Tundra> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.2 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: lemonade@ietf.org, Peter Coates X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Mon, 10 Apr 2006, Mark Crispin wrote: > On Mon, 10 Apr 2006, Peter Coates wrote: > > > > Our server spreads users over multiple back ends, and if joe shares any of > > his folders with sue, then the server sue is directed to will have to proxy > > some requests to joe's machine. This is an entirely reasonable approach. > > And thus IMAP has a mechanism, called "referrals", to support this. You seem > to have chosen not to use referrals. That seems to be a common design choice - cf. the Cyrus Murder and the Perdition proxy. Tony. -- f.a.n.finch http://dotat.at/ BERWICK ON TWEED TO WHITBY: WEST OR SOUTHWEST 5 OR 6, PERHAPS INCREASING 7 LATER IN NORTH. RAIN AT FIRST. MAINLY GOOD. SLIGHT OR MODERATE. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Apr 10 21:28:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT7fx-0003wb-QE; Mon, 10 Apr 2006 21:28:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT7fv-0003wV-C7 for lemonade@ietf.org; Mon, 10 Apr 2006 21:28:11 -0400 Received: from smtp.andrew.cmu.edu ([128.2.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT7fu-0000BD-3U for lemonade@ietf.org; Mon, 10 Apr 2006 21:28:11 -0400 Received: from [192.168.137.22] (69-171-17-197.kntnny.adelphia.net [69.171.17.197]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.5/8.13.6) with ESMTP id k3B1S3U6011302 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 10 Apr 2006 21:28:04 -0400 Message-ID: <443B0621.6010800@andrew.cmu.edu> Date: Mon, 10 Apr 2006 21:28:01 -0400 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Thunderbird 1.5 (X11/20060313) MIME-Version: 1.0 To: Tony Finch Subject: Re: [lemonade] problems implementing RESETKEY GENURLAUTH and URLFETCH References: <000101c65cfd$97e29cd0$1f229681@Tundra> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: lemonade@ietf.org, Mark Crispin , Peter Coates X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Tony Finch wrote: > On Mon, 10 Apr 2006, Mark Crispin wrote: >> On Mon, 10 Apr 2006, Peter Coates wrote: >>> Our server spreads users over multiple back ends, and if joe shares any of >>> his folders with sue, then the server sue is directed to will have to proxy >>> some requests to joe's machine. This is an entirely reasonable approach. >> And thus IMAP has a mechanism, called "referrals", to support this. You seem >> to have chosen not to use referrals. > > That seems to be a common design choice - cf. the Cyrus Murder and the > Perdition proxy. Cyrus Murder will issue referrals iff the client has shown that it can handle them (it sends either an RLIST or RLSUB) Do any clients other than Pine support mailbox referrals? -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Apr 10 21:58:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT89N-0006wY-IP; Mon, 10 Apr 2006 21:58:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT89M-0006wO-GV for lemonade@ietf.org; Mon, 10 Apr 2006 21:58:36 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT89E-0000mw-MC for lemonade@ietf.org; Mon, 10 Apr 2006 21:58:36 -0400 Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k3B1wRmU029395 for ; Mon, 10 Apr 2006 19:58:28 -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 <0IXJ00601C2AF900@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Mon, 10 Apr 2006 19:58:27 -0600 (MDT) Received: from Tundra ([199.247.232.254]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IXJ008O5C5B2RE3@mail-amer.sun.com>; Mon, 10 Apr 2006 19:58:26 -0600 (MDT) Date: Mon, 10 Apr 2006 18:58:23 -0700 From: Peter Coates Subject: RE: [lemonade] problems implementing RESETKEY GENURLAUTH and URLFETCH In-reply-to: <443B0621.6010800@andrew.cmu.edu> To: "'Ken Murchison'" , "'Tony Finch'" Message-id: <000201c65d0b$6bb427b0$1f229681@Tundra> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcZdBzarn2zai80TSnGpXIQJEzuM5gAA54wg X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: lemonade@ietf.org, 'Mark Crispin' X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org If we used referrals, the story with GENURLAUTH and URLFETCH would be worse. These are commands that are not open to being referred. They have to be proxied piecemeal. The discussion here is leading me to believe that there is a problem with the design of these commands. Bit of a shame that as I have done the (seriously ugly) work to do this proxying. On the other hand, the cost of a GENURLAUTH command with multiple URLs which happen to be hosted on multiple hosts is potentially much higher than a client would expect. That is the sort of surprise that ought not to be. Peter -----Original Message----- From: Ken Murchison [mailto:murch@andrew.cmu.edu] Sent: April 10, 2006 18:28 To: Tony Finch Cc: Mark Crispin; lemonade@ietf.org; Peter Coates Subject: Re: [lemonade] problems implementing RESETKEY GENURLAUTH and URLFETCH Tony Finch wrote: > On Mon, 10 Apr 2006, Mark Crispin wrote: >> On Mon, 10 Apr 2006, Peter Coates wrote: >>> Our server spreads users over multiple back ends, and if joe shares >>> any of his folders with sue, then the server sue is directed to will >>> have to proxy some requests to joe's machine. This is an entirely reasonable approach. >> And thus IMAP has a mechanism, called "referrals", to support this. >> You seem to have chosen not to use referrals. > > That seems to be a common design choice - cf. the Cyrus Murder and the > Perdition proxy. Cyrus Murder will issue referrals iff the client has shown that it can handle them (it sends either an RLIST or RLSUB) Do any clients other than Pine support mailbox referrals? -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Apr 11 03:53:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTDgr-0008CS-6C; Tue, 11 Apr 2006 03:53:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTDgp-0008Ba-L7 for lemonade@ietf.org; Tue, 11 Apr 2006 03:53:31 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTDgo-0005Ep-83 for lemonade@ietf.org; Tue, 11 Apr 2006 03:53:31 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.34) id 1FTDgm-0003KI-Q0; Tue, 11 Apr 2006 07:53:29 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id E2C33498003; Tue, 11 Apr 2006 09:00:15 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03823-04; Tue, 11 Apr 2006 09:00:11 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id E484D498002; Tue, 11 Apr 2006 09:00:09 +0100 (BST) Date: Tue, 11 Apr 2006 08:53:21 +0100 References: <000101c65cfd$97e29cd0$1f229681@Tundra> <443B0621.6010800@andrew.cmu.edu> In-Reply-To: <443B0621.6010800@andrew.cmu.edu> MIME-Version: 1.0 Message-Id: <21242.1144742002.293406@peirce.dave.cridland.net> From: Dave Cridland To: Ken Murchison Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Rutherford-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Enhancements to Internet email to support diverse service enivronments Subject: [lemonade] MAILBOX-REFERRALS support. X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue Apr 11 02:28:01 2006, Ken Murchison wrote: > Tony Finch wrote: >> On Mon, 10 Apr 2006, Mark Crispin wrote: >>> On Mon, 10 Apr 2006, Peter Coates wrote: >>>> Our server spreads users over multiple back ends, and if joe >>>> shares any of >>>> his folders with sue, then the server sue is directed to will >>>> have to proxy >>>> some requests to joe's machine. This is an entirely reasonable >>>> approach. >>> And thus IMAP has a mechanism, called "referrals", to support >>> this. You seem >>> to have chosen not to use referrals. >> >> That seems to be a common design choice - cf. the Cyrus Murder and >> the >> Perdition proxy. > > Cyrus Murder will issue referrals iff the client has shown that it > can handle them (it sends either an RLIST or RLSUB) > > Or a LIST (REMOTE) - if the client supports LISTEXT, which mine does. > Do any clients other than Pine support mailbox referrals? Yes, Polymer does, although I've only tested this against the public Cyrus IMAP Murder. I'm very tempted, however, to remove the support, or at least make it off by default, because: a) The latency increase is huge - remote mailboxes cause an appreciable delay in the client due to having to setup a new IMAP connection - in addition, you lose state if you're referred by a SELECT, although CONDSTORE helps with this. b) The complexity issues are huge, since there's a sudden distinction between the server a URL points to and the actual connection that needs to be made. For a client (like mine) that uses URLs intensively, this is a bit of a pain, especially when I need to persist URLs (for instance, as bookmarks. Stored in ACAP of course). c) It's impossible to copy messages between folders without downloading, and re-uploading them. I strongly suspect that whilst referrals are good protocol design, this is an area where practical concerns rule in favour of the proxy design - not only can you immediately support more clients, but various complexities vanish. 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 Apr 11 09:53:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTJJ0-00069O-FX; Tue, 11 Apr 2006 09:53:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTJIz-00068R-4R for lemonade@ietf.org; Tue, 11 Apr 2006 09:53:17 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTJIy-0002ad-RD for lemonade@ietf.org; Tue, 11 Apr 2006 09:53:17 -0400 X-IronPort-AV: i="4.04,112,1144036800"; d="scan'208"; a="31245903:sNHT63009032" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] problems implementing RESETKEY GENURLAUTH and URLFETCH Date: Tue, 11 Apr 2006 09:53:15 -0400 Message-ID: <330A23D8336C0346B5C1A5BB19666647029F6061@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] problems implementing RESETKEY GENURLAUTH and URLFETCH Thread-Index: AcZdBzarn2zai80TSnGpXIQJEzuM5gAA54wgABkZPlA= From: "Burger, Eric" To: "Peter Coates" X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Live by the Proxy, Die by the Proxy. -----Original Message----- From: Peter Coates [mailto:peter.coates@sun.com]=20 Sent: Monday, April 10, 2006 9:58 PM To: 'Ken Murchison'; 'Tony Finch' Cc: lemonade@ietf.org; 'Mark Crispin' Subject: RE: [lemonade] problems implementing RESETKEY GENURLAUTH and URLFETCH If we used referrals, the story with GENURLAUTH and URLFETCH would be worse. These are commands that are not open to being referred. They have to be proxied piecemeal. The discussion here is leading me to believe that there is a problem with the design of these commands. Bit of a shame that as I have done the (seriously ugly) work to do this proxying. On the other hand, the cost of a GENURLAUTH command with multiple URLs which happen to be hosted on multiple hosts is potentially much higher than a client would expect. That is the sort of surprise that ought not to be. Peter=20 -----Original Message----- From: Ken Murchison [mailto:murch@andrew.cmu.edu]=20 Sent: April 10, 2006 18:28 To: Tony Finch Cc: Mark Crispin; lemonade@ietf.org; Peter Coates Subject: Re: [lemonade] problems implementing RESETKEY GENURLAUTH and URLFETCH Tony Finch wrote: > On Mon, 10 Apr 2006, Mark Crispin wrote: >> On Mon, 10 Apr 2006, Peter Coates wrote: >>> Our server spreads users over multiple back ends, and if joe shares=20 >>> any of his folders with sue, then the server sue is directed to will >>> have to proxy some requests to joe's machine. This is an entirely reasonable approach. >> And thus IMAP has a mechanism, called "referrals", to support this. =20 >> You seem to have chosen not to use referrals. >=20 > That seems to be a common design choice - cf. the Cyrus Murder and the > Perdition proxy. Cyrus Murder will issue referrals iff the client has shown that it can handle them (it sends either an RLIST or RLSUB) Do any clients other than Pine support mailbox referrals? -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University _______________________________________________ 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 Apr 11 11:29:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTKoT-000551-Ky; Tue, 11 Apr 2006 11:29:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTKoS-00052S-Fv for lemonade@ietf.org; Tue, 11 Apr 2006 11:29:52 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTKoO-0006Dv-3F for lemonade@ietf.org; Tue, 11 Apr 2006 11:29:52 -0400 X-IronPort-AV: i="4.04,112,1144036800"; d="scan'208"; a="31248256:sNHT44963076" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversions) Date: Tue, 11 Apr 2006 11:29:47 -0400 Message-ID: <330A23D8336C0346B5C1A5BB19666647029F61F0@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversions) Thread-Index: AcZQZrrZLsKgPGpUReWpv+T2d4feXQNE/JXw From: "Burger, Eric" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Just to bring this to closure (as chair): We definitely need a mechanism for object transcoding. That is in the charter and required by the voice messaging and mobile markets. Said differently, the work group consensus is there is a need for such a protocol mechanism. When we looked at the "minimum set of transcoding facilities" in order to prove interoperability, we ran in to the VPIM problem squared. For review, the VPIM problem was that just about all interesting voice codecs have some kind of IPR issues attached. We ended up selecting G.726, since the patents expired (!). The problem is that G.726 is a lousy codec (lots of MIPS for very little compression) and just about no one implemented it. The "squared" problem is that unlike VPIM, where everyone was building a voice messaging system, LEMONADE is addressing disparate markets. What is interesting to the voice messaging folks, namely codec transcoding, is of little interest to mobile folks, namely compressing/adapting (read "downgrading") static content. Moreover, compressing static content is not of interest to the unified messaging folks. Thus we looked for a transcoding operation that (1) would exercise the transcoding mechanism, including the myriad transcoding parameters and (2) would be generally useful to most or all of the target markets for LEMONADE. The solution we came up with is HTML to text. This transformation is generally useful for the unified messaging and mobile markets. It is not quite as useful for the voice messaging folks, but it is simple enough to implement that it should not be a burden. SPEAK NOW OR FOREVER HOLD YOUR PEACE: If you DISAGREE with this position, respond to the list by 29 April 2006 with: (1) Your Objection (2) Justification for the Objection (3) Concrete proposal that meets the constraints. Thanks. -----Original Message----- From: Ned Freed [mailto:ned.freed@mrochek.com]=20 Sent: Saturday, March 25, 2006 6:30 PM To: Keith Moore Cc: Enhancements to Internet email to support diverse service enivronments; Ned Freed Subject: Re: [lemonade] on MTI conversions > yes, but the point is that demonstrating interoperability is a separate > issue from MTI. That depends on what sort of interoperability you're talking about. Let's please remember that this is the LEMONADE group, with some fairly specific goals for support of some fairly specific sorts of clients. The conversion facility isn't being developed because server-side conversion is something we all lust after, but rather because specific sorts of conversions are needed by some limited-capability clients. Having said that, I think there's a conundrum lurking in all this, which is that for various reasons (IPR concerns being the most obvious) it may not be possible to specify the full set of MTI conversions a LEMONADE client actually needs. As I pointed out at the meeting, this gets very close to the same set of issues that had VPIM all wrapped around the axle for some time. To put this another way, I would be willing to accept a toy MTI conversion despite my serious misgivings if it can be shown that the set of conversions generally useful to a LEMONADE client and which we are able to mandate in an IETF specification is empty. But I don't think that's the case: The obvious counterexample is the HTML to text the WG settled on. > the purpose of demonstrating interoperability of a feature is to > validate the specification - if two implementations of the same spec > interoperate, this provides a sanity check of the spec. But this begs the question of what should be in the specification to meet our WG requirements. > of course if other profiles want to define other MTI conversions before > compliance can be claimed with those profiles, that's fine. but I got > the strong impression that a lot of time was being wasted in the meeting > trying to figure out which marginally useful conversion all Lemonade > servers have to implement for no other purpose than to satisfy a > misunderstanding of IESG MTI criteria. I believe this impression is not only incorrect, it is actually backwards. The slide initially showed a fairly significant list of MTI conversions. It was argued that some aren't needed by all clients and others are encumbered in various ways. This brought the list down to HTML to text, but with the caveat that the others will probably still be mandated by some OMA spec or other. It was then argued that the one remaining isn't generally useful, but I didn't see a lot of people buying into the argument. The need for one MTI was only raised as an afterthought. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Apr 11 11:31:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTKqN-0005dw-3g; Tue, 11 Apr 2006 11:31:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTKqL-0005dr-EG for lemonade@ietf.org; Tue, 11 Apr 2006 11:31:49 -0400 Received: from mxout3.cac.washington.edu ([140.142.32.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTKqK-0006L0-48 for lemonade@ietf.org; Tue, 11 Apr 2006 11:31:49 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout3.cac.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k3BFVjQ2025618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Apr 2006 08:31:45 -0700 X-Auth-Received: from Shimo-Tomobiki.panda.com (panda.com [206.124.149.114]) (authenticated authid=mrc) by smtp.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k3BFVe0D026183 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 11 Apr 2006 08:31:44 -0700 Date: Tue, 11 Apr 2006 08:31:36 -0700 From: Mark Crispin To: Dave Cridland Subject: Re: [lemonade] MAILBOX-REFERRALS support. In-Reply-To: <21242.1144742002.293406@peirce.dave.cridland.net> Message-ID: References: <000101c65cfd$97e29cd0$1f229681@Tundra> <443B0621.6010800@andrew.cmu.edu> <21242.1144742002.293406@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='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __FRAUD_419_BADTHINGS 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue, 11 Apr 2006, Dave Cridland wrote: > Yes, Polymer does, although I've only tested this against the public Cyrus > IMAP Murder. I'm very tempted, however, to remove the support, or at least > make it off by default Note though that there are two types of referrals; a referral which takes place even though the server will proxy, and one that takes place when the server will give an error. Of course, the latter happens most often with login referrals. -- 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 Apr 11 11:31:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTKqQ-0005h5-8x; Tue, 11 Apr 2006 11:31:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTKqP-0005f2-3u for lemonade@ietf.org; Tue, 11 Apr 2006 11:31:53 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTKqO-0006L6-TM for lemonade@ietf.org; Tue, 11 Apr 2006 11:31:53 -0400 X-IronPort-AV: i="4.04,112,1144036800"; d="scan'208"; a="31248289:sNHT41511152" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] URLAUTH edits to be made during AUTH48 Date: Tue, 11 Apr 2006 11:31:52 -0400 Message-ID: <330A23D8336C0346B5C1A5BB19666647029F61FA@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] URLAUTH edits to be made during AUTH48 Thread-Index: AcZZZZ5MBNTzmXUVS2mbse+Kmc309wEF2QJQ From: "Burger, Eric" To: "Alexey Melnikov" , "Cyrus Daboo" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: lemonade@ietf.org, Mark Crispin X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org As chair: Make it So (AUTH48 edit) -----Original Message----- From: Alexey Melnikov [mailto:alexey.melnikov@isode.com]=20 Sent: Thursday, April 06, 2006 6:29 AM To: Cyrus Daboo Cc: lemonade@ietf.org; Mark Crispin Subject: Re: [lemonade] URLAUTH edits to be made during AUTH48 Cyrus Daboo wrote: > Hi Alexey, > > --On April 5, 2006 11:06:41 AM +0100 Alexey Melnikov=20 > wrote: > >>>>>> authimapurl =3D "imap://" enc-user "@" hostport "/" imessagepart >>>>>> ; replaces "imapurl" and "iserver" rules for >>>>>> URLAUTH >>>>>> ; authorized URLs >>>>> >>>> You should still use iuserauth above, as something like >>>> "joe;auth=3Ddigest-md5" would be allowed here. >>> >>> I'm not sure that I understand. Is ;AUTH=3D allowed with no userid? >> >> Yes. You want to prohibit it for URLAUTH URLs only. > > So the following would work then: > > authimapurl =3D "imap://" enc-user [iauth] "@" hostport "/"=20 > imessagepart > ; replaces "imapurl" and "iserver" rules for URLAUTH > ; authorized URLs Yes, this would work. _______________________________________________ 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 Apr 11 15:45:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTOnf-00033x-SU; Tue, 11 Apr 2006 15:45:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTOne-00033r-HQ for lemonade@ietf.org; Tue, 11 Apr 2006 15:45:18 -0400 Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTOnd-00079J-6u for lemonade@ietf.org; Tue, 11 Apr 2006 15:45:18 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout2.cac.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k3BJj83a013850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Apr 2006 12:45:08 -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.6+UW06.03/8.13.6+UW06.03) with ESMTP id k3BJj7N4009148 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 11 Apr 2006 12:45:08 -0700 Date: Tue, 11 Apr 2006 12:45:06 -0700 (Pacific Daylight Time) From: Mark Crispin To: "Burger, Eric" Subject: RE: [lemonade] URLAUTH edits to be made during AUTH48 In-Reply-To: <330A23D8336C0346B5C1A5BB19666647029F61FA@ATLANTIS.Brooktrout.com> Message-ID: References: <330A23D8336C0346B5C1A5BB19666647029F61FA@ATLANTIS.Brooktrout.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='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Cyrus Daboo , Alexey Melnikov , lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue, 11 Apr 2006, Burger, Eric wrote: > As chair: Make it So (AUTH48 edit) I request a clarification. Are you, as chair, instructing me to go ahead and make the authimapurl = "imap://" enc-user [iauth] "@" hostport "/" imessagepart ; replaces "imapurl" and "iserver" rules for URLAUTH ; authorized URLs edit (which I had intended to do as the obvious solution before all this foofaraw erupted) as well as adding the requested text about how URLFETCH effectively executes with the access of the user who issued the GENURLAUTH? Or are you just stating your opinion and putting the weight of being chair behind that opinion? Put another way, shall I schedule time to work on reviewing the RFC Editor's work, installing the changes, and posting the diffs? Or should I wait for Ted to say something? -- 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 Apr 11 16:35:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTPa6-0001Qu-7l; Tue, 11 Apr 2006 16:35:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTPa5-0001Qp-6S for lemonade@ietf.org; Tue, 11 Apr 2006 16:35:21 -0400 Received: from mxout3.cac.washington.edu ([140.142.32.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTPa3-0001pZ-Rp for lemonade@ietf.org; Tue, 11 Apr 2006 16:35:21 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout3.cac.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k3BKZERL004644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Apr 2006 13:35:14 -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.6+UW06.03/8.13.5+UW06.03) with ESMTP id k3BKZDCr014945 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 11 Apr 2006 13:35:13 -0700 Date: Tue, 11 Apr 2006 13:35:13 -0700 (Pacific Daylight Time) From: Mark Crispin To: "Burger, Eric" Subject: RE: [lemonade] problems implementing RESETKEY GENURLAUTH and URLFETCH In-Reply-To: <330A23D8336C0346B5C1A5BB19666647029F6061@ATLANTIS.Brooktrout.com> Message-ID: References: <330A23D8336C0346B5C1A5BB19666647029F6061@ATLANTIS.Brooktrout.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='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue, 11 Apr 2006, Burger, Eric wrote: > Live by the Proxy, Die by the Proxy. There ought to be a koan on that line of thought, to be recited every time someone says "a proxy is easy, just tie together client code and server code." :-) -- 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 Apr 11 17:13:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTQAj-00039U-O4; Tue, 11 Apr 2006 17:13:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTQAi-00039K-GL for lemonade@ietf.org; Tue, 11 Apr 2006 17:13:12 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTQAh-0003T6-6X for lemonade@ietf.org; Tue, 11 Apr 2006 17:13:12 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3BLD8j9004438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 11 Apr 2006 14:13:09 -0700 Received: from [192.168.1.13] (loud.qualcomm.com [129.46.172.15]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3BLD0ZY027441; Tue, 11 Apr 2006 14:13:06 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <000101c65cfd$97e29cd0$1f229681@Tundra> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Tue, 11 Apr 2006 14:09:50 -0700 To: Mark Crispin , Peter Coates From: Randall Gellens Subject: RE: [lemonade] problems implementing RESETKEY GENURLAUTH and URLFETCH Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 5:28 PM -0700 4/10/06, Mark Crispin wrote: > If my client needs multiple URLs generated, why should it have to > go through multiple RTTs to do it? Separating each URL into its own command requires a round-trip for each because the URLAUTH response is untagged? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- It is much easier to suggest solutions when you know nothing about the problem. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Apr 11 17:16:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTQEM-0003J5-J5; Tue, 11 Apr 2006 17:16:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTQEL-0003J0-DR for lemonade@ietf.org; Tue, 11 Apr 2006 17:16:57 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTQEL-0003Wz-3q for lemonade@ietf.org; Tue, 11 Apr 2006 17:16:57 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3BLGpYc004804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 11 Apr 2006 14:16:52 -0700 Received: from [192.168.1.13] (loud.qualcomm.com [129.46.172.15]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3BLGm2E028966; Tue, 11 Apr 2006 14:16:51 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <330A23D8336C0346B5C1A5BB19666647029F61F0@ATLANTIS.Brooktrout.com> References: <330A23D8336C0346B5C1A5BB19666647029F61F0@ATLANTIS.Brooktrout.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Tue, 11 Apr 2006 14:15:09 -0700 To: "Burger, Eric" , From: Randall Gellens Subject: Re: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversions) 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: cf4fa59384e76e63313391b70cd0dd25 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 11:29 AM -0400 4/11/06, Eric Burger wrote: > What > is interesting to the voice messaging folks, namely codec transcoding, > is of little interest to mobile folks Just as an aside, I'm not sure this is the case. I can imagine that codec transcoding could be helpful to mobile email clients on handsets. This is strictly a parenthetical observation -- I am not disagreeing with your email. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- There's nothing wrong with me. Maybe there's something wrong with the universe. --'Dr. Beverly Crusher' in ST:TNG _Remember Me_. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Apr 11 18:20:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTRE3-0006er-Kb; Tue, 11 Apr 2006 18:20:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTRE2-0006em-En for lemonade@ietf.org; Tue, 11 Apr 2006 18:20:42 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTRE2-0006Uk-1O for lemonade@ietf.org; Tue, 11 Apr 2006 18:20:42 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.34) id 1FTRE0-0000x0-Oy; Tue, 11 Apr 2006 22:20:40 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 1F712498002; Tue, 11 Apr 2006 23:27:34 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07622-09; Tue, 11 Apr 2006 23:27:29 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 082ED498003; Tue, 11 Apr 2006 23:27:27 +0100 (BST) Date: Tue, 11 Apr 2006 23:20:32 +0100 Subject: Re: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversions) References: <330A23D8336C0346B5C1A5BB19666647029F61F0@ATLANTIS.Brooktrout.com> In-Reply-To: <330A23D8336C0346B5C1A5BB19666647029F61F0@ATLANTIS.Brooktrout.com> MIME-Version: 1.0 Message-Id: <9875.1144794033.255616@peirce.dave.cridland.net> From: Dave Cridland To: "Burger\, Eric" Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Rutherford-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue Apr 11 16:29:47 2006, Burger, Eric wrote: > The "squared" problem is that unlike VPIM, where everyone was > building a > voice messaging system, LEMONADE is addressing disparate markets. > What > is interesting to the voice messaging folks, namely codec > transcoding, > is of little interest to mobile folks, namely compressing/adapting > (read > "downgrading") static content. Moreover, compressing static > content is > not of interest to the unified messaging folks. > > I'm not entirely sure that's true. Mobile folk have limited sound codecs available, as Randy points out, and desktop folk on constrained bandwidth might want to use different codecs for content preview. > Thus we looked for a transcoding operation that (1) would exercise > the > transcoding mechanism, including the myriad transcoding parameters > and > (2) would be generally useful to most or all of the target markets > for > LEMONADE. The solution we came up with is HTML to text. This > transformation is generally useful for the unified messaging and > mobile > markets. It is not quite as useful for the voice messaging folks, > but > it is simple enough to implement that it should not be a burden. > > I'm far from convinced that HTML to text is actually as useful as people apparently think it is. The only messages I find that don't come with a useful multipart/alternative are spam, anyway. (Perhaps I'm lucky). This looks to me like finding a transformation for the sake of it. As an alternative, might I suggest character set transformations for text/plain? Server support for character sets can be - and often are - much wider than client support, especially for some of the more obscure character sets, such as TIS620 (Thai, still not shipped in Java, apparently) as an example. We could pick a selection of character sets as sources, and transform them to UTF-8. In practise, I'd imagine most implementations would end up using iconv or similar, and therefore support a much wider set than the MTI set. (The transformation I'd most want to use would be JFIF quality and resolution changes, however, which are much more interesting.) > SPEAK NOW OR FOREVER HOLD YOUR PEACE: If you DISAGREE with this > position, respond to the list by 29 April 2006 with: > (1) Your Objection text/html -> text/plain is mostly pointless. > (2) Justification for the Objection HTML has good support, and the majority of HTML messages have text/plain alternates which are as the author's system intended. > (3) Concrete proposal that meets the constraints. > > Character set conversion for text/plain parts from various character sets (iso-8859-*, various others) to UTF-8. This is very simple to implement on most (all?) platforms if we choose the source character sets carefully, and should be useful on most targets platforms. 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 Apr 11 18:46:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTRci-0000ps-AQ; Tue, 11 Apr 2006 18:46:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTRch-0000pn-6O for lemonade@ietf.org; Tue, 11 Apr 2006 18:46:11 -0400 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTRcf-0007LP-TL for lemonade@ietf.org; Tue, 11 Apr 2006 18:46:11 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1FTRce-0000WS-T8 for lemonade@ietf.org; Tue, 11 Apr 2006 22:46:08 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 53982498004 for ; Tue, 11 Apr 2006 23:53:02 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07727-10 for ; Tue, 11 Apr 2006 23:52:50 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 10CC7498002 for ; Tue, 11 Apr 2006 23:52:49 +0100 (BST) Date: Tue, 11 Apr 2006 23:45:54 +0100 MIME-Version: 1.0 Message-Id: <9875.1144795555.072071@peirce.dave.cridland.net> From: Dave Cridland To: Enhancements to Internet email to support diverse service enivronments Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Pythagoras-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [lemonade] Compression X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hiya folks, I'm currently using COMPRESS=DEFLATE in normal usage, and it's compressing my download stream to 35-40% of the original size. This is remarkably good compression, and it's worth noting this is mostly compressing the IMAP protocol stream, rather than body parts - where body parts are being compressed, they're quite small textual parts, often quoting previous ones, which helps. I've also been doing some experimentation based on supplying a URLAUTH URL to the message I'm replying to during Submission, which is then used to prime compression - this is actually using an application-level stream compression in ESMTP, an analogue of COMPRESS=DEFLATE. Because of the quoted parts, this means that while simple compression reduces the data to 50.0%, this method can reduce it to 36.6% including transmission of the URLAUTH, which itself accounts for 23% of the actual transmission, on average. I suspect that in the editing draft case with CATENATE, this might be more effective, but draft editing is considerably harder to simulate, especially as I don't have the data to use. I think this is actually worth implementing - although the saving isn't huge, it's nevertheless allowing to send 3 emails instead of 2, roughly, and it's fairly easy to implement. 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 Apr 11 19:02:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTRso-0002Nq-Oz; Tue, 11 Apr 2006 19:02:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTRsm-0002Ng-M9 for lemonade@ietf.org; Tue, 11 Apr 2006 19:02:48 -0400 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTRsl-000091-AY for lemonade@ietf.org; Tue, 11 Apr 2006 19:02:48 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M14YG8NVPS003Z9Z@mauve.mrochek.com> for lemonade@ietf.org; Tue, 11 Apr 2006 16:02:44 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1144796552; h=Date: From:Subject:MIME-version:Content-type; b=sgwYBahvctxQzvqfSQW0PifaU Yaxzb59/M0OMIar4K0fJNoLTSnz8sOwSWhDe/cz5php/sODVLcJy+u2FCBIjQ== Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M13VB5HSG000007A@mauve.mrochek.com>; Tue, 11 Apr 2006 16:02:40 -0700 (PDT) To: Dave Cridland Message-id: <01M14YG6ZR6I00007A@mauve.mrochek.com> Date: Tue, 11 Apr 2006 15:51:18 -0700 (PDT) From: Ned Freed Subject: Re: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversions) In-reply-to: "Your message dated Tue, 11 Apr 2006 23:20:32 +0100" <9875.1144794033.255616@peirce.dave.cridland.net> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <330A23D8336C0346B5C1A5BB19666647029F61F0@ATLANTIS.Brooktrout.com> <9875.1144794033.255616@peirce.dave.cridland.net> X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Enhancements to Internet email to support diverse service enivronments , Burger Eric X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > I'm far from convinced that HTML to text is actually as useful as > people apparently think it is. The only messages I find that don't > come with a useful multipart/alternative are spam, anyway. (Perhaps > I'm lucky). That's exactly what you are: Lucky. I get legitimate HTML-only messages all the time, enough to account for a significant percentage of my mail. And they from a huge variety of sources. I also get a lot of multipart/alternatives (some spam, quite a few not) where the text/plain part basically says "if you are reading this your client is a piece of crap". A specific example of this last sort of behavior is the Apple e-newsletter I regularly receive. Like it or not, a lot of people now think it is perfectly OK to send HTML-only email. And this number seems to be steadily increasing, and I doubt anything we say or do is going to have the slightest impact. > This looks to me like finding a transformation for the > sake of it. I disagree. > As an alternative, might I suggest character set transformations for > text/plain? Server support for character sets can be - and often are > - much wider than client support, especially for some of the more > obscure character sets, such as TIS620 (Thai, still not shipped in > Java, apparently) as an example. We could pick a selection of > character sets as sources, and transform them to UTF-8. Interesting idea. Transformation to utf-8 on the server would be useful in quite a few cases. I would have no objection to adding or even switching to this. But I still think the objections to HTML->text are totally misplaced. > In practise, I'd imagine most implementations would end up using > iconv or similar, and therefore support a much wider set than the MTI > set. > (The transformation I'd most want to use would be JFIF quality and > resolution changes, however, which are much more interesting.) Agreed, but past experience getting consensus on this sort of thing has not been good. > > (1) Your Objection > text/html -> text/plain is mostly pointless. I use it many time every day, so I hardly find it to be pointless. > > (2) Justification for the Objection > HTML has good support, and the majority of HTML messages have > text/plain alternates which are as the author's system intended. Not in my world, they don't. Unless by "intent" you mean the author didn't bother to provide a usable plain text equivalent but used a structure that only makes sense when one is provided. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Apr 11 19:08:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTRyI-0005MW-Tx; Tue, 11 Apr 2006 19:08:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTRyH-0005MR-RU for lemonade@ietf.org; Tue, 11 Apr 2006 19:08:29 -0400 Received: from mxout1.cac.washington.edu ([140.142.32.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTRyG-0000Wi-Gm for lemonade@ietf.org; Tue, 11 Apr 2006 19:08:29 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout1.cac.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k3BN8J4x005505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Apr 2006 16:08:20 -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.6+UW06.03/8.13.5+UW06.03) with ESMTP id k3BN8Jt7023287 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 11 Apr 2006 16:08:19 -0700 Date: Tue, 11 Apr 2006 16:08:18 -0700 (Pacific Daylight Time) From: Mark Crispin To: Ned Freed Subject: Re: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversions) In-Reply-To: <01M14YG6ZR6I00007A@mauve.mrochek.com> Message-ID: References: <330A23D8336C0346B5C1A5BB19666647029F61F0@ATLANTIS.Brooktrout.com> <9875.1144794033.255616@peirce.dave.cridland.net> <01M14YG6ZR6I00007A@mauve.mrochek.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='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Enhancements to Internet email to support diverse service enivronments , Burger Eric X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue, 11 Apr 2006, Ned Freed wrote: > I also get a lot of multipart/alternatives (some spam, quite a few not) > where the text/plain part basically says "if you are reading this your > client is a piece of crap". A specific example of this last sort of > behavior is the Apple e-newsletter I regularly receive. I get that from a merchant that I used to deal with. Not long ago, the merchant asked me why they lost my business. I told them. They are actually looking into getting it fixed. > Like it or not, a lot of people now think it is perfectly OK to send > HTML-only email. And this number seems to be steadily increasing, and I > doubt anything we say or do is going to have the slightest impact. In many cases, they don't know any better; it's the crappy software that they were sold. -- 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 Apr 12 00:39:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTX8Q-0000A3-E3; Wed, 12 Apr 2006 00:39:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTX8O-00009y-U6 for lemonade@ietf.org; Wed, 12 Apr 2006 00:39:16 -0400 Received: from mail3.panix.com ([166.84.1.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTX8N-00053Z-N7 for lemonade@ietf.org; Wed, 12 Apr 2006 00:39:16 -0400 Received: from mailspool2.panix.com (mailspool2.panix.com [166.84.1.79]) by mail3.panix.com (Postfix) with ESMTP id 6A66613AA72 for ; Wed, 12 Apr 2006 00:39:15 -0400 (EDT) Received: from [192.168.1.11] (ool-45749fe3.dyn.optonline.net [69.116.159.227]) by mailspool2.panix.com (Postfix) with ESMTP id 96F9E64A001 for ; Wed, 12 Apr 2006 00:39:15 -0400 (EDT) Mime-Version: 1.0 X-Sender: Message-Id: In-Reply-To: <9875.1144794033.255616@peirce.dave.cridland.net> References: <330A23D8336C0346B5C1A5BB19666647029F61F0@ATLANTIS.Brooktrout.com> <9875.1144794033.255616@peirce.dave.cridland.net> X-Mailer: Eudora for Mac OS X 6.2.3 (MacOS 10.3) Date: Tue, 11 Apr 2006 23:45:37 -0400 To: Enhancements to Internet email to support diverse service enivronments From: "Robert A. Rosenberg" Subject: Re: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversions) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.5 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 23:20 +0100 on 04/11/2006, Dave Cridland wrote about Re: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversio: >Character set conversion for text/plain parts from various character >sets (iso-8859-*, various others) to UTF-8. This is very simple to >implement on most (all?) platforms if we choose the source character >sets carefully, and should be useful on most targets platforms. One caveat for the ISO-8859-1 -> UTF-8 transformation - You need a sanity check for x80-x9f codepoints or just assume that the Charset is a lie and act as if it were Windows-1252/CP-1252. This works except if the message is coming from a Macintosh Client where there is a non-Windows compatible mapping of the ISO-8859-1 x80-x9f codepoints created by the MacRoman -> ISO-8859-1 transformation as well as the inaccurate ISO-8859-1 -> UFT-8 transformations for the few glyphs that exist in MacRoman but not ISO-8859-1 [the fractions and 2 or 3 other glyphs] where the MacRoman -> ISO-8859-1 transforms use ISO codepoint slots in the xa0-xff range for glyphs that are in MacRoman but neither Windows-1252 nor ISO-8859-1. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Apr 12 06:45:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTcqt-0008Iq-RV; Wed, 12 Apr 2006 06:45:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTcqs-0008Il-NV for lemonade@ietf.org; Wed, 12 Apr 2006 06:45:34 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTcqs-0000HO-86 for lemonade@ietf.org; Wed, 12 Apr 2006 06:45:34 -0400 X-IronPort-AV: i="4.04,114,1144036800"; d="scan'208,217"; a="31271222:sNHT53360064" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Re: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversions) Date: Wed, 12 Apr 2006 06:48:07 -0400 Message-ID: <330A23D8336C0346B5C1A5BB196666470231C302@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversions) Thread-Index: AcZdtoqTu4Pv96J2R8+df+IYmhuTMQAaAqjO From: "Burger, Eric" To: "Dave Cridland" X-Spam-Score: 0.5 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1599795551==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============1599795551== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65E1E.957BEC5C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65E1E.957BEC5C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Would character set conversions exercise parameters, as well? -----Original Message----- From: Dave Cridland [mailto:dave@cridland.net] Sent: Tue Apr 11 18:23:21 2006 To: Burger, Eric Cc: Enhancements to Internet email to support diverse service = enivronments Subject: Re: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversions) On Tue Apr 11 16:29:47 2006, Burger, Eric wrote: > The "squared" problem is that unlike VPIM, where everyone was=20 > building a > voice messaging system, LEMONADE is addressing disparate markets. =20 > What > is interesting to the voice messaging folks, namely codec=20 > transcoding, > is of little interest to mobile folks, namely compressing/adapting=20 > (read > "downgrading") static content. Moreover, compressing static=20 > content is > not of interest to the unified messaging folks. >=20 >=20 I'm not entirely sure that's true. Mobile folk have limited sound=20 codecs available, as Randy points out, and desktop folk on=20 constrained bandwidth might want to use different codecs for content=20 preview. > Thus we looked for a transcoding operation that (1) would exercise=20 > the > transcoding mechanism, including the myriad transcoding parameters=20 > and > (2) would be generally useful to most or all of the target markets=20 > for > LEMONADE. The solution we came up with is HTML to text. This > transformation is generally useful for the unified messaging and=20 > mobile > markets. It is not quite as useful for the voice messaging folks,=20 > but > it is simple enough to implement that it should not be a burden. >=20 >=20 I'm far from convinced that HTML to text is actually as useful as=20 people apparently think it is. The only messages I find that don't=20 come with a useful multipart/alternative are spam, anyway. (Perhaps=20 I'm lucky). This looks to me like finding a transformation for the=20 sake of it. As an alternative, might I suggest character set transformations for=20 text/plain? Server support for character sets can be - and often are=20 - much wider than client support, especially for some of the more=20 obscure character sets, such as TIS620 (Thai, still not shipped in=20 Java, apparently) as an example. We could pick a selection of=20 character sets as sources, and transform them to UTF-8. In practise, I'd imagine most implementations would end up using=20 iconv or similar, and therefore support a much wider set than the MTI=20 set. (The transformation I'd most want to use would be JFIF quality and=20 resolution changes, however, which are much more interesting.) > SPEAK NOW OR FOREVER HOLD YOUR PEACE: If you DISAGREE with this > position, respond to the list by 29 April 2006 with: > (1) Your Objection text/html -> text/plain is mostly pointless. > (2) Justification for the Objection HTML has good support, and the majority of HTML messages have=20 text/plain alternates which are as the author's system intended. > (3) Concrete proposal that meets the constraints. >=20 >=20 Character set conversion for text/plain parts from various character=20 sets (iso-8859-*, various others) to UTF-8. This is very simple to=20 implement on most (all?) platforms if we choose the source character=20 sets carefully, and should be useful on most targets platforms. Dave. --=20 You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw ------_=_NextPart_001_01C65E1E.957BEC5C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: CALL FOR CONSENSUS (was RE: [lemonade] on MTI = conversions)

Would character set conversions exercise parameters, = as well?

 -----Original Message-----
From:   Dave Cridland [mailto:dave@cridland.net]
Sent:   Tue Apr 11 18:23:21 2006
To:     Burger, Eric
Cc:     Enhancements to Internet email to support = diverse service enivronments
Subject:        Re: CALL FOR = CONSENSUS (was RE: [lemonade] on MTI conversions)

On Tue Apr 11 16:29:47 2006, Burger, Eric wrote:
> The "squared" problem is that unlike VPIM, where everyone = was
> building a
> voice messaging system, LEMONADE is addressing disparate = markets. 
> What
> is interesting to the voice messaging folks, namely codec
> transcoding,
> is of little interest to mobile folks, namely = compressing/adapting
> (read
> "downgrading") static content.  Moreover, = compressing static
> content is
> not of interest to the unified messaging folks.
>
>
I'm not entirely sure that's true. Mobile folk have limited sound
codecs available, as Randy points out, and desktop folk on
constrained bandwidth might want to use different codecs for content
preview.


> Thus we looked for a transcoding operation that (1) would = exercise
> the
> transcoding mechanism, including the myriad transcoding = parameters
> and
> (2) would be generally useful to most or all of the target = markets
> for
> LEMONADE.  The solution we came up with is HTML to text.  = This
> transformation is generally useful for the unified messaging = and
> mobile
> markets.  It is not quite as useful for the voice messaging = folks,
> but
> it is simple enough to implement that it should not be a = burden.
>
>
I'm far from convinced that HTML to text is actually as useful as
people apparently think it is. The only messages I find that don't
come with a useful multipart/alternative are spam, anyway. (Perhaps
I'm lucky). This looks to me like finding a transformation for the
sake of it.

As an alternative, might I suggest character set transformations for
text/plain? Server support for character sets can be - and often are
- much wider than client support, especially for some of the more
obscure character sets, such as TIS620 (Thai, still not shipped in
Java, apparently) as an example. We could pick a selection of
character sets as sources, and transform them to UTF-8.

In practise, I'd imagine most implementations would end up using
iconv or similar, and therefore support a much wider set than the = MTI
set.

(The transformation I'd most want to use would be JFIF quality and
resolution changes, however, which are much more interesting.)


> SPEAK NOW OR FOREVER HOLD YOUR PEACE: If you DISAGREE with this
> position, respond to the list by 29 April 2006 with:
>       (1) Your Objection

text/html -> text/plain is mostly pointless.


>       (2) Justification for the = Objection

HTML has good support, and the majority of HTML messages have
text/plain alternates which are as the author's system intended.


>       (3) Concrete proposal that meets the = constraints.
>
>
Character set conversion for text/plain parts from various character
sets (iso-8859-*, various others) to UTF-8. This is very simple to
implement on most (all?) platforms if we choose the source character
sets carefully, and should be useful on most targets platforms.

Dave.
--
           You see = things; and you say "Why?"
   But I dream things that never were; and I say "Why = not?"
    - George Bernard Shaw

------_=_NextPart_001_01C65E1E.957BEC5C-- --===============1599795551== 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 --===============1599795551==-- From lemonade-bounces@ietf.org Wed Apr 12 09:15:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTfBk-00074x-DN; Wed, 12 Apr 2006 09:15:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTfBj-00074a-Ja for lemonade@ietf.org; Wed, 12 Apr 2006 09:15:15 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTfBi-00058J-6f for lemonade@ietf.org; Wed, 12 Apr 2006 09:15:15 -0400 Received: from [172.16.2.164] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Wed, 12 Apr 2006 14:15:10 +0100 Message-ID: <443CFD5F.20501@isode.com> Date: Wed, 12 Apr 2006 14:15:11 +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] problems implementing RESETKEY GENURLAUTH and URLFETCH References: <000101c65cfd$97e29cd0$1f229681@Tundra> 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.2 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Randall Gellens wrote: > At 5:28 PM -0700 4/10/06, Mark Crispin wrote: > >> If my client needs multiple URLs generated, why should it have to go >> through multiple RTTs to do it? > > Separating each URL into its own command requires a round-trip for > each because the URLAUTH response is untagged? But surely * GENURLAUTH is the same as * GENURLAUTH * GENURLAUTH or * GENURLAUTH * GENURLAUTH ? So the IMAP server can treat a single GENURLAUTH command with multiple URLs as multiple GENURLAUTH commands with one URL. The client can always match a received URL against an URL it requested to sign. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Apr 12 09:26:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTfMU-0004jG-BG; Wed, 12 Apr 2006 09:26:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTfMT-0004eV-3I for lemonade@ietf.org; Wed, 12 Apr 2006 09:26:21 -0400 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTfMP-0005VY-PK for lemonade@ietf.org; Wed, 12 Apr 2006 09:26:21 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1FTfMO-0007HM-Dj; Wed, 12 Apr 2006 13:26:16 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 1939B498003; Wed, 12 Apr 2006 14:33:16 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11086-08; Wed, 12 Apr 2006 14:33:07 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 0BDDD498002; Wed, 12 Apr 2006 14:33:06 +0100 (BST) Date: Wed, 12 Apr 2006 14:26:04 +0100 Subject: Re: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversions) References: <330A23D8336C0346B5C1A5BB196666470231C302@ATLANTIS.Brooktrout.com> In-Reply-To: <330A23D8336C0346B5C1A5BB196666470231C302@ATLANTIS.Brooktrout.com> MIME-Version: 1.0 Message-Id: <9875.1144848365.868969@peirce.dave.cridland.net> From: Dave Cridland To: "Burger\, Eric" Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Heisenberg-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed Apr 12 11:48:07 2006, Burger, Eric wrote: > Would character set conversions exercise parameters, as well? > > It would only exercise parameters, in fact. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Apr 12 11:12:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTh1Y-0002j4-Qu; Wed, 12 Apr 2006 11:12:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTh1Y-0002iz-0o for lemonade@ietf.org; Wed, 12 Apr 2006 11:12:52 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57] helo=zcars04f.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTh1W-0001Ei-MO for lemonade@ietf.org; Wed, 12 Apr 2006 11:12:52 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k3CFClU04412 for ; Wed, 12 Apr 2006 11:12:48 -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 Apr 2006 11:12:21 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D09886FA6@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Liaison Statement, "OMA LS 0096 on Mobile Email to the IETF Lemonade WG" Thread-Index: AcZd4VAJETz4MXyeRc+h5gwwAGm9lAAT7wLA From: "Glenn Parsons" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [lemonade] New Liaison Statement, "OMA LS 0096 on Mobile Email 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: , Errors-To: lemonade-bounces@ietf.org =20 Title: OMA LS 0096 on Mobile Email to the IETF Lemonade WG Submission Date: 2006-04-11 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=3D212=20 From: Dean Willis(OMA) To: IETF Lemonade(gparsons@nortel.com, eburger@cantata.com) Cc: lisa@osafoundation.org hardie@qualcomm.com Reponse Contact: jerry.weingarten@comverse.com Technical Contact: jerry.weingarten@comverse.com Purpose: For information Body: OMA MWG-MEM thanks IETF LEMONADE for their consideration of our previous liaison. We understand, and will take into consideration, your comments. Specifically, we have not yet been able to study a subset of the OMA STI parameters, but will include any subsetting as part of our work. Note that work continues on the MEM architecture document (AD) and that we plan to submit this for formal review, which is part of our approval process, prior to the end of June. =20 In addition, we have initiated work on a MEM technical specification (TS) for a LEMONADE realization. This will now make the LEMONADE profile-bis document an OMA-IETF dependency that will be tracked by OMA and IETF liaison representatives. We would appreciate ongoing updates on your progress with the completion of this work. OMA MWG-MEM intends to continue to provide detailed updates of the Mobile e-mail enabler related activities as our work progresses. OMA MWG-MEM will hold its next meetings on 17-19 May in Kansas, and June 12-16 in Osaka, Japan. Attachment(s): Original LS in Word Format (https://datatracker.ietf.org/documents/LIAISON/file299.doc) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Apr 12 11:34:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FThMY-0004QO-89; Wed, 12 Apr 2006 11:34:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FThMX-0004QJ-9i for lemonade@ietf.org; Wed, 12 Apr 2006 11:34:33 -0400 Received: from agminet01.oracle.com ([141.146.126.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FThMU-0002Fi-W9 for lemonade@ietf.org; Wed, 12 Apr 2006 11:34:33 -0400 Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k3CFXYdj020689; Wed, 12 Apr 2006 10:33:34 -0500 Received: from rgmsgw301.us.oracle.com (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k3CFXXfR025176; Wed, 12 Apr 2006 09:33:33 -0600 Received: from us.oracle.com (dhcp-4op5-4op6-west-144-25-174-12.us.oracle.com [144.25.174.12]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k3CFXXst025162 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 12 Apr 2006 09:33:33 -0600 From: "Stephane H. Maes" To: "Dave Cridland" , "Burger, Eric" Subject: RE: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversions) Date: Wed, 12 Apr 2006 08:33:32 -0700 Organization: Oracle Message-ID: <20060412083332813.00000004488@smaes-lap3> In-Reply-To: <9875.1144848365.868969@peirce.dave.cridland.net> X-Mailer: Oracle Connector for Outlook 10.1.2.0.3 71207 (11.0.8010) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "stephane.maes@oracle.com" List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Noty the ones from STI I think Stephane = _____ Stephane H. Maes, PhD, Director of Architecture, Mobile, Voice, and Communications Platforms, Orac= le. Ph: +1-203-300-7786 (mobile/SMS); Fax / Office UM: +1-650-607-6296 e-mail: stephane.maes@oracle.com IM: shmaes (AIM/Y!/skype) or stephane_maes@hotmail.com (MSN Messenger) or s= tephane.maes@gmail.com (Google) -----Original Message----- From: Dave Cridland [mailto:dave@cridland.net] = Sent: Wednesday, April 12, 2006 6:26 AM To: Burger, Eric Cc: Enhancements to Internet email to support diverse service enivronments Subject: Re: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversions) On Wed Apr 12 11:48:07 2006, Burger, Eric wrote: > Would character set conversions exercise parameters, as well? > > It would only exercise parameters, in fact. 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 Wed Apr 12 19:37:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTouE-0003RL-1T; Wed, 12 Apr 2006 19:37:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTouC-0003RG-Ni for lemonade@ietf.org; Wed, 12 Apr 2006 19:37:48 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTouB-000524-Bo for lemonade@ietf.org; Wed, 12 Apr 2006 19:37:48 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3CNbjZs023207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Apr 2006 16:37:46 -0700 Received: from [192.168.1.13] (loud.qualcomm.com [129.46.172.15]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3CNba8H001651; Wed, 12 Apr 2006 16:37:44 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <443CFD5F.20501@isode.com> References: <000101c65cfd$97e29cd0$1f229681@Tundra> <443CFD5F.20501@isode.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Wed, 12 Apr 2006 16:37:20 -0700 To: Alexey Melnikov , lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] problems implementing RESETKEY GENURLAUTH and URLFETCH 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: 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: , Errors-To: lemonade-bounces@ietf.org At 2:15 PM +0100 4/12/06, Alexey Melnikov wrote: > Randall Gellens wrote: > >> At 5:28 PM -0700 4/10/06, Mark Crispin wrote: >> >>> If my client needs multiple URLs generated, why should it have >>> to go through multiple RTTs to do it? >> >> Separating each URL into its own command requires a round-trip for >> each because the URLAUTH response is untagged? > > But surely > * GENURLAUTH > > is the same as > > * GENURLAUTH > * GENURLAUTH > > or > > * GENURLAUTH > * GENURLAUTH > ? That's what I thought, which is why I asked. So even if the client had to send multiple commands, it can pipeline them. > So the IMAP server can treat a single GENURLAUTH command with > multiple URLs as multiple GENURLAUTH commands with one URL. In the case where the one IMAP server is proxying for additional back-end servers, it would turn the one command into several, then intercept the multiple tagged OKs, and send back one OK after the proxied commands completed? > > The client can always match a received URL against an URL it > requested to sign. Good point. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- You see, wire telegraph is a kind of very, very long cat. You pull his tail in New York and his head is meowing in Los Angeles. Do you understand this? And radio operates in exactly the same way: you send signals here, they receive them there. The only difference is that there is no cat. --Albert Einstein _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Apr 12 23:19:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTsMY-00022S-D5; Wed, 12 Apr 2006 23:19:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTsMX-00022K-Ai for lemonade@ietf.org; Wed, 12 Apr 2006 23:19:17 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTsMS-00033b-VJ for lemonade@ietf.org; Wed, 12 Apr 2006 23:19:17 -0400 Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k3D3JCZe011939 for ; Wed, 12 Apr 2006 21:19:12 -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 <0IXN000014ADU200@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Wed, 12 Apr 2006 21:19:12 -0600 (MDT) Received: from Tundra ([199.247.232.254]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IXN008ZQ57XQC10@mail-amer.sun.com> for lemonade@ietf.org; Wed, 12 Apr 2006 21:19:12 -0600 (MDT) Date: Wed, 12 Apr 2006 20:19:08 -0700 From: Peter Coates To: lemonade@ietf.org Message-id: <00b101c65ea9$07e88240$1f229681@Tundra> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcZeqQZ7Vi79wif8QsuR+ZGn9Q1kMw== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [lemonade] IMAP URLs in CATENATE X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0733605021==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============0733605021== Content-type: multipart/alternative; boundary="Boundary_(ID_amzjt9ykXOXz3Xuw1LPE4w)" This is a multi-part message in MIME format. --Boundary_(ID_amzjt9ykXOXz3Xuw1LPE4w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Would it not make sense to extend the CATENATE spec to allow IMAP URLs with the URLAUTH extensions. thus a URL with no userid and not URLAUTH part would be equivalent to an IMAP URL with userid equal to the logged in userid. And I have all the same fun with proxying bits. (actually the command itself might be being proxied, then the URLs might get proxied again. Oh what a tangled web we weave.) Peter --Boundary_(ID_amzjt9ykXOXz3Xuw1LPE4w) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
Would it not make sense to extend the CATENATE spec to allow IMAP URLs with the URLAUTH extensions.  thus a URL with no userid and not URLAUTH part would be equivalent to an IMAP URL with userid equal to the logged in userid.
 
And I have all the same fun with proxying bits.  (actually the command itself might be being proxied, then the URLs might get proxied again.  Oh what a tangled web we weave.)
 
Peter
--Boundary_(ID_amzjt9ykXOXz3Xuw1LPE4w)-- --===============0733605021== 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 --===============0733605021==-- From lemonade-bounces@ietf.org Thu Apr 13 16:51:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU8mV-0002ql-P8; Thu, 13 Apr 2006 16:51:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU8mU-0002qd-Lp for lemonade@ietf.org; Thu, 13 Apr 2006 16:51:10 -0400 Received: from mxout7.cac.washington.edu ([140.142.32.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU8mT-0003GQ-6P for lemonade@ietf.org; Thu, 13 Apr 2006 16:51:10 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout7.cac.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k3DKp8fi002310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 13 Apr 2006 13:51:08 -0700 X-Auth-Received: from shiva2.cac.washington.edu (shiva2.cac.washington.edu [140.142.37.173]) (authenticated authid=mrc) by smtp.washington.edu (8.13.6+UW06.03/8.13.6+UW06.03) with ESMTP id k3DKp7nm023605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 13 Apr 2006 13:51:08 -0700 Date: Thu, 13 Apr 2006 13:51:07 -0700 (PDT) From: Mark Crispin To: lemonade@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Subject: [lemonade] URLAUTH draft changes X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org The proposed set of changes to draft-ietf-lemonade-urlauth-08.txt follow. Following each change is a set of comments prefixed with ;;; that explain the change. Assuming that there are no further objections, I will then review the RFC Editor's work and merge these changes. Speak now or forever.... 73c73 < that it only supports authentication, and confuses the concepts --- > that it only supports authentication, and confuses the concepts of ;;; grammar correction 78c78 < conveys authorization in the URL name itself, and reuses a portion of --- > conveys authorization in the URL string itself, and reuses a portion of ;;; precision correction (no such thing as a "URL name") 195c195 < [IMAPURL] is extended by allowing the addition of ;EXPIRE=" --- > [IMAPURL] is extended by allowing the addition of ";EXPIRE=" ;;; typographic correction: missing open quote. 416,417c416,423 < As a consequence, the iserver rule of [IMAPURL] is modified < so that iuserauth is mandatory. --- > As a consequence, relative URLs are not permitted, and > enc-user is mandatory, in URLAUTH authorized URLs. > > Note: the server component of the URL is generally the > logged in userid and server. If not, then the logged in > userid and server MUST have owner-type access to the > mailbox access key table owned by the userid and server > indicated by the server component of the URL. ;;; per recent discussion regarding the URLAUTH security model. 424,425c430,431 < (4) the server MAY also verify that the Message-ID and/or < second components (if present) are valid. --- > (4) the server MAY also verify that the iuid and/or isection > components (if present) are valid. ;;; per discussion; "Message-ID" and "second" are obvious errors. 478a485,491 > The URLFETCH command effectively executes with the access of the userid > in the server component of the URL (which is generally the userid that > issued the GENURLAUTH). By itself, the URLAUTH does NOT grant access to > the data; once validated, it grants whatever access to the data is held > by the userid in the server component of the URL. That access may have > changed since the GENURLAUTH was done. > ;;; more per recent discussion regarding the URLAUTH security model. 626c639,641 < authimapurl = "imap://" iuserauth "@" hostport "/" imessagepart --- > authimapurl = "imap://" enc-user [iauth] "@" hostport "/" imessagepart > ; replaces "imapurl" and "iserver" rules for URLAUTH > ; authorized URLs ;;; indicate that enc-user is mandatory (it is optional in iuserauth) 633a649,651 > enc-user = 1*achar > ; same as "enc_user" in RFC 2192 > ;;; per underscore vs. hyphen foofaraw 638c656 < access = ("submit+" iuserauth) / ("user+" iuserauth) / --- > access = ("submit+" enc-user) / ("user+" enc-user) / ;;; remove iauth as possible value in these fields. 677a696,702 > Although this specification does not prohibit the theoretical > capability to generate a URL with a server component other than the > logged in userid and server, this capability should only be provided > when the logged in userid/server has been authorized as equivalent to > the server component userid/server, or otherwise has access to that > userid/server mailbox access key table. > ;;; further security caution per recent discussion regarding the URLAUTH ;;; security model. 719,720c744 < Specifications: ABNF", draft-crocker-abnf-rfc2234bis (work < in progress). --- > Specifications: ABNF", RFC 4234, October 2005. ;;; update since RFC now issued (probably will be updated in RFC Editor ;;; version too). 723c747 < draft-newman-lemonade-burl (work in progress). --- > draft-ietf-lemonade-burl (work in progress). ;;; update now that WG draft (probably will be updated in RFC Editor ;;; version too). -- 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 Thu Apr 13 19:15:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUB1u-0002PT-4W; Thu, 13 Apr 2006 19:15:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUB1s-0002PO-OS for lemonade@ietf.org; Thu, 13 Apr 2006 19:15:12 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUB1r-0008Av-6z for lemonade@ietf.org; Thu, 13 Apr 2006 19:15:12 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3DNF8xj015494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 13 Apr 2006 16:15:09 -0700 Received: from [192.168.1.13] (loud.qualcomm.com [129.46.172.15]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3DNF6F9017227; Thu, 13 Apr 2006 16:15:07 -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: Thu, 13 Apr 2006 16:13:12 -0700 To: Mark Crispin , lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] URLAUTH draft changes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 1:51 PM -0700 4/13/06, Mark Crispin wrote: > 677a696,702 >> Although this specification does not prohibit the theoretical >> capability to generate a URL with a server component other than the >> logged in userid and server, this capability should only be provided >> when the logged in userid/server has been authorized as equivalent to >> the server component userid/server, or otherwise has access to that >> userid/server mailbox access key table. >> > > ;;; further security caution per recent discussion regarding the URLAUTH > ;;; security model. I'm not sure what "this capability should only be provided" means. Does it mean the server should reject a GENURLAUTH where the server or userid differ from that of the current session? If so, I'd prefer the text to say so more clearly. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- There is hardly anything in the world that some one cannot make a little worse, and sell a little cheaper. --John Ruskin (1819-1900) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Apr 13 19:34:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUBKJ-0000QY-9R; Thu, 13 Apr 2006 19:34:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUBKI-0000QL-0P for lemonade@ietf.org; Thu, 13 Apr 2006 19:34:14 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUBKH-0000RX-Nx for lemonade@ietf.org; Thu, 13 Apr 2006 19:34:13 -0400 Received: from mxout1.cac.washington.edu ([140.142.32.134]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FUB8O-0001gT-Hi for lemonade@ietf.org; Thu, 13 Apr 2006 19:21:59 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout1.cac.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k3DNLt3c005658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Apr 2006 16:21:55 -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.6+UW06.03/8.13.6+UW06.03) with ESMTP id k3DNLsOf030442 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 13 Apr 2006 16:21:55 -0700 Date: Thu, 13 Apr 2006 16:21:54 -0700 (Pacific Daylight Time) From: Mark Crispin To: Randall Gellens Subject: Re: [lemonade] URLAUTH draft changes In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: -2.6 (--) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu, 13 Apr 2006, Randall Gellens wrote: > Does it > mean the server should reject a GENURLAUTH where the server or userid differ > from that of the current session? I don't know how the server could do a GENURLAUTH where the server or userid differ from that of the current session, since somehow the server has to get ahold of the mailbox key table for that other userid/server in order to generate it. But that's an implementation issue. I'm just pointing out that the implementation would have to do that if it is to allow such a thing. -- 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 Thu Apr 13 20:08:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUBrN-0002XL-MW; Thu, 13 Apr 2006 20:08:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUBrM-0002XE-LP for lemonade@ietf.org; Thu, 13 Apr 2006 20:08:24 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUBKI-0000RB-PQ for lemonade@ietf.org; Thu, 13 Apr 2006 19:34:14 -0400 Received: from mxout4.cac.washington.edu ([140.142.33.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FUB5P-0001eo-2T for lemonade@ietf.org; Thu, 13 Apr 2006 19:18:52 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout4.cac.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k3DNInE1022689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Apr 2006 16:18:49 -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.6+UW06.03/8.13.6+UW06.03) with ESMTP id k3DNInxV029698 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 13 Apr 2006 16:18:49 -0700 Date: Thu, 13 Apr 2006 16:18:49 -0700 (Pacific Daylight Time) From: Mark Crispin To: Randall Gellens Subject: Re: [lemonade] URLAUTH draft changes In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: -2.6 (--) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu, 13 Apr 2006, Randall Gellens wrote: >>> Although this specification does not prohibit the theoretical >>> capability to generate a URL with a server component other than the >>> logged in userid and server, this capability should only be provided >>> when the logged in userid/server has been authorized as equivalent to >>> the server component userid/server, or otherwise has access to that >>> userid/server mailbox access key table. > > I'm not sure what "this capability should only be provided" means. Does it > mean the server should reject a GENURLAUTH where the server or userid differ > from that of the current session? If so, I'd prefer the text to say so more > clearly. No, it means what it says. It is a cautionary security note. It's exactly like saying that you shouldn't implement separate authentication vs. authorization users in SASL unless you have some means to validate that the authentication user can acquire the authorization user's credentials. -- 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 Apr 14 14:26:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUSzV-0006iG-SS; Fri, 14 Apr 2006 14:25:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUSzU-0006iB-1N for lemonade@ietf.org; Fri, 14 Apr 2006 14:25:56 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUSzS-0003Iv-IS for lemonade@ietf.org; Fri, 14 Apr 2006 14:25:56 -0400 X-IronPort-AV: i="4.04,121,1144036800"; d="scan'208"; a="31338470:sNHT461890884" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversions) Date: Fri, 14 Apr 2006 14:25:49 -0400 Message-ID: <330A23D8336C0346B5C1A5BB1966664702A9183A@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversions) Thread-Index: AcZeNQ3aLUy7HAWqSH+E97tEu2MHcQBu2bRw From: "Burger, Eric" To: "Dave Cridland" , "Ned Freed" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Part of me wants to say, "Live with it, it is HTML to text." Another part of me wants to say, "Character set conversion is so trivial, let's go with that." Yet another part of me is inclined to say, "Do HTML to text *and* character set conversions." I am leaning towards option 1 (HTML->text) as so far I hear one voice of dissent and I am worried about option 2 (character set conversions) leading to months of debate over which character sets need to be supported and how to deal with non-standard, but common, character set encodings. Thoughts? -----Original Message----- From: Dave Cridland [mailto:dave@cridland.net]=20 Sent: Wednesday, April 12, 2006 9:26 AM To: Burger, Eric Cc: Enhancements to Internet email to support diverse service enivronments Subject: Re: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversions) On Wed Apr 12 11:48:07 2006, Burger, Eric wrote: > Would character set conversions exercise parameters, as well? >=20 >=20 It would only exercise parameters, in fact. 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 Fri Apr 14 14:41:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUTEY-0000ik-MF; Fri, 14 Apr 2006 14:41:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUTEY-0000if-2m for lemonade@ietf.org; Fri, 14 Apr 2006 14:41:30 -0400 Received: from mxout5.cac.washington.edu ([140.142.32.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUTEV-0003lX-L4 for lemonade@ietf.org; Fri, 14 Apr 2006 14:41:29 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout5.cac.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k3EIfJ03028290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 14 Apr 2006 11:41:19 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.6+UW06.03/8.13.6+UW06.03) with ESMTP id k3EIfHwu015117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 14 Apr 2006 11:41:18 -0700 Date: Fri, 14 Apr 2006 11:41:16 -0700 (PDT) From: Mark Crispin To: "Burger, Eric" Subject: RE: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversions) In-Reply-To: <330A23D8336C0346B5C1A5BB1966664702A9183A@ATLANTIS.Brooktrout.com> Message-ID: References: <330A23D8336C0346B5C1A5BB1966664702A9183A@ATLANTIS.Brooktrout.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Enhancements to Internet email to support diverse service enivronments , Ned Freed X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Fri, 14 Apr 2006, Burger, Eric wrote: > Part of me wants to say, "Live with it, it is HTML to text." > > Another part of me wants to say, "Character set conversion is so > trivial, let's go with that." > > Yet another part of me is inclined to say, "Do HTML to text *and* > character set conversions." What about the fourth choice: Do HTML to text. As a server implementation option, also do character set conversions. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Apr 14 16:06:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUUYz-0005gZ-38; Fri, 14 Apr 2006 16:06:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUUYx-0005gU-UQ for lemonade@ietf.org; Fri, 14 Apr 2006 16:06:39 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUUYw-000703-Mn for lemonade@ietf.org; Fri, 14 Apr 2006 16:06:39 -0400 X-IronPort-AV: i="4.04,121,1144036800"; d="scan'208"; a="31340361:sNHT40288088" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversions) Date: Fri, 14 Apr 2006 16:06:37 -0400 Message-ID: <330A23D8336C0346B5C1A5BB1966664702A91964@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversions) Thread-Index: AcZf82hJjoqk7SV2R5OQhNcBcCaP4AAC2Cfw From: "Burger, Eric" To: "Mark Crispin" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Fourth choice is not a choice, but the reality: if one implements a conversion, they are going to do a suite. The reason for choice 3 was so that we would REQUIRE multiple conversions, to ensure that people write code to handle more than one.=20 -----Original Message----- From: mrc@pangtzu.panda.com [mailto:mrc@pangtzu.panda.com] On Behalf Of Mark Crispin Sent: Friday, April 14, 2006 2:41 PM To: Burger, Eric Cc: Dave Cridland; Ned Freed; Enhancements to Internet email to support diverse service enivronments Subject: RE: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversions) On Fri, 14 Apr 2006, Burger, Eric wrote: > Part of me wants to say, "Live with it, it is HTML to text." > > Another part of me wants to say, "Character set conversion is so > trivial, let's go with that." > > Yet another part of me is inclined to say, "Do HTML to text *and* > character set conversions." What about the fourth choice: Do HTML to text. As a server implementation option, also do character set=20 conversions. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Apr 14 16:50:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUVFJ-0002Yh-Hb; Fri, 14 Apr 2006 16:50:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUVFI-0002Yc-Te for lemonade@ietf.org; Fri, 14 Apr 2006 16:50:24 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUVFH-0008V9-KA for lemonade@ietf.org; Fri, 14 Apr 2006 16:50:24 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3EKoG6v011868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 14 Apr 2006 13:50:16 -0700 Received: from [192.168.1.13] (vpn-10-50-0-60.qualcomm.com [10.50.0.60]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3EKoDmG016678; Fri, 14 Apr 2006 13:50:15 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <330A23D8336C0346B5C1A5BB1966664702A9183A@ATLANTIS.Brooktrout.com> References: <330A23D8336C0346B5C1A5BB1966664702A9183A@ATLANTIS.Brooktrout.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Fri, 14 Apr 2006 13:50:03 -0700 To: "Burger, Eric" , "Dave Cridland" , "Ned Freed" From: Randall Gellens Subject: RE: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversions) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 2:25 PM -0400 4/14/06, Eric Burger wrote: > I am leaning towards option 1 (HTML->text) as so far I hear one voice of > dissent and I am worried about option 2 (character set conversions) > leading to months of debate over which character sets need to be > supported and how to deal with non-standard, but common, character set > encodings. > > Thoughts? Sounds reasonable to me. Text to HTML is fairly simple, while charsets tend to be more complicated then they seem. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Whenever people agree with me I always feel I must be wrong. --Oscar Wilde _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Apr 15 02:50:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUebq-000874-TU; Sat, 15 Apr 2006 02:50:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUebp-00086z-9W for lemonade@ietf.org; Sat, 15 Apr 2006 02:50:17 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUdRh-0008TI-JW for lemonade@ietf.org; Sat, 15 Apr 2006 01:35:45 -0400 Received: from mail1.panix.com ([166.84.1.72]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FUdE3-0004yj-7S for lemonade@ietf.org; Sat, 15 Apr 2006 01:21:40 -0400 Received: from mailspool2.panix.com (mailspool2.panix.com [166.84.1.79]) by mail1.panix.com (Postfix) with ESMTP id D35BB5B2B7 for ; Sat, 15 Apr 2006 01:21:24 -0400 (EDT) Received: from [192.168.1.11] (ool-45749fe3.dyn.optonline.net [69.116.159.227]) by mailspool2.panix.com (Postfix) with ESMTP id D037464A001 for ; Sat, 15 Apr 2006 01:21:24 -0400 (EDT) Mime-Version: 1.0 X-Sender: Message-Id: In-Reply-To: <330A23D8336C0346B5C1A5BB1966664702A9183A@ATLANTIS.Brooktrout.com> References: <330A23D8336C0346B5C1A5BB1966664702A9183A@ATLANTIS.Brooktrout.com> X-Mailer: Eudora for Mac OS X 6.2.3 (MacOS 10.3) Date: Sat, 15 Apr 2006 00:38:05 -0400 To: Enhancements to Internet email to support diverse service enivronments From: "Robert A. Rosenberg" Subject: RE: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversions) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -2.6 (--) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 14:25 -0400 on 04/14/2006, Burger, Eric wrote about Re: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversio: >I am worried about option 2 (character set conversions) leading to >months of debate over which character sets need to be supported and >how to deal with non-standard, but common, character set encodings. While I do not feel I am that qualified to offer an opinion on if option 2 should be done and if it is what character sets should be supported, I will repeat my prior comment that one that would probably be included (ISO-8859-1 <-> Unicode) can not be 100% successful (ie: Accurate) in all cases due to there being 3 separate glyph mappings that are marked in Email as ISO-8859-1. These are: 1) True ISO-8859-1 where the x80-x9f code point range is used for the useless (so far as Email and other data storage as opposed to being sent to display devices) C1 control characters that the ISO wants to be there for historical reasons instead of usable glyphs . 2) Windows-1252 (AKA CP-1252) which is the native code used on Windows Computers where this 32 codepoint range is used for useful glyphs in lieu of the useless ISO mandated C1 Control Codes. Many Windows Email and Web Design programs blindly mark files with these codepoints as ISO-8859-1 even when this is a lie (ie: The file has data with these codepoints). Note: I am speaking generically when I say the "Native Code" since based on the language that is selected for Windows Support, you can/would get the Windows-125x superset versions of the ISO-8859-x codes as well as Unicode having replaced the old 256 codepoint codes. OTOH - The use of a ISO-8859-x Charset in Email I think outweighs the number of UTF-8 marked messages. 3) Macintosh Source Email marked as ISO-8859-1 (or other ISO-8859-x Charsets). This represents a problem since the xa0-xff mappings to/from MacRoman is accurate except for a few glyphs that are not in MacRoman and which thus represent glyphs that do not exist in either Windows-1252 or ISO-8859-1. The major problem is that the Mac mapped glyphs in its version of ISO-8859-1 does not agree with the positions of the Windows-1252 x80-x9f glyphs (although I think all 32 glyphs in that codepoint range are in the Mac version - just in different locations in that range). Windows-1252 can easily be handled by just assuming an codepoints in the x80-x9f codepoint range that occur in a message marked as ISO-8859-1 should be treated as if the charset was designated as Windows-1252 when transforming to Unicode (and when going from Unicode to ISO-8859-1 just map any occurrences of the 32 "extra" glyphs to their Windows-1252 positions). The case of the Macintosh version of ISO-8859-1 is a separate issue due to the missing/extra glyphs in the xa0-xff range as well as the non-Windows-1252 arrangement of the 32 glyphs mapped to the x80-9f codepoint range. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Apr 15 20:46:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUvP0-0004WF-NY; Sat, 15 Apr 2006 20:46:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUXf4-0002J0-Gp for lemonade@ietf.org; Fri, 14 Apr 2006 19:25:10 -0400 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUXf3-000668-5Y for lemonade@ietf.org; Fri, 14 Apr 2006 19:25:10 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M1963HLMK0004Z0Z@mauve.mrochek.com> for lemonade@ietf.org; Fri, 14 Apr 2006 16:24:41 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1145057083; h=Date: From:Subject:MIME-version:Content-type; b=mB4tWMM+N2uPcoJ4AoYslrkFY eXAMTd+aZ/49Z1p49PwFbV340JfnIbcw48bWH995QaAAT2gZ6wSk7kNW9dM/g== Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M18S9QZPOW0008CX@mauve.mrochek.com>; Fri, 14 Apr 2006 16:24:38 -0700 (PDT) To: Randall Gellens Message-id: <01M1963G9KEA0008CX@mauve.mrochek.com> Date: Fri, 14 Apr 2006 16:23:24 -0700 (PDT) From: Ned Freed Subject: RE: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversions) In-reply-to: "Your message dated Fri, 14 Apr 2006 13:50:03 -0700" MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <330A23D8336C0346B5C1A5BB1966664702A9183A@ATLANTIS.Brooktrout.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-Mailman-Approved-At: Sat, 15 Apr 2006 20:46:09 -0400 Cc: diverse service enivronments , Ned Freed , Enhancements, Burger Eric X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > At 2:25 PM -0400 4/14/06, Eric Burger wrote: > > I am leaning towards option 1 (HTML->text) as so far I hear one voice of > > dissent and I am worried about option 2 (character set conversions) > > leading to months of debate over which character sets need to be > > supported and how to deal with non-standard, but common, character set > > encodings. > > > > Thoughts? > Sounds reasonable to me. Text to HTML is fairly simple, while > charsets tend to be more complicated then they seem. OK, I gotta ask. Does the HTML->text thing allow me to change text/html; charset=gb18030 to text/plain; charset=utf-8 And if not, why not? Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Apr 15 21:07:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUvjT-0001he-Cl; Sat, 15 Apr 2006 21:07:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUvjS-0001hZ-83 for lemonade@ietf.org; Sat, 15 Apr 2006 21:07:18 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUvjP-0004sO-U2 for lemonade@ietf.org; Sat, 15 Apr 2006 21:07:18 -0400 X-IronPort-AV: i="4.04,122,1144036800"; d="scan'208"; a="31366701:sNHT45940532" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversions) Date: Sat, 15 Apr 2006 21:07:10 -0400 Message-ID: <330A23D8336C0346B5C1A5BB1966664702A91A7F@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversions) Thread-Index: AcZgWU7U8w2rWRutQOKPTWT6iQ3a7AAmK41A From: "Burger, Eric" To: "Enhancements to Internet email to support diverse serviceenivronments" X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org This is why I am not a fan of mandating the character set conversion to be our conversion. It would require us to document which mapping works, and that is WAY outside of our charter. -----Original Message----- From: Robert A. Rosenberg [mailto:hal9001@panix.com]=20 Sent: Saturday, April 15, 2006 12:38 AM To: Enhancements to Internet email to support diverse serviceenivronments Subject: RE: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversions) At 14:25 -0400 on 04/14/2006, Burger, Eric wrote about Re: CALL FOR=20 CONSENSUS (was RE: [lemonade] on MTI conversio: >I am worried about option 2 (character set conversions) leading to=20 >months of debate over which character sets need to be supported and=20 >how to deal with non-standard, but common, character set encodings. While I do not feel I am that qualified to offer an opinion on if=20 option 2 should be done and if it is what character sets should be=20 supported, I will repeat my prior comment that one that would=20 probably be included (ISO-8859-1 <-> Unicode) can not be 100%=20 successful (ie: Accurate) in all cases due to there being 3 separate=20 glyph mappings that are marked in Email as ISO-8859-1. These are: 1) True ISO-8859-1 where the x80-x9f code point range is used for=20 the useless (so far as Email and other data storage as=20 opposed to being sent to display devices) C1 control characters that=20 the ISO wants to be there for historical reasons instead of usable=20 glyphs . 2) Windows-1252 (AKA CP-1252) which is the native code used on=20 Windows Computers where this 32 codepoint range is used for useful=20 glyphs in lieu of the useless ISO mandated C1 Control Codes. Many=20 Windows Email and Web Design programs blindly mark files with these=20 codepoints as ISO-8859-1 even when this is a lie (ie: The file has=20 data with these codepoints). Note: I am speaking generically when I=20 say the "Native Code" since based on the language that is selected=20 for Windows Support, you can/would get the Windows-125x superset=20 versions of the ISO-8859-x codes as well as Unicode having replaced=20 the old 256 codepoint codes. OTOH - The use of a ISO-8859-x Charset=20 in Email I think outweighs the number of UTF-8 marked messages. 3) Macintosh Source Email marked as ISO-8859-1 (or other ISO-8859-x=20 Charsets). This represents a problem since the xa0-xff mappings=20 to/from MacRoman is accurate except for a few glyphs that are not in=20 MacRoman and which thus represent glyphs that do not exist in either=20 Windows-1252 or ISO-8859-1. The major problem is that the Mac mapped=20 glyphs in its version of ISO-8859-1 does not agree with the positions=20 of the Windows-1252 x80-x9f glyphs (although I think all 32 glyphs in=20 that codepoint range are in the Mac version - just in different=20 locations in that range). Windows-1252 can easily be handled by just assuming an codepoints in=20 the x80-x9f codepoint range that occur in a message marked as=20 ISO-8859-1 should be treated as if the charset was designated as=20 Windows-1252 when transforming to Unicode (and when going from=20 Unicode to ISO-8859-1 just map any occurrences of the 32 "extra"=20 glyphs to their Windows-1252 positions). The case of the Macintosh version of ISO-8859-1 is a separate issue=20 due to the missing/extra glyphs in the xa0-xff range as well as the=20 non-Windows-1252 arrangement of the 32 glyphs mapped to the x80-9f=20 codepoint range. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Apr 16 14:30:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVC0W-00049S-5e; Sun, 16 Apr 2006 14:30:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVC0V-00049N-5A for lemonade@ietf.org; Sun, 16 Apr 2006 14:29:59 -0400 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVC0U-0002JJ-LH for lemonade@ietf.org; Sun, 16 Apr 2006 14:29:59 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1FVC0T-00084G-A4; Sun, 16 Apr 2006 18:29:57 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id EBF2F498003; Sun, 16 Apr 2006 19:37:39 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06316-01; Sun, 16 Apr 2006 19:37:30 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 1EF8F498002; Sun, 16 Apr 2006 19:37:29 +0100 (BST) Date: Sun, 16 Apr 2006 19:29:45 +0100 Subject: RE: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversions) References: <330A23D8336C0346B5C1A5BB1966664702A91A7F@ATLANTIS.Brooktrout.com> In-Reply-To: <330A23D8336C0346B5C1A5BB1966664702A91A7F@ATLANTIS.Brooktrout.com> MIME-Version: 1.0 Message-Id: <7915.1145212186.189845@peirce.dave.cridland.net> From: Dave Cridland To: "Burger\, Eric" Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Pythagoras-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Sun Apr 16 02:07:10 2006, Burger, Eric wrote: > This is why I am not a fan of mandating the character set > conversion to > be our conversion. It would require us to document which mapping > works, > and that is WAY outside of our charter. > > I'm not convinced that character set conversion requires documenting clients incorrectly marking the character set. I appreciate that this is, to a degree, ignoring the real world, however I don't think we ought to be mandating heuristics to handle software errors of this nature in a standards track proposal. Saying that servers MUST handle iso-8859-1 -> utf-8 is surely within our charter, and as far as I'm aware that mapping works if the character set used really is iso-8859-1 to begin with. If it isn't, then the client is buggy, and how servers deal with buggy content is entirely up to them. As for which character sets, I'd be perfectly content with utf-8 as sole (required) output, and an almost random selection of character sets as input. (Probably the top 5 or so used in real email. ASCII ought to be fairly trivial). I'm also still pondering Ned Freed's point that character set conversion is a reasonable (and possibly essential) thing to include within HTML conversion - if this is the case, we need to document character set conversions anyway, and my suggestion is essentially a text/plain=>text/plain conversion. (In other words, the parameters form part of the type). On the other hand, what constitutes a text/html to text/plain conversion? Are we mandating, in effect, that all mailservers wishing to do content-conversion include a full W3C TR conformant text-based HTML renderer? I think we probably are, and that strikes me as considerable effort, not "fairly simple". Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Apr 16 16:01:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVDPf-0001QN-Vz; Sun, 16 Apr 2006 16:00:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVDPe-0001QI-Hn for lemonade@ietf.org; Sun, 16 Apr 2006 16:00:02 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVDPd-0004oo-4G for lemonade@ietf.org; Sun, 16 Apr 2006 16:00:02 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Sun, 16 Apr 2006 20:59:55 +0100 Message-ID: <4440DFCC.9090302@isode.com> Date: Sat, 15 Apr 2006 12:58:04 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: 'Enhancements to Internet email to support diverse service enivronments' , Chris Newman References: <443F824E.70601@isode.com> In-Reply-To: <443F824E.70601@isode.com> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [lemonade] Re: Question about BURL document X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org One more question: In section 6 ("Response Codes"): > 554 5.3.4 Message too big for system > > The message (subsequent to URL resolution) is larger than the per- > message size limit for this server. Shouldn't this be 552 5.3.4? RFC 2821 says: 552 Requested mail action aborted: exceeded storage allocation 554 Transaction failed (Or, in the case of a connection-opening response, "No SMTP service here") _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Apr 16 16:01:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVDPa-0001Q7-RP; Sun, 16 Apr 2006 15:59:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVDPZ-0001Pz-QN for lemonade@ietf.org; Sun, 16 Apr 2006 15:59:57 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVDPY-0004of-Bb for lemonade@ietf.org; Sun, 16 Apr 2006 15:59:57 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Sun, 16 Apr 2006 20:59:51 +0100 Message-ID: <443F824E.70601@isode.com> Date: Fri, 14 Apr 2006 12:06:54 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: 'Enhancements to Internet email to support diverse service enivronments' , Chris Newman MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Subject: [lemonade] Question about BURL document X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org RFC 3030 (CHUNKING) says: The BDAT command takes one required argument, the exact length of the data segment in octets. The message data is sent immediately after the trailing of the BDAT command line. Once the receiver-SMTP receives the specified number of octets, it will return a 250 reply code. While BURL says: 354 Waiting for additional BURL or BDAT commands A BURL command without the "LAST" modifier was sent. The URL for this BURL command was successfully resolved, but the content will not necessarily be committed to persistent storage until the rest of the message content is collected. For example, a Unix server may have written the content to a queue file buffer, but not yet performed an fsync() operation. If the server loses power, the content can still be lost. I thought that BDAT and BURL should behave almost identical. Differences such as this one will not help implementors, as it is so easy just to cut & paste BDAT code and modify it to support BURL. There are currently no examples in BURL showing multiple BDAT/BURL, so the 354 response code doesn't appear in any example. Can we change the BURL spec to return 250 in this case, to be the same as RFC 3030? Alexey _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Apr 16 16:01:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVDPf-0001QN-Vz; Sun, 16 Apr 2006 16:00:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVDPe-0001QI-Hn for lemonade@ietf.org; Sun, 16 Apr 2006 16:00:02 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVDPd-0004oo-4G for lemonade@ietf.org; Sun, 16 Apr 2006 16:00:02 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Sun, 16 Apr 2006 20:59:55 +0100 Message-ID: <4440DFCC.9090302@isode.com> Date: Sat, 15 Apr 2006 12:58:04 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: 'Enhancements to Internet email to support diverse service enivronments' , Chris Newman References: <443F824E.70601@isode.com> In-Reply-To: <443F824E.70601@isode.com> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [lemonade] Re: Question about BURL document X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org One more question: In section 6 ("Response Codes"): > 554 5.3.4 Message too big for system > > The message (subsequent to URL resolution) is larger than the per- > message size limit for this server. Shouldn't this be 552 5.3.4? RFC 2821 says: 552 Requested mail action aborted: exceeded storage allocation 554 Transaction failed (Or, in the case of a connection-opening response, "No SMTP service here") _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Apr 16 16:01:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVDPa-0001Q7-RP; Sun, 16 Apr 2006 15:59:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVDPZ-0001Pz-QN for lemonade@ietf.org; Sun, 16 Apr 2006 15:59:57 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVDPY-0004of-Bb for lemonade@ietf.org; Sun, 16 Apr 2006 15:59:57 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Sun, 16 Apr 2006 20:59:51 +0100 Message-ID: <443F824E.70601@isode.com> Date: Fri, 14 Apr 2006 12:06:54 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: 'Enhancements to Internet email to support diverse service enivronments' , Chris Newman MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Subject: [lemonade] Question about BURL document X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org RFC 3030 (CHUNKING) says: The BDAT command takes one required argument, the exact length of the data segment in octets. The message data is sent immediately after the trailing of the BDAT command line. Once the receiver-SMTP receives the specified number of octets, it will return a 250 reply code. While BURL says: 354 Waiting for additional BURL or BDAT commands A BURL command without the "LAST" modifier was sent. The URL for this BURL command was successfully resolved, but the content will not necessarily be committed to persistent storage until the rest of the message content is collected. For example, a Unix server may have written the content to a queue file buffer, but not yet performed an fsync() operation. If the server loses power, the content can still be lost. I thought that BDAT and BURL should behave almost identical. Differences such as this one will not help implementors, as it is so easy just to cut & paste BDAT code and modify it to support BURL. There are currently no examples in BURL showing multiple BDAT/BURL, so the 354 response code doesn't appear in any example. Can we change the BURL spec to return 250 in this case, to be the same as RFC 3030? Alexey _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Apr 16 17:49:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVF6c-000471-Tg; Sun, 16 Apr 2006 17:48:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVF6c-00046w-2G for lemonade@ietf.org; Sun, 16 Apr 2006 17:48:30 -0400 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVF6Y-0000Xv-Ng for lemonade@ietf.org; Sun, 16 Apr 2006 17:48:28 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M1BVAS90M8004R0O@mauve.mrochek.com> for lemonade@ietf.org; Sun, 16 Apr 2006 14:48:22 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1145224060; h=Date: From:Subject:MIME-version:Content-type; b=VDW18+dnovUlrtt5mV3QJ0vNz 9qlNEUdRyPa9Mp8zo5OjiVrmuzG+5na65Mre59CUWbH+jRE/ktnZo6v6l8hRg== Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M1AGSNVZ9S00007A@mauve.mrochek.com>; Sun, 16 Apr 2006 14:48:19 -0700 (PDT) To: Alexey Melnikov Message-id: <01M1BVAQETEC00007A@mauve.mrochek.com> Date: Sun, 16 Apr 2006 14:44:25 -0700 (PDT) From: Ned Freed Subject: Re: [lemonade] Question about BURL document In-reply-to: "Your message dated Fri, 14 Apr 2006 12:06:54 +0100" <443F824E.70601@isode.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed References: <443F824E.70601@isode.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: 'Enhancements to Internet email to support diverse service enivronments' , Chris Newman X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > RFC 3030 (CHUNKING) says: > The BDAT command > takes one required argument, the exact length of the data segment in > octets. The message data is sent immediately after the trailing > of the BDAT command line. Once the receiver-SMTP receives the > specified number of octets, it will return a 250 reply code. > While BURL says: > 354 Waiting for additional BURL or BDAT commands > A BURL command without the "LAST" modifier was sent. The URL for > this BURL command was successfully resolved, but the content will > not necessarily be committed to persistent storage until the rest > of the message content is collected. For example, a Unix server > may have written the content to a queue file buffer, but not yet > performed an fsync() operation. If the server loses power, the > content can still be lost. > I thought that BDAT and BURL should behave almost identical. Differences > such as this one will not help implementors, as it is so easy just to > cut & paste BDAT code and modify it to support BURL. > There are currently no examples in BURL showing multiple BDAT/BURL, so > the 354 response code doesn't appear in any example. > Can we change the BURL spec to return 250 in this case, to be the same > as RFC 3030? I thought we had already noted this as needing fixing, since in addition to the mismatch with BDAT it is a semantic mismatch with how 3yz statuses are used in DATA (the next thing the client sends with DATA is the the remainder of the current command, not a new command). I further note that the description of intermediate replies in both RFC 821 and RFC 2821 is poor and could use some wordsmithing. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Apr 16 17:52:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVF9W-0004HE-DF; Sun, 16 Apr 2006 17:51:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVF9V-0004H9-3y for lemonade@ietf.org; Sun, 16 Apr 2006 17:51:29 -0400 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVF9T-0000ca-Qj for lemonade@ietf.org; Sun, 16 Apr 2006 17:51:29 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M1BVEJ84K0005FTO@mauve.mrochek.com> for lemonade@ietf.org; Sun, 16 Apr 2006 14:51:24 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1145224242; h=Date: From:Subject:MIME-version:Content-type; b=ZxES23EKPd3kYLzACTzKQDoS3 5mr2VD9Zw14Af3jShuTNHYTz/C/stxBek9jHaKGVsE8Y0uen3q1p55VH7DHlg== Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M1AGSNVZ9S00007A@mauve.mrochek.com>; Sun, 16 Apr 2006 14:51:18 -0700 (PDT) To: Alexey Melnikov Message-id: <01M1BVEG1NXC00007A@mauve.mrochek.com> Date: Sun, 16 Apr 2006 14:49:45 -0700 (PDT) From: Ned Freed Subject: Re: [lemonade] Re: Question about BURL document In-reply-to: "Your message dated Sat, 15 Apr 2006 12:58:04 +0100" <4440DFCC.9090302@isode.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed References: <443F824E.70601@isode.com> <4440DFCC.9090302@isode.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: 'Enhancements to Internet email to support diverse service enivronments' , Chris Newman X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > One more question: > In section 6 ("Response Codes"): > > 554 5.3.4 Message too big for system > > > > The message (subsequent to URL resolution) is larger than the per- > > message size limit for this server. > Shouldn't this be 552 5.3.4? RFC 2821 says: > 552 Requested mail action aborted: exceeded storage allocation > 554 Transaction failed (Or, in the case of a connection-opening > response, "No SMTP service here") Yes, it should be 552. The one exception is a size error in reponse to RCPT TO, which needs to be something other than 552 to work around the bug in RFC 821. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Apr 16 20:06:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVHEr-0001H3-Ap; Sun, 16 Apr 2006 20:05:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVHEq-0001Gt-Cj for lemonade@ietf.org; Sun, 16 Apr 2006 20:05:08 -0400 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVHEm-0005j2-07 for lemonade@ietf.org; Sun, 16 Apr 2006 20:05:08 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M1C036APOG001PWD@mauve.mrochek.com> for lemonade@ietf.org; Sun, 16 Apr 2006 17:05:00 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1145232258; h=Date: From:Subject:MIME-version:Content-type; b=H9zPcD36JPrkGIlz/N54NWrL4 CyMtkWJKvEX1IrZ0Yxe+SzXz/JOXLwIoEwQ/g8LAWlwwphrnjGAh/mNBPtmYg== Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M1AGSNVZ9S00007A@mauve.mrochek.com>; Sun, 16 Apr 2006 17:04:58 -0700 (PDT) To: Dave Cridland Message-id: <01M1C0357BN000007A@mauve.mrochek.com> Date: Sun, 16 Apr 2006 16:58:11 -0700 (PDT) From: Ned Freed Subject: RE: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversions) In-reply-to: "Your message dated Sun, 16 Apr 2006 19:29:45 +0100" <7915.1145212186.189845@peirce.dave.cridland.net> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <330A23D8336C0346B5C1A5BB1966664702A91A7F@ATLANTIS.Brooktrout.com> <7915.1145212186.189845@peirce.dave.cridland.net> X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Enhancements to Internet email to support diverse service enivronments , Burger Eric X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > On Sun Apr 16 02:07:10 2006, Burger, Eric wrote: > > This is why I am not a fan of mandating the character set > > conversion to > > be our conversion. It would require us to document which mapping > > works, > > and that is WAY outside of our charter. > > > > > I'm not convinced that character set conversion requires documenting > clients incorrectly marking the character set. I appreciate that this > is, to a degree, ignoring the real world, however I don't think we > ought to be mandating heuristics to handle software errors of this > nature in a standards track proposal. I agree 100%. The problem of mislabelled material is insoluable in general - if it wasn't why would we need the labels to begin with? If we're to head down this slippery slope, we might as well deal with inappropriate file names on parts, and for that matter incorrect media types are not exactly unheard of. > Saying that servers MUST handle iso-8859-1 -> utf-8 is surely within > our charter, and as far as I'm aware that mapping works if the > character set used really is iso-8859-1 to begin with. If it isn't, > then the client is buggy, and how servers deal with buggy content is > entirely up to them. Exactly. > As for which character sets, I'd be perfectly content with utf-8 as > sole (required) output, and an almost random selection of character > sets as input. (Probably the top 5 or so used in real email. ASCII > ought to be fairly trivial). > I'm also still pondering Ned Freed's point that character set > conversion is a reasonable (and possibly essential) thing to include > within HTML conversion - if this is the case, we need to document > character set conversions anyway, and my suggestion is essentially a > text/plain=>text/plain conversion. (In other words, the parameters > form part of the type). I'm by no means sure they are esential, but I'm by no means sure they aren't. > On the other hand, what constitutes a text/html to text/plain > conversion? Are we mandating, in effect, that all mailservers wishing > to do content-conversion include a full W3C TR conformant text-based > HTML renderer? I think we probably are, and that strikes me as > considerable effort, not "fairly simple". I don't we really need to go that far. But I do think that finding the right language to describe what's required may be tricky. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Apr 17 04:50:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVPQ9-0001NY-Tz; Mon, 17 Apr 2006 04:49:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVPQ7-0001NT-Ui for lemonade@ietf.org; Mon, 17 Apr 2006 04:49:19 -0400 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVPQ5-0001Ha-Hh for lemonade@ietf.org; Mon, 17 Apr 2006 04:49:17 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1FVPQ3-0005Nm-HD; Mon, 17 Apr 2006 08:49:15 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 4BA3A498003; Mon, 17 Apr 2006 09:57:04 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09217-01; Mon, 17 Apr 2006 09:56:55 +0100 (BST) Received: from JOHN (unknown [IPv6:2001:4bd0:2029:0:ec98:d40e:61a9:422c]) by turner.dave.cridland.net (Postfix) with ESMTP id 2F4AB498002; Mon, 17 Apr 2006 09:56:53 +0100 (BST) Date: Mon, 17 Apr 2006 09:50:38 +0100 Subject: RE: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversions) References: <330A23D8336C0346B5C1A5BB1966664702A91A7F@ATLANTIS.Brooktrout.com> <7915.1145212186.189845@peirce.dave.cridland.net> <01M1C0357BN000007A@mauve.mrochek.com> In-Reply-To: <01M1C0357BN000007A@mauve.mrochek.com> MIME-Version: 1.0 Message-Id: <4032.1145263839.823000@JOHN> From: Dave Cridland To: Ned Freed Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Heisenberg-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Enhancements to Internet email to support diverse service enivronments , "Burger, Eric" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Mon Apr 17 00:58:11 2006, Ned Freed wrote: >> I'm also still pondering Ned Freed's point that character set >> conversion is a reasonable (and possibly essential) thing to >> include >> within HTML conversion - if this is the case, we need to document >> character set conversions anyway, and my suggestion is essentially >> a >> text/plain=>text/plain conversion. (In other words, the parameters >> form part of the type). > > I'm by no means sure they are esential, but I'm by no means sure > they aren't. > > I'm not sure either way, but the more I think about it, the more I suspect that, at the very least, a "pure" text/html => text/plain translation would have to mandate that the text/plain type included a charset parameter identical to that in the text/html type. Leaving it out implies the client is requesting a character set transform to ASCII. >> On the other hand, what constitutes a text/html to text/plain >> conversion? Are we mandating, in effect, that all mailservers >> wishing >> to do content-conversion include a full W3C TR conformant >> text-based >> HTML renderer? I think we probably are, and that strikes me as >> considerable effort, not "fairly simple". > > I don't we really need to go that far. But I do think that finding > the right > language to describe what's required may be tricky. > > It's not what I feel is required to satisfy the actual use-case - dragging the essential information from HTML into plain text - but I suspect that the only way of specifying what's requiredis to reference the W3C's documents. That in itself is fine, but pretty much rules out any possibility of advancing to Draft, because there's no realistic hope that email servers might provide a full text/plain renderer for HTML, when as far as I'm aware, nobody else ever has. I might be pessimistic, or Lynx or Links might actually be strictly conforming to the W3C's relevant TRs, however. On the other hand, if we try to specify what is, and is not, important information in an HTML document, I fear we'll be not only *way* outside charter - indeed, outside remit for the IETF - but it's really not somewhere I think we want to go anyway. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Apr 17 09:50:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVU76-0002GA-2F; Mon, 17 Apr 2006 09:50:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVU74-0002FO-9c for lemonade@ietf.org; Mon, 17 Apr 2006 09:49:58 -0400 Received: from out1.smtp.messagingengine.com ([66.111.4.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVU73-0006mU-3c for lemonade@ietf.org; Mon, 17 Apr 2006 09:49:58 -0400 Received: from frontend2.internal (frontend2.internal [10.202.2.151]) by frontend1.messagingengine.com (Postfix) with ESMTP id 47EDBD4C4FE; Mon, 17 Apr 2006 09:49:56 -0400 (EDT) Received: from frontend3.messagingengine.com ([10.202.2.152]) by frontend2.internal (MEProxy); Mon, 17 Apr 2006 09:49:25 -0400 X-Sasl-enc: ku6Jtiv7R3uzTrMd0CYMloFLAJxNW7UZSq20ZVTxZgIr 1145281765 Received: from [17.101.35.110] (unknown [17.101.35.110]) by www.fastmail.fm (Postfix) with ESMTP id A9433861F; Mon, 17 Apr 2006 09:49:24 -0400 (EDT) Date: Mon, 17 Apr 2006 09:51:06 -0400 From: Cyrus Daboo To: "Burger, Eric" , Enhancements to Internet email to support diverse serviceenivronments Subject: RE: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversions) Message-ID: <79CE69473F48D23D794FBD5F@Cyrus-Daboo.local> In-Reply-To: <330A23D8336C0346B5C1A5BB1966664702A91A7F@ATLANTIS.Brooktrout.com> References: <330A23D8336C0346B5C1A5BB1966664702A91A7F@ATLANTIS.Brooktrout.co m> X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Eric, --On April 15, 2006 9:07:10 PM -0400 "Burger, Eric" wrote: > This is why I am not a fan of mandating the character set conversion to > be our conversion. It would require us to document which mapping works, > and that is WAY outside of our charter. Based on my experience the problem with mislabeled character sets is likely to be much less of an issue to deal with than the problem of malformed HTML in text/html bodies. In either case I think both character set and html->plain should be mandated as they are very common operations that most client authors have dealt with one way or another. Really you can't do html->plain without addressing character set conversion one way or another - and it is worth noting that the character set conversion in the html case may not be triggered solely by the MIME content header parameter - there can also be a character set in the HTML and that and the MIME one may not be the same! -- Cyrus Daboo _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Apr 17 11:10:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVVNK-0005XZ-2L; Mon, 17 Apr 2006 11:10:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVVNI-0005XU-7V for lemonade@ietf.org; Mon, 17 Apr 2006 11:10:48 -0400 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVVNH-0002r0-PR for lemonade@ietf.org; Mon, 17 Apr 2006 11:10:48 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M1CVP3C7MO005GP7@mauve.mrochek.com> for lemonade@ietf.org; Mon, 17 Apr 2006 08:10:42 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1145286593; h=Date: From:Subject:MIME-version:Content-type; b=XOix5yvcrs9KG0Avc+DTO5Z0I zA0y3RG+M2MJ10IhNmYlTJvgaDyDc0c1Ve0QTZQM4KBSremDl15jcsnpgKElQ== Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M1AGSNVZ9S00007A@mauve.mrochek.com>; Mon, 17 Apr 2006 08:10:39 -0700 (PDT) To: Dave Cridland Message-id: <01M1CVP1XTEK00007A@mauve.mrochek.com> Date: Mon, 17 Apr 2006 08:03:52 -0700 (PDT) From: Ned Freed Subject: RE: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversions) In-reply-to: "Your message dated Mon, 17 Apr 2006 09:50:38 +0100" <4032.1145263839.823000@JOHN> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <330A23D8336C0346B5C1A5BB1966664702A91A7F@ATLANTIS.Brooktrout.com> <7915.1145212186.189845@peirce.dave.cridland.net> <01M1C0357BN000007A@mauve.mrochek.com> <4032.1145263839.823000@JOHN> X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Enhancements to Internet email to support diverse service enivronments , Ned Freed , Burger Eric X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > On Mon Apr 17 00:58:11 2006, Ned Freed wrote: > >> I'm also still pondering Ned Freed's point that character set > >> conversion is a reasonable (and possibly essential) thing to > >> include > >> within HTML conversion - if this is the case, we need to document > >> character set conversions anyway, and my suggestion is essentially > >> a > >> text/plain=>text/plain conversion. (In other words, the parameters > >> form part of the type). > > > > I'm by no means sure they are esential, but I'm by no means sure > > they aren't. > > > > > I'm not sure either way, but the more I think about it, the more I > suspect that, at the very least, a "pure" text/html => text/plain > translation would have to mandate that the text/plain type included a > charset parameter identical to that in the text/html type. Leaving it > out implies the client is requesting a character set transform to > ASCII. Well, sure, since the default charset for text/plain is US-ASCII. > >> On the other hand, what constitutes a text/html to text/plain > >> conversion? Are we mandating, in effect, that all mailservers > >> wishing > >> to do content-conversion include a full W3C TR conformant > >> text-based > >> HTML renderer? I think we probably are, and that strikes me as > >> considerable effort, not "fairly simple". > > > > I don't we really need to go that far. But I do think that finding > > the right language to describe what's required may be tricky. > It's not what I feel is required to satisfy the actual use-case - > dragging the essential information from HTML into plain text - but I > suspect that the only way of specifying what's requiredis to > reference the W3C's documents. That in itself is fine, but pretty > much rules out any possibility of advancing to Draft, because there's > no realistic hope that email servers might provide a full text/plain > renderer for HTML, when as far as I'm aware, nobody else ever has. I > might be pessimistic, or Lynx or Links might actually be strictly > conforming to the W3C's relevant TRs, however. I guess I still don't see the problem. Lossy and imperfect conversions of various sorts have been specified in an assortment of standards going back to 1984 (e.g., X.400-1984) if not earlier. Perfection isn't required; the only tricky thing is deciding how much imperfection is acceptable and how much specificity is needed. I'm far from convinced that language simply specifying a "best effort" conversion be done is unacceptable here. > On the other hand, if we try to specify what is, and is not, > important information in an HTML document, I fear we'll be not only > *way* outside charter - indeed, outside remit for the IETF - but it's > really not somewhere I think we want to go anyway. Agreed that that is a path to madness. But this is only an issue if we're required to open this particular cans of worms to proceed, and I'm still not hearing a justification for why we have to open it. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Apr 17 13:28:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVXWh-0006Dl-UQ; Mon, 17 Apr 2006 13:28:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVXWf-0006Ac-7L; Mon, 17 Apr 2006 13:28:37 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVXWe-0001wj-SN; Mon, 17 Apr 2006 13:28:37 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k3HHSaCH032495; Mon, 17 Apr 2006 10:28:36 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k3HHSa6p032494; Mon, 17 Apr 2006 10:28:36 -0700 Date: Mon, 17 Apr 2006 10:28:36 -0700 Message-Id: <200604171728.k3HHSa6p032494@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: lemonade@ietf.org, rfc-editor@rfc-editor.org Subject: [lemonade] RFC 4469 on Internet Message Access Protocol (IMAP) CATENATE 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: , Errors-To: lemonade-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4469 Title: Internet Message Access Protocol (IMAP) CATENATE Extension Author: P. Resnick Status: Standards Track Date: April 2006 Mailbox: presnick@qualcomm.com Pages: 13 Characters: 21822 Updates: RFC3501, RFC3502 See-Also: I-D Tag: draft-ietf-lemonade-catenate-05.txt URL: http://www.rfc-editor.org/rfc/rfc4469.txt The CATENATE extension to the Internet Message Access Protocol (IMAP) extends the APPEND command to allow clients to create messages on the IMAP server that may contain a combination of new data along with parts of (or entire) messages already on the server. Using this extension, the client can catenate parts of an already existing message onto a new message without having to first download the data and then upload it back to the server. [STANDARDS TRACK] This document is a product of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Apr 17 20:04:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVdhv-0002pO-KJ; Mon, 17 Apr 2006 20:04:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVdhu-0002pJ-Sf for lemonade@ietf.org; Mon, 17 Apr 2006 20:04:38 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVbwx-0000RZ-14 for lemonade@ietf.org; Mon, 17 Apr 2006 18:12:03 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FVbgF-0002MW-3k for lemonade@ietf.org; Mon, 17 Apr 2006 17:54:47 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3HLsjAU030591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 17 Apr 2006 14:54:45 -0700 Received: from [192.168.1.13] (loud.qualcomm.com [129.46.172.15]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3HLshex020113 for ; Mon, 17 Apr 2006 14:54:44 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <330A23D8336C0346B5C1A5BB1966664702A9183A@ATLANTIS.Brooktrout.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Mon, 17 Apr 2006 14:53:29 -0700 To: From: Randall Gellens Subject: RE: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversions) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: -2.6 (--) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 12:38 AM -0400 4/15/06, Robert A. Rosenberg wrote: > I will repeat my prior comment that one that would probably be > included (ISO-8859-1 <-> Unicode) can not be 100% successful (ie: > Accurate) in all cases due to there being 3 separate glyph mappings > that are marked in Email as ISO-8859-1. I agree with comments from Ned and others that we don't need (and it would be dangerous for us to attempt) to specify heuristics for recognizing and dealing with mislabeled charsets. However, something very much like Robert's description of the problem could be included as an informative aside ("Implementers may wish to note that, historically, clients have incorrectly labeled as ISO-8859-1 at least two different....") It seems to be helpful information that would be nice to have documented. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- The best way to have a good idea is to have lots of ideas. --Linus Pauling _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Apr 17 22:10:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVffU-0006Yz-Jh; Mon, 17 Apr 2006 22:10:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVffS-0006Yj-Pc for lemonade@ietf.org; Mon, 17 Apr 2006 22:10:14 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVePV-000171-2H for lemonade@ietf.org; Mon, 17 Apr 2006 20:49:41 -0400 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FVdvN-0003tW-Co for lemonade@ietf.org; Mon, 17 Apr 2006 20:18:35 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M1DEU5YWO000521Y@mauve.mrochek.com> for lemonade@ietf.org; Mon, 17 Apr 2006 17:18:25 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1145319452; h=Date: From:Subject:MIME-version:Content-type; b=VjH+kqigBWkhyrGirb7XdeIYT 9D7wVbPh+SApm9v1zZ65OpVrjD8wQ9Y7ZbEEaq6JuwLpJbfL0K9Kxtx6f/AXQ== Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M1D6XF9NK000007A@mauve.mrochek.com>; Mon, 17 Apr 2006 17:18:23 -0700 (PDT) To: Randall Gellens Message-id: <01M1DEU4ZOQU00007A@mauve.mrochek.com> Date: Mon, 17 Apr 2006 17:14:53 -0700 (PDT) From: Ned Freed Subject: RE: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversions) In-reply-to: "Your message dated Mon, 17 Apr 2006 14:53:29 -0700" MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <330A23D8336C0346B5C1A5BB1966664702A9183A@ATLANTIS.Brooktrout.com> X-Spam-Score: -2.6 (--) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > At 12:38 AM -0400 4/15/06, Robert A. Rosenberg wrote: > > I will repeat my prior comment that one that would probably be > > included (ISO-8859-1 <-> Unicode) can not be 100% successful (ie: > > Accurate) in all cases due to there being 3 separate glyph mappings > > that are marked in Email as ISO-8859-1. > I agree with comments from Ned and others that we don't need (and it > would be dangerous for us to attempt) to specify heuristics for > recognizing and dealing with mislabeled charsets. > However, something very much like Robert's description of the problem > could be included as an informative aside ("Implementers may wish to > note that, historically, clients have incorrectly labeled as > ISO-8859-1 at least two different....") It seems to be helpful > information that would be nice to have documented. I have no problem with including an informational note about these issues. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Apr 18 09:42:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVqSy-0003rK-Im; Tue, 18 Apr 2006 09:42:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVodU-0006sb-BF for lemonade@ietf.org; Tue, 18 Apr 2006 07:44:48 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVodS-00017J-LC for lemonade@ietf.org; Tue, 18 Apr 2006 07:44:48 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Tue, 18 Apr 2006 12:44:20 +0100 Message-ID: <4444D108.2090902@isode.com> Date: Tue, 18 Apr 2006 12:44:08 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Randall Gellens Subject: Re: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversions) References: <330A23D8336C0346B5C1A5BB1966664702A9183A@ATLANTIS.Brooktrout.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: 79899194edc4f33a41f49410777972f8 X-Mailman-Approved-At: Tue, 18 Apr 2006 09:42:03 -0400 Cc: support diverse service enivronments , Ned Freed , Enhancements, "Burger, Eric" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Randall Gellens wrote: > At 2:25 PM -0400 4/14/06, Eric Burger wrote: > >> I am leaning towards option 1 (HTML->text) as so far I hear one >> voice of >> dissent and I am worried about option 2 (character set conversions) >> leading to months of debate over which character sets need to be >> supported and how to deal with non-standard, but common, character set >> encodings. >> >> Thoughts? > > Sounds reasonable to me. Text to HTML is fairly simple, while > charsets tend to be more complicated then they seem. Randy, I think you underestimate the complexity of this. For example, how does one convert element to text? How to deal with column widths in percents and pixels, etc.? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Apr 18 17:22:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVxeV-0001Hr-JP; Tue, 18 Apr 2006 17:22:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVxeU-0001He-Gi for lemonade@ietf.org; Tue, 18 Apr 2006 17:22:26 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVxeT-0007YH-2u for lemonade@ietf.org; Tue, 18 Apr 2006 17:22:26 -0400 Received: from fe-amer-10.sun.com ([192.18.108.184]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k3ILMOmU013984 for ; Tue, 18 Apr 2006 15:22:24 -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 <0IXX00101SJK1200@mail-amer.sun.com> (original mail from peter.coates@sun.com) for lemonade@ietf.org; Tue, 18 Apr 2006 15:22:24 -0600 (MDT) Received: from Tundra ([129.150.34.43]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IXX00JRUSPANA20@mail-amer.sun.com> for lemonade@ietf.org; Tue, 18 Apr 2006 15:22:24 -0600 (MDT) Date: Tue, 18 Apr 2006 14:22:23 -0700 From: Peter Coates To: lemonade@ietf.org Message-id: <000001c6632e$2ff04a00$2b229681@Tundra> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcZjLi7MI1XDDw2SR9KtjtNBuQtatg== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [lemonade] append catenate error returns X-BeenThere: lemonade@ietf.org X-Mailman-Version: 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="===============1354756109==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============1354756109== Content-type: multipart/alternative; boundary="Boundary_(ID_CYu/1jFqZTLwuYCl9pNrnA)" This is a multi-part message in MIME format. --Boundary_(ID_CYu/1jFqZTLwuYCl9pNrnA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT I am surprised by the following paragraph in http://www.ietf.org/internet-drafts/draft-ietf-lemonade-catenate-05.txt Note: Use of an absolute IMAP URL or any URL that refers to anything other than a message or message part from the current authenticated IMAP session is outside of the scope of this document, would require an extension to this specification, and a server implementing only this specification would return NO to such a request. I would have thought that a client sending a URL of a form that does not meet the spec deservers a BAD response... Peter --Boundary_(ID_CYu/1jFqZTLwuYCl9pNrnA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
 
      Note: Use of an absolute IMAP URL or any URL that refers to
      anything other than a message or message part from the current
      authenticated IMAP session is outside of the scope of this
      document, would require an extension to this specification, and a
      server implementing only this specification would return NO to
      such a request.
I would have thought that a client sending a URL of a form that does not meet the spec deservers a BAD response...
 
Peter
--Boundary_(ID_CYu/1jFqZTLwuYCl9pNrnA)-- --===============1354756109== 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 --===============1354756109==-- From lemonade-bounces@ietf.org Tue Apr 18 17:32:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVxoI-0005zI-Bj; Tue, 18 Apr 2006 17:32:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVxoG-0005sG-E3 for lemonade@ietf.org; Tue, 18 Apr 2006 17:32:32 -0400 Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVxoE-000896-1p for lemonade@ietf.org; Tue, 18 Apr 2006 17:32:32 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout2.cac.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k3ILWSkZ013130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 18 Apr 2006 14:32: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.6+UW06.03/8.13.6+UW06.03) with ESMTP id k3ILWSgH018126 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 18 Apr 2006 14:32:28 -0700 Date: Tue, 18 Apr 2006 14:32:28 -0700 (Pacific Daylight Time) From: Mark Crispin To: Peter Coates Subject: Re: [lemonade] append catenate error returns In-Reply-To: <000001c6632e$2ff04a00$2b229681@Tundra> Message-ID: References: <000001c6632e$2ff04a00$2b229681@Tundra> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue, 18 Apr 2006, Peter Coates wrote: > I am surprised by the following paragraph in > http://www.ietf.org/internet-drafts/draft-ietf-lemonade-catenate-05.txt > > Note: Use of an absolute IMAP URL or any URL that refers to > anything other than a message or message part from the current > authenticated IMAP session is outside of the scope of this > document, would require an extension to this specification, and a > server implementing only this specification would return NO to > such a request. > > I would have thought that a client sending a URL of a form that does not > meet the spec deservers a BAD response... The form/syntax of the URL meets the specification. However, CATENATE does not, at the present time, require that a server implement URLs that refer to anything other than a message or message part from the current authenticated IMAP session. This is in keeping with the limited scope of Lemonade's charter. Nothing prevents a server from implementing more. -- 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 Apr 18 19:21:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVzW7-00045u-6n; Tue, 18 Apr 2006 19:21:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVzW5-00045p-HR for lemonade@ietf.org; Tue, 18 Apr 2006 19:21:53 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVzW4-0005Ts-7a for lemonade@ietf.org; Tue, 18 Apr 2006 19:21:53 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3INLkfN023755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 Apr 2006 16:21:47 -0700 Received: from [192.168.1.13] (loud.qualcomm.com [129.46.172.15]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3INLjuD018420; Tue, 18 Apr 2006 16:21:45 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <4444D108.2090902@isode.com> References: <330A23D8336C0346B5C1A5BB1966664702A9183A@ATLANTIS.Brooktrout.com> <4444D108.2090902@isode.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Tue, 18 Apr 2006 16:14:50 -0700 To: Alexey Melnikov From: Randall Gellens Subject: Re: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversions) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: support diverse service enivronments , Ned Freed , "Burger, Eric" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 12:44 PM +0100 4/18/06, Alexey Melnikov wrote: > I think you underestimate the complexity of this. > For example, how does one convert
element to text? How to > deal with column widths in percents and pixels, etc.? You're right, Alexey, I was overlooking aspects of this that add significant difficulty, such as tables. I was thinking of the Qpopper code that converts HTML to plain text. It does a decent job on the basic stuff (paragraphs, attributes, entities, etc.) I don't think it handles tables, though. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Nothing in the world is more dangerous than sincere ignorance and conscientious stupidity. --Martin Luther King, Jr. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Apr 19 07:29:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWArq-0004Y6-As; Wed, 19 Apr 2006 07:29:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWAro-0004Y0-U0 for lemonade@ietf.org; Wed, 19 Apr 2006 07:29:04 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWAro-0005nu-LW for lemonade@ietf.org; Wed, 19 Apr 2006 07:29:04 -0400 X-IronPort-AV: i="4.04,134,1144036800"; d="scan'208,217"; a="31456512:sNHT48990704" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Re: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversions) Date: Wed, 19 Apr 2006 07:31:51 -0400 Message-ID: <330A23D8336C0346B5C1A5BB196666470231C341@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversions) Thread-Index: AcZjP0O/GwP3A3N2Sy6fXOIScIVBegAZZZ4w From: "Burger, Eric" To: "Randall Gellens" , "Alexey Melnikov" X-Spam-Score: 0.5 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: support diverse service enivronments , Ned Freed X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0384207731==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============0384207731== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C663A4.DA3DF980" This is a multi-part message in MIME format. ------_=_NextPart_001_01C663A4.DA3DF980 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So here is the quandry: (1) define achievable subset of full HTML 4.01 = to text, (2) punt on what the result is supposed to look like and say do = full HTML, (3) really mandate full HTML to text, (4) do something else. You know, charset is beginning to not look so bad... -----Original Message----- From: Randall Gellens [mailto:randy@qualcomm.com] Sent: Tue Apr 18 19:24:39 2006 To: Alexey Melnikov Cc: support diverse service enivronments; Ned Freed; Burger, Eric Subject: Re: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversions) At 12:44 PM +0100 4/18/06, Alexey Melnikov wrote: > I think you underestimate the complexity of this. > For example, how does one convert
element to text? How to=20 > deal with column widths in percents and pixels, etc.? You're right, Alexey, I was overlooking aspects of this that add=20 significant difficulty, such as tables. I was thinking of the=20 Qpopper code that converts HTML to plain text. It does a decent job=20 on the basic stuff (paragraphs, attributes, entities, etc.) I don't=20 think it handles tables, though. --=20 Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Nothing in the world is more dangerous than sincere ignorance and conscientious stupidity. --Martin Luther King, Jr. ------_=_NextPart_001_01C663A4.DA3DF980 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: CALL FOR CONSENSUS (was RE: [lemonade] on MTI = conversions)

So here is the quandry: (1) define achievable subset = of full HTML 4.01 to text, (2) punt on what the result is supposed to = look like and say do full HTML, (3) really mandate full HTML to text, = (4) do something else.

You know, charset is beginning to not look so bad...

 -----Original Message-----
From:   Randall Gellens [mailto:randy@qualcomm.com]
Sent:   Tue Apr 18 19:24:39 2006
To:     Alexey Melnikov
Cc:     support diverse service enivronments; Ned = Freed; Burger, Eric
Subject:        Re: CALL FOR = CONSENSUS (was RE: [lemonade] on MTI conversions)

At 12:44 PM +0100 4/18/06, Alexey Melnikov wrote:

>  I think you underestimate the complexity of this.
>  For example, how does one convert <table> element to = text? How to
> deal with column widths in percents and pixels, etc.?

You're right, Alexey, I was overlooking aspects of this that add
significant difficulty, such as tables.  I was thinking of the
Qpopper code that converts HTML to plain text.  It does a decent = job
on the basic stuff (paragraphs, attributes, entities, etc.)  I = don't
think it handles tables, though.
--
Randall Gellens
Opinions are personal;    facts are = suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Nothing in the world is more dangerous than sincere ignorance and
conscientious stupidity.
          --Martin Luther = King, Jr.

------_=_NextPart_001_01C663A4.DA3DF980-- --===============0384207731== 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 --===============0384207731==-- From lemonade-bounces@ietf.org Thu Apr 20 19:31:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWicA-0001tG-AQ; Thu, 20 Apr 2006 19:31:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWic9-0001t9-46 for lemonade@ietf.org; Thu, 20 Apr 2006 19:31:09 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWic7-00005m-Q8 for lemonade@ietf.org; Thu, 20 Apr 2006 19:31:09 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3KNV6rc008230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 20 Apr 2006 16:31:07 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3KNV4lE010956 for ; Thu, 20 Apr 2006 16:31:05 -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: Thu, 20 Apr 2006 16:23:56 -0700 To: lemonade@ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [lemonade] A Few Comments on profile-bis-01 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org (1) I find the use of numeric references hard to read. For example: In the [14]/[15] variant of the Lemonade "forward without download" strategy, messages are initially composed and edited within an MUA. The [15] extension to [18] is then used to create the messages Please go back to using named references! (2) The text says that, after the message has been submitted, "The client marks the forwarded message on the IMAP server." This seems a little odd, since, especially in the CATENATE case, the message is submitted, not forwarded. Also, in the non-catenate case, parts of various messages are used in subsequent ones, which seems even less like forwarding. (3) Likewise, the description of the $Forwarded flag could be more clear that it also means "submitted". -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Computers are useless. They can only give you answers. --Pablo Picasso (1881-1973) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Apr 21 04:49:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWrKY-0000fj-2w; Fri, 21 Apr 2006 04:49:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWrKW-0000eb-1Z for lemonade@ietf.org; Fri, 21 Apr 2006 04:49:32 -0400 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWrJz-000137-TB for lemonade@ietf.org; Fri, 21 Apr 2006 04:49:02 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1FWrJy-0000vz-J8; Fri, 21 Apr 2006 08:48:58 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id C743E498003; Fri, 21 Apr 2006 09:57:27 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05702-06; Fri, 21 Apr 2006 09:57:19 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id B9E89498002; Fri, 21 Apr 2006 09:57:17 +0100 (BST) Date: Fri, 21 Apr 2006 09:48:47 +0100 Subject: Re: [lemonade] A Few Comments on profile-bis-01 References: In-Reply-To: MIME-Version: 1.0 Message-Id: <7915.1145609328.090776@peirce.dave.cridland.net> From: Dave Cridland To: Randall Gellens Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Heisenberg-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Fri Apr 21 00:23:56 2006, Randall Gellens wrote: > (1) I find the use of numeric references hard to read. For example: Yes, this is a teething issue with the switch to xml2rfc - it's simply a missing PI we need to add (I think that's been added now in the working copy, but I'll check). > (2) The text says that, after the message has been submitted, "The > client marks the forwarded message on the IMAP server." This seems > a little odd, since, especially in the CATENATE case, the message > is submitted, not forwarded. Also, in the non-catenate case, parts > of various messages are used in subsequent ones, which seems even > less like forwarding. > > Speaking personally, I'm in general agreement with you, and raised this use of $Forwarded as an issue in Profile 1, but the consensus went against me on the use of the flag. I think it's a little odd, too, but not exactly incorrect. Note that it's not the message that's being submitted that's being marked, but the message that's used as the source for the attachment, thus partially forwarded, so while it's not a traditional "forward", neither is it exactly not forwarding either. > (3) Likewise, the description of the $Forwarded flag could be more > clear that it also means "submitted". No, it doesn't - although the text relating to which message is being marked as $Forwarded ought to be clearer, if you're mislead here. I'll try to come up with some better text to describe what's going on. 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 Apr 21 15:33:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX1N3-0001lE-Dn; Fri, 21 Apr 2006 15:32:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX1N2-0001l9-FZ for lemonade@ietf.org; Fri, 21 Apr 2006 15:32:48 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FX1N2-0002Dv-4y for lemonade@ietf.org; Fri, 21 Apr 2006 15:32:48 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3LJWjIX020991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 21 Apr 2006 12:32:45 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3LJWhEn026012; Fri, 21 Apr 2006 12:32:44 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <7915.1145609328.090776@peirce.dave.cridland.net> References: <7915.1145609328.090776@peirce.dave.cridland.net> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Fri, 21 Apr 2006 12:32:41 -0700 To: Dave Cridland From: Randall Gellens Subject: Re: [lemonade] A Few Comments on profile-bis-01 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: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 9:48 AM +0100 4/21/06, Dave Cridland wrote: > On Fri Apr 21 00:23:56 2006, Randall Gellens wrote: >> (2) The text says that, after the message has been submitted, "The >> client marks the forwarded message on the IMAP server." This >> seems a little odd, since, especially in the CATENATE case, the >> message is submitted, not forwarded. Also, in the non-catenate >> case, parts of various messages are used in subsequent ones, which >> seems even less like forwarding. >> > Speaking personally, I'm in general agreement with you, and raised > this use of $Forwarded as an issue in Profile 1, but the consensus > went against me on the use of the flag. I think it's a little odd, > too, but not exactly incorrect. > > Note that it's not the message that's being submitted that's being > marked, but the message that's used as the source for the > attachment, thus partially forwarded, so while it's not a > traditional "forward", neither is it exactly not forwarding either. > >> (3) Likewise, the description of the $Forwarded flag could be more >> clear that it also means "submitted". > > No, it doesn't - although the text relating to which message is > being marked as $Forwarded ought to be clearer, if you're mislead > here. I'll try to come up with some better text to describe what's > going on. Thanks, Dave. So I now think we need two things: better text that describes how $Forwarded is used, and a way to mark a message as having been submitted. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Pohl's law: Nothing is so good that somebody, somewhere, will not hate it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Apr 21 18:57:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX4Yi-0007FG-Pr; Fri, 21 Apr 2006 18:57:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX4Yh-0007EM-Bc for lemonade@ietf.org; Fri, 21 Apr 2006 18:57:03 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FX4Yd-0005eX-WC for lemonade@ietf.org; Fri, 21 Apr 2006 18:57:03 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3LMuqtK031238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 21 Apr 2006 15:56:52 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3LMunZe022257; Fri, 21 Apr 2006 15:56:50 -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: Fri, 21 Apr 2006 15:54:17 -0700 To: Dave Cridland From: Randall Gellens Subject: Re: [lemonade] A Few Comments on profile-bis-01 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I suppose a client could mark all drafts with the \Draft flag, including those created with CATENATE, and could then remove the flag when the message has been sent. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- You may be recognized soon. Hide. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Apr 21 19:40:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX5EB-0002rU-Qm; Fri, 21 Apr 2006 19:39:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX5EB-0002rP-HB for lemonade@ietf.org; Fri, 21 Apr 2006 19:39:55 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FX5EA-0008D6-3s for lemonade@ietf.org; Fri, 21 Apr 2006 19:39:55 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3LNdq9F012442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 21 Apr 2006 16:39:52 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3LNdoKC006068 for ; Fri, 21 Apr 2006 16:39:51 -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: Fri, 21 Apr 2006 16:39:07 -0700 To: lemonade@ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [lemonade] binary? X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org What did we decide about BINARY? I recall some discussions on issues/difficulties with the fetch part (especially encrypted content), and some separate ones on the append part that might require an annotatemore element to identify mailboxes that can or cannot support it. But I'm not sure where we left things. I do recall that binary fetch was shown to be a bigger win than compression. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Everything is controlled by a small evil group to which, unfortunately, no one we know belongs. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Apr 24 09:17:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY0ws-0002kz-TK; Mon, 24 Apr 2006 09:17:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY0wq-0002kD-WC for lemonade@ietf.org; Mon, 24 Apr 2006 09:17:53 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY0wp-0003X7-Ho for lemonade@ietf.org; Mon, 24 Apr 2006 09:17:52 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id E624B4AC23 for ; Mon, 24 Apr 2006 15:17:49 +0200 (CEST) Message-Id: <5jqWiFjdklho6LijxgHdsA.md5@libertango.oryx.com> Date: Mon, 24 Apr 2006 15:20:12 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversions) References: <330A23D8336C0346B5C1A5BB1966664702A9183A@ATLANTIS.Brooktrout.com> <4444D108.2090902@isode.com> In-Reply-To: <4444D108.2090902@isode.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Alexey Melnikov writes: > Randy, I think you underestimate the complexity of this. > For example, how does one convert
element to text? How to deal > with column widths in percents and pixels, etc.? And how