Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VLURkT009076 for ; Fri, 31 Oct 2003 13:30:27 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VLURLb009075 for ietf-imapext-bks; Fri, 31 Oct 2003 13:30:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VLUPkT009068 for ; Fri, 31 Oct 2003 13:30:26 -0800 (PST) (envelope-from ned+imapext@innosoft.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01L2DSJNECA800Q4RU@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf-imapext@imc.org; Fri, 31 Oct 2003 13:30:26 -0800 (PST) Date: Fri, 31 Oct 2003 13:13:41 -0800 (PST) From: ned+imapext@INNOSOFT.COM Subject: Re: Jabbering - imapext@ietf.xmpp.org In-reply-to: "Your message dated Fri, 31 Oct 2003 13:47:06 -0700" <2147483647.1067608026@[192.168.42.6]> To: Lyndon Nerenberg Cc: Pete Resnick , ietf-imapext@imc.org Message-id: <01L2HAW0NET800Q4RU@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <2147483647.1067597124@[10.0.1.10]> <1476766497.1067594028@[192.168.42.6]> <2147483647.1067608026@[192.168.42.6]> Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > Did you have tool > > problems, or was the jabber scribe simply not saying anything > > comprehensible enough for you? > The problem with Jabber is that the scribe cannot keep up with the > discussion in real time. Well, it pretty much depends on how fast a typist you are. I've done this a couple of times, including one very busy ASRG meeting, and I think I've managed to keep up and cover the relevant points, but then again I'm a very fast typist. And if you do this you most certainly aren't going to be able to do much in the way of contributing to the discussion. It is also hard work by any measure, and not something I'd be willing to do for more than a couple of sessions at any given IETF. > And neither can the remote correspondents. Speaking as someone who has tried to participate remotely on a couple of occasions, the problem is usually not having enough information to keep up with rather than having too much. > And it > is impossible to transcribe the nuances of the conversation on the fly, and > without that context it's very easy to misinterpret what's really being > said. (I used to work for a court reporting company. There is a reason > those people get paid as much as they do.) Indeed. Transcription is in all its various forms is clearly an art, and it is silly to believe that any random person will be able to do it well. (Not even when we're talking about random IETF attendees.) Clearly this is no real substitute for actually being there. > > > The mailing lists are not broken -- let's not try to fix them. > > And this has what to do with the existence of the jabber room? > Everything. We're talking about communication within the WG. I am making > the claim that the mailing list is a useful and appropriate tool for the WG > members to communicate -- accurately -- their thoughts. I am also making > the claim that Jabber does not allow for accurate communication, and is the > wrong tool to solve this problem (if indeed there really is a problem here > that needs solving). Hmm. Well, I think I see your point, but on the other hand, the ability to talk to the chair right away when issues come up is an intriguing one that may have some real advantages. I think it is worth trying at least. If it helps, great, and if it sucks we'll at least have learned something. Ned Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VKlDkT007388 for ; Fri, 31 Oct 2003 12:47:14 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VKlDRk007387 for ietf-imapext-bks; Fri, 31 Oct 2003 12:47:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VKlCkT007382 for ; Fri, 31 Oct 2003 12:47:12 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from [192.168.42.6] (peregrin.orthanc.ca [192.168.42.6]) by orthanc.ca (8.12.9p1/8.12.9) with ESMTP id h9VKlAP5033354; Fri, 31 Oct 2003 13:47:11 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Fri, 31 Oct 2003 13:47:06 -0700 From: Lyndon Nerenberg To: Pete Resnick cc: ietf-imapext@imc.org Subject: Re: Jabbering - imapext@ietf.xmpp.org Message-ID: <2147483647.1067608026@[192.168.42.6]> In-Reply-To: References: <2147483647.1067597124@[10.0.1.10]> <1476766497.1067594028@[192.168.42.6]> X-Mailer: Mulberry/3.1.0b9 (Mac OS X Demo) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Did you have tool > problems, or was the jabber scribe simply not saying anything > comprehensible enough for you? The problem with Jabber is that the scribe cannot keep up with the discussion in real time. And neither can the remote correspondents. And it is impossible to transcribe the nuances of the conversation on the fly, and without that context it's very easy to misinterpret what's really being said. (I used to work for a court reporting company. There is a reason those people get paid as much as they do.) >> The mailing lists are not broken -- let's not try to fix them. > > And this has what to do with the existence of the jabber room? Everything. We're talking about communication within the WG. I am making the claim that the mailing list is a useful and appropriate tool for the WG members to communicate -- accurately -- their thoughts. I am also making the claim that Jabber does not allow for accurate communication, and is the wrong tool to solve this problem (if indeed there really is a problem here that needs solving). --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VHXikT099203 for ; Fri, 31 Oct 2003 09:33:44 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VHXi0T099202 for ietf-imapext-bks; Fri, 31 Oct 2003 09:33:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from episteme-software.com (216-43-25-66.ip.mcleodusa.net [216.43.25.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VHXhkT099197 for ; Fri, 31 Oct 2003 09:33:43 -0800 (PST) (envelope-from presnick@qualcomm.com) Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b1); Fri, 31 Oct 2003 11:33:44 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <1476766497.1067594028@[192.168.42.6]> References: <2147483647.1067597124@[10.0.1.10]> <1476766497.1067594028@[192.168.42.6]> X-Mailer: Eudora [Macintosh version 6.1a2] Date: Fri, 31 Oct 2003 11:33:42 -0600 To: Lyndon Nerenberg From: Pete Resnick Subject: Re: Jabbering - imapext@ietf.xmpp.org Cc: ietf-imapext@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 10/31/03 at 9:53 AM -0700, Lyndon Nerenberg wrote: >My experience with jabber over the last few IETFs is that it's >nothing more than a pain in the a**. I've successfully used jabber during the face-to-face, both for watching side commentary while in a large session (to ask questions for simple things while the session is going on) as well as watching what was going on in a session I couldn't be at while in another room. Did you have tool problems, or was the jabber scribe simply not saying anything comprehensible enough for you? >The mailing lists are not broken -- let's not try to fix them. And this has what to do with the existence of the jabber room? Again, the jabber room is NOT trying to fix anything about the mailing list, and it's CERTAINLY NOT trying to replace it for official business. It's another channel of communication (just like private e-mail between members of a working group) where people can work minor things out without wasting the time of the entire working group. Is there some problem with that? pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VGrvkT097820 for ; Fri, 31 Oct 2003 08:53:57 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VGrvLm097819 for ietf-imapext-bks; Fri, 31 Oct 2003 08:53:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VGrukT097807 for ; Fri, 31 Oct 2003 08:53:56 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from [192.168.42.6] (peregrin.orthanc.ca [192.168.42.6]) by orthanc.ca (8.12.9p1/8.12.9) with ESMTP id h9VGrrP5032257 for ; Fri, 31 Oct 2003 09:53:54 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Fri, 31 Oct 2003 09:53:48 -0700 From: Lyndon Nerenberg To: ietf-imapext@imc.org Subject: Re: Jabbering - imapext@ietf.xmpp.org Message-ID: <1476766497.1067594028@[192.168.42.6]> In-Reply-To: References: <2147483647.1067597124@[10.0.1.10]> X-Mailer: Mulberry/3.1.0b9 (Mac OS X Demo) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Absolutely, though my feeling is that serious discussions should *not* > take place in jabber at this point. My experience with jabber over the last few IETFs is that it's nothing more than a pain in the a**. The mailing lists are not broken -- let's not try to fix them. --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VFoJkT095439 for ; Fri, 31 Oct 2003 07:50:19 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VFoIBR095438 for ietf-imapext-bks; Fri, 31 Oct 2003 07:50:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from episteme-software.com (216-43-25-66.ip.mcleodusa.net [216.43.25.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VFoHkT095424 for ; Fri, 31 Oct 2003 07:50:17 -0800 (PST) (envelope-from presnick@qualcomm.com) Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b1); Fri, 31 Oct 2003 09:50:17 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <2147483647.1067597124@[10.0.1.10]> References: <2147483647.1067597124@[10.0.1.10]> X-Mailer: Eudora [Macintosh version 6.1a2] Date: Fri, 31 Oct 2003 09:50:15 -0600 To: Cyrus Daboo From: Pete Resnick Subject: Re: Jabbering - imapext@ietf.xmpp.org Cc: ietf-imapext@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 10/31/03 at 10:45 AM -0500, Cyrus Daboo wrote: >If serious discussions are going to take place on the jabber list, >is it possible to have some summary of those posted to the email list Absolutely, though my feeling is that serious discussions should *not* take place in jabber at this point. Jabber might be a nice way, if someone happens to be around, to ask a quick "Hey, what's the status of my draft?" or "I don't understand a piece of this draft. Can someone explain what I'm missing, or should I bring this to the author as a problem?" kind of question. I expect serious issue discussions to always be on the list. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VFjPkT095289 for ; Fri, 31 Oct 2003 07:45:25 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VFjOY3095288 for ietf-imapext-bks; Fri, 31 Oct 2003 07:45:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VFjKkT095279 for ; Fri, 31 Oct 2003 07:45:23 -0800 (PST) (envelope-from daboo@cyrusoft.com) Received: from [63.163.82.24] (socrates.cyrusoft.com [63.163.82.24]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id h9VFbNEG017283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Oct 2003 10:37:23 -0500 Date: Fri, 31 Oct 2003 10:45:24 -0500 From: Cyrus Daboo To: Pete Resnick , ietf-imapext@imc.org Subject: Re: Jabbering - imapext@ietf.xmpp.org Message-ID: <2147483647.1067597124@[10.0.1.10]> In-Reply-To: References: X-Mailer: Mulberry/3.1.0b9 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Pete, - --On Thursday, October 30, 2003 23:21 -0600 Pete Resnick wrote: | Just to let folks know: I plan to "hang out" in the IMAPEXT room on the | new jabber server that Marshall recently announced. Everyone should feel | free to "hang out" or drop in for group related questions. Frankly, right now I have enough trouble keeping up with email, let alone anything that's more 'real-time' than that. If serious discussions are going to take place on the jabber list, is it possible to have some summary of those posted to the email list (I'm not talking about a URL to jabber archive but a real email message with any jabber discussions from the last week, say). - -- Cyrus Daboo -----BEGIN PGP SIGNATURE----- Version: Mulberry PGP Plugin v3.0 Comment: processed by Mulberry PGP Plugin iQA/AwUBP6KDmSK4BGrbmMvFEQIjzwCbBS96sJcnI6ZBXWQMUz6MXjVK1BYAoIV4 mDmg+d51OEgdWj4FB6e6u9V+ =wL9q -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9V5LFkT005158 for ; Thu, 30 Oct 2003 21:21:15 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9V5LFLl005157 for ietf-imapext-bks; Thu, 30 Oct 2003 21:21:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from episteme-software.com (216-43-25-66.ip.mcleodusa.net [216.43.25.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9V5LEkT005152 for ; Thu, 30 Oct 2003 21:21:14 -0800 (PST) (envelope-from presnick@qualcomm.com) Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b1) for ; Thu, 30 Oct 2003 23:21:16 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: X-Mailer: Eudora [Macintosh version 6.1a2] Date: Thu, 30 Oct 2003 23:21:14 -0600 To: ietf-imapext@imc.org From: Pete Resnick Subject: Jabbering - imapext@ietf.xmpp.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Just to let folks know: I plan to "hang out" in the IMAPEXT room on the new jabber server that Marshall recently announced. Everyone should feel free to "hang out" or drop in for group related questions. -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UHnCkT075986 for ; Thu, 30 Oct 2003 09:49:12 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UHnC1V075985 for ietf-imapext-bks; Thu, 30 Oct 2003 09:49:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UHnBkT075979 for ; Thu, 30 Oct 2003 09:49:11 -0800 (PST) (envelope-from ned+imapext@innosoft.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01L2FM9SPCDS00D1EZ@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf-imapext@imc.org; Thu, 30 Oct 2003 09:49:11 -0800 (PST) Date: Thu, 30 Oct 2003 09:28:58 -0800 (PST) From: ned+imapext@INNOSOFT.COM Subject: IESG review of draft-ietf-imapext-condstore-04.txt To: IMAP extensions Mailing List Message-id: <01L2FOVDLGWI00D1EZ@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG reviewed this document today, and Ted Hardie has recorded the following discuss comments: ---- Section 3.2 says: Note: A client trying to make an atomic change to the state of a particular metadata item (or a set of metadata items) should be prepared to deal with the case when the server returns MODIFIED response code if the state of the metadata item being watched hasn't changed (but the state of some other metadata item has). This is necessary, because some servers don't store separate mod-sequences for different metadata items. However, a server implementation SHOULD avoid generating spurious MODIFIED responses for +FLAGS/-FLAGS STORE operations, even when the server stores a single mod-sequence per message. Upon the receipt of MODIFIED response code the client SHOULD try to figure out if the required metadata items have indeed changed. If they haven't the client SHOULD retry the command. First, this is a classic case of IMAP being so server focused as to make a client's life hell. In order to avoid keeping per-metadatum state, the protocol now forces client round trips to check that what it wants to change isn't the bit that has already been changed. While I won't challenge that design choice based on my own preference, I'm not sure that I believe "SHOULD try to figure out" is a realistic piece of protocol specification, and seeing it in a document about conditional storage makes my head hurt. Cleaning up the language so it is clear exactly what the client has to do would be useful. I also think the sentence "a server implementation SHOULD avoid generating spurious MODIFIED responses for +FLAGS/-FLAGS STORE operations, even when the server stores a single mod-sequence per message" doesn't make any sense. What is the server supposed to do here? Not send a modified response even though it knows something changed and doesn't know what, based on some extra-protocol knowledge? This doesn't seem like a win for interoperability. If it doesn't know what changed (because it is using a single mod-sequence) it's not spurious, just lame. I believe we normally have documents that update other RFCs mention that in the abstract, and since this does, it probably ought to. ---- Ned Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TNfnkT052344 for ; Wed, 29 Oct 2003 15:41:49 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TNfnaJ052338 for ietf-imapext-bks; Wed, 29 Oct 2003 15:41:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from sentosa.post1.com (sentosa.post1.com [202.27.17.100]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9TNfikT052305 for ; Wed, 29 Oct 2003 15:41:44 -0800 (PST) (envelope-from jseng@pobox.org.sg) Received: (qmail 42733 invoked from network); 30 Oct 2003 00:00:08 -0000 Received: from p5200-ipad75marunouchi.tokyo.ocn.ne.jp (HELO pobox.org.sg) (220.107.220.200) by sentosa.post1.com with SMTP; 30 Oct 2003 00:00:08 -0000 Message-ID: <3FA04E1E.9070906@pobox.org.sg> Date: Thu, 30 Oct 2003 07:32:46 +0800 From: James Seng User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: Mark Crispin CC: Abhijit Menon-Sen , ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, ietf-imapext@imc.org, ietf-smtp@imc.org Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) References: <00fd01c39ce8$b6f19fe0$79d52b09@DAVIS1> <014c01c39cf4$5675cd60$79d52b09@DAVIS1> <20031028095243.A1525@lustre.dyn.wiw.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > I do not believe that this is true for Chinese. AFAIK, Chinese primary > school kids use Latin script with hanyu-pinyin as a stopgap prior to their > mastery of Han script (which takes many years). Nope. Hanyu Pinyin was designed to replace the Han ideograph but it never did. > Note that when I say "recognize Latin script", I mean the ability to > determine that "dog" is a three-letter word that has the letters "d", "o", > and "g", each of which the individual recognizes and can name. This does > not include the ability to recognize that this refers to a domesticated > canine. Based on your reasonings, I think we should all reverted back to numbers, because that is the only universal recongizable set of symbols we have. We have this argument in IDN before and we certainly dont need this again. If you feel we should all stick to Latin, yes, you are entitled to your opinion but please do so in other place, and not here. The group is suppose to work on Internationalization of Email address (identifiers), not debate whether we need it or not. -James Seng Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TNfVkT052285 for ; Wed, 29 Oct 2003 15:41:31 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TNfVi5052280 for ietf-imapext-bks; Wed, 29 Oct 2003 15:41:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from sentosa.post1.com (sentosa.post1.com [202.27.17.100]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9TNfQkT052246 for ; Wed, 29 Oct 2003 15:41:26 -0800 (PST) (envelope-from jseng@pobox.org.sg) Received: (qmail 42705 invoked from network); 29 Oct 2003 23:59:48 -0000 Received: from p5200-ipad75marunouchi.tokyo.ocn.ne.jp (HELO pobox.org.sg) (220.107.220.200) by sentosa.post1.com with SMTP; 29 Oct 2003 23:59:48 -0000 Message-ID: <3FA04CA4.6050409@pobox.org.sg> Date: Thu, 30 Oct 2003 07:26:28 +0800 From: James Seng User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: Mark Crispin CC: Mark Davis , Keith Moore , dcrocker@brandenburg.com, paf@cisco.com, ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, IMAP Extensions WG , ietf-smtp@imc.org, presnick@qualcomm.com, hardie@qualcomm.com, ned.freed@mrochek.com Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA) References: <00fd01c39ce8$b6f19fe0$79d52b09@DAVIS1> <014c01c39cf4$5675cd60$79d52b09@DAVIS1> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Crispin, You need to get out of US (or Wsshington) more often. -James Seng > I am not convinced that it is possible to use a computer on the Internet > anywhere in the world without at least a basic acquaintance with Latin > script. > > I do not believe many individuals (other than primary school children) are > literate in their native language but are completely illiterate in Latin > script. This does not mean "being able to read or write the English > language"; rather, this simply means knowing the Latin script alphabet. > > Put another way, individuals who are completely illiterate in Latin script > are also likely to be illiterate in their native language script as well. > > No other script on the planet has such international recognition. > > There is undoubtably a *preference* for one's native script; and that > preference should be respected as much as possible. > > -- Mark -- > > http://staff.washington.edu/mrc > Science does not emerge from voting, party politics, or public debate. > Si vis pacem, para bellum. > > > > > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TNIvkT050958 for ; Wed, 29 Oct 2003 15:18:57 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TNIv96050957 for ietf-imapext-bks; Wed, 29 Oct 2003 15:18:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TNIqkT050926; Wed, 29 Oct 2003 15:18:52 -0800 (PST) (envelope-from michelsu@windows.microsoft.com) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 29 Oct 2003 15:18:49 -0800 Received: from 157.54.8.109 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 29 Oct 2003 15:18:49 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 29 Oct 2003 15:18:49 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 29 Oct 2003 15:19:48 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 29 Oct 2003 15:18:47 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [idn] FYI: BOF on Internationalized Email Addresses (IEA) Date: Wed, 29 Oct 2003 15:18:45 -0800 Message-ID: <84DD35E3DD87D5489AC42A59926DABE9046E700D@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [idn] FYI: BOF on Internationalized Email Addresses (IEA) thread-index: AcOc5UacENkLjcQgTxGePqP067EdhwBjOJ7A From: "Michel Suignard" To: "James Seng" , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: , , , , , , , , , "Pete Resnick" , "Ted Hardie" , "Ned Freed" X-OriginalArrivalTime: 29 Oct 2003 23:18:47.0668 (UTC) FILETIME=[014BD340:01C39E73] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9TNIqkU050935 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: JS>I seen John and Paul proposal but I have not seen Michel. Is there a draft that I can read JS>up? I don't have a proposal. I am listed there as a co-editor of the IRI spec which has a peripheral impact on the IEA (such as extending the URI mailto scheme). Like many I am listening with interest to the points made for or against the two proposals. Michel Suignard Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TLIakT045160 for ; Wed, 29 Oct 2003 13:18:36 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TLIaLf045157 for ietf-imapext-bks; Wed, 29 Oct 2003 13:18:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp1.andrew.cmu.edu (SMTP1.andrew.cmu.edu [128.2.10.81]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TLIZkT045147 for ; Wed, 29 Oct 2003 13:18:35 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9TLIaE7008121; Wed, 29 Oct 2003 16:18:36 -0500 Date: Wed, 29 Oct 2003 16:18:35 -0500 (EST) From: Rob Siemborski To: Cyrus Daboo cc: ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt In-Reply-To: <2147483647.1067444221@[10.0.1.5]> Message-ID: References: <200310131515.LAA10872@ietf.org> <2147483647.1067444221@[10.0.1.5]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 29 Oct 2003, Cyrus Daboo wrote: > | This version includes the change in the capability name as well as the > | revised base64 text. > > Minor point from the protocol police: the examples are all missing the > tagged OK for the CAPABILITY command. Oh! How embarrassing. Thanks, this will be fixed. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TLH1kT045063 for ; Wed, 29 Oct 2003 13:17:01 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TLH1go045062 for ietf-imapext-bks; Wed, 29 Oct 2003 13:17:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TLGxkT045055 for ; Wed, 29 Oct 2003 13:17:00 -0800 (PST) (envelope-from daboo@cyrusoft.com) Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [63.163.82.24]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id h9TL9HEG020889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2003 16:09:20 -0500 Date: Wed, 29 Oct 2003 16:17:01 -0500 From: Cyrus Daboo To: Rob Siemborski , ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt Message-ID: <2147483647.1067444221@[10.0.1.5]> In-Reply-To: References: <200310131515.LAA10872@ietf.org> X-Mailer: Mulberry/3.1.0b9 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Rob, --On Wednesday, October 29, 2003 16:02 -0500 Rob Siemborski wrote: | Since the ID editor apparently ate the update I tried to post to this | document, I have posted an updated version of it here: | | http://www.contrib.andrew.cmu.edu/~rjs3/ietf/draft-siemborski-imap-sasl-i | nitial-response-01b.txt | | This version includes the change in the capability name as well as the | revised base64 text. Minor point from the protocol police: the examples are all missing the tagged OK for the CAPABILITY command. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TL2VkT044405 for ; Wed, 29 Oct 2003 13:02:31 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TL2VsJ044404 for ietf-imapext-bks; Wed, 29 Oct 2003 13:02:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp1.andrew.cmu.edu (SMTP1.andrew.cmu.edu [128.2.10.81]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TL2UkT044397 for ; Wed, 29 Oct 2003 13:02:30 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from CYRUS.andrew.cmu.edu (CYRUS.andrew.cmu.edu [128.2.10.175]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9TL2WE7007334 for ; Wed, 29 Oct 2003 16:02:32 -0500 Date: Wed, 29 Oct 2003 16:02:30 -0500 (EST) From: Rob Siemborski To: ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt In-Reply-To: <200310131515.LAA10872@ietf.org> Message-ID: References: <200310131515.LAA10872@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 13 Oct 2003 Internet-Drafts@ietf.org wrote: > Title : IMAP Extension for SASL Initial Client Response > Author(s) : R. Siemborski > Filename : draft-siemborski-imap-sasl-initial-response-00.txt > Pages : 7 > Date : 2003-10-10 Since the ID editor apparently ate the update I tried to post to this document, I have posted an updated version of it here: http://www.contrib.andrew.cmu.edu/~rjs3/ietf/draft-siemborski-imap-sasl-initial-response-01b.txt This version includes the change in the capability name as well as the revised base64 text. So, who's coming to IETF-58? -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TGjSkT028908 for ; Wed, 29 Oct 2003 08:45:28 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TGjREH028907 for ietf-imapext-bks; Wed, 29 Oct 2003 08:45:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from relay-6m.club-internet.fr (relay-6m.club-internet.fr [194.158.104.45]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TGjMkT028887; Wed, 29 Oct 2003 08:45:22 -0800 (PST) (envelope-from jefsey@club-internet.fr) Received: from jfc2.club-internet.fr (f02v-21-20.d0.club-internet.fr [212.195.240.20]) by relay-6m.club-internet.fr (Postfix) with ESMTP id A66FC2567A; Wed, 29 Oct 2003 17:45:14 +0100 (CET) Message-Id: <6.0.0.22.2.20031029163607.04355ba0@mail.club-internet.fr> X-Sender: jefsey@mail.club-internet.fr X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 29 Oct 2003 16:50:39 +0100 To: Zefram From: "J-F C. (Jefsey) Morfin" Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) Cc: Dave Crocker , ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, ietf-imapext@imc.org, ietf-smtp@imc.org In-Reply-To: <20031028093114.GC20198@fysh.org> References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com> <12228881609.20031027074111@brandenburg.com> <20031027105222.4eae54fd.moore@cs.utk.edu> <355752681.20031027161925@brandenburg.com> <20031028093114.GC20198@fysh.org> Mime-Version: 1.0 Content-Type: text/plain; x-avg-checked=avg-ok-6A73736C; charset=us-ascii; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 10:31 28/10/03, Zefram said: >I think the first task in this area should be to investigate the nature >and degree of desire for non-ASCII local parts. This desire needs to be >weighed against the benefits we derive from writing all local parts in a >small, fixed alphabet (ASCII printables). May I ask which part of the world you come from? This being said only Americans want/are satisfied with "internationalized" (sic) names (the artificial extension of the American character set with most of the American foreign scripting, within an ascii frame). No one really wants multilingual names (a totally internationalized (sic) frame supporting languages and therefore some language oriented rules - at least ni management and user support). The users need vernacular support, that is to be able to freely do in the mail what they use to do elsewhere. I note that for non-American writers "international names" means names that everyone from every nation will understand. It happens to be the ascii character set limited to the DNS used names (they were selected for that reason). jfc Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T1fGI7016916 for ; Tue, 28 Oct 2003 17:41:16 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T1fGmp016915 for ietf-imapext-bks; Tue, 28 Oct 2003 17:41:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from [63.202.92.152] (adsl-66-125-125-69.dsl.pltn13.pacbell.net [66.125.125.69]) (authenticated bits=0) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T1f6I8016895; Tue, 28 Oct 2003 17:41:06 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Tue, 28 Oct 2003 17:41:55 -0800 To: Margaret.Wasserman@nokia.com, , , , , , , , , From: Paul Hoffman / IMC Subject: Location of the IMAA list (was: RE: FYI: BOF on Internationalized Email Addresses (IEA)) Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:54 AM -0500 10/28/03, Margaret.Wasserman@nokia.com wrote: >The BOF description lists imaa@imc.org as the >discussion list, but this discussion is being >cc:ed to ietf-imaa@imc.org. I'd suggest that you >move this discussion to whichever of those lists >is actually correct. It is ietf-imaa@imc.org, although because Patrik sent out the wrong address, I have made sure that both addresses work. An archive of the list, and links to the current versions of the drafts, can be found at . No more messages to all lists: that's what the IMAA list is for. --Paul Hoffman, Director --Internet Mail Consortium Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T08MI7012949 for ; Tue, 28 Oct 2003 16:08:22 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T08Mhv012948 for ietf-imapext-bks; Tue, 28 Oct 2003 16:08:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from hatl0ms21.CORP.COX.COM (lakehearnglobal.coxinc.com [206.157.224.254]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T08FI7012920; Tue, 28 Oct 2003 16:08:16 -0800 (PST) (envelope-from Valdis.Kletnieks@vt.edu) Received: from catl0ms22.corp.cox.com ([10.62.200.101]) by hatl0ms21.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Tue, 28 Oct 2003 19:08:13 -0500 Received: from mail pickup service by catl0ms22.corp.cox.com with Microsoft SMTPSVC; Tue, 28 Oct 2003 18:58:56 -0500 Received: from hatl0ms22.CORP.COX.COM ([10.62.201.69]) by catl0ms22.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 28 Oct 2003 16:35:02 -0500 Received: from bastion2.cox.com ([10.225.2.51]) by hatl0ms22.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Tue, 28 Oct 2003 16:28:31 -0500 Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by bastion2.cox.com (8.11.7p1+Sun/8.11.6) with SMTP id h9SLSRO10130; Tue, 28 Oct 2003 16:28:28 -0500 (EST) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1AEajF-0001VS-2l for ietf-list@asgard.ietf.org; Tue, 28 Oct 2003 15:46:13 -0500 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1AEa7u-00033N-AZ for ietf@asgard.ietf.org; Tue, 28 Oct 2003 15:07:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20519; Tue, 28 Oct 2003 15:07:26 -0500 (EST) From: Valdis.Kletnieks@vt.edu Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEa7s-0005if-00; Tue, 28 Oct 2003 15:07:36 -0500 Received: from turing-police.cc.vt.edu ([128.173.14.107]) by ietf-mx with esmtp (Exim 4.12) id 1AEa7r-0005iU-00; Tue, 28 Oct 2003 15:07:35 -0500 Received: from turing-police.cc.vt.edu (IDENT:valdis@localhost [127.0.0.1]) by turing-police.cc.vt.edu (8.12.10/8.12.10) with ESMTP id h9SK7J6P004972; Tue, 28 Oct 2003 15:07:19 -0500 Message-Id: <200310282007.h9SK7J6P004972@turing-police.cc.vt.edu> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4+dev To: Mark Davis Cc: Mark Crispin , Keith Moore , dcrocker@brandenburg.com, paf@cisco.com, ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, IMAP Extensions WG , ietf-smtp@imc.org, presnick@qualcomm.com, hardie@qualcomm.com, ned.freed@mrochek.com Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA) In-Reply-To: Your message of "Mon, 27 Oct 2003 17:39:32 PST." <014c01c39cf4$5675cd60$79d52b09@DAVIS1> References: <00fd01c39ce8$b6f19fe0$79d52b09@DAVIS1> <014c01c39cf4$5675cd60$79d52b09@DAVIS1> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1503687178P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Tue, 28 Oct 2003 15:07:19 -0500 X-OriginalArrivalTime: 28 Oct 2003 21:28:31.0955 (UTC) FILETIME=[6F9C6230:01C39D9A] Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --==_Exmh_-1503687178P Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, 27 Oct 2003 17:39:32 PST, Mark Davis said: > email addresses. Mr. Tanaka can have one with Latin letters and one wit= h > Japanese (e.g. =E3=83=A0=E3=83=AB=E3=82=AF@=E3=82=AB=E3=82=AF.=E3=83=AF= =E3=82=B7=E3=83=B3=E3=82=B0=E3=83=88=E3=83=B3.=E3=82=A8=E3=83=87=E3=82=A5= ). This gets interesting in the context of a "reply all". Apologies for breaking the UTF-8 in the quote, but it's illustrative - if= the breakage had been in the To/Cc lines, things would have broken even worse= unless whatever scheme we end up using is ASCII-transparent. --==_Exmh_-1503687178P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQE/nsx3cC3lWbTT17ARAlD1AKC74t7EwonvMVVb4YcOTjs6cE9mCwCfX9xR fx4FhsH1KZDlHM6R8Ip+I+A= =61XB -----END PGP SIGNATURE----- --==_Exmh_-1503687178P-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SNH9I7011150 for ; Tue, 28 Oct 2003 15:17:09 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SNH92m011149 for ietf-imapext-bks; Tue, 28 Oct 2003 15:17:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from hatl0ms21.CORP.COX.COM (lakehearnglobal.coxinc.com [206.157.224.254]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SNH5I7011103; Tue, 28 Oct 2003 15:17:05 -0800 (PST) (envelope-from klensin@jck.com) Received: from CATL0MS81.corp.cox.com ([10.62.200.231]) by hatl0ms21.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Tue, 28 Oct 2003 18:16:29 -0500 Received: from mail pickup service by CATL0MS81.corp.cox.com with Microsoft SMTPSVC; Tue, 28 Oct 2003 18:16:28 -0500 Received: from hatl0ms23.corp.cox.com ([10.64.200.56]) by catl0ms23.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 28 Oct 2003 15:52:19 -0500 Received: from bastion2.cox.com ([10.225.2.51]) by hatl0ms23.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 28 Oct 2003 15:37:56 -0500 Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by bastion2.cox.com (8.11.7p1+Sun/8.11.6) with SMTP id h9SKbmv16600; Tue, 28 Oct 2003 15:37:49 -0500 (EST) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1AEZlm-0004nU-3B for ietf-list@asgard.ietf.org; Tue, 28 Oct 2003 14:44:46 -0500 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1AEXlX-00008u-Kd for ietf@asgard.ietf.org; Tue, 28 Oct 2003 12:36:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11141; Tue, 28 Oct 2003 12:36:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEXlV-0002Hm-00; Tue, 28 Oct 2003 12:36:22 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx with esmtp (Exim 4.12) id 1AEXlV-0002Hi-00; Tue, 28 Oct 2003 12:36:21 -0500 Received: from bs.jck.com ([209.187.148.211] helo=localhost) by bs.jck.com with esmtp (Exim 4.10) id 1AEXlK-000NIP-00; Tue, 28 Oct 2003 12:36:11 -0500 Date: Tue, 28 Oct 2003 12:36:07 -0500 From: John C Klensin To: Marc Blanchet , Mark Davis , Mark Crispin , Abhijit Menon-Sen cc: "ietf-imaa@imc.org" , "idn@ops.ietf.org" , "ietf-822@imc.org" , "ietf@ietf.org" , "ietf-pop3ext@imc.org" , "lemonade@ietf.org" , "discuss@apps.ietf.org" , "ietf-imapext@imc.org" , "ietf-smtp@imc.org" Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA) Message-ID: <12344770.1067344567@KLENSIN-TP> In-Reply-To: <280960000.1067357574@classic.viagenie.qc.ca> References: <00fd01c39ce8$b6f19fe0$79d52b09@DAVIS1> <014c01c39cf4$5675cd60$79d52b09@DAVIS1> <20031028095243.A1525@lustre.dyn.wiw.org> <00a001c39d65$b23177f0$7900a8c0@DAVIS1> <280960000.1067357574@classic.viagenie.qc.ca> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Oct 2003 20:37:57.0507 (UTC) FILETIME=[5EF05D30:01C39D93] Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Tuesday, October 28, 2003 11:12 -0500 Marc Blanchet wrote: > it appears to me that this thread is not very different from > the idn considerations on usage of idn in the world. So what > is really new in this discussion? See the draft. Quick answer: DNS interfaces really exist at the protocol level, and a large part of the hypothesis behind IDNA was that it would be possible, after we had enough implementations, to prevent an end-user from ever seeing an encoded domain name. That story just doesn't hold for a special encoding-based (aka MUA-only) email local part implementation, and maybe not for email generally. For example, under current rules, an MTA is required to stuff the name it actually sees in HELO/EHLO and the MAIL command into various headers. If it is expected to notice that they have special encodings and decodes them, we've gone rather far into "the infrastructure is involved", even if the actual on-the-wire transport is not impacted. If it doesn't do that, the encodings --both the IDNA domain parts and the special mail encoding-- are going to be in the user's face, in the most literal sense of that term. The similarity of that situation to the early IDN discussions is the importance of the "what problem are you solving" question. And it is very clear to me that, for email addresses, the answer has got to "user sees their own characters in their email addresses and the email addresses of those whose languages they speak/ recognize. Users typically don't actually see envelopes. But seeing, e.g., different forms/codings of an address in the header "From:" field than appears in "Return-path:" or than appears in a signature line in the message body, is going to create real unhappiness. Similarly as has been pointed out in another context, seeing an address in different from when it appears in a header than when it (and that header) are encapsulated in a message/?? body part is just not going to amuse any user to whom we've said "ok, now you have i18n strings, enjoy your new found local language capabilities". And I guess that tells you what I think the problem is that we need to solve. YMMD. john Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SK7eI7002513 for ; Tue, 28 Oct 2003 12:07:40 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SK7eQW002512 for ietf-imapext-bks; Tue, 28 Oct 2003 12:07:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from turing-police.cc.vt.edu (turing-police.cc.vt.edu [128.173.14.107]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SK7bI7002497; Tue, 28 Oct 2003 12:07:37 -0800 (PST) (envelope-from Valdis.Kletnieks@vt.edu) Received: from turing-police.cc.vt.edu (IDENT:valdis@localhost [127.0.0.1]) by turing-police.cc.vt.edu (8.12.10/8.12.10) with ESMTP id h9SK7J6P004972; Tue, 28 Oct 2003 15:07:19 -0500 Message-Id: <200310282007.h9SK7J6P004972@turing-police.cc.vt.edu> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4+dev To: Mark Davis Cc: Mark Crispin , Keith Moore , dcrocker@brandenburg.com, paf@cisco.com, ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, IMAP Extensions WG , ietf-smtp@imc.org, presnick@qualcomm.com, hardie@qualcomm.com, ned.freed@mrochek.com Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA) In-Reply-To: Your message of "Mon, 27 Oct 2003 17:39:32 PST." <014c01c39cf4$5675cd60$79d52b09@DAVIS1> From: Valdis.Kletnieks@vt.edu References: <00fd01c39ce8$b6f19fe0$79d52b09@DAVIS1> <014c01c39cf4$5675cd60$79d52b09@DAVIS1> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1503687178P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Tue, 28 Oct 2003 15:07:19 -0500 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --==_Exmh_-1503687178P Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, 27 Oct 2003 17:39:32 PST, Mark Davis said: > email addresses. Mr. Tanaka can have one with Latin letters and one wit= h > Japanese (e.g. =E3=83=A0=E3=83=AB=E3=82=AF@=E3=82=AB=E3=82=AF.=E3=83=AF= =E3=82=B7=E3=83=B3=E3=82=B0=E3=83=88=E3=83=B3.=E3=82=A8=E3=83=87=E3=82=A5= ). This gets interesting in the context of a "reply all". Apologies for breaking the UTF-8 in the quote, but it's illustrative - if= the breakage had been in the To/Cc lines, things would have broken even worse= unless whatever scheme we end up using is ASCII-transparent. --==_Exmh_-1503687178P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQE/nsx3cC3lWbTT17ARAlD1AKC74t7EwonvMVVb4YcOTjs6cE9mCwCfX9xR fx4FhsH1KZDlHM6R8Ip+I+A= =61XB -----END PGP SIGNATURE----- --==_Exmh_-1503687178P-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SJ02I7099534 for ; Tue, 28 Oct 2003 11:00:02 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SJ02A0099531 for ietf-imapext-bks; Tue, 28 Oct 2003 11:00:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SJ01I7099526 for ; Tue, 28 Oct 2003 11:00:01 -0800 (PST) (envelope-from jeffstep@exchange.microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 28 Oct 2003 11:00:02 -0800 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 28 Oct 2003 11:00:02 -0800 Received: from df-muttley.platinum.corp.microsoft.com ([10.197.1.66]) by DF-BEG.platinum.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 28 Oct 2003 11:00:02 -0800 Received: from df-benji.platinum.corp.microsoft.com ([10.197.0.89]) by df-muttley.platinum.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 28 Oct 2003 11:00:01 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7112.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Exchange server has a broken SASL implementation Date: Tue, 28 Oct 2003 11:00:01 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Exchange server has a broken SASL implementation Thread-Index: AcOcsrFYHGy95BGDR+agHFpyl8JBeQA0Ry3w From: "Jeff Stephenson" To: "IMAP Interest List" , "IMAP Extensions WG" X-OriginalArrivalTime: 28 Oct 2003 19:00:01.0541 (UTC) FILETIME=[B0971B50:01C39D85] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9SJ02I7099527 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Actually, Exchange didn't get around to implementing this recently - it's been in Windows 2000 SMTP (which is what Exchange uses) since the release of Windows 2K. I'm dredging my memory here, but I believe that the code for this was locked down during the ID stage of RFC 2554, before the RFC was released. As I recall, it was interop-tested at the time, but there wasn't a lot to test against and I don't recall the results. I've passed this along to the Exchange folks, who say it's a known issue that wasn't fixed when discovered out of fear of breaking anything that might have relied on this behavior. If this behavior is breaking other apps, that would increase the impetus to fix it. -- jeff Jeff Stephenson Software Developer Microsoft Outlook > -----Original Message----- > From: Ken Murchison > Subject: Re: Exchange server has a broken SASL implementation ... > However, if there is/was any question about the specs, there > are mailing lists that can be contacted for clarification. > Interop testing could be done with non-MS products. The CMU > SASL library comes with test harnesses which can be used for > testing. There are at least 2 major MTAs (sendmail, postfix) > which use CMU SASL that could have been consulted for comparison. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SHaNI7096288 for ; Tue, 28 Oct 2003 09:36:23 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SHaMpH096287 for ietf-imapext-bks; Tue, 28 Oct 2003 09:36:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SHaII7096263; Tue, 28 Oct 2003 09:36:18 -0800 (PST) (envelope-from klensin@jck.com) Received: from bs.jck.com ([209.187.148.211] helo=localhost) by bs.jck.com with esmtp (Exim 4.10) id 1AEXlK-000NIP-00; Tue, 28 Oct 2003 12:36:11 -0500 Date: Tue, 28 Oct 2003 12:36:07 -0500 From: John C Klensin To: Marc Blanchet , Mark Davis , Mark Crispin , Abhijit Menon-Sen cc: "ietf-imaa@imc.org" , "idn@ops.ietf.org" , "ietf-822@imc.org" , "ietf@ietf.org" , "ietf-pop3ext@imc.org" , "lemonade@ietf.org" , "discuss@apps.ietf.org" , "ietf-imapext@imc.org" , "ietf-smtp@imc.org" Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA) Message-ID: <12344770.1067344567@KLENSIN-TP> In-Reply-To: <280960000.1067357574@classic.viagenie.qc.ca> References: <00fd01c39ce8$b6f19fe0$79d52b09@DAVIS1> <014c01c39cf4$5675cd60$79d52b09@DAVIS1> <20031028095243.A1525@lustre.dyn.wiw.org> <00a001c39d65$b23177f0$7900a8c0@DAVIS1> <280960000.1067357574@classic.viagenie.qc.ca> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Tuesday, October 28, 2003 11:12 -0500 Marc Blanchet wrote: > it appears to me that this thread is not very different from > the idn considerations on usage of idn in the world. So what > is really new in this discussion? See the draft. Quick answer: DNS interfaces really exist at the protocol level, and a large part of the hypothesis behind IDNA was that it would be possible, after we had enough implementations, to prevent an end-user from ever seeing an encoded domain name. That story just doesn't hold for a special encoding-based (aka MUA-only) email local part implementation, and maybe not for email generally. For example, under current rules, an MTA is required to stuff the name it actually sees in HELO/EHLO and the MAIL command into various headers. If it is expected to notice that they have special encodings and decodes them, we've gone rather far into "the infrastructure is involved", even if the actual on-the-wire transport is not impacted. If it doesn't do that, the encodings --both the IDNA domain parts and the special mail encoding-- are going to be in the user's face, in the most literal sense of that term. The similarity of that situation to the early IDN discussions is the importance of the "what problem are you solving" question. And it is very clear to me that, for email addresses, the answer has got to "user sees their own characters in their email addresses and the email addresses of those whose languages they speak/ recognize. Users typically don't actually see envelopes. But seeing, e.g., different forms/codings of an address in the header "From:" field than appears in "Return-path:" or than appears in a signature line in the message body, is going to create real unhappiness. Similarly as has been pointed out in another context, seeing an address in different from when it appears in a header than when it (and that header) are encapsulated in a message/?? body part is just not going to amuse any user to whom we've said "ok, now you have i18n strings, enjoy your new found local language capabilities". And I guess that tells you what I think the problem is that we need to solve. YMMD. john Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SGMhI7092036 for ; Tue, 28 Oct 2003 08:22:43 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SGMh5W092030 for ietf-imapext-bks; Tue, 28 Oct 2003 08:22:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from w1309.hostcentric.net (w1309.hostcentric.net [66.40.78.254]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9SGMcI7092008 for ; Tue, 28 Oct 2003 08:22:39 -0800 (PST) (envelope-from mark.davis@jtcsv.com) Received: (qmail 2789 invoked by alias); 28 Oct 2003 16:22:38 -0000 Received: from unknown (HELO DAVIS1) (12.235.201.242) by 0 with SMTP; 28 Oct 2003 16:22:38 -0000 Message-ID: <00fb01c39d6f$b46cdd70$7900a8c0@DAVIS1> From: "Mark Davis" To: "Marc Blanchet" , "Mark Crispin" , "Abhijit Menon-Sen" Cc: , , , , , , , , References: <00fd01c39ce8$b6f19fe0$79d52b09@DAVIS1> <014c01c39cf4$5675cd60$79d52b09@DAVIS1> <20031028095243.A1525@lustre.dyn.wiw.org> <00a001c39d65$b23177f0$7900a8c0@DAVIS1> <280960000.1067357574@classic.viagenie.qc.ca> Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA) Date: Tue, 28 Oct 2003 08:22:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I wouldn't have thought so either, but at least some people questioned the need for non-Latin characters, and went so far as to exclude them from a proposed problem statement: > ... There is a growing need to use additional > characters, specifically Latin characters with diacriticals and non-Latin > characters, in email addresses to better serve the needs of the > multi-national Internet community... Mark __________________________________ http://www.macchiato.com â–º शिषà¥à¤¯à¤¾à¤¦à¤¿à¤šà¥à¤›à¥‡à¤¤à¥à¤ªà¤°à¤¾à¤œà¤¯à¤®à¥ â—„ ----- Original Message ----- From: "Marc Blanchet" To: "Mark Davis" ; "Mark Crispin" ; "Abhijit Menon-Sen" Cc: ; ; ; ; ; ; ; ; Sent: Tue, 2003 Oct 28 08:12 Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA) > > it appears to me that this thread is not very different from the idn > considerations on usage of idn in the world. So what is really new in this > discussion? > > Marc. > > -- Tuesday, October 28, 2003 07:10:59 -0800 Mark Davis > wrote/a ecrit: > > >> > (I agree that it's currently nearly impossible to use computers if one > >> > isn't familiar with the Latin script, of course.) > >> > >> Which probably makes the rest of this discussion academic, unless we're > >> going to undertake solving *that* problem for Microsoft and the various > >> UNIX/Linux vendors... > > > > It is currently impossible to use the Internet without knowing the Latin > > script. However, the goal of most well-designed client software and > > operating systems is to permit the user to work entirely within their > > native language, with a fully localized system. This is reaching to India > > and other countries; Microsoft has introduced fully localized versions of > > Indic Windows just recently, and Linux vendors are hard at work to > > produce fully localized versions of their software. > > > > Email and Web addresses are the big remaining holdouts for most people. > > People should not be forced to use a script that they are unfamiliar > > with, just to use email addresses and sites in their own countries. Even > > if they are familiar with the Latin script, it is very often a very bad > > match for their languages, making it very difficult to figure out how > > native words would be spelled in it. > > > > Mark > > > > > > ------------------------------------------ > Marc Blanchet > Hexago > tel: +1-418-266-5533x225 > ------------------------------------------ > http://www.freenet6.net: IPv6 connectivity > ------------------------------------------ > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SGEnI7091339 for ; Tue, 28 Oct 2003 08:14:49 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SGEnxK091338 for ietf-imapext-bks; Tue, 28 Oct 2003 08:14:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from panoramix.hexago.com ([209.71.226.3]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SGEjI7091273; Tue, 28 Oct 2003 08:14:45 -0800 (PST) (envelope-from Marc.Blanchet@viagenie.qc.ca) Received: from localhost (retro.viagenie.qc.ca [IPv6:3ffe:b00:c18:3::22]) (authenticated bits=0) by panoramix.hexago.com (8.12.8/8.12.8) with ESMTP id h9SGD66r006992; Tue, 28 Oct 2003 11:13:14 -0500 (EST) Date: Tue, 28 Oct 2003 11:12:54 -0500 From: Marc Blanchet To: Mark Davis , Mark Crispin , Abhijit Menon-Sen cc: ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, ietf-imapext@imc.org, ietf-smtp@imc.org Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA) Message-ID: <280960000.1067357574@classic.viagenie.qc.ca> In-Reply-To: <00a001c39d65$b23177f0$7900a8c0@DAVIS1> References: <00fd01c39ce8$b6f19fe0$79d52b09@DAVIS1> <014c01c39cf4$5675cd60$79d52b09@DAVIS1> <20031028095243.A1525@lustre.dyn.wiw.org> <00a001c39d65$b23177f0$7900a8c0@DAVIS1> X-Mailer: Mulberry/3.1.0b9 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: it appears to me that this thread is not very different from the idn considerations on usage of idn in the world. So what is really new in this discussion? Marc. -- Tuesday, October 28, 2003 07:10:59 -0800 Mark Davis wrote/a ecrit: >> > (I agree that it's currently nearly impossible to use computers if one >> > isn't familiar with the Latin script, of course.) >> >> Which probably makes the rest of this discussion academic, unless we're >> going to undertake solving *that* problem for Microsoft and the various >> UNIX/Linux vendors... > > It is currently impossible to use the Internet without knowing the Latin > script. However, the goal of most well-designed client software and > operating systems is to permit the user to work entirely within their > native language, with a fully localized system. This is reaching to India > and other countries; Microsoft has introduced fully localized versions of > Indic Windows just recently, and Linux vendors are hard at work to > produce fully localized versions of their software. > > Email and Web addresses are the big remaining holdouts for most people. > People should not be forced to use a script that they are unfamiliar > with, just to use email addresses and sites in their own countries. Even > if they are familiar with the Latin script, it is very often a very bad > match for their languages, making it very difficult to figure out how > native words would be spelled in it. > > Mark > ------------------------------------------ Marc Blanchet Hexago tel: +1-418-266-5533x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SFB5I7086579 for ; Tue, 28 Oct 2003 07:11:05 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SFB5bp086575 for ietf-imapext-bks; Tue, 28 Oct 2003 07:11:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from w1309.hostcentric.net (w1309.hostcentric.net [66.40.78.254]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9SFB0I7086537 for ; Tue, 28 Oct 2003 07:11:00 -0800 (PST) (envelope-from mark.davis@jtcsv.com) Received: (qmail 31822 invoked by alias); 28 Oct 2003 15:10:59 -0000 Received: from unknown (HELO DAVIS1) (12.235.201.242) by 0 with SMTP; 28 Oct 2003 15:10:59 -0000 Message-ID: <00a001c39d65$b23177f0$7900a8c0@DAVIS1> From: "Mark Davis" To: "Mark Crispin" , "Abhijit Menon-Sen" Cc: , , , , , , , , References: <00fd01c39ce8$b6f19fe0$79d52b09@DAVIS1> <014c01c39cf4$5675cd60$79d52b09@DAVIS1> <20031028095243.A1525@lustre.dyn.wiw.org> Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) Date: Tue, 28 Oct 2003 07:10:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > (I agree that it's currently nearly impossible to use computers if one > > isn't familiar with the Latin script, of course.) > > Which probably makes the rest of this discussion academic, unless we're > going to undertake solving *that* problem for Microsoft and the various > UNIX/Linux vendors... It is currently impossible to use the Internet without knowing the Latin script. However, the goal of most well-designed client software and operating systems is to permit the user to work entirely within their native language, with a fully localized system. This is reaching to India and other countries; Microsoft has introduced fully localized versions of Indic Windows just recently, and Linux vendors are hard at work to produce fully localized versions of their software. Email and Web addresses are the big remaining holdouts for most people. People should not be forced to use a script that they are unfamiliar with, just to use email addresses and sites in their own countries. Even if they are familiar with the Latin script, it is very often a very bad match for their languages, making it very difficult to figure out how native words would be spelled in it. Mark Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SEspI7085643 for ; Tue, 28 Oct 2003 06:54:51 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SEspVG085639 for ietf-imapext-bks; Tue, 28 Oct 2003 06:54:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from w1309.hostcentric.net (w1309.hostcentric.net [66.40.78.254]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9SEskI7085608 for ; Tue, 28 Oct 2003 06:54:46 -0800 (PST) (envelope-from mark.davis@jtcsv.com) Received: (qmail 23826 invoked by alias); 28 Oct 2003 14:54:45 -0000 Received: from unknown (HELO DAVIS1) (12.235.201.242) by 0 with SMTP; 28 Oct 2003 14:54:45 -0000 Message-ID: <006b01c39d63$6d928d70$7900a8c0@DAVIS1> From: "Mark Davis" To: "Stephane Bortzmeyer" Cc: "Mark Crispin" , "Keith Moore" , , , , , , , , , , "IMAP Extensions WG" , , , , References: <00fd01c39ce8$b6f19fe0$79d52b09@DAVIS1> <014c01c39cf4$5675cd60$79d52b09@DAVIS1> <20031028085023.GB6617@nic.fr> Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA) Date: Tue, 28 Oct 2003 06:54:45 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0068_01C39D20.5EDF9090" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0068_01C39D20.5EDF9090 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sigh. I used "Greek" in an analogy because I was hoping that some of the = Latin-only folks out there would at least recognize the name of one = other script. But how comforable would you really be, if = =D9=8A=D9=8F=D9=8F =D9=88=D9=90=D8=B1=D9=90 = =D9=81=D9=8F=D8=B1=D8=B3=D9=90=D8=AF =D8=AA=D9=8F = =D8=B1=D9=8E=D9=90=D8=AF =D9=8E=D9=86 = =D9=90=D9=86=D8=AA=D9=90=D8=B1=D9=90=D9=84=D9=8A = =D8=AF=D9=90=D9=81=D9=81=D9=90=D8=B1=D9=90=D9=86=D8=AA = =D8=B3=D9=83=D8=B1=D9=90=D9=BE=D8=AA=D8=8C = =D8=B3=D9=90=D9=85=D9=BE=D9=84=D9=8A =D8=AA=D9=8F = =D9=8F=D9=86=D8=AF=D9=90=D8=B1=D8=B3=D8=AA=D9=8E=D9=86=D8=AF = =D9=90=D9=85=D9=8E=D9=90=D9=84 = =D9=8E=D8=AF=D8=AF=D8=B1=D9=90=D8=B3=D8=B3=D9=90=D8=B3=D8=8C = =D9=8E=D9=86=D8=AF =D9=8E =D8=B3=D9=83=D8=B1=D9=90=D9=BE=D8=AA = =D8=AA=D9=87=D9=8E=D8=AA =D9=83=D9=8F=D9=8F=D9=84=D8=AF = =D9=8F=D9=86=D9=84=D9=8A = =D9=BE=D9=8E=D8=B1=D8=AA=D9=8E=D9=90=D9=84=D9=84=D9=8A = =D8=B1=D9=90=D9=81=D9=84=D9=90=D9=83=D8=AA =D8=AA=D9=87=D9=90 = =D8=B1=D9=8E=D9=90=D9=84 = =D8=B3=D9=BE=D9=90=D9=84=D9=84=D9=90=D9=86=DA=AF =D9=8F=D9=81 = =D9=8A=D9=8F=D9=8F=D8=B1 =D9=88=D9=8F=D8=B1=D8=AF=D8=B3? Mark __________________________________ =20 ----- Original Message -----=20 From: "Stephane Bortzmeyer" To: "Mark Davis" Cc: "Mark Crispin" ; "Keith Moore" = ; ; ; = ; ; ; = ; ; ; = ; "IMAP Extensions WG" ; = ; ; ; = Sent: Tue, 2003 Oct 28 00:50 Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses = (IEA) > On Mon, Oct 27, 2003 at 05:39:32PM -0800, > Mark Davis wrote=20 > a message of 76 lines which said: >=20 > > We should remember that for a great many people in the world, Latin = letters are > > quite unnatural; it'd be a bit like if we had to use Greek letters = in all email > > addresses.=20 >=20 > It would be a bit like if we had to use Greek letters in mathematics > :-) >=20 > ------=_NextPart_000_0068_01C39D20.5EDF9090 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Sigh. I used "Greek" in an analogy = because I=20 was hoping that some of the Latin-only folks out there would at least=20 recognize the name of one other script. But how comforable = would you=20 really be, if =D9=8A=D9=8F=D9=8F =D9=88=D9=90=D8=B1=D9=90 = =D9=81=D9=8F=D8=B1=D8=B3=D9=90=D8=AF =D8=AA=D9=8F = =D8=B1=D9=8E=D9=90=D8=AF =D9=8E=D9=86 = =D9=90=D9=86=D8=AA=D9=90=D8=B1=D9=90=D9=84=D9=8A = =D8=AF=D9=90=D9=81=D9=81=D9=90=D8=B1=D9=90=D9=86=D8=AA = =D8=B3=D9=83=D8=B1=D9=90=D9=BE=D8=AA=D8=8C = =D8=B3=D9=90=D9=85=D9=BE=D9=84=D9=8A =D8=AA=D9=8F=20 =D9=8F=D9=86=D8=AF=D9=90=D8=B1=D8=B3=D8=AA=D9=8E=D9=86=D8=AF = =D9=90=D9=85=D9=8E=D9=90=D9=84 = =D9=8E=D8=AF=D8=AF=D8=B1=D9=90=D8=B3=D8=B3=D9=90=D8=B3=D8=8C = =D9=8E=D9=86=D8=AF =D9=8E =D8=B3=D9=83=D8=B1=D9=90=D9=BE=D8=AA = =D8=AA=D9=87=D9=8E=D8=AA =D9=83=D9=8F=D9=8F=D9=84=D8=AF = =D9=8F=D9=86=D9=84=D9=8A = =D9=BE=D9=8E=D8=B1=D8=AA=D9=8E=D9=90=D9=84=D9=84=D9=8A = =D8=B1=D9=90=D9=81=D9=84=D9=90=D9=83=D8=AA =D8=AA=D9=87=D9=90=20 =D8=B1=D9=8E=D9=90=D9=84 = =D8=B3=D9=BE=D9=90=D9=84=D9=84=D9=90=D9=86=DA=AF =D9=8F=D9=81 = =D9=8A=D9=8F=D9=8F=D8=B1 =D9=88=D9=8F=D8=B1=D8=AF=D8=B3?

Mark
__________________________________

 <= /DIV>
----- Original Message -----
From: "Stephane Bortzmeyer" <bortzmeyer@nic.fr>
To: "Mark Davis" <mark.davis@jtcsv.com>
Cc: "Mark Crispin" <MRC@CAC.Washington.EDU>; "Keith = Moore"=20 <moore@cs.utk.edu>; <dcrocker@brandenburg.com>; = <paf@cisco.com>; <ietf-imaa@imc.org>; <idn@ops.ietf.org>; <ietf-822@imc.org>; <ietf@ietf.org>; <ietf-pop3ext@imc.org>; = <lemonade@ietf.org>; <discuss@apps.ietf.org>; "IMAP = Extensions WG"=20 <ietf-imapext@imc.org>; = <ietf-smtp@imc.org>; <presnick@qualcomm.com>; = <hardie@qualcomm.com>; = <ned.freed@mrochek.com>
Sent: Tue, 2003 Oct 28 00:50
Subject: Re: [idn] Re: FYI: BOF on Internationalized = Email=20 Addresses (IEA)

> On Mon, Oct 27, = 2003 at=20 05:39:32PM -0800,
>  Mark Davis <mark.davis@jtcsv.com> wrote =
>  a=20 message of 76 lines which said:
>
> > We should remember = that=20 for a great many people in the world, Latin letters are
> > = quite=20 unnatural; it'd be a bit like if we had to use Greek letters in all=20 email
> > addresses.
>
> It would be a bit like = if we had=20 to use Greek letters in mathematics
> :-)
>
>=20 ------=_NextPart_000_0068_01C39D20.5EDF9090-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SABtI7071606 for ; Tue, 28 Oct 2003 02:11:55 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SABtK7071605 for ietf-imapext-bks; Tue, 28 Oct 2003 02:11:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from melkebalanse.gulbrandsen.priv.no (melkebalanse.gulbrandsen.priv.no [217.19.171.131]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SABlI7071585; Tue, 28 Oct 2003 02:11:51 -0800 (PST) (envelope-from arnt@gulbrandsen.priv.no) Message-Id: From: Arnt Gulbrandsen To: Mark Crispin Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) Cc: ietf@ietf.org, lemonade@ietf.org, IETF RFC-822 list , IMAA list , IMAP Extensions WG , ietf-pop3ext@imc.org, ietf-smtp@imc.org, Abhijit Menon-Sen , discuss@apps.ietf.org, IETF/IDN WG References: <00fd01c39ce8$b6f19fe0$79d52b09@DAVIS1> <014c01c39cf4$5675cd60$79d52b09@DAVIS1> <20031028095243.A1525@lustre.dyn.wiw.org> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Tue, 28 Oct 2003 11:15:17 +0100 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: > On Tue, 28 Oct 2003, Abhijit Menon-Sen wrote: >> (I agree that it's currently nearly impossible to use computers if >> one isn't familiar with the Latin script, of course.) > > Which probably makes the rest of this discussion academic, unless > we're going to undertake solving *that* problem for Microsoft and the > various UNIX/Linux vendors... You're not appreciating the full complexity of the problem. ;) Not only should the email standards permit MUAs and MTAs of the year 2020 to solve the problem Abhijit mentions, but they should even permit such future programs to interoperate with latinate ones of the present and near future. And if it's too hard for latinate MUAs to implement the IEA standard, that won't happen. --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S9dsI7070478 for ; Tue, 28 Oct 2003 01:39:54 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9S9dsXL070477 for ietf-imapext-bks; Tue, 28 Oct 2003 01:39:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S9drI7070465; Tue, 28 Oct 2003 01:39:53 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h9S9jrf12762; Tue, 28 Oct 2003 01:45:54 -0800 Date: Tue, 28 Oct 2003 01:13:50 -0800 From: Dave Crocker X-Mailer: The Bat! (v2.00.22) Reply-To: dcrocker@brandenburg.com Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <2337816887.20031028011350@brandenburg.com> To: Pete Resnick CC: ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, , , , , Dave Crocker Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) In-Reply-To: References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com> <12228881609.20031027074111@brandenburg.com> <20031027105222.4eae54fd.moore@cs.utk.edu> <355752681.20031027161925@brandenburg.com> <16285.48493.496028.516294@moriarty.gnomon.org.uk> <14814332829.20031027184226@brandenburg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Pete, >>RB> Restricting the disucssion to local-parts runs the risk of excluding >>RB> other potentially relevent issues. PR> I agree. Limiting discussion at this point to local-part does not PR> take into account some of the possibilities. That was exactly the intent of the text. We have already seen how nicely the text served to bring into pretty stark relief one bit of expectation from one of the proposals. It is only fitting to have it serve the same purpose for another one. IETF BOF time is pretty lousy for an open-ended chat. Having specifications to chat about is only marginally better than not having them. What makes the real difference is having serious focus to the meeting. If we go into this meeting without even having a clear sense of the scope of the problem to be tackled, then the chance of having a productive meeting is pretty small. At the moment, it appears that the focus of the meeting is likely to be: Shall we break existing Internet mail or shall we lay an enhancement on top of it that preserves the installed base. (I'm sure that everyone else who was present at the pre-MIME/ESMTP discussions is really looking forward to repeating the experience.) d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S8pFI7057432 for ; Tue, 28 Oct 2003 00:51:15 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9S8pF4N057431 for ietf-imapext-bks; Tue, 28 Oct 2003 00:51:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S8pCI7057400; Tue, 28 Oct 2003 00:51:13 -0800 (PST) (envelope-from bortzmeyer@nic.fr) Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id h9S8oNQW1526872; Tue, 28 Oct 2003 09:50:23 +0100 (CET) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 5FF63FF47; Tue, 28 Oct 2003 09:50:23 +0100 (CET) Date: Tue, 28 Oct 2003 09:50:23 +0100 From: Stephane Bortzmeyer To: Mark Davis Cc: Mark Crispin , Keith Moore , dcrocker@brandenburg.com, paf@cisco.com, ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, IMAP Extensions WG , ietf-smtp@imc.org, presnick@qualcomm.com, hardie@qualcomm.com, ned.freed@mrochek.com Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA) Message-ID: <20031028085023.GB6617@nic.fr> References: <00fd01c39ce8$b6f19fe0$79d52b09@DAVIS1> <014c01c39cf4$5675cd60$79d52b09@DAVIS1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <014c01c39cf4$5675cd60$79d52b09@DAVIS1> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.21-3-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.4i Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, Oct 27, 2003 at 05:39:32PM -0800, Mark Davis wrote a message of 76 lines which said: > We should remember that for a great many people in the world, Latin letters are > quite unnatural; it'd be a bit like if we had to use Greek letters in all email > addresses. It would be a bit like if we had to use Greek letters in mathematics :-) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S7LEI7028878 for ; Mon, 27 Oct 2003 23:21:14 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9S7LEvD028877 for ietf-imapext-bks; Mon, 27 Oct 2003 23:21:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from episteme-software.com (216-43-25-66.ip.mcleodusa.net [216.43.25.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S7L7I7028794; Mon, 27 Oct 2003 23:21:07 -0800 (PST) (envelope-from presnick@qualcomm.com) Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b1); Tue, 28 Oct 2003 01:21:01 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <14814332829.20031027184226@brandenburg.com> References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com> <12228881609.20031027074111@brandenburg.com> <20031027105222.4eae54fd.moore@cs.utk.edu> <355752681.20031027161925@brandenburg.com> <16285.48493.496028.516294@moriarty.gnomon.org.uk> <14814332829.20031027184226@brandenburg.com> X-Mailer: Eudora [Macintosh version 6.1a2] Date: Tue, 28 Oct 2003 01:20:58 -0600 To: dcrocker@brandenburg.com From: Pete Resnick Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) Cc: Roy Badami , ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, , , , , Dave Crocker Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 10/27/03 at 6:42 PM -0800, Dave Crocker wrote: >RB> Even though, given IDNA now exists as a proposed standard, the main >RB> issues relate to the local part, the issue under discussion is that of >RB> internationalized mail addresses, not just internationalized >RB> local-parts. > >Really? What work needs to be done, except for local part? IDNA takes care >of the right-hand side. Please review John Klensin's draft before making these kinds of assumptions. >RB> Restricting the disucssion to local-parts runs the risk of excluding >RB> other potentially relevent issues. I agree. Limiting discussion at this point to local-part does not take into account some of the possibilities. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S4gMI7092682 for ; Mon, 27 Oct 2003 20:42:22 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9S4gMwH092681 for ietf-imapext-bks; Mon, 27 Oct 2003 20:42:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S4gHI7092646; Mon, 27 Oct 2003 20:42:17 -0800 (PST) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9S4gHaZ024278; Mon, 27 Oct 2003 20:42:17 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9S4gHx0026302 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 27 Oct 2003 20:42:17 -0800 Date: Mon, 27 Oct 2003 20:42:19 -0800 (Pacific Standard Time) From: Mark Crispin To: Abhijit Menon-Sen cc: ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, ietf-imapext@imc.org, ietf-smtp@imc.org Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) In-Reply-To: <20031028095243.A1525@lustre.dyn.wiw.org> Message-ID: References: <00fd01c39ce8$b6f19fe0$79d52b09@DAVIS1> <014c01c39cf4$5675cd60$79d52b09@DAVIS1> <20031028095243.A1525@lustre.dyn.wiw.org> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 28 Oct 2003, Abhijit Menon-Sen wrote: > The number of people in India who can read and write only their native > language, but have no usable knowledge of Latin script, is much larger > than the tiny number who are familiar with both. I'm told that this is > true for many native speakers of Chinese and Arabic as well. I defer to your superior knowledge about India. I do not believe that this is true for Chinese. AFAIK, Chinese primary school kids use Latin script with hanyu-pinyin as a stopgap prior to their mastery of Han script (which takes many years). > The use of local scripts is much more than just a "preference" for the > numerous localisation efforts in India which focus on making computing > more accessible to poor farmers and people in villages. A poor farmer or villager in China is more likely to be totally illiterate than to be literate in Han script but unable to recognize Latin script. Note that when I say "recognize Latin script", I mean the ability to determine that "dog" is a three-letter word that has the letters "d", "o", and "g", each of which the individual recognizes and can name. This does not include the ability to recognize that this refers to a domesticated canine. > (I agree that it's currently nearly impossible to use computers if one > isn't familiar with the Latin script, of course.) Which probably makes the rest of this discussion academic, unless we're going to undertake solving *that* problem for Microsoft and the various UNIX/Linux vendors... -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S4MmI7091588 for ; Mon, 27 Oct 2003 20:22:48 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9S4Mm9O091586 for ietf-imapext-bks; Mon, 27 Oct 2003 20:22:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from miranda.org (IDENT:qmailr@miranda.org [209.58.150.153]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9S4MlI7091575 for ; Mon, 27 Oct 2003 20:22:47 -0800 (PST) (envelope-from ams@wiw.org) Received: (qmail 21999 invoked from network); 28 Oct 2003 04:22:45 -0000 Received: from miranda.org (HELO lustre.dyn.wiw.org) (ams@209.58.150.153) by miranda.org with SMTP; 28 Oct 2003 04:22:45 -0000 Received: from ams by lustre.dyn.wiw.org with local (Exim 4.20) id 1AELNT-0000RV-Fn; Tue, 28 Oct 2003 09:52:43 +0530 Date: Tue, 28 Oct 2003 09:52:43 +0530 From: Abhijit Menon-Sen To: Mark Crispin Cc: ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, ietf-imapext@imc.org, ietf-smtp@imc.org Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) Message-ID: <20031028095243.A1525@lustre.dyn.wiw.org> References: <00fd01c39ce8$b6f19fe0$79d52b09@DAVIS1> <014c01c39cf4$5675cd60$79d52b09@DAVIS1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 2003-10-27 19:37:37 -0800, MRC@CAC.Washington.EDU wrote: > > I do not believe many individuals (other than primary school children) are > literate in their native language but are completely illiterate in Latin > script. This does not mean "being able to read or write the English > language"; rather, this simply means knowing the Latin script alphabet. Mark, The number of people in India who can read and write only their native language, but have no usable knowledge of Latin script, is much larger than the tiny number who are familiar with both. I'm told that this is true for many native speakers of Chinese and Arabic as well. The use of local scripts is much more than just a "preference" for the numerous localisation efforts in India which focus on making computing more accessible to poor farmers and people in villages. (I agree that it's currently nearly impossible to use computers if one isn't familiar with the Latin script, of course.) -- ams Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S3bmI7089708 for ; Mon, 27 Oct 2003 19:37:48 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9S3bmiK089707 for ietf-imapext-bks; Mon, 27 Oct 2003 19:37:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S3bgI7089683; Mon, 27 Oct 2003 19:37:43 -0800 (PST) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout5.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9S3baMk024515; Mon, 27 Oct 2003 19:37:36 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9S3bZSS003692 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 27 Oct 2003 19:37:35 -0800 Date: Mon, 27 Oct 2003 19:37:37 -0800 (Pacific Standard Time) From: Mark Crispin To: Mark Davis cc: Keith Moore , dcrocker@brandenburg.com, paf@cisco.com, ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, IMAP Extensions WG , ietf-smtp@imc.org, presnick@qualcomm.com, hardie@qualcomm.com, ned.freed@mrochek.com Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA) In-Reply-To: <014c01c39cf4$5675cd60$79d52b09@DAVIS1> Message-ID: References: <00fd01c39ce8$b6f19fe0$79d52b09@DAVIS1> <014c01c39cf4$5675cd60$79d52b09@DAVIS1> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 27 Oct 2003, Mark Davis wrote: > Based on what I've seen, I think it quite likely that people will want email > addresses in their native script, even if that means that outsiders can't > (easily) use those email address. That may well be the case. > We should remember that for a great many people in the world, Latin > letters are quite unnatural; it'd be a bit like if we had to use Greek > letters in all email addresses. And there are many projects underway in > less-developed countries to bring computers to masses of people that > will even less familiarity with Latin letters. I am not convinced that it is possible to use a computer on the Internet anywhere in the world without at least a basic acquaintance with Latin script. I do not believe many individuals (other than primary school children) are literate in their native language but are completely illiterate in Latin script. This does not mean "being able to read or write the English language"; rather, this simply means knowing the Latin script alphabet. Put another way, individuals who are completely illiterate in Latin script are also likely to be illiterate in their native language script as well. No other script on the planet has such international recognition. There is undoubtably a *preference* for one's native script; and that preference should be respected as much as possible. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S2gUI7087955 for ; Mon, 27 Oct 2003 18:42:30 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9S2gUTA087954 for ietf-imapext-bks; Mon, 27 Oct 2003 18:42:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S2gSI7087943; Mon, 27 Oct 2003 18:42:28 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h9S2mVf18218; Mon, 27 Oct 2003 18:48:31 -0800 Date: Mon, 27 Oct 2003 18:42:26 -0800 From: Dave Crocker X-Mailer: The Bat! (v2.00.22) Reply-To: dcrocker@brandenburg.com Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <14814332829.20031027184226@brandenburg.com> To: Roy Badami CC: ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, , , , Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) In-Reply-To: <16285.48493.496028.516294@moriarty.gnomon.org.uk> References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com> <12228881609.20031027074111@brandenburg.com> <20031027105222.4eae54fd.moore@cs.utk.edu> <355752681.20031027161925@brandenburg.com> <16285.48493.496028.516294@moriarty.gnomon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Roy, >> Mail Internationalised Local-Part (MILP) RB> Even though, given IDNA now exists as a proposed standard, the main RB> issues relate to the local part, the issue under discussion is that of RB> internationalized mail addresses, not just internationalized RB> local-parts. Really? What work needs to be done, except for local part? IDNA takes care of the right-hand side. So what is there to do about "internationalized mail addresses" other than the local part? RB> Restricting the disucssion to local-parts runs the risk of excluding RB> other potentially relevent issues. For instance, one of the issues RB> that has been discussed on the IMAA list is whether full-width at RB> should be recognized in an internationalized mail address. full-width _where_? somewhere other than local part? if yes, then how can that be practical? if no, then the charter does not preclude their use. (if you think otherwise, please explain.) d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S1dbI7085759 for ; Mon, 27 Oct 2003 17:39:37 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9S1da1v085756 for ietf-imapext-bks; Mon, 27 Oct 2003 17:39:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from w1309.hostcentric.net (w1309.hostcentric.net [66.40.78.254]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9S1dWI7085729 for ; Mon, 27 Oct 2003 17:39:32 -0800 (PST) (envelope-from mark.davis@jtcsv.com) Received: (qmail 22048 invoked by alias); 28 Oct 2003 01:39:33 -0000 Received: from unknown (HELO DAVIS1) (129.42.184.35) by 0 with SMTP; 28 Oct 2003 01:39:33 -0000 Message-ID: <014c01c39cf4$5675cd60$79d52b09@DAVIS1> From: "Mark Davis" To: "Mark Crispin" Cc: "Keith Moore" , , , , , , , , , , "IMAP Extensions WG" , , , , References: <00fd01c39ce8$b6f19fe0$79d52b09@DAVIS1> Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA) Date: Mon, 27 Oct 2003 17:39:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ok, I understand more about the context. Based on what I've seen, I think it quite likely that people will want email addresses in their native script, even if that means that outsiders can't (easily) use those email address. After all, it is quite easy to have multiple email addresses. Mr. Tanaka can have one with Latin letters and one with Japanese (e.g. ムルク@カク.ワシングトン.エデゥ). We should remember that for a great many people in the world, Latin letters are quite unnatural; it'd be a bit like if we had to use Greek letters in all email addresses. And there are many projects underway in less-developed countries to bring computers to masses of people that will even less familiarity with Latin letters. Mark __________________________________ http://www.macchiato.com â–º शिषà¥à¤¯à¤¾à¤¦à¤¿à¤šà¥à¤›à¥‡à¤¤à¥à¤ªà¤°à¤¾à¤œà¤¯à¤®à¥ â—„ ----- Original Message ----- From: "Mark Crispin" To: "Mark Davis" Cc: "Keith Moore" ; ; ; ; ; ; ; ; ; ; "IMAP Extensions WG" ; ; ; ; Sent: Mon, 2003 Oct 27 17:15 Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA) > On Mon, 27 Oct 2003, Mark Davis wrote: > > I'm curious: why do you think that everyone would be satisfied with Latin > > characters only, and no non-Latin characters? > > I didn't say that. I stated my belief that, for reasons of practicality, > most individuals in regions which do not use Latin script accept the use > of Latin script for multinational exchange. > > It does not work well for an individual in Japan with surname Tanaka to > expect the overwhelming majority of non-Japanese individuals worldwide to > know his surname is written with the Han characters for "rice paddy" and > "middle", or what those characters look like, or how to enter those > characters on the computer. > > It does, however, work for him to expect that the overwhelming majority of > individuals worldwide to know how to deal with the 6 Latin letters that > form the romanization "Tanaka". > > Nor is it very likely that this situation will change in the future. I > doubt that many individuals in the world are literate in all the world's > active scripts. Literacy in one's native script and basic Latin script is > something that most computer users possess today. > > For domestic exchange only, that pair of Han characters are probably > alright. Within Western Europe, it's probably alright to use Latin > characters with diacriticals. > > Perhaps the main problem that needs to be decided in any IEA effort is if > it is alright to have email addresses that are only usable in limited > areas of the world; or if not, how to represent internationalized email > addresses in a usable fashion when (not if) the email address needs to be > represented for a person and/or computer is illiterate in that script. > > A likely side issue is whether it is "good enough" to promote Latin > characters with diacriticals to the same status of "everybody must know > how to do these" that is required for ASCII. > > -- Mark -- > > http://staff.washington.edu/mrc > Science does not emerge from voting, party politics, or public debate. > Si vis pacem, para bellum. > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S1FYI7084848 for ; Mon, 27 Oct 2003 17:15:34 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9S1FYgT084847 for ietf-imapext-bks; Mon, 27 Oct 2003 17:15:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S1FTI7084821; Mon, 27 Oct 2003 17:15:30 -0800 (PST) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9S1EwaZ010323; Mon, 27 Oct 2003 17:14:59 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9S1Ewx0018732 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 27 Oct 2003 17:14:58 -0800 Date: Mon, 27 Oct 2003 17:15:00 -0800 (Pacific Standard Time) From: Mark Crispin To: Mark Davis cc: Keith Moore , dcrocker@brandenburg.com, paf@cisco.com, ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, IMAP Extensions WG , ietf-smtp@imc.org, presnick@qualcomm.com, hardie@qualcomm.com, ned.freed@mrochek.com Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA) In-Reply-To: <00fd01c39ce8$b6f19fe0$79d52b09@DAVIS1> Message-ID: References: <00fd01c39ce8$b6f19fe0$79d52b09@DAVIS1> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 27 Oct 2003, Mark Davis wrote: > I'm curious: why do you think that everyone would be satisfied with Latin > characters only, and no non-Latin characters? I didn't say that. I stated my belief that, for reasons of practicality, most individuals in regions which do not use Latin script accept the use of Latin script for multinational exchange. It does not work well for an individual in Japan with surname Tanaka to expect the overwhelming majority of non-Japanese individuals worldwide to know his surname is written with the Han characters for "rice paddy" and "middle", or what those characters look like, or how to enter those characters on the computer. It does, however, work for him to expect that the overwhelming majority of individuals worldwide to know how to deal with the 6 Latin letters that form the romanization "Tanaka". Nor is it very likely that this situation will change in the future. I doubt that many individuals in the world are literate in all the world's active scripts. Literacy in one's native script and basic Latin script is something that most computer users possess today. For domestic exchange only, that pair of Han characters are probably alright. Within Western Europe, it's probably alright to use Latin characters with diacriticals. Perhaps the main problem that needs to be decided in any IEA effort is if it is alright to have email addresses that are only usable in limited areas of the world; or if not, how to represent internationalized email addresses in a usable fashion when (not if) the email address needs to be represented for a person and/or computer is illiterate in that script. A likely side issue is whether it is "good enough" to promote Latin characters with diacriticals to the same status of "everybody must know how to do these" that is required for ASCII. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S1A0I7084626 for ; Mon, 27 Oct 2003 17:10:00 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9S1A0Ct084625 for ietf-imapext-bks; Mon, 27 Oct 2003 17:10:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from panoramix.hexago.com ([209.71.226.3]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S19rI7084577; Mon, 27 Oct 2003 17:09:58 -0800 (PST) (envelope-from Marc.Blanchet@viagenie.qc.ca) Received: from localhost (retro.viagenie.qc.ca [IPv6:3ffe:b00:c18:3::22]) (authenticated bits=0) by panoramix.hexago.com (8.12.8/8.12.8) with ESMTP id h9S18c6r006354; Mon, 27 Oct 2003 20:08:39 -0500 (EST) Date: Mon, 27 Oct 2003 20:08:25 -0500 From: Marc Blanchet To: Dave Crocker , ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, ietf-imapext@imc.org, ietf-smtp@imc.org Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA) Message-ID: <839550000.1067303305@classic.viagenie.qc.ca> In-Reply-To: <355752681.20031027161925@brandenburg.com> References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com> <12228881609.20031027074111@brandenburg.com> <20031027105222.4eae54fd.moore@cs.utk.edu> <355752681.20031027161925@brandenburg.com> X-Mailer: Mulberry/3.1.0b8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: - good start! - timeline seems pretty agressive... will see. - would probably good to have a requirement document upfront. Might not the same way that idn requirement ends up, but a narrow-implementable requirement would help to have a concensus (hopefully) on what needs to be done. - while the idn req went not that good, now that we have experience, I think we should try to be better and have one. I know I might start some debate with this, but still think it is the best way to go... - would be useful to have some reference to idn (idna) in the charter, as background work. the developers and users will have to take care of "both" (ie. idn and imail) in the email infrastructure. Marc. -- Monday, October 27, 2003 16:19:25 -0800 Dave Crocker wrote/a ecrit: > Folks, > > On the theory that discussions go better when they have a concrete > deliverable, here is a proposed charter for a proposed working group. > > The following started with Mark Crispin's text, although it might not > look it. Besides the usual goals for a charter, the following text > attempts to specify the problem domain in the narrowest feasible form > that is valid. If anyone thinks the scope is too narrow, they need to > explain why. > > > > DRAFT CHARTER > > Mail Internationalised Local-Part (MILP) > --------------------------------- > > The portion of RFC2822 and portion of RFC2821 > mail addresses are restricted to a subset of ASCII. This poses a > fundamental barrier for users needing mail addresses to be expressed in a > richer set of characters, such as Latin characters with diacriticals and > the many Asian characters. The goal of the current work is to add > local-part support for these additional characters, while preserving the > large, installed base of ASCII usage. > > The group will take: > > draft-hoffman-imaa-03.txt > draft-klensin-emailaddr-i18n-01.txt > draft-duerst-iri-04.txt > > as input to discussions. > > The group will pay particular attention to barriers to adoption and > utility, as well as any impact the new scheme might have on the existing > base of Internet mail usage. > > > Milestones > ---------- > > Nov, 03: BOF > > Dec, 03: WG chartered > > Feb, 03: Initial draft of working group specifications. > > Jun, 03: Specifications submitted for IETF approval > > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA > ------------------------------------------ Marc Blanchet Hexago tel: +1-418-266-5533x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S0pGI7083785 for ; Mon, 27 Oct 2003 16:51:16 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9S0pGwh083784 for ietf-imapext-bks; Mon, 27 Oct 2003 16:51:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from willow.gnomon.org.uk (willow.gnomon.org.uk [69.10.132.76]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S0pEI7083774 for ; Mon, 27 Oct 2003 16:51:14 -0800 (PST) (envelope-from roy+dated+1069894271.45404d@gnomon.org.uk) Received: from moriarty.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by willow.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9S0pDRX014098 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Tue, 28 Oct 2003 00:51:16 GMT Received: from moriarty.gnomon.org.uk (roy@localhost [127.0.0.1]) by moriarty.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9S0pCZe008703 for ; Tue, 28 Oct 2003 00:51:12 GMT Received: by moriarty.gnomon.org.uk (tmda-sendmail, from uid 559); Tue, 28 Oct 2003 00:50:59 +0000 (GMT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16285.48493.496028.516294@moriarty.gnomon.org.uk> Date: Tue, 28 Oct 2003 00:50:53 +0000 To: Dave Crocker Cc: ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, , , , Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) In-Reply-To: <355752681.20031027161925@brandenburg.com> References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com> <12228881609.20031027074111@brandenburg.com> <20031027105222.4eae54fd.moore@cs.utk.edu> <355752681.20031027161925@brandenburg.com> X-Mailer: VM 7.03 under Emacs 20.7.2 From: Roy Badami X-Delivery-Agent: TMDA/0.81 (Swaps) X-Primary-Address: roy@gnomon.org.uk Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Mail Internationalised Local-Part (MILP) Even though, given IDNA now exists as a proposed standard, the main issues relate to the local part, the issue under discussion is that of internationalized mail addresses, not just internationalized local-parts. Restricting the disucssion to local-parts runs the risk of excluding other potentially relevent issues. For instance, one of the issues that has been discussed on the IMAA list is whether full-width at should be recognized in an internationalized mail address. IMHO, the charter shouldn't be framed in a way that is sufficiently narrow as to render such questions out of scope. -roy Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S0KYI7082575 for ; Mon, 27 Oct 2003 16:20:34 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9S0KY5V082574 for ietf-imapext-bks; Mon, 27 Oct 2003 16:20:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S0KWI7082563; Mon, 27 Oct 2003 16:20:32 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h9S0Qaf09143; Mon, 27 Oct 2003 16:26:36 -0800 Date: Mon, 27 Oct 2003 16:19:25 -0800 From: Dave Crocker X-Mailer: The Bat! (v2.00.22) Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <355752681.20031027161925@brandenburg.com> To: ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, , , , Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) In-Reply-To: References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com> <12228881609.20031027074111@brandenburg.com> <20031027105222.4eae54fd.moore@cs.utk.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Folks, On the theory that discussions go better when they have a concrete deliverable, here is a proposed charter for a proposed working group. The following started with Mark Crispin's text, although it might not look it. Besides the usual goals for a charter, the following text attempts to specify the problem domain in the narrowest feasible form that is valid. If anyone thinks the scope is too narrow, they need to explain why. DRAFT CHARTER Mail Internationalised Local-Part (MILP) --------------------------------- The portion of RFC2822 and portion of RFC2821 mail addresses are restricted to a subset of ASCII. This poses a fundamental barrier for users needing mail addresses to be expressed in a richer set of characters, such as Latin characters with diacriticals and the many Asian characters. The goal of the current work is to add local-part support for these additional characters, while preserving the large, installed base of ASCII usage. The group will take: draft-hoffman-imaa-03.txt draft-klensin-emailaddr-i18n-01.txt draft-duerst-iri-04.txt as input to discussions. The group will pay particular attention to barriers to adoption and utility, as well as any impact the new scheme might have on the existing base of Internet mail usage. Milestones ---------- Nov, 03: BOF Dec, 03: WG chartered Feb, 03: Initial draft of working group specifications. Jun, 03: Specifications submitted for IETF approval d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S0GOI7082404 for ; Mon, 27 Oct 2003 16:16:24 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9S0GOjl082403 for ietf-imapext-bks; Mon, 27 Oct 2003 16:16:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from w1309.hostcentric.net (w1309.hostcentric.net [66.40.78.254]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9S0GKI7082376 for ; Mon, 27 Oct 2003 16:16:20 -0800 (PST) (envelope-from mark.davis@jtcsv.com) Received: (qmail 22319 invoked by alias); 28 Oct 2003 00:16:21 -0000 Received: from unknown (HELO DAVIS1) (129.42.184.35) by 0 with SMTP; 28 Oct 2003 00:16:21 -0000 Message-ID: <00fd01c39ce8$b6f19fe0$79d52b09@DAVIS1> From: "Mark Davis" To: "Mark Crispin" , "Keith Moore" Cc: , , , , , , , , , , , , , References: Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA) Date: Mon, 27 Oct 2003 16:16:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'm curious: why do you think that everyone would be satisfied with Latin characters only, and no non-Latin characters? Mark __________________________________ http://www.macchiato.com â–º शिषà¥à¤¯à¤¾à¤¦à¤¿à¤šà¥à¤›à¥‡à¤¤à¥à¤ªà¤°à¤¾à¤œà¤¯à¤®à¥ â—„ ----- Original Message ----- From: "Mark Crispin" To: "Keith Moore" Cc: ; ; ; ; ; ; ; ; ; ; ; ; ; Sent: Mon, 2003 Oct 27 11:10 Subject: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA) > On Mon, 27 Oct 2003, Keith Moore wrote: > > >> Thanks for taking a stab at a problem statement. I'd like to drill down > >> on this just a bit. > >> What is the source of the "growing need"? Is it: > >> [snip] > > > I agree that this needs to be stated, but someone other than me will have > to do it. > > I believe that the primary push for this functionality comes from regions > which use Latin alphabetics with diacriticals; and that most individuals > in regions which do not use Latin script are accept the use of Latin > script for multinational interchange. In many regions where Latin > diacriticals are used, there is no acceptable transform of a surname to a > form that does not use diacriticals. Simply omitting the diacritical > causes (at least to the inhabitants of those regions) a misspelling. > > This set of beliefs naturally biases how I approach the problem. The > problem statement must be free of bias, including mine. > > -- Mark -- > > http://staff.washington.edu/mrc > Science does not emerge from voting, party politics, or public debate. > Si vis pacem, para bellum. > > > > > > > > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RNhGI7081094 for ; Mon, 27 Oct 2003 15:43:16 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RNhGgw081090 for ietf-imapext-bks; Mon, 27 Oct 2003 15:43:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from sentosa.post1.com (sentosa.post1.com [202.27.17.100]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9RNh9I7081060 for ; Mon, 27 Oct 2003 15:43:12 -0800 (PST) (envelope-from jseng@pobox.org.sg) Received: (qmail 5838 invoked from network); 28 Oct 2003 00:01:35 -0000 Received: from rifcd-04p117.ppp.odn.ad.jp (HELO pobox.org.sg) (211.3.24.117) by sentosa.post1.com with SMTP; 28 Oct 2003 00:01:35 -0000 Message-ID: <3F9CFC5D.7060509@pobox.org.sg> Date: Mon, 27 Oct 2003 19:07:09 +0800 From: James Seng User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= CC: ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, ietf-imapext@imc.org, ietf-smtp@imc.org, Pete Resnick , Ted Hardie , Ned Freed Subject: Re: [idn] FYI: BOF on Internationalized Email Addresses (IEA) References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com> In-Reply-To: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I seen John and Paul proposal but I have not seen Michel. Is there a draft that I can read up? ps: I wont be able to join the meeting but I am interested in the subject. -James Seng Patrik Fältström wrote: > At the IETF in Minneapolis, there will be a BOF on Internationalized > Email Addresses (IEA). > > It is *preliminary* on the agenda on Monday, November 10, 2003 at > 1530-1730. > > Chairs: Pete Resnick, Patrik Fältström > Mailing list:imaa@imc.org (other salient lists include uri@w3.org) > Agenda: > > Agenda Bashing (Chairs) 5 min. > Topic Introduction (Chairs) 10 min. > Proposals > IDNA-Based (Paul Hoffman) 15 min. > Infrastructure-Based (John Klensin) 15 min. > IRI-Based (Michel Suignard) 15 min. > > Discussion 60 min. > > Topics for discussion: > > Are there other solutions which have been specified? > > The solutions present the problem at different scopes; > > Where should the IETF tackle it? > > Are some short-term, and other long-term? > > Can the solutions be staged or co-exist? > > If staged, how to migrate from one to another? > > What are the next steps for the IETF? > > > NB: This BoF is exploratory in nature, and it is not intended that the > IETF will finalize a decision in this venue. It was proposed to foster > a community discussion, not charter a working group or pick a winner. If > further work is required, step one would be identifying individuals > willing to carry that work forward. > > Reading material: > draft-hoffman-imaa-03.txt > draft-klensin-emailaddr-i18n-01.txt > draft-duerst-iri-04.txt > > Pete and myself hope people will come with a lot of constructive > comments and ideas. > > Patrik, co-chair of the bof > > > > > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJBNI7069325 for ; Mon, 27 Oct 2003 11:11:23 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RJBN5v069324 for ietf-imapext-bks; Mon, 27 Oct 2003 11:11:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJBII7069299; Mon, 27 Oct 2003 11:11:18 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout3.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9RJAtC2014056; Mon, 27 Oct 2003 11:10:56 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9RJAtOx022764; Mon, 27 Oct 2003 11:10:55 -0800 Date: Mon, 27 Oct 2003 11:10:55 -0800 (PST) From: Mark Crispin To: Keith Moore cc: dcrocker@brandenburg.com, paf@cisco.com, ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, ietf-imapext@imc.org, ietf-smtp@imc.org, presnick@qualcomm.com, hardie@qualcomm.com, ned.freed@mrochek.com Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) In-Reply-To: <20031027134403.5eaaee9e.moore@cs.utk.edu> Message-ID: References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com> <12228881609.20031027074111@brandenburg.com> <20031027105222.4eae54fd.moore@cs.utk.edu> <20031027134403.5eaaee9e.moore@cs.utk.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 27 Oct 2003, Keith Moore wrote: > Thanks for taking a stab at a problem statement. I'd like to drill down > on this just a bit. > What is the source of the "growing need"? Is it: > [snip] I agree that this needs to be stated, but someone other than me will have to do it. I believe that the primary push for this functionality comes from regions which use Latin alphabetics with diacriticals; and that most individuals in regions which do not use Latin script are accept the use of Latin script for multinational interchange. In many regions where Latin diacriticals are used, there is no acceptable transform of a surname to a form that does not use diacriticals. Simply omitting the diacritical causes (at least to the inhabitants of those regions) a misspelling. This set of beliefs naturally biases how I approach the problem. The problem statement must be free of bias, including mine. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RIjdI7067925 for ; Mon, 27 Oct 2003 10:45:39 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RIjdHM067924 for ietf-imapext-bks; Mon, 27 Oct 2003 10:45:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RIjXI7067898; Mon, 27 Oct 2003 10:45:33 -0800 (PST) (envelope-from moore@cs.utk.edu) Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 4F4301401D; Mon, 27 Oct 2003 13:45:34 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25223-11; Mon, 27 Oct 2003 13:45:33 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with ESMTP id 3AA6C13FEC; Mon, 27 Oct 2003 13:45:33 -0500 (EST) Date: Mon, 27 Oct 2003 13:44:03 -0500 From: Keith Moore To: Mark Crispin Cc: moore@cs.utk.edu, dcrocker@brandenburg.com, paf@cisco.com, ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, ietf-imapext@imc.org, ietf-smtp@imc.org, presnick@qualcomm.com, hardie@qualcomm.com, ned.freed@mrochek.com Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) Message-Id: <20031027134403.5eaaee9e.moore@cs.utk.edu> In-Reply-To: References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com> <12228881609.20031027074111@brandenburg.com> <20031027105222.4eae54fd.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark, Thanks for taking a stab at a problem statement. I'd like to drill down on this just a bit. What is the source of the "growing need"? Is it: a. for users of many languages (particularly those not using Latin alphabets) email addresses are difficult to remember b. for users of many languages (particularly those not using Latin alphabets) email addresses are difficult to transcribe or type c. users want to use their names in email addresses d. users are confused by apparently arbitrary restrictions on use of characters in email addresses, and this leads to mistakes e. on computer systems employing non-ASCII names for other purposes (e.g. login or account names) these do not map well to ASCII email addresses or something else that I don't see? > As presently constituted, email addresses are limited to the 26 Latin > alphabetics, 10 digits, and a limited number of special characters in > the ASCII character set. There is a growing need to use additional > characters, specifically Latin characters with diacriticals and > non-Latin characters, in email addresses to better serve the needs of > the multi-national Internet community. However, the restrictions of > ASCII email addresses have served as a "lingua franca" since everybody > can enter ASCII email addresses, and there is an ongoing need for this > as well. The problem to be solved is the resolution of these two > needs. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RHkjI7063911 for ; Mon, 27 Oct 2003 09:46:45 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RHkj7Q063910 for ietf-imapext-bks; Mon, 27 Oct 2003 09:46:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RHkiI7063899 for ; Mon, 27 Oct 2003 09:46:44 -0800 (PST) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id h9RHkXZl032388; Mon, 27 Oct 2003 12:46:33 -0500 (EST) Message-ID: <3F9D5AAB.2060606@oceana.com> Date: Mon, 27 Oct 2003 12:49:31 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Arnt Gulbrandsen CC: IMAP Interest List , Mark Crispin , IMAP Extensions WG Subject: Re: Exchange server has a broken SASL implementation References: <3F9D4469.6020008@oceana.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Arnt Gulbrandsen wrote: > Ken Murchison writes: > >> Mark Crispin wrote: >> >>> Yet more proof that the SASL specifications as currently constituted >>> are too complex, and why IMAP should not add initial-response until >>> the SASL specifications are fixed. >> >> >> Or its more proof that M$ doesn't care about specs and choose to >> [re]define then as they see fit. > > > Do not attribute to malice that which can be adequately explained by > ignorance/release pressure/lack of time/blah/blah. So far, every > Microsoft programmer I've spoken to seemed to try hard. (I'm not saying > they succeed, but I _am_ saying they don't seem a malicious bunch.) I didn't mean to imply that anything that doesn't meet the specs was done maliciously by the programmers (over frustration from replying to Outlook bug emails). I have no knowledge that any mistakes are anything other than just simple mistakes. However, if there is/was any question about the specs, there are mailing lists that can be contacted for clarification. Interop testing could be done with non-MS products. The CMU SASL library comes with test harnesses which can be used for testing. There are at least 2 major MTAs (sendmail, postfix) which use CMU SASL that could have been consulted for comparison. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RHUuI7062585 for ; Mon, 27 Oct 2003 09:30:56 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RHUuw2062584 for ietf-imapext-bks; Mon, 27 Oct 2003 09:30:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mx.spindry.com (p1.spindry.com [64.5.41.83]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RHUsI7062559; Mon, 27 Oct 2003 09:30:54 -0800 (PST) (envelope-from bill-imc@carpenter.ORG) Received: from filenet-gw.filenet.com ([198.3.8.1] helo=ATTABOY.carpenter.ORG) by mx.spindry.com with smtp (Exim 3.36 #2) id 1AEBCg-0005Z8-00; Mon, 27 Oct 2003 12:30:54 -0500 Date: Mon, 27 Oct 2003 09:30:46 -0800 Message-ID: <4027-Mon27Oct2003093046-0800-bill@carpenter.ORG> X-Mailer: 21.1 (patch 9) "Canyonlands" XEmacs Lucid (via feedmail 11-beta-2 I) wjc loop; VM 6.71 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: bill-imc@carpenter.ORG (WJCarpenter) To: ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, ietf-imapext@imc.org, ietf-smtp@imc.org Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) In-Reply-To: References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com> <12228881609.20031027074111@brandenburg.com> <20031027105222.4eae54fd.moore@cs.utk.edu> Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: mc> As presently constituted, email addresses are limited to the 26 mc> Latin alphabetics, 10 digits, and a limited number of special mc> characters in the ASCII character set. There is a growing need to upper and lower case alphabetics -- bill-imc@carpenter.ORG (WJCarpenter) PGP 0x91865119 38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RHIBI7061906 for ; Mon, 27 Oct 2003 09:18:11 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RHIBMu061905 for ietf-imapext-bks; Mon, 27 Oct 2003 09:18:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RHIAI7061897 for ; Mon, 27 Oct 2003 09:18:10 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout5.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9RHHsMk024887; Mon, 27 Oct 2003 09:17:59 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9RHHs2l015776; Mon, 27 Oct 2003 09:17:54 -0800 Date: Mon, 27 Oct 2003 09:17:54 -0800 (PST) From: Mark Crispin To: Arnt Gulbrandsen cc: Ken Murchison , IMAP Interest List , IMAP Extensions WG Subject: Re: Exchange server has a broken SASL implementation In-Reply-To: Message-ID: References: <3F9D4469.6020008@oceana.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 27 Oct 2003, Arnt Gulbrandsen wrote: > Do not attribute to malice that which can be adequately explained by > ignorance/release pressure/lack of time/blah/blah. So far, every > Microsoft programmer I've spoken to seemed to try hard. (I'm not saying > they succeed, but I _am_ saying they don't seem a malicious bunch.) I agree with Arnt on all three of the above points. > We're talking about a set of interrelated documents that are light on > examples and free of a test suite. I'm not greatly surprised that > people have trouble implementing them correctly. We have seen this happen over and over again. The documents are broken. If Microsoft programmers don't care about specs and redefine them as they see fit, then we can say the same thing about the programmers of almost every other SASL server. This is an *extremely* common blunder. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RHDtI7061696 for ; Mon, 27 Oct 2003 09:13:55 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RHDts6061695 for ietf-imapext-bks; Mon, 27 Oct 2003 09:13:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RHDpI7061670; Mon, 27 Oct 2003 09:13:51 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout2.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9RHDThu011833; Mon, 27 Oct 2003 09:13:30 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9RHDTew015664; Mon, 27 Oct 2003 09:13:29 -0800 Date: Mon, 27 Oct 2003 09:13:29 -0800 (PST) From: Mark Crispin To: Keith Moore cc: Dave Crocker , paf@cisco.com, ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, ietf-imapext@imc.org, ietf-smtp@imc.org, presnick@qualcomm.com, hardie@qualcomm.com, ned.freed@mrochek.com Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) In-Reply-To: <20031027105222.4eae54fd.moore@cs.utk.edu> Message-ID: References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com> <12228881609.20031027074111@brandenburg.com> <20031027105222.4eae54fd.moore@cs.utk.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 27 Oct 2003, Keith Moore wrote: > what problem are we trying to solve here? I agree with Keith. This isn't to say that I dispute that there is a problem to be solved -- indeed, I think that the problem is apparent to all -- but we must have a problem statement that we all agree upon before we even think about solutions. I don't think that references to drafts of proposed solutions suffice as a problem statement. Leaving aside questions of possible bias (= present a problem in such a way that this is the obvious best solution), having the problem statement in a draft (which by its nature is an ephemeral document) muddies the issues. The problem statement should consist of a single paragraph (and preferably in one or two sentences), separate from any proposed solution, and stated in a charter which is approved by everyone. Here's a start at such a statement: As presently constituted, email addresses are limited to the 26 Latin alphabetics, 10 digits, and a limited number of special characters in the ASCII character set. There is a growing need to use additional characters, specifically Latin characters with diacriticals and non-Latin characters, in email addresses to better serve the needs of the multi-national Internet community. However, the restrictions of ASCII email addresses have served as a "lingua franca" since everybody can enter ASCII email addresses, and there is an ongoing need for this as well. The problem to be solved is the resolution of these two needs. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RHB3I7061570 for ; Mon, 27 Oct 2003 09:11:03 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RHB32X061568 for ietf-imapext-bks; Mon, 27 Oct 2003 09:11:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RHB2I7061559 for ; Mon, 27 Oct 2003 09:11:02 -0800 (PST) (envelope-from arnt@gulbrandsen.priv.no) Message-Id: From: Arnt Gulbrandsen To: Ken Murchison Subject: Re: Exchange server has a broken SASL implementation Cc: IMAP Interest List , Mark Crispin , IMAP Extensions WG References: <3F9D4469.6020008@oceana.com> In-Reply-To: <3F9D4469.6020008@oceana.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Mon, 27 Oct 2003 18:14:44 +0100 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ken Murchison writes: > Mark Crispin wrote: >> Yet more proof that the SASL specifications as currently constituted >> are too complex, and why IMAP should not add initial-response until >> the SASL specifications are fixed. > > Or its more proof that M$ doesn't care about specs and choose to > [re]define then as they see fit. Do not attribute to malice that which can be adequately explained by ignorance/release pressure/lack of time/blah/blah. So far, every Microsoft programmer I've spoken to seemed to try hard. (I'm not saying they succeed, but I _am_ saying they don't seem a malicious bunch.) We're talking about a set of interrelated documents that are light on examples and free of a test suite. I'm not greatly surprised that people have trouble implementing them correctly. (Larry: if there were a test suite for SMTP/SASL, would Microsoft have used it?) --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RH1rI7061180 for ; Mon, 27 Oct 2003 09:01:53 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RH1r3U061179 for ietf-imapext-bks; Mon, 27 Oct 2003 09:01:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from panoramix.hexago.com ([209.71.226.3]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RH1oI7061125; Mon, 27 Oct 2003 09:01:50 -0800 (PST) (envelope-from Marc.Blanchet@viagenie.qc.ca) Received: from localhost (retro.viagenie.qc.ca [IPv6:3ffe:b00:c18:3::22]) (authenticated bits=0) by panoramix.hexago.com (8.12.8/8.12.8) with ESMTP id h9RH0M6r005886; Mon, 27 Oct 2003 12:00:22 -0500 (EST) Date: Mon, 27 Oct 2003 12:00:01 -0500 From: Marc Blanchet To: Keith Moore , Dave Crocker cc: paf@cisco.com, ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, ietf-imapext@imc.org, ietf-smtp@imc.org, presnick@qualcomm.com, hardie@qualcomm.com, ned.freed@mrochek.com Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) Message-ID: <575390000.1067274001@classic.viagenie.qc.ca> In-Reply-To: <20031027105222.4eae54fd.moore@cs.utk.edu> References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com> <12228881609.20031027074111@brandenburg.com> <20031027105222.4eae54fd.moore@cs.utk.edu> X-Mailer: Mulberry/3.1.0b8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: -- Monday, October 27, 2003 10:52:22 -0500 Keith Moore wrote/a ecrit: >> PF> What are the next steps for the IETF? >> >> Would it help to have a draft charter for the meeting? > > let's back up a step further. > > what problem are we trying to solve here? to me, that (problem we are trying to solve) would be part of the introduction in the charter... so I guess some initial proposal for: - what are we trying to solve - what would be the way to solve it would be a good starting point together with the "state-of-the-art" presentations. Marc. > > Keith ------------------------------------------ Marc Blanchet Hexago tel: +1-418-266-5533x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RGbWI7060051 for ; Mon, 27 Oct 2003 08:37:32 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RGbWa9060050 for ietf-imapext-bks; Mon, 27 Oct 2003 08:37:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from episteme-software.com (216-43-25-66.ip.mcleodusa.net [216.43.25.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RGbRI7060023; Mon, 27 Oct 2003 08:37:27 -0800 (PST) (envelope-from presnick@qualcomm.com) Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b1); Mon, 27 Oct 2003 10:37:25 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <20031027105222.4eae54fd.moore@cs.utk.edu> References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com> <12228881609.20031027074111@brandenburg.com> <20031027105222.4eae54fd.moore@cs.utk.edu> X-Mailer: Eudora [Macintosh version 6.1a2] Date: Mon, 27 Oct 2003 10:37:21 -0600 To: Keith Moore From: Pete Resnick Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) Cc: Dave Crocker , moore@cs.utk.edu, paf@cisco.com, ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, ietf-imapext@imc.org, ietf-smtp@imc.org, hardie@qualcomm.com, ned.freed@mrochek.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 10/27/03 at 10:52 AM -0500, Keith Moore wrote: >>DC: Would it help to have a draft charter for the meeting? As was mentioned in the draft agenda at , we want to simply start the discussion, not immediately attempt to charter a working group. >let's back up a step further. > >what problem are we trying to solve here? Please have a look at draft-hoffman-imaa, draft-klensin-emailaddr-i18n, and draft-duerst-iri. Certainly the first two have very explicit descriptions of the problem. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RGBnI7058337 for ; Mon, 27 Oct 2003 08:11:49 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RGBnrk058334 for ietf-imapext-bks; Mon, 27 Oct 2003 08:11:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RGBlI7058326 for ; Mon, 27 Oct 2003 08:11:48 -0800 (PST) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id h9RGBZZl030658; Mon, 27 Oct 2003 11:11:36 -0500 (EST) Message-ID: <3F9D4469.6020008@oceana.com> Date: Mon, 27 Oct 2003 11:14:33 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Mark Crispin CC: IMAP Interest List , IMAP Extensions WG Subject: Re: Exchange server has a broken SASL implementation References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > It looks like Microsoft finally implemented support for the GSSAPI SASL > mechanism. > > Unfortunately, they screwed it up. In their SMTP server, they respond to > the command "AUTH GSSAPI" with "334 gssapi supported". > > Yet more proof that the SASL specifications as currently constituted are > too complex, and why IMAP should not add initial-response until the SASL > specifications are fixed. Or its more proof that M$ doesn't care about specs and choose to [re]define then as they see fit. Can you show me where the SASL specs or SMTP SASL profile gives them license to put garbage in the challenge? -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RFrrI7057219 for ; Mon, 27 Oct 2003 07:53:53 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RFrraY057218 for ietf-imapext-bks; Mon, 27 Oct 2003 07:53:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RFrnI7057198; Mon, 27 Oct 2003 07:53:50 -0800 (PST) (envelope-from moore@cs.utk.edu) Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 812AC14142; Mon, 27 Oct 2003 10:53:50 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01580-02; Mon, 27 Oct 2003 10:53:49 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with ESMTP id 7D86C14094; Mon, 27 Oct 2003 10:53:49 -0500 (EST) Date: Mon, 27 Oct 2003 10:52:22 -0500 From: Keith Moore To: Dave Crocker Cc: moore@cs.utk.edu, paf@cisco.com, ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, ietf-imapext@imc.org, ietf-smtp@imc.org, presnick@qualcomm.com, hardie@qualcomm.com, ned.freed@mrochek.com Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) Message-Id: <20031027105222.4eae54fd.moore@cs.utk.edu> In-Reply-To: <12228881609.20031027074111@brandenburg.com> References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com> <12228881609.20031027074111@brandenburg.com> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > PF> What are the next steps for the IETF? > > Would it help to have a draft charter for the meeting? let's back up a step further. what problem are we trying to solve here? Keith Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RFipI7056728 for ; Mon, 27 Oct 2003 07:44:52 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RFipmG056727 for ietf-imapext-bks; Mon, 27 Oct 2003 07:44:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RFimI7056714; Mon, 27 Oct 2003 07:44:48 -0800 (PST) (envelope-from dcrocker@brandenburg.com) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h9RFokf29900; Mon, 27 Oct 2003 07:50:46 -0800 Date: Mon, 27 Oct 2003 07:41:11 -0800 From: Dave Crocker X-Mailer: The Bat! (v2.00.22) Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <12228881609.20031027074111@brandenburg.com> To: =?ISO-8859-1?B?UGF0cmlrIEbkbHRzdHL2bQ==?= CC: ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, , , , , Pete Resnick , Ted Hardie , Ned Freed Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) In-Reply-To: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com> References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Patrik, Thanks for putting this BOF together. PF> Where should the IETF tackle it? I am not sure I understand this question. Please clarify. PF> What are the next steps for the IETF? Would it help to have a draft charter for the meeting? (I realize that the presence of such different specifications makes a charter at least a bit challenging, but it seems to help to have a draft, to make things concrete.) d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RFZSI7056003 for ; Mon, 27 Oct 2003 07:35:28 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RFZSN2056002 for ietf-imapext-bks; Mon, 27 Oct 2003 07:35:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout6.cac.washington.edu (mxout6.cac.washington.edu [140.142.33.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RFZRI7055995 for ; Mon, 27 Oct 2003 07:35:27 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout6.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9RFZM0Y029502; Mon, 27 Oct 2003 07:35:27 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9RFZMLi011061; Mon, 27 Oct 2003 07:35:22 -0800 Date: Mon, 27 Oct 2003 07:35:22 -0800 (PST) From: Mark Crispin To: IMAP Interest List , IMAP Extensions WG Subject: Exchange server has a broken SASL implementation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It looks like Microsoft finally implemented support for the GSSAPI SASL mechanism. Unfortunately, they screwed it up. In their SMTP server, they respond to the command "AUTH GSSAPI" with "334 gssapi supported". Yet more proof that the SASL specifications as currently constituted are too complex, and why IMAP should not add initial-response until the SASL specifications are fixed. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9QJtRI7031768 for ; Sun, 26 Oct 2003 11:55:27 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9QJtRLs031767 for ietf-imapext-bks; Sun, 26 Oct 2003 11:55:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.74.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9QJtGI7031748; Sun, 26 Oct 2003 11:55:17 -0800 (PST) (envelope-from paf@cisco.com) Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 26 Oct 2003 20:53:10 +0100 Received: from xbe-ams-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h9QJt4l0006339; Sun, 26 Oct 2003 20:55:04 +0100 (MET) Received: from xfe-ams-311.cisco.com ([144.254.228.204]) by xbe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 26 Oct 2003 20:55:11 +0100 Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-311.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 26 Oct 2003 20:55:10 +0100 Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com> Cc: Pete Resnick , Ted Hardie , Ned Freed From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: FYI: BOF on Internationalized Email Addresses (IEA) Date: Sun, 26 Oct 2003 20:55:08 +0100 To: ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, ietf-imapext@imc.org, ietf-smtp@imc.org X-Mailer: Apple Mail (2.606) X-OriginalArrivalTime: 26 Oct 2003 19:55:10.0612 (UTC) FILETIME=[101FC540:01C39BFB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9QJtIIA031751 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At the IETF in Minneapolis, there will be a BOF on Internationalized Email Addresses (IEA). It is *preliminary* on the agenda on Monday, November 10, 2003 at 1530-1730. Chairs: Pete Resnick, Patrik Fältström Mailing list:imaa@imc.org (other salient lists include uri@w3.org) Agenda: Agenda Bashing (Chairs) 5 min. Topic Introduction (Chairs) 10 min. Proposals IDNA-Based (Paul Hoffman) 15 min. Infrastructure-Based (John Klensin) 15 min. IRI-Based (Michel Suignard) 15 min. Discussion 60 min. Topics for discussion: Are there other solutions which have been specified? The solutions present the problem at different scopes; Where should the IETF tackle it? Are some short-term, and other long-term? Can the solutions be staged or co-exist? If staged, how to migrate from one to another? What are the next steps for the IETF? NB: This BoF is exploratory in nature, and it is not intended that the IETF will finalize a decision in this venue. It was proposed to foster a community discussion, not charter a working group or pick a winner. If further work is required, step one would be identifying individuals willing to carry that work forward. Reading material: draft-hoffman-imaa-03.txt draft-klensin-emailaddr-i18n-01.txt draft-duerst-iri-04.txt Pete and myself hope people will come with a lot of constructive comments and ideas. Patrik, co-chair of the bof Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MGNxI7049540 for ; Wed, 22 Oct 2003 09:23:59 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MGNxvj049539 for ietf-imapext-bks; Wed, 22 Oct 2003 09:23:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MGNwI7049534 for ; Wed, 22 Oct 2003 09:23:58 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [63.163.82.24] (socrates.cyrusoft.com [63.163.82.24]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id h9MGHHEG012831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Oct 2003 12:17:20 -0400 Date: Wed, 22 Oct 2003 12:24:05 -0400 From: Cyrus Daboo To: Rob Siemborski cc: Arnt Gulbrandsen , IMAP extensions Mailing List Subject: Re: I-D ACTION:draft-daboo-imap-annotatemore-04.txt Message-ID: <2147483647.1066825445@[10.0.1.12]> In-Reply-To: References: <200310211958.PAA04193@ietf.org> <1066798632.10244.6.camel@hurina> <2147483647.1066819234@[10.0.1.12]> <2147483647.1066824623@[10.0.1.12]> X-Mailer: Mulberry/3.1.0b8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Rob, --On Wednesday, October 22, 2003 12:14 -0400 Rob Siemborski wrote: | I did just notice (in the GETANNOTATION text): | | This command is only available in authenticated state [IMAP4]. | | Shouldn't it also be available in the selected state? AFAIK, they aren't | the same. OK - fixed in working copy. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MGECI7049151 for ; Wed, 22 Oct 2003 09:14:12 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MGECxd049150 for ietf-imapext-bks; Wed, 22 Oct 2003 09:14:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MGEAI7049143 for ; Wed, 22 Oct 2003 09:14:10 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9MGE8k4013781; Wed, 22 Oct 2003 12:14:08 -0400 Date: Wed, 22 Oct 2003 12:14:07 -0400 (EDT) From: Rob Siemborski To: Cyrus Daboo cc: Arnt Gulbrandsen , IMAP extensions Mailing List Subject: Re: I-D ACTION:draft-daboo-imap-annotatemore-04.txt In-Reply-To: <2147483647.1066824623@[10.0.1.12]> Message-ID: References: <200310211958.PAA04193@ietf.org> <1066798632.10244.6.camel@hurina> <2147483647.1066819234@[10.0.1.12]> <2147483647.1066824623@[10.0.1.12]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 22 Oct 2003, Cyrus Daboo wrote: > | I tend to agree that punting seems to be the safest option. > > Would you want to restrict GETANNOTATION in the same way? Not offhand, GETANNOTATION can safely suffer partial failures, e.g.: * ANNOTATION * ANNOTATION x NO Couldn't contact some backend servers I did just notice (in the GETANNOTATION text): This command is only available in authenticated state [IMAP4]. Shouldn't it also be available in the selected state? AFAIK, they aren't the same. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MGAGI7049031 for ; Wed, 22 Oct 2003 09:10:16 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MGAGRX049030 for ietf-imapext-bks; Wed, 22 Oct 2003 09:10:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MGAFI7049024 for ; Wed, 22 Oct 2003 09:10:15 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [63.163.82.24] (socrates.cyrusoft.com [63.163.82.24]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id h9MG3ZEG012670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Oct 2003 12:03:37 -0400 Date: Wed, 22 Oct 2003 12:10:23 -0400 From: Cyrus Daboo To: Rob Siemborski , Arnt Gulbrandsen cc: IMAP extensions Mailing List Subject: Re: I-D ACTION:draft-daboo-imap-annotatemore-04.txt Message-ID: <2147483647.1066824623@[10.0.1.12]> In-Reply-To: References: <200310211958.PAA04193@ietf.org> <1066798632.10244.6.camel@hurina> <2147483647.1066819234@[10.0.1.12]> X-Mailer: Mulberry/3.1.0b8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Rob, --On Wednesday, October 22, 2003 12:05 -0400 Rob Siemborski wrote: | On Wed, 22 Oct 2003, Arnt Gulbrandsen wrote: | |> Cyrus Daboo writes: |> > There could be client applications that require an all-or-nothing |> > change. That said having partial failure (or success) responses would |> > be OK too. Either that or we punt the whole question by disallowing |> > multi-mailbox operations in the first place. |> |> Punting seems like a good idea. If necessary, add language mentioning |> that clients can send several store commands at the same time. (That |> should be possible, as I remember the draft... right?) | | I tend to agree that punting seems to be the safest option. Would you want to restrict GETANNOTATION in the same way? -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MG5AI7048885 for ; Wed, 22 Oct 2003 09:05:10 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MG5AZQ048884 for ietf-imapext-bks; Wed, 22 Oct 2003 09:05:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MG56I7048877 for ; Wed, 22 Oct 2003 09:05:07 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9MG53k4013771; Wed, 22 Oct 2003 12:05:03 -0400 Date: Wed, 22 Oct 2003 12:05:02 -0400 (EDT) From: Rob Siemborski To: Arnt Gulbrandsen cc: Cyrus Daboo , IMAP extensions Mailing List Subject: Re: I-D ACTION:draft-daboo-imap-annotatemore-04.txt In-Reply-To: Message-ID: References: <200310211958.PAA04193@ietf.org> <1066798632.10244.6.camel@hurina> <2147483647.1066819234@[10.0.1.12]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 22 Oct 2003, Arnt Gulbrandsen wrote: > Cyrus Daboo writes: > > There could be client applications that require an all-or-nothing > > change. That said having partial failure (or success) responses would > > be OK too. Either that or we punt the whole question by disallowing > > multi-mailbox operations in the first place. > > Punting seems like a good idea. If necessary, add language mentioning > that clients can send several store commands at the same time. (That > should be possible, as I remember the draft... right?) I tend to agree that punting seems to be the safest option. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MFGNI7046110 for ; Wed, 22 Oct 2003 08:16:23 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MFGN9Q046109 for ietf-imapext-bks; Wed, 22 Oct 2003 08:16:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MFGHI7046102 for ; Wed, 22 Oct 2003 08:16:22 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Message-Id: From: Arnt Gulbrandsen To: Cyrus Daboo Subject: Re: I-D ACTION:draft-daboo-imap-annotatemore-04.txt Cc: Rob Siemborski , IMAP extensions Mailing List References: <200310211958.PAA04193@ietf.org> <1066798632.10244.6.camel@hurina> <2147483647.1066819234@[10.0.1.12]> In-Reply-To: <2147483647.1066819234@[10.0.1.12]> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Wed, 22 Oct 2003 17:19:37 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus Daboo writes: > There could be client applications that require an all-or-nothing > change. That said having partial failure (or success) responses would > be OK too. Either that or we punt the whole question by disallowing > multi-mailbox operations in the first place. Punting seems like a good idea. If necessary, add language mentioning that clients can send several store commands at the same time. (That should be possible, as I remember the draft... right?) --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MEeQI7043849 for ; Wed, 22 Oct 2003 07:40:26 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MEeQg7043848 for ietf-imapext-bks; Wed, 22 Oct 2003 07:40:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MEeOI7043843 for ; Wed, 22 Oct 2003 07:40:25 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [10.0.1.12] (socrates.cyrusoft.com [63.163.82.24]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id h9MEXkEG011576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Oct 2003 10:33:49 -0400 Date: Wed, 22 Oct 2003 10:40:34 -0400 From: Cyrus Daboo To: Rob Siemborski , ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-daboo-imap-annotatemore-04.txt Message-ID: <2147483647.1066819234@[10.0.1.12]> In-Reply-To: References: <200310211958.PAA04193@ietf.org> <1066798632.10244.6.camel@hurina> X-Mailer: Mulberry/3.1.0b8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Rob, --On Wednesday, October 22, 2003 10:10 -0400 Rob Siemborski wrote: |> > If the server is unable to store the annotations for one or more |> > mailboxes matching the mailbox-name pattern, then the SETANNOTATION |> > command MUST fail and there MUST NOT be any changes to any of the |> > matching mailboxes, even those for which annotations could have been |> > changed successfully. |> |> So you want to limit ANNOTATEMORE to work only with servers using |> transactional databases? | | This worries me, as it is a pretty severe implementation burden on IMAP | proxies as well. | |> Maybe SETANNOTATION could rather just send untagged replies for |> mailboxes it changes? | | Or perhaps untagged NO responses for those annotations it couldn't change. There could be client applications that require an all-or-nothing change. That said having partial failure (or success) responses would be OK too. Either that or we punt the whole question by disallowing multi-mailbox operations in the first place. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MEAwI7042643 for ; Wed, 22 Oct 2003 07:10:58 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MEAwHn042642 for ietf-imapext-bks; Wed, 22 Oct 2003 07:10:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MEAuI7042636 for ; Wed, 22 Oct 2003 07:10:56 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9MEAtk4013621 for ; Wed, 22 Oct 2003 10:10:55 -0400 Date: Wed, 22 Oct 2003 10:10:56 -0400 (EDT) From: Rob Siemborski To: ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-daboo-imap-annotatemore-04.txt In-Reply-To: <1066798632.10244.6.camel@hurina> Message-ID: References: <200310211958.PAA04193@ietf.org> <1066798632.10244.6.camel@hurina> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 22 Oct 2003, Timo Sirainen wrote: > > If the server is unable to store the annotations for one or more > > mailboxes matching the mailbox-name pattern, then the SETANNOTATION > > command MUST fail and there MUST NOT be any changes to any of the > > matching mailboxes, even those for which annotations could have been > > changed successfully. > > So you want to limit ANNOTATEMORE to work only with servers using > transactional databases? This worries me, as it is a pretty severe implementation burden on IMAP proxies as well. > Maybe SETANNOTATION could rather just send untagged replies for > mailboxes it changes? Or perhaps untagged NO responses for those annotations it couldn't change. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9M4vLI7054523 for ; Tue, 21 Oct 2003 21:57:21 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9M4vLOi054522 for ietf-imapext-bks; Tue, 21 Oct 2003 21:57:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9M4vJI7054513 for ; Tue, 21 Oct 2003 21:57:20 -0700 (PDT) (envelope-from tss@iki.fi) Received: from localhost.kpnqwest.fi (localhost [127.0.0.1]) by oma.irssi.org (Postfix) with ESMTP id 52F685C616E3 for ; Wed, 22 Oct 2003 07:57:13 +0300 (EEST) Subject: Re: I-D ACTION:draft-daboo-imap-annotatemore-04.txt From: Timo Sirainen To: ietf-imapext@imc.org In-Reply-To: <200310211958.PAA04193@ietf.org> References: <200310211958.PAA04193@ietf.org> Content-Type: text/plain Message-Id: <1066798632.10244.6.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Wed, 22 Oct 2003 07:57:12 +0300 Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > If the server is unable to store the annotations for one or more > mailboxes matching the mailbox-name pattern, then the SETANNOTATION > command MUST fail and there MUST NOT be any changes to any of the > matching mailboxes, even those for which annotations could have been > changed successfully. So you want to limit ANNOTATEMORE to work only with servers using transactional databases? Maybe SETANNOTATION could rather just send untagged replies for mailboxes it changes? Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LKpXI7039742 for ; Tue, 21 Oct 2003 13:51:33 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LKpX09039740 for ietf-imapext-bks; Tue, 21 Oct 2003 13:51:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LKpWI7039734 for ; Tue, 21 Oct 2003 13:51:33 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [63.163.82.24]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id h9LKj2EG031301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Oct 2003 16:45:06 -0400 Received: from mx3.andrew.cmu.edu (MX3.andrew.cmu.edu [128.2.10.113]) by mail1.andrew.cmu.edu (Cyrus v2.1.15-077) with LMTP; Tue, 21 Oct 2003 16:39:03 -0400 X-Sieve: CMU Sieve 2.2 Received: from mx3.andrew.cmu.edu ([unix socket]) by mx3.andrew.cmu.edu (Cyrus v2.1.12-075) with LMTP; Tue, 21 Oct 2003 16:39:02 -0400 Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx3.andrew.cmu.edu (8.12.10/8.12.9) with ESMTP id h9LKcu85001100; Tue, 21 Oct 2003 16:38:57 -0400 Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1AC2ls-0005Oy-1t for ietf-announce-list@asgard.ietf.org; Tue, 21 Oct 2003 16:06:24 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1AC2eR-0005AF-H0 for all-ietf@asgard.ietf.org; Tue, 21 Oct 2003 15:58:43 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04193 for ; Tue, 21 Oct 2003 15:58:32 -0400 (EDT) Message-Id: <200310211958.PAA04193@ietf.org> To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 21 Oct 2003 15:58:32 -0400 Subject: I-D ACTION:draft-daboo-imap-annotatemore-04.txt X-Resent-Mailer: Mulberry/3.1.0b8 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========1DDCBDEFA700D5D5269E==========" X-Spam-Level: **** Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --==========1DDCBDEFA700D5D5269E========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IMAP ANNOTATEMORE Extension Author(s) : C. Daboo Filename : draft-daboo-imap-annotatemore-04.txt Pages : 17 Date : 2003-10-21 The ANNOTATEMORE extension to the Internet Message Access Protocol [IMAP4] permits clients and servers to maintain 'metadata' on IMAP4 servers. It is possible to store data on a per-mailbox basis or on the server as a whole. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-daboo-imap-annotatemore-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-daboo-imap-annotatemore-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-daboo-imap-annotatemore-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --==========1DDCBDEFA700D5D5269E========== Content-Type: multipart/alternative; boundary="==========12F7B0FC35D353082042==========" --==========12F7B0FC35D353082042========== Content-Type: message/external-body; ACCESS-TYPE=mail-server; SERVER="mailserv@ietf.org" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-10-21153612.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-daboo-imap-annotatemore-04.txt --==========12F7B0FC35D353082042========== Content-Type: message/external-body; name="draft-daboo-imap-annotatemore-04.txt"; SITE="ftp.ietf.org"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-10-21153612.I-D@ietf.org> --==========12F7B0FC35D353082042==========-- --==========1DDCBDEFA700D5D5269E==========-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LK1KI7038236 for ; Tue, 21 Oct 2003 13:01:20 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LK1K30038235 for ietf-imapext-bks; Tue, 21 Oct 2003 13:01:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LK1II7038230 for ; Tue, 21 Oct 2003 13:01:19 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04903; Tue, 21 Oct 2003 16:01:09 -0400 (EDT) Message-Id: <200310212001.QAA04903@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-annotate-08.txt Date: Tue, 21 Oct 2003 16:01:09 -0400 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF. Title : IMAP ANNOTATE Extension Author(s) : R. Gellens, C. Daboo Filename : draft-ietf-imapext-annotate-08.txt Pages : 22 Date : 2003-10-21 The ANNOTATE extension to the Internet Message Access Protocol [IMAP4] permits clients and servers to maintain 'metadata' for messages stored in an IMAP4 mailbox. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-imapext-annotate-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imapext-annotate-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-21154123.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-annotate-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-annotate-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-21154123.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9KM8XI7011823 for ; Mon, 20 Oct 2003 15:08:33 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9KM8XWj011822 for ietf-imapext-bks; Mon, 20 Oct 2003 15:08:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from episteme-software.com (216-43-25-66.ip.mcleodusa.net [216.43.25.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9KM8WI7011817 for ; Mon, 20 Oct 2003 15:08:32 -0700 (PDT) (envelope-from presnick@qualcomm.com) Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b1); Mon, 20 Oct 2003 17:08:39 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: X-Mailer: Eudora [Macintosh version 6.1a2] Date: Mon, 20 Oct 2003 17:08:32 -0500 To: Lemonade From: Pete Resnick Subject: IMAP COMPOSE extension Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [Bcc'ed to IMAPEXT; please followup to LEMONADE] I didn't have time last week to finish an I-D before the deadline, but I figured I should at least start the conversation on the list before Minneapolis. When talking about IMAP Push vs. IMAP Pull for "forward without download" in Vienna, a lot of us thought that in either case, it would be handy to have an an IMAP COMPOSE command. The idea here would be COMPOSE would be pretty much like APPEND (with the mailbox in which to append, an optional flag list and optional date/time string), except that instead of a message literal, it would take as parameters any number of literals and "message part identifiers". All of the literals and the message parts would be appended together in the destination mailbox as one big message. The client would be responsible for providing the appropriate MIME boundaries in the literals. Having a composed message on the IMAP server would work for either IMAP push or IMAP pull, and this would obviously be useful for more than just "forward without download". However, I still have some issues with the exact nature of this command. Specifically, my big question is how to deal with the "message part identifiers". A message part identifier would clearly include a sequence number or UID followed by message data item names or a macro, just like FETCH. However, the downside to making it look exactly like the FETCH parameters is that you can only compose a message made up of parts that are contained in the currently selected mailbox. Maybe that is sufficient given the application for which LEMONADE wants this, but it's clearly a limitation. The other choice is that the message part identifier would also include a mailbox name. We could come up with some syntax for that or just use a relative IMAP URL. Of course, the upside is that you'd be able to collect together messages in different parts of the IMAP store. But there are a couple of really big downsides: 1. It breaks the assumption that you only ever have one mailbox selected. In effect, you'd be required on the server to access multiple mailboxes in the course of a single command execution. Maybe that's OK to require for this extension; maybe not. 2. If it is allowed to be other than a relative URL to *this* IMAP server, suddenly you get into the business of doing all of the IMAP client work that folks were so worried about when this discussion started. 3. Allowing it to be a URL might start us down the slippery slope of allowing *any* kind of URL, not just IMAP. The results of that are left as an exercise to the reader. Having the more general syntax (i.e., something that includes the mailbox) might be nice for folks who want to do fancier things in the future. We could allow any server to say "NO" if given something with another mailbox (or server, or scheme). Or maybe we don't want to do this at all. Feedback desired. I'll float a straw-man proposal to the list (which obviously won't make it as an I-D for Minneapolis) as soon as I can. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IA4MI7010149 for ; Sat, 18 Oct 2003 03:04:22 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9IA4M1o010148 for ietf-imapext-bks; Sat, 18 Oct 2003 03:04:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IA4KI7010143 for ; Sat, 18 Oct 2003 03:04:20 -0700 (PDT) (envelope-from mganesh@india.hp.com) Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by atlrel6.hp.com (Postfix) with ESMTP id EEA951C0111F; Sat, 18 Oct 2003 06:04:15 -0400 (EDT) Received: from nt23060 (nt23060.india.hp.com [15.42.230.60]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id PAA07255; Sat, 18 Oct 2003 15:33:04 +0530 (IST) From: "Madan Ganesh Velayudham" To: "'Lyndon Nerenberg'" Cc: "'IMAP Extensions WG'" Subject: RE: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt Date: Sat, 18 Oct 2003 15:34:13 +0530 Organization: Hewlett-Packard STSD Message-ID: <00dd01c3955f$2f998d90$3ce62a0f@nt23060> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <700090757.1066396251@[192.168.42.6]> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: owner-ietf-imapext@mail.imc.org > [mailto:owner-ietf-imapext@mail.imc.org] On Behalf Of Lyndon Nerenberg > Sent: Saturday, October 18, 2003 12:41 AM > To: Madan Ganesh Velayudham > Cc: 'IMAP Extensions WG' > Subject: RE: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt > > > > > I understand them clearly. My belif is that my solution > > would have some performance benefits compared having them > > externally. > > Then do the math and prove it. Definitely. > > > I will try to find some loop holes in sieve for arugments :-) > > Please stop wasting our time. We do engineering here. > Marketing is down > the hall. That was just a comment. Pls donot take it seriously. > > --lyndon > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9HJB3I7022434 for ; Fri, 17 Oct 2003 12:11:03 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9HJB362022433 for ietf-imapext-bks; Fri, 17 Oct 2003 12:11:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9HJB2I7022427 for ; Fri, 17 Oct 2003 12:11:02 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Received: from [192.168.42.6] (peregrin.orthanc.ca [192.168.42.6]) by orthanc.ca (8.12.9p1/8.12.9) with ESMTP id h9HJB0P5058981; Fri, 17 Oct 2003 13:11:00 -0600 (MDT) (envelope-from lyndon@orthanc.ca) Date: Fri, 17 Oct 2003 13:10:51 -0600 From: Lyndon Nerenberg To: Madan Ganesh Velayudham cc: "'IMAP Extensions WG'" Subject: RE: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt Message-ID: <700090757.1066396251@[192.168.42.6]> In-Reply-To: <000301c394a6$afa405b0$3ce62a0f@nt23060> References: <000301c394a6$afa405b0$3ce62a0f@nt23060> X-Mailer: Mulberry/3.1.0b8 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========10C64BD7E4C20F34569B==========" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --==========10C64BD7E4C20F34569B========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > I understand them clearly. My belif is that my solution > would have some performance benefits compared having them > externally. Then do the math and prove it. > I will try to find some loop holes in sieve for arugments :-) Please stop wasting our time. We do engineering here. Marketing is down=20 the hall. --lyndon --==========10C64BD7E4C20F34569B========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: Mulberry PGP Plugin v3.0 Comment: processed by Mulberry PGP Plugin iQA/AwUBP5A+w+LnPQjwN7SAEQJklQCdHaNdBQzV8/G7ohcbdE4Qcj8k3osAoL1/ vyEWrXKiz6vz0nT+vnLZhq3M =CUFM -----END PGP SIGNATURE----- --==========10C64BD7E4C20F34569B==========-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9HDJ6I7009929 for ; Fri, 17 Oct 2003 06:19:06 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9HDJ6ST009928 for ietf-imapext-bks; Fri, 17 Oct 2003 06:19:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9HDJ4I7009923 for ; Fri, 17 Oct 2003 06:19:05 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9HDJ2k4004101; Fri, 17 Oct 2003 09:19:02 -0400 Date: Fri, 17 Oct 2003 09:19:02 -0400 (EDT) From: Rob Siemborski To: Madan Ganesh Velayudham cc: "'Mark Crispin'" , "'IMAP Extensions WG'" Subject: RE: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt In-Reply-To: <000301c394a6$afa405b0$3ce62a0f@nt23060> Message-ID: References: <000301c394a6$afa405b0$3ce62a0f@nt23060> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 17 Oct 2003, Madan Ganesh Velayudham wrote: > Thanks for your recommendations. Could you please get > me the wg that analyzes sieve. There is currently no working group, however there are a bunch of people who read the ietf-mta-filters@imc.org list. http://www.imc.org/ietf-mta-filters/index.html -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9HCmTI7008827 for ; Fri, 17 Oct 2003 05:48:29 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9HCmT5O008826 for ietf-imapext-bks; Fri, 17 Oct 2003 05:48:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9HCmOI7008818 for ; Fri, 17 Oct 2003 05:48:28 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Message-Id: From: Arnt Gulbrandsen To: Cyrus Daboo Subject: Re: SASL Initial Response? Cc: Ken Murchison , Rob Siemborski , Mark Crispin , IMAP Extensions WG References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> <3F8305BF.2050706@oceana.com> <2147483647.1066304385@socrates.cyrusoft.com> <2147483647.1066311186@socrates.cyrusoft.com> In-Reply-To: <2147483647.1066311186@socrates.cyrusoft.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Fri, 17 Oct 2003 14:51:16 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus Daboo writes: > A summary of the profiles and mechanisms - not a full detailed > description of each. This could be as simple as a table listing which > options a particular protocol's profile provides. e.g.: That table belongs on www.iana.org, doesn't it? Like the (hopelessly outdated) IMAP extensions page. > | b) a document that points out common errors in SASL implementations > > Yes.. Like 2683? Good idea, but I can't even comment on it, far less suggest appropriate content. --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9HC3aI7007805 for ; Fri, 17 Oct 2003 05:03:36 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9HC3asI007804 for ietf-imapext-bks; Fri, 17 Oct 2003 05:03:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9HC3ZI7007799 for ; Fri, 17 Oct 2003 05:03:35 -0700 (PDT) (envelope-from mganesh@india.hp.com) Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel12.hp.com (Postfix) with ESMTP id 3873C1C02155; Fri, 17 Oct 2003 05:03:34 -0700 (PDT) Received: from nt23060 (nt23060.india.hp.com [15.42.230.60]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id RAA25058; Fri, 17 Oct 2003 17:32:18 +0530 (IST) From: "Madan Ganesh Velayudham" To: "'Mark Crispin'" Cc: "'IMAP Extensions WG'" Subject: RE: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt Date: Fri, 17 Oct 2003 17:33:26 +0530 Organization: Hewlett-Packard STSD Message-ID: <000301c394a6$afa405b0$3ce62a0f@nt23060> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > Capabilities are defined in RFC 3501 as atoms. You can not > have multi-atom capabilities. This is an ongoing design > issue which other capabilities have had to face (and has had > considerable discussion) but as yet there is no clear solution. > Thanks for the explanation. > I need to reiterate that sieve already has this > functionality, and quite a bit more. You should be looking > into sieve rather than trying to shoehorn an orthogonal (and > much less functional) capability into IMAP. Hmm.. That was an effort to embedd the logic in IMAP. I will analyze further on this. > > In most environments, filters are done in the MTA and/or MDA, > especially when a filter is a defined set of rules which are > executed for all incoming mail. Filters are generally not > done in the MUA (such as an IMAP > server) because of the problem of executing a filter > repetitively on the same data; when it is done the MUA often > has to undertake heroic (and sometimes unsuccessful) efforts > to avoid this problem. > > In most environments, IMAP servers are completely separate > from the MTA and MDA. There would be a substantial > implementation burden to create an intercommunication of > filtering information between the IMAP server and a separate > MTA/MDA (perhaps from a different vendor). > > It is not likely that you will have much success convincing > either IMAP or MTA/MDA server implementors to implement your > extension, especially since sieve already addresses these > needs and quite a bit more. > > In general, IETF protocols avoid having multiple solutions > for the same problem. When multiple solutions exist, there > is strong pressure to have one solution win and the others I understand them clearly. My belif is that my solution would have some performance benefits compared having them externally. I will try to find some loop holes in sieve for arugments :-) > pass into oblivion. For many years, there was such pressure > between IMAP and POP since these two protocols seemingly did > the same thing. And, to be honest, it is likely that IMAP > would not have happened had I known about POP. I like this point very much :-) > > I strongly urge you to look into sieve, and become involved > in that development effort. You will find many helpful > people working on sieve, and you'll achieve your goals much > faster. Otherwise, you are likely to end up having wasted > your time (and other people's time) with no results to show for it. Thanks for your recommendations. Could you please get me the wg that analyzes sieve. +MG > -----Original Message----- > From: Mark Crispin [mailto:mrc@CAC.Washington.EDU] > Sent: Friday, October 17, 2003 12:35 AM > To: Madan Ganesh Velayudham > Cc: 'IMAP Extensions WG'; madan-ganesh.v@hp.com > Subject: RE: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt > > > On Fri, 17 Oct 2003, Madan Ganesh Velayudham wrote: > > * CAPABILITY IMAP4rev1 AUTH=DIGEST-MD5ORGANIZE=ADD,UPDATE > > [APPEND,DELETE,STORE],REMOVE,ENABLE,DISABLE,LIST > > > > I understand [APPEND, ... ] is the one which you are > > mentioning. Pls correct me if I'm wrong. I shall correct it > > while refining the draft. > > Capabilities are defined in RFC 3501 as atoms. You can not > have multi-atom capabilities. This is an ongoing design > issue which other capabilities have had to face (and has had > considerable discussion) but as yet there is no clear solution. > > > > As such, this functionality does not seem to be within > the scope of > > > IMAP; and instead belongs with Sieve. > > + Client need nt do extra operations. > > > > + I'm trying to leverage already available IMAP commands > > ( APPEND, STORE, Search Criterias, etc., ) to implement > > this organization of message for user. I feel there wont be > > much implementation strain : code reusability. > > > > + Many customers would be interested in single entity which > > will do the required tasks instead of having two independent > > entities. > > I need to reiterate that sieve already has this > functionality, and quite a bit more. You should be looking > into sieve rather than trying to shoehorn an orthogonal (and > much less functional) capability into IMAP. > > In most environments, filters are done in the MTA and/or MDA, > especially when a filter is a defined set of rules which are > executed for all incoming mail. Filters are generally not > done in the MUA (such as an IMAP > server) because of the problem of executing a filter > repetitively on the same data; when it is done the MUA often > has to undertake heroic (and sometimes unsuccessful) efforts > to avoid this problem. > > In most environments, IMAP servers are completely separate > from the MTA and MDA. There would be a substantial > implementation burden to create an intercommunication of > filtering information between the IMAP server and a separate > MTA/MDA (perhaps from a different vendor). > > It is not likely that you will have much success convincing > either IMAP or MTA/MDA server implementors to implement your > extension, especially since sieve already addresses these > needs and quite a bit more. > > In general, IETF protocols avoid having multiple solutions > for the same problem. When multiple solutions exist, there > is strong pressure to have one solution win and the others > pass into oblivion. For many years, there was such pressure > between IMAP and POP since these two protocols seemingly did > the same thing. And, to be honest, it is likely that IMAP > would not have happened had I known about POP. > > I strongly urge you to look into sieve, and become involved > in that development effort. You will find many helpful > people working on sieve, and you'll achieve your goals much > faster. Otherwise, you are likely to end up having wasted > your time (and other people's time) with no results to show for it. > > -- Mark -- > http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GLOvI7010783 for ; Thu, 16 Oct 2003 14:24:57 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GLOu2Z010782 for ietf-imapext-bks; Thu, 16 Oct 2003 14:24:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GLOtI7010769 for ; Thu, 16 Oct 2003 14:24:55 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Received: from [192.168.42.6] (peregrin.orthanc.ca [192.168.42.6]) by orthanc.ca (8.12.9p1/8.12.9) with ESMTP id h9GLOnP5054037; Thu, 16 Oct 2003 15:24:49 -0600 (MDT) (envelope-from lyndon@orthanc.ca) Date: Thu, 16 Oct 2003 15:24:43 -0600 From: Lyndon Nerenberg To: madan-ganesh.v@hp.com cc: ietf-imapext@imc.org Subject: IMAP Organize Extension Message-ID: <2147483647.1066317883@[192.168.42.6]> X-Mailer: Mulberry/3.1.0b8 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========C47C3D6041106DB99DBE==========" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --==========C47C3D6041106DB99DBE========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline The functionality of Organize already exists in SIEVE. Pushing the configuration of MDA filters into multiple unrelated=20 protocols is just bad engineering. Also, this document falsely claims to be a product of the WG, which it is = not. It's not even within the scope of the WG charter. This draft should be withdrawn immediately. We should instead focus on=20 getting ManageSieve onto the standards track. --lyndon --==========C47C3D6041106DB99DBE========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: Mulberry PGP Plugin v3.0 Comment: processed by Mulberry PGP Plugin iQA/AwUBP48MoeLnPQjwN7SAEQIM2gCeJ04vc4ig4m8k2z1nQKvJBiwx6/MAn1gn 6CeOFyF947RFvzm0u2/DbDPq =5qsS -----END PGP SIGNATURE----- --==========C47C3D6041106DB99DBE==========-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GKPAI7006556 for ; Thu, 16 Oct 2003 13:25:12 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GKPAHk006555 for ietf-imapext-bks; Thu, 16 Oct 2003 13:25:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GKP8I7006547 for ; Thu, 16 Oct 2003 13:25:08 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9GKNsk4002841; Thu, 16 Oct 2003 16:23:54 -0400 Date: Thu, 16 Oct 2003 16:23:55 -0400 (EDT) From: Rob Siemborski To: Madan Ganesh Velayudham cc: "'Mark Crispin'" , "'IMAP Extensions WG'" , madan-ganesh.v@hp.com Subject: RE: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt In-Reply-To: <000e01c39418$4731fc50$3ce62a0f@nt23060> Message-ID: References: <000e01c39418$4731fc50$3ce62a0f@nt23060> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 17 Oct 2003, Madan Ganesh Velayudham wrote: > > In fact, it seems to me that sieve is more flexible than this > > extension ever could be, since it is embeddable without > > protocol changes in any mail handling program (IMAP server, > > LMTP/SMTP server, POP client, etc). > > > + Many customers would be interested in single entity which > will do the required tasks instead of having two independent > entities. What users may perceive as a single entity does not need to be a single protocol on the wire. In fact, a single server product can support multiple protocols and provide this functionality and the administrators can still see it as a single product. For example, Cyrus implements mail filtering with Sieve scripts that can be manage remotely without touching the IMAP protocol at all. Users can have a mail client that supports both IMAP and MANAGESIEVE and have it maintain their filters *and* read their mail. The client can even support Sieve itself and provide a GUI to manipulate the filters. This doesn't require an extension to IMAP, and Sieve is already more flexible than the much more limited set of IMAP operations (In addition to simple file/reject/discard type actions, there are currently extensions for vacation messages, spam/virus scoring, regular expressions, relational comparisons and so on). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GJd4I7002226 for ; Thu, 16 Oct 2003 12:39:04 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GJd4fc002224 for ietf-imapext-bks; Thu, 16 Oct 2003 12:39:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GJd2I7002210 for ; Thu, 16 Oct 2003 12:39:03 -0700 (PDT) (envelope-from tony@att.com) Received: from maillennium.att.com ([135.25.114.99]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h9GJcxOa014201 for ; Thu, 16 Oct 2003 14:38:59 -0500 Received: from att.com (unknown[135.210.73.148](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20031016193615gw100lr88ne> (Authid: tony); Thu, 16 Oct 2003 19:36:16 +0000 Message-ID: <3F8EF3CF.7030101@att.com> Date: Thu, 16 Oct 2003 15:38:55 -0400 From: Tony Hansen User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: IMAP Extensions WG Subject: Re: SASL Initial Response? References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> <3F8305BF.2050706@oceana.com> <2147483647.1066304385@socrates.cyrusoft.com> <3F8EDE30.8070501@isode.com> In-Reply-To: <3F8EDE30.8070501@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > As I am the guilty party I should probably comment on this. It is quite > common for base64 encoding/decoding to be implemented by utility > functions that you steal from your friend or just implemented in a > library written by somebody-who-no-longer-works-for-the-company ten > years ago. These functions may have assumptions quite different from > those of IMAP AUTHENTICATE, because they could have been written for a > different environment. For example they were originally used to handle > MIME base64, which allows for spaces and CRLFs. Ditto. I was using a base64 library and it worked great, until I had a string that caused the base64 output to be >76 characters and it inserted a crlf. Sigh. Tony Hansen tony@att.com Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GJ5iI7000981 for ; Thu, 16 Oct 2003 12:05:44 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GJ5i4P000980 for ietf-imapext-bks; Thu, 16 Oct 2003 12:05:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GJ5hI7000975 for ; Thu, 16 Oct 2003 12:05:43 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout2.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9GJ4phu021171; Thu, 16 Oct 2003 12:04:52 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9GJ4p1T003590; Thu, 16 Oct 2003 12:04:51 -0700 Date: Thu, 16 Oct 2003 12:04:51 -0700 (PDT) From: Mark Crispin To: Madan Ganesh Velayudham cc: "'IMAP Extensions WG'" , madan-ganesh.v@hp.com Subject: RE: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt In-Reply-To: <000201c39414$7b9c8d60$3ce62a0f@nt23060> Message-ID: References: <000201c39414$7b9c8d60$3ce62a0f@nt23060> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 17 Oct 2003, Madan Ganesh Velayudham wrote: > * CAPABILITY IMAP4rev1 AUTH=DIGEST-MD5ORGANIZE=ADD,UPDATE > [APPEND,DELETE,STORE],REMOVE,ENABLE,DISABLE,LIST > > I understand [APPEND, ... ] is the one which you are > mentioning. Pls correct me if I'm wrong. I shall correct it > while refining the draft. Capabilities are defined in RFC 3501 as atoms. You can not have multi-atom capabilities. This is an ongoing design issue which other capabilities have had to face (and has had considerable discussion) but as yet there is no clear solution. > > As such, this functionality does not seem to be within the > > scope of IMAP; and instead belongs with Sieve. > + Client need nt do extra operations. > > + I'm trying to leverage already available IMAP commands > ( APPEND, STORE, Search Criterias, etc., ) to implement > this organization of message for user. I feel there wont be > much implementation strain : code reusability. > > + Many customers would be interested in single entity which > will do the required tasks instead of having two independent > entities. I need to reiterate that sieve already has this functionality, and quite a bit more. You should be looking into sieve rather than trying to shoehorn an orthogonal (and much less functional) capability into IMAP. In most environments, filters are done in the MTA and/or MDA, especially when a filter is a defined set of rules which are executed for all incoming mail. Filters are generally not done in the MUA (such as an IMAP server) because of the problem of executing a filter repetitively on the same data; when it is done the MUA often has to undertake heroic (and sometimes unsuccessful) efforts to avoid this problem. In most environments, IMAP servers are completely separate from the MTA and MDA. There would be a substantial implementation burden to create an intercommunication of filtering information between the IMAP server and a separate MTA/MDA (perhaps from a different vendor). It is not likely that you will have much success convincing either IMAP or MTA/MDA server implementors to implement your extension, especially since sieve already addresses these needs and quite a bit more. In general, IETF protocols avoid having multiple solutions for the same problem. When multiple solutions exist, there is strong pressure to have one solution win and the others pass into oblivion. For many years, there was such pressure between IMAP and POP since these two protocols seemingly did the same thing. And, to be honest, it is likely that IMAP would not have happened had I known about POP. I strongly urge you to look into sieve, and become involved in that development effort. You will find many helpful people working on sieve, and you'll achieve your goals much faster. Otherwise, you are likely to end up having wasted your time (and other people's time) with no results to show for it. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GJ4DI7000925 for ; Thu, 16 Oct 2003 12:04:13 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GJ4DEZ000924 for ietf-imapext-bks; Thu, 16 Oct 2003 12:04:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GJ4BI7000919 for ; Thu, 16 Oct 2003 12:04:11 -0700 (PDT) (envelope-from mganesh@india.hp.com) Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel13.hp.com (Postfix) with ESMTP id DC8971C00C36; Thu, 16 Oct 2003 12:04:10 -0700 (PDT) Received: from nt23060 (nt23060.india.hp.com [15.42.230.60]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id AAA09665; Fri, 17 Oct 2003 00:32:59 +0530 (IST) From: "Madan Ganesh Velayudham" To: "'Rob Siemborski'" , "'Mark Crispin'" Cc: "'IMAP Extensions WG'" , Subject: RE: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt Date: Fri, 17 Oct 2003 00:34:07 +0530 Organization: Hewlett-Packard STSD Message-ID: <000e01c39418$4731fc50$3ce62a0f@nt23060> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Rob, Thanks for your comments. > -----Original Message----- > From: owner-ietf-imapext@mail.imc.org > [mailto:owner-ietf-imapext@mail.imc.org] On Behalf Of Rob Siemborski > Sent: Thursday, October 16, 2003 2:21 AM > To: Mark Crispin > Cc: IMAP Extensions WG; madan-ganesh.v@hp.com > Subject: Re: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt > > > > On Wed, 15 Oct 2003, Mark Crispin wrote: > > > As such, this functionality does not seem to be within the scope of > > IMAP; and instead belongs with Sieve. Not withstanding the > attractive > > nuisance of rendering IMAP into Exchange ("shove everything > remotely > > related to email into one protocol"), I don't see how ORGANIZE > > provides any added value over Sieve. > > I agree with Mark's comments. I don't see any win here over > sieve, except that the client can avoid making the additional > MANAGESIEVE connection to update its filtering rules, which > is not compelling enough to try to reimplement all of Sieve's > functionality inside of the IMAP protocol. As I mentioned in Mark's reply, I'm trying to leverage existing IMAP commands feature to orgainze user mails. > > (Which reminds me -- MANAGESIEVE has yet to be published as > an RFC, I should probably bother Tim again). I've just went through the abstract of it and understand that managing sieve script remotely. > > In fact, it seems to me that sieve is more flexible than this > extension ever could be, since it is embeddable without > protocol changes in any mail handling program (IMAP server, > LMTP/SMTP server, POP client, etc). > + Many customers would be interested in single entity which will do the required tasks instead of having two independent entities. Please let me know your comments. Thanks again, MG > -Rob > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Rob Siemborski | Andrew Systems Group * Research Systems > Programmer PGP:0x5CE32FCC | Cyert Hall 207 * > rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- > Version: 3.12 > GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ > N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ > DI+++ G e h r- y? ------END GEEK CODE BLOCK----- > > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GIb3I7099488 for ; Thu, 16 Oct 2003 11:37:03 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GIb3Bk099487 for ietf-imapext-bks; Thu, 16 Oct 2003 11:37:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GIb2I7099478 for ; Thu, 16 Oct 2003 11:37:02 -0700 (PDT) (envelope-from mganesh@india.hp.com) Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by atlrel6.hp.com (Postfix) with ESMTP id 512BF1C02475; Thu, 16 Oct 2003 14:37:01 -0400 (EDT) Received: from nt23060 (nt23060.india.hp.com [15.42.230.60]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id AAA08091; Fri, 17 Oct 2003 00:05:45 +0530 (IST) From: "Madan Ganesh Velayudham" To: "'Mark Crispin'" , "'IMAP Extensions WG'" Cc: Subject: RE: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt Date: Fri, 17 Oct 2003 00:06:53 +0530 Organization: Hewlett-Packard STSD Message-ID: <000201c39414$7b9c8d60$3ce62a0f@nt23060> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Mark, Thanks for your comments. > -----Original Message----- > From: owner-ietf-imapext@mail.imc.org > [mailto:owner-ietf-imapext@mail.imc.org] On Behalf Of Mark Crispin > Sent: Thursday, October 16, 2003 1:41 AM > To: IMAP Extensions WG > Cc: madan-ganesh.v@hp.com > Subject: Re: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt > > > > Leaving aside the bugs in this specification (for example, > the added capabilities violate RFC 3501, security > considerations are glossed over), it seems that the purpose > of this proposed extension is not to "organize", but rather > to define MDA filtering rules. * CAPABILITY IMAP4rev1 AUTH=DIGEST-MD5ORGANIZE=ADD,UPDATE [APPEND,DELETE,STORE],REMOVE,ENABLE,DISABLE,LIST I understand [APPEND, ... ] is the one which you are mentioning. Pls correct me if I'm wrong. I shall correct it while refining the draft. Since the ORGANIZE command is in autenticated state, only users with proper credentials can have access to PUOT. I will definitely elaborate 3.2 Section ... [ When the IMAP server receives... It performs the specified action.. ] to include more implementation issues. How IMAP could behave for append, delete, store operations. In future, I would like expand these operations to include forwarding messages, automatic response for messages, etc. I could understand that the much emphasis is on define organizing (filtering) rules. I understand I should elaborate it. > > As such, this functionality does not seem to be within the > scope of IMAP; and instead belongs with Sieve. Not > withstanding the attractive nuisance of rendering IMAP into > Exchange ("shove everything remotely related to email into > one protocol"), I don't see how ORGANIZE provides any added > value over Sieve. + Client need nt do extra operations. + I'm trying to leverage already available IMAP commands ( APPEND, STORE, Search Criterias, etc., ) to implement this organization of message for user. I feel there wont be much implementation strain : code reusability. + Many customers would be interested in single entity which will do the required tasks instead of having two independent entities. > > The proposed SMTP extension for ORGANIZE is bizarre. The > purpose seems to be to shoehorn manipulation of MDA filtering > rules into yet another orthogonal protocol (plus note the > syntax errors in the example). The SMTP extensions people > can shoot that down. > I understand it and will definitely correct any errors. Actually, the idea that I came to me, just thought capture them in the draft merely I don't want to extent this part. This is just an idea. Thanks again, MG > -- Mark -- > http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GI6sI7098610 for ; Thu, 16 Oct 2003 11:06:54 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GI6slB098608 for ietf-imapext-bks; Thu, 16 Oct 2003 11:06:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GI6mI7098601 for ; Thu, 16 Oct 2003 11:06:53 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Thu, 16 Oct 2003 19:06:53 +0100 Message-ID: <3F8EDE30.8070501@isode.com> Date: Thu, 16 Oct 2003 19:06:40 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Crispin CC: Rob Siemborski , Cyrus Daboo , Ken Murchison , IMAP Extensions WG Subject: Re: SASL Initial Response? References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> <3F8305BF.2050706@oceana.com> <2147483647.1066304385@socrates.cyrusoft.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: >Another damning point. Just recently, it was claimed that RFC 3501 does >not enforce BASE64 syntax in the AUTHENTICATE command. The Formal Syntax >says otherwise; but that was countered with "nobody reads the formal >syntax." Or, as in the case with Courier server, the formal syntax is >openly defied if it does not match how the implementor chooses to >interpret the main text. > As I am the guilty party I should probably comment on this. It is quite common for base64 encoding/decoding to be implemented by utility functions that you steal from your friend or just implemented in a library written by somebody-who-no-longer-works-for-the-company ten years ago. These functions may have assumptions quite different from those of IMAP AUTHENTICATE, because they could have been written for a different environment. For example they were originally used to handle MIME base64, which allows for spaces and CRLFs. (And I am actually talking from my own experience and I've ended up discovering certain side effects of a base64 decoder I has borrowed). So, explicitly emphasizing some problems with existing base64 decoders will not hurt. >Perhaps if we lived in a world in which it was a criminal offense to >distribute non-compliant protocol implementations, we might see greater >attention to specifications. I don't see that happening; if anything I >see an increasingly lackadasical approach to specifications. > >Thus, we need more pedagogical texts, separate from the specifications, if >we hope to retain any interoperability at all. > Exactly. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GHbtI7097380 for ; Thu, 16 Oct 2003 10:37:55 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GHbtQr097379 for ietf-imapext-bks; Thu, 16 Oct 2003 10:37:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GHbsI7097372 for ; Thu, 16 Oct 2003 10:37:54 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout2.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9GHbhhu004895; Thu, 16 Oct 2003 10:37:48 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9GHbhjJ027922; Thu, 16 Oct 2003 10:37:43 -0700 Date: Thu, 16 Oct 2003 10:37:43 -0700 (PDT) From: Mark Crispin To: Rob Siemborski cc: Cyrus Daboo , Ken Murchison , IMAP Extensions WG Subject: Re: SASL Initial Response? In-Reply-To: Message-ID: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> <3F8305BF.2050706@oceana.com> <2147483647.1066304385@socrates.cyrusoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 16 Oct 2003, Rob Siemborski wrote: > Do you mean: > a) a document that includes SASL profiles for all of these protocols > b) a document that points out common errors in SASL implementations > c) a document akin to STD 1 that just points at the documents > that define various SASL profiles. What I would think would be a "SASL for Dummies"; that is, a document which gives a "how to" overview of SASL along with real-life examples. We live in a world full of implementors who do not read specifications. This isn't just with hacker-wannabees in the open source community; vendors are hiring such individuals. There's also a matter of blunder; simply not understanding how seemingly unrelated statements interact (or, for that matter, the significance of a seemingly unimportant statement). As I pointed out before, many POP and SMTP server SASL implementations fail to handle properly the case when the client does not provide an initial response for the PLAIN mechanism. Rob's new set of I-Ds should help a lot. But it should also tell us that we can not depend upon specifications, especially syntax of the specification, to get people to do the right thing. Another damning point. Just recently, it was claimed that RFC 3501 does not enforce BASE64 syntax in the AUTHENTICATE command. The Formal Syntax says otherwise; but that was countered with "nobody reads the formal syntax." Or, as in the case with Courier server, the formal syntax is openly defied if it does not match how the implementor chooses to interpret the main text. Perhaps if we lived in a world in which it was a criminal offense to distribute non-compliant protocol implementations, we might see greater attention to specifications. I don't see that happening; if anything I see an increasingly lackadasical approach to specifications. Thus, we need more pedagogical texts, separate from the specifications, if we hope to retain any interoperability at all. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GHZWI7097330 for ; Thu, 16 Oct 2003 10:35:32 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GHZWwP097329 for ietf-imapext-bks; Thu, 16 Oct 2003 10:35:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GHZUI7097322 for ; Thu, 16 Oct 2003 10:35:31 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [63.163.82.24]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id h9GHTjEG027245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Oct 2003 13:29:47 -0400 Date: Thu, 16 Oct 2003 13:36:17 -0400 From: Cyrus Daboo To: Rob Siemborski , Alexey Melnikov cc: Mark Crispin , Ken Murchison , IMAP Extensions WG Subject: Re: SASL Initial Response? Message-ID: <2147483647.1066311377@socrates.cyrusoft.com> In-Reply-To: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> <3F8305BF.2050706@oceana.com> <2147483647.1066304385@socrates.cyrusoft.com> <3F8ED428.30502@isode.com> X-Mailer: Mulberry/3.1.0b8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Rob, --On Thursday, October 16, 2003 13:30 -0400 Rob Siemborski wrote: | (c) seems likely to fall out of date. It would have to be updated on a regular basis to account for new protocols and mechanisms, but the document will point to the definitive place to get the most up to date information (e.g. IANA for mechanisms). -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GHWLI7097254 for ; Thu, 16 Oct 2003 10:32:21 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GHWL7Y097253 for ietf-imapext-bks; Thu, 16 Oct 2003 10:32:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GHWKI7097246 for ; Thu, 16 Oct 2003 10:32:20 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [63.163.82.24]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id h9GHQXEG027182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Oct 2003 13:26:35 -0400 Date: Thu, 16 Oct 2003 13:33:06 -0400 From: Cyrus Daboo To: Rob Siemborski cc: Mark Crispin , Ken Murchison , IMAP Extensions WG Subject: Re: SASL Initial Response? Message-ID: <2147483647.1066311186@socrates.cyrusoft.com> In-Reply-To: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> <3F8305BF.2050706@oceana.com> <2147483647.1066304385@socrates.cyrusoft.com> X-Mailer: Mulberry/3.1.0b8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Rob, --On Thursday, October 16, 2003 12:55 -0400 Rob Siemborski wrote: | I'm somewhat confused by what you're proposing here Cyrus... | | Do you mean: | | a) a document that includes SASL profiles for all of these protocols A summary of the profiles and mechanisms - not a full detailed description of each. This could be as simple as a table listing which options a particular protocol's profile provides. e.g.: Protocol Initial Response Base64 Encoding Relevant RFCs Supported IMAP No Yes 3501 ACAP Yes Yes 2244 SMTP Yes Yes 2821, 2554 etc Mechanism Initial Response Supports Security RFCs Allowed Layer CRAM-MD5 No No 2195 DIGEST-MD5 Sometimes (see rfc) Yes 2831 GSSAPI Yes Yes 2222 etc | b) a document that points out common errors in SASL implementations Yes.. | c) a document akin to STD 1 that just points at the documents | that define various SASL profiles. The table should list the references. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GHUjI7097208 for ; Thu, 16 Oct 2003 10:30:45 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GHUjtb097207 for ietf-imapext-bks; Thu, 16 Oct 2003 10:30:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GHUhI7097201 for ; Thu, 16 Oct 2003 10:30:44 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9GHUek4002582; Thu, 16 Oct 2003 13:30:40 -0400 Date: Thu, 16 Oct 2003 13:30:40 -0400 (EDT) From: Rob Siemborski To: Alexey Melnikov cc: Cyrus Daboo , Mark Crispin , Ken Murchison , IMAP Extensions WG Subject: Re: SASL Initial Response? In-Reply-To: <3F8ED428.30502@isode.com> Message-ID: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> <3F8305BF.2050706@oceana.com> <2147483647.1066304385@socrates.cyrusoft.com> <3F8ED428.30502@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 16 Oct 2003, Alexey Melnikov wrote: > >I'm somewhat confused by what you're proposing here Cyrus... > > > >Do you mean: > > > >a) a document that includes SASL profiles for all of these protocols > >b) a document that points out common errors in SASL implementations > >c) a document akin to STD 1 that just points at the documents > >that define various SASL profiles. > > > I think Cyrus was talking about b) with some pieces of c). > > After writing HTTP SASL spec and reviewing XMPP/BEEP/SMTP/etc. I am > willing to invest effort in this. Ok. (b) seems worthwhile but I wonder if there is enough there to justify a document separate from RFC2222bis. (c) seems likely to fall out of date. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GHO7I7097028 for ; Thu, 16 Oct 2003 10:24:07 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GHO7bN097027 for ietf-imapext-bks; Thu, 16 Oct 2003 10:24:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GHO6I7097021 for ; Thu, 16 Oct 2003 10:24:06 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Thu, 16 Oct 2003 18:24:05 +0100 Message-ID: <3F8ED428.30502@isode.com> Date: Thu, 16 Oct 2003 18:23:52 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rob Siemborski CC: Cyrus Daboo , Mark Crispin , Ken Murchison , IMAP Extensions WG Subject: Re: SASL Initial Response? References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> <3F8305BF.2050706@oceana.com> <2147483647.1066304385@socrates.cyrusoft.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski wrote: >On Thu, 16 Oct 2003, Cyrus Daboo wrote: > > >>I think what would be handy is to have a single informational RFC, that >>could be continually updated, that summarizes all the SASL profiles for >>standard protocols that use it. i.e. the document would describe how IMAP, >>ACAP, SMTP, POP3, LDAP, BEEP etc all use SASL paying particular attention >>to implementation differences (the initial response has been shown to be >>one problem). This document could list the relevant RFCs to read to get the >>specifics for implementing each profile. i.e. it would be the something >>akin t the IMAP implementer's guide but for SASL. >> >> > >I'm somewhat confused by what you're proposing here Cyrus... > >Do you mean: > >a) a document that includes SASL profiles for all of these protocols >b) a document that points out common errors in SASL implementations >c) a document akin to STD 1 that just points at the documents >that define various SASL profiles. > I think Cyrus was talking about b) with some pieces of c). After writing HTTP SASL spec and reviewing XMPP/BEEP/SMTP/etc. I am willing to invest effort in this. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GGtjI7095655 for ; Thu, 16 Oct 2003 09:55:45 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GGtjs8095654 for ietf-imapext-bks; Thu, 16 Oct 2003 09:55:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GGthI7095646 for ; Thu, 16 Oct 2003 09:55:43 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SMTP5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9GGtek4002521; Thu, 16 Oct 2003 12:55:40 -0400 Date: Thu, 16 Oct 2003 12:55:40 -0400 (EDT) From: Rob Siemborski To: Cyrus Daboo cc: Mark Crispin , Ken Murchison , IMAP Extensions WG Subject: Re: SASL Initial Response? In-Reply-To: <2147483647.1066304385@socrates.cyrusoft.com> Message-ID: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> <3F8305BF.2050706@oceana.com> <2147483647.1066304385@socrates.cyrusoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 16 Oct 2003, Cyrus Daboo wrote: > I think what would be handy is to have a single informational RFC, that > could be continually updated, that summarizes all the SASL profiles for > standard protocols that use it. i.e. the document would describe how IMAP, > ACAP, SMTP, POP3, LDAP, BEEP etc all use SASL paying particular attention > to implementation differences (the initial response has been shown to be > one problem). This document could list the relevant RFCs to read to get the > specifics for implementing each profile. i.e. it would be the something > akin t the IMAP implementer's guide but for SASL. I'm somewhat confused by what you're proposing here Cyrus... Do you mean: a) a document that includes SASL profiles for all of these protocols b) a document that points out common errors in SASL implementations c) a document akin to STD 1 that just points at the documents that define various SASL profiles. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GFhGI7093504 for ; Thu, 16 Oct 2003 08:43:16 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GFhGfD093503 for ietf-imapext-bks; Thu, 16 Oct 2003 08:43:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GFhFI7093498 for ; Thu, 16 Oct 2003 08:43:15 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout5.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9GFhCMk005131; Thu, 16 Oct 2003 08:43:13 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9GFhCdq016889; Thu, 16 Oct 2003 08:43:12 -0700 Date: Thu, 16 Oct 2003 08:43:12 -0700 (PDT) From: Mark Crispin To: Cyrus Daboo cc: Ken Murchison , IMAP Extensions WG Subject: Re: SASL Initial Response? In-Reply-To: <2147483647.1066304385@socrates.cyrusoft.com> Message-ID: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> <3F8305BF.2050706@oceana.com> <2147483647.1066304385@socrates.cyrusoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 16 Oct 2003, Cyrus Daboo wrote: > I think what would be handy is to have a single informational RFC, that > could be continually updated, that summarizes all the SASL profiles for > standard protocols that use it. i.e. the document would describe how IMAP, > ACAP, SMTP, POP3, LDAP, BEEP etc all use SASL paying particular attention > to implementation differences (the initial response has been shown to be > one problem). This document could list the relevant RFCs to read to get the > specifics for implementing each profile. i.e. it would be the something > akin t the IMAP implementer's guide but for SASL. This is an excellent idea. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GFcvI7093336 for ; Thu, 16 Oct 2003 08:38:57 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GFcvcY093335 for ietf-imapext-bks; Thu, 16 Oct 2003 08:38:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GFcuI7093327 for ; Thu, 16 Oct 2003 08:38:56 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [63.163.82.24]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id h9GFXCEG025485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Oct 2003 11:33:13 -0400 Date: Thu, 16 Oct 2003 11:39:45 -0400 From: Cyrus Daboo To: Mark Crispin , Ken Murchison cc: IMAP Extensions WG Subject: Re: SASL Initial Response? Message-ID: <2147483647.1066304385@socrates.cyrusoft.com> In-Reply-To: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> <3F8305BF.2050706@oceana.com> X-Mailer: Mulberry/3.1.0b8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Mark, {Coming into this debate late since I've been on vacation...] --On Tuesday, October 7, 2003 18:33 -0700 Mark Crispin wrote: |> At the very least, shouldn't the IMAP initial response doc and revised |> SMTP AUTH and POP3 AUTH docs be able to proceed in parallel, especially |> if they all use similar language for the initial client response issue? | | The question is if the SMTP and POP3 documents are going to advance or | not. This also depends upon the SASL document. I'd like to hear IESG | feedback on this. Clearly implementing SASL across multiple protocols is problematic because you have to read multiple documents to fully understand what optional features are supported etc. I think what would be handy is to have a single informational RFC, that could be continually updated, that summarizes all the SASL profiles for standard protocols that use it. i.e. the document would describe how IMAP, ACAP, SMTP, POP3, LDAP, BEEP etc all use SASL paying particular attention to implementation differences (the initial response has been shown to be one problem). This document could list the relevant RFCs to read to get the specifics for implementing each profile. i.e. it would be the something akin t the IMAP implementer's guide but for SASL. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FKoiI7091360 for ; Wed, 15 Oct 2003 13:50:44 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9FKoir1091359 for ietf-imapext-bks; Wed, 15 Oct 2003 13:50:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FKogI7091353 for ; Wed, 15 Oct 2003 13:50:42 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9FKoak4000934; Wed, 15 Oct 2003 16:50:36 -0400 Date: Wed, 15 Oct 2003 16:50:35 -0400 (EDT) From: Rob Siemborski To: Mark Crispin cc: IMAP Extensions WG , madan-ganesh.v@hp.com Subject: Re: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt In-Reply-To: Message-ID: References: <200310151932.PAA18348@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 15 Oct 2003, Mark Crispin wrote: > As such, this functionality does not seem to be within the scope of IMAP; > and instead belongs with Sieve. Not withstanding the attractive nuisance > of rendering IMAP into Exchange ("shove everything remotely related to > email into one protocol"), I don't see how ORGANIZE provides any added > value over Sieve. I agree with Mark's comments. I don't see any win here over sieve, except that the client can avoid making the additional MANAGESIEVE connection to update its filtering rules, which is not compelling enough to try to reimplement all of Sieve's functionality inside of the IMAP protocol. (Which reminds me -- MANAGESIEVE has yet to be published as an RFC, I should probably bother Tim again). In fact, it seems to me that sieve is more flexible than this extension ever could be, since it is embeddable without protocol changes in any mail handling program (IMAP server, LMTP/SMTP server, POP client, etc). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FKCGI7090436 for ; Wed, 15 Oct 2003 13:12:16 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9FKCGYv090435 for ietf-imapext-bks; Wed, 15 Oct 2003 13:12:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout6.cac.washington.edu (mxout6.cac.washington.edu [140.142.33.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FKCFI7090430 for ; Wed, 15 Oct 2003 13:12:15 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout6.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9FKBL0Y014853; Wed, 15 Oct 2003 13:11:21 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9FKBLT0003668; Wed, 15 Oct 2003 13:11:21 -0700 Date: Wed, 15 Oct 2003 13:11:21 -0700 (PDT) From: Mark Crispin To: IMAP Extensions WG cc: madan-ganesh.v@hp.com Subject: Re: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt In-Reply-To: <200310151932.PAA18348@ietf.org> Message-ID: References: <200310151932.PAA18348@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Leaving aside the bugs in this specification (for example, the added capabilities violate RFC 3501, security considerations are glossed over), it seems that the purpose of this proposed extension is not to "organize", but rather to define MDA filtering rules. As such, this functionality does not seem to be within the scope of IMAP; and instead belongs with Sieve. Not withstanding the attractive nuisance of rendering IMAP into Exchange ("shove everything remotely related to email into one protocol"), I don't see how ORGANIZE provides any added value over Sieve. The proposed SMTP extension for ORGANIZE is bizarre. The purpose seems to be to shoehorn manipulation of MDA filtering rules into yet another orthogonal protocol (plus note the syntax errors in the example). The SMTP extensions people can shoot that down. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9F8fJI7057123 for ; Wed, 15 Oct 2003 01:41:19 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9F8fJ4D057121 for ietf-imapext-bks; Wed, 15 Oct 2003 01:41:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from melkebalanse.gulbrandsen.priv.no (melkebalanse.gulbrandsen.priv.no [217.19.171.131]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9F8f7I7057024 for ; Wed, 15 Oct 2003 01:41:14 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Message-Id: From: Arnt Gulbrandsen To: Mark Crispin Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt Cc: Alexey Melnikov , Rob Siemborski , IMAP extensions Mailing List References: <200310131515.LAA10872@ietf.org> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Wed, 15 Oct 2003 10:43:55 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: > On Tue, 14 Oct 2003, Rob Siemborski wrote: >> I have replaced that paragraph with: >> >> When decoding the [BASE64] data in the initial client response, >> decoding errors MUST be treated as [IMAP4] would handle them in any >> normal SASL client response. In particular, the server should check >> for any characters not explicitly allowed by the BASE64 alphabet, >> as well as any sequence of BASE64 characters that contains the pad >> character ('=') anywhere other than the end of the string (e.g. >> "=AAA" and "AAA=BBB" are not allowed). > > Excellent. Thanks! I like it. --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EIX4I7059360 for ; Tue, 14 Oct 2003 11:33:04 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EIX4xZ059359 for ietf-imapext-bks; Tue, 14 Oct 2003 11:33:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout6.cac.washington.edu (mxout6.cac.washington.edu [140.142.33.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EIWxI7059354 for ; Tue, 14 Oct 2003 11:32:59 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout6.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9EIWo0Y028747; Tue, 14 Oct 2003 11:32:50 -0700 Received: from Shimo-Tomobiki.Panda.COM (D-140-142-21-77.dhcp4.washington.edu [140.142.21.77]) (authenticated bits=0) by smtp.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9EIWmx0004715 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 14 Oct 2003 11:32:50 -0700 Date: Tue, 14 Oct 2003 11:32:54 -0700 (Pacific Daylight Time) From: Mark Crispin To: Rob Siemborski cc: Arnt Gulbrandsen , IMAP extensions Mailing List , alexey.melnikov@isode.com Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt In-Reply-To: Message-ID: References: <200310131515.LAA10872@ietf.org> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 14 Oct 2003, Rob Siemborski wrote: > I have replaced that paragraph with: > > When decoding the [BASE64] data in the initial client response, decoding > errors MUST be treated as [IMAP4] would handle them in any normal SASL > client response. In particular, the server should check for > any characters not explicitly allowed by the BASE64 alphabet, as well as > any sequence of BASE64 characters that contains the pad character ('=') > anywhere other than the end of the string (e.g. "=AAA" and "AAA=BBB" are > not allowed). Excellent. Thanks! -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EIQ3I7059086 for ; Tue, 14 Oct 2003 11:26:03 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EIQ3Od059085 for ietf-imapext-bks; Tue, 14 Oct 2003 11:26:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EIQ2I7059080 for ; Tue, 14 Oct 2003 11:26:02 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9EIPxWn000878; Tue, 14 Oct 2003 14:26:00 -0400 Date: Tue, 14 Oct 2003 14:25:59 -0400 (EDT) From: Rob Siemborski To: Mark Crispin cc: Arnt Gulbrandsen , IMAP extensions Mailing List , alexey.melnikov@isode.com Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt In-Reply-To: Message-ID: References: <200310131515.LAA10872@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 14 Oct 2003, Mark Crispin wrote: > > replacing it with something like "When base64 decoding the initial > > response argument, it MUST be treated as [IMAP4] would treat any > > other SASL client response.") > > It wouldn't hurt to add expository text with something like the original > wording, just for emphasis. I have replaced that paragraph with: When decoding the [BASE64] data in the initial client response, decoding errors MUST be treated as [IMAP4] would handle them in any normal SASL client response. In particular, the server should check for any characters not explicitly allowed by the BASE64 alphabet, as well as any sequence of BASE64 characters that contains the pad character ('=') anywhere other than the end of the string (e.g. "=AAA" and "AAA=BBB" are not allowed). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EIAII7058597 for ; Tue, 14 Oct 2003 11:10:18 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EIAI6l058596 for ietf-imapext-bks; Tue, 14 Oct 2003 11:10:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EIAHI7058587 for ; Tue, 14 Oct 2003 11:10:17 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9EIA6Mk020884; Tue, 14 Oct 2003 11:10:06 -0700 Received: from Shimo-Tomobiki.Panda.COM (D-140-142-21-77.dhcp4.washington.edu [140.142.21.77]) (authenticated bits=0) by smtp.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9EIA2x0002041 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 14 Oct 2003 11:10:06 -0700 Date: Tue, 14 Oct 2003 11:10:08 -0700 (Pacific Daylight Time) From: Mark Crispin To: Rob Siemborski cc: Arnt Gulbrandsen , IMAP extensions Mailing List , alexey.melnikov@isode.com Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt In-Reply-To: Message-ID: References: <200310131515.LAA10872@ietf.org> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 14 Oct 2003, Rob Siemborski wrote: > In that case, I am inclined to drop the paragraph from this draft (perhaps > replacing it with something like "When base64 decoding the initial > response argument, it MUST be treated as [IMAP4] would treat any > other SASL client response.") It wouldn't hurt to add expository text with something like the original wording, just for emphasis. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EHwQI7058214 for ; Tue, 14 Oct 2003 10:58:26 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EHwQ41058213 for ietf-imapext-bks; Tue, 14 Oct 2003 10:58:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EHwKI7058208 for ; Tue, 14 Oct 2003 10:58:21 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9EHwIWn000835; Tue, 14 Oct 2003 13:58:18 -0400 Date: Tue, 14 Oct 2003 13:58:17 -0400 (EDT) From: Rob Siemborski To: Mark Crispin cc: Arnt Gulbrandsen , IMAP extensions Mailing List , alexey.melnikov@isode.com Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt In-Reply-To: Message-ID: References: <200310131515.LAA10872@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 14 Oct 2003, Mark Crispin wrote: > > > This stuff is over and above the restrictions imposed by RFC 3501 > > > section 6.2.2. > > Since Alexey was the one who wanted me to add this, I'll ask him to > > comment here. > > I'm not Alexey, but I'll comment anyway. > > RFC 3501 fully supports the proposed restrictions in the Formal Syntax. > Characters that are not in the BASE64 alphabet and non-terminal = are > specifically prohibited in the formal syntax, violation of which leads to > a BAD. > > Just because something isn't explicitly mentioned in expository text (such > as 6.2.2) does not mean that it isn't there. In that case, I am inclined to drop the paragraph from this draft (perhaps replacing it with something like "When base64 decoding the initial response argument, it MUST be treated as [IMAP4] would treat any other SASL client response.") -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EHCOI7056855 for ; Tue, 14 Oct 2003 10:12:24 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EHCOhn056854 for ietf-imapext-bks; Tue, 14 Oct 2003 10:12:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EHCMI7056848 for ; Tue, 14 Oct 2003 10:12:23 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Tue, 14 Oct 2003 18:12:16 +0100 Message-ID: <3F8C2E6C.9080806@isode.com> Date: Tue, 14 Oct 2003 18:12:12 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Crispin CC: Arnt Gulbrandsen , Rob Siemborski , IMAP extensions Mailing List Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt References: <200310131515.LAA10872@ietf.org> <3F8C2764.3050208@isode.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: >On Tue, 14 Oct 2003, Alexey Melnikov wrote: > > >>>This stuff is over and above the restrictions imposed by RFC 3501 >>>section 6.2.2. >>> >>> >>Yes. The base IMAP spec should be updated as well. >> >> > >As noted in my previous message, this is unnecessary except as an >explanatory note. The Formal Syntax is already clear on this point. > Yes, but nobody reads ABNF anyway ;-). You are right, "this is not a bug", but I suggest you add some text, as this is a known issue that causes problems already. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EH1HI7056277 for ; Tue, 14 Oct 2003 10:01:17 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EH1HdE056276 for ietf-imapext-bks; Tue, 14 Oct 2003 10:01:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EH1CI7056271 for ; Tue, 14 Oct 2003 10:01:16 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout3.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9EH0rC2032706; Tue, 14 Oct 2003 10:00:58 -0700 Received: from Shimo-Tomobiki.Panda.COM (mes128085095.airdata.net [166.128.85.95]) (authenticated bits=0) by smtp.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9EH0gx0027011 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 14 Oct 2003 10:00:49 -0700 Date: Tue, 14 Oct 2003 10:00:43 -0700 (Pacific Daylight Time) From: Mark Crispin To: Alexey Melnikov cc: Arnt Gulbrandsen , Rob Siemborski , IMAP extensions Mailing List Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt In-Reply-To: <3F8C2764.3050208@isode.com> Message-ID: References: <200310131515.LAA10872@ietf.org> <3F8C2764.3050208@isode.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 14 Oct 2003, Alexey Melnikov wrote: > > This stuff is over and above the restrictions imposed by RFC 3501 > > section 6.2.2. > Yes. The base IMAP spec should be updated as well. As noted in my previous message, this is unnecessary except as an explanatory note. The Formal Syntax is already clear on this point. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EH0GI7056240 for ; Tue, 14 Oct 2003 10:00:16 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EH0GUC056239 for ietf-imapext-bks; Tue, 14 Oct 2003 10:00:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EH06I7056228 for ; Tue, 14 Oct 2003 10:00:06 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9EGxhMk007239; Tue, 14 Oct 2003 09:59:43 -0700 Received: from Shimo-Tomobiki.Panda.COM (mes128085095.airdata.net [166.128.85.95]) (authenticated bits=0) by smtp.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9EGxBx0026784 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 14 Oct 2003 09:59:35 -0700 Date: Tue, 14 Oct 2003 09:59:12 -0700 (Pacific Daylight Time) From: Mark Crispin To: Rob Siemborski cc: Arnt Gulbrandsen , IMAP extensions Mailing List , alexey.melnikov@isode.com Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt In-Reply-To: Message-ID: References: <200310131515.LAA10872@ietf.org> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 14 Oct 2003, Rob Siemborski wrote: > > If the server cannot decode the [BASE64] data > > transmitted by the client, the server MUST fail the authentication > > with a tagged BAD response. In particular, the server MUST reject > > (and not ignore) any characters not explicitly allowed by the BASE64 > > alphabet, and should reject any sequence of BASE64 characters that > > contains the pad character ('=') anywhere other than the end of the > > string (e.g. "=AAA" and "AAA=BBB" are not allowed). > > This stuff is over and above the restrictions imposed by RFC 3501 > > section 6.2.2. > Since Alexey was the one who wanted me to add this, I'll ask him to > comment here. I'm not Alexey, but I'll comment anyway. RFC 3501 fully supports the proposed restrictions in the Formal Syntax. Characters that are not in the BASE64 alphabet and non-terminal = are specifically prohibited in the formal syntax, violation of which leads to a BAD. Just because something isn't explicitly mentioned in expository text (such as 6.2.2) does not mean that it isn't there. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EGgLI7055646 for ; Tue, 14 Oct 2003 09:42:21 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EGgLGl055645 for ietf-imapext-bks; Tue, 14 Oct 2003 09:42:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EGgKI7055640 for ; Tue, 14 Oct 2003 09:42:20 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Tue, 14 Oct 2003 17:42:16 +0100 Message-ID: <3F8C2764.3050208@isode.com> Date: Tue, 14 Oct 2003 17:42:12 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Arnt Gulbrandsen CC: Rob Siemborski , IMAP extensions Mailing List Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt References: <200310131515.LAA10872@ietf.org> In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Arnt Gulbrandsen wrote: > If the server cannot decode the [BASE64] data > transmitted by the client, the server MUST fail the authentication > with a tagged BAD response. In particular, the server MUST reject > (and not ignore) any characters not explicitly allowed by the BASE64 > alphabet, and should reject any sequence of BASE64 characters that > contains the pad character ('=') anywhere other than the end of the > string (e.g. "=AAA" and "AAA=BBB" are not allowed). > > This stuff is over and above the restrictions imposed by RFC 3501 > section 6.2.2. Yes. The base IMAP spec should be updated as well. > I don't feel pedantic enough to look up the original base64 RFC and > see if there's equivalent text there. Unfortunately the base64 RFC was published before the issue was raised. There are problems in real world that different implementations treat invalid (as shown in the text above) base64 text in different ways. Some implementations just ignore invalid characters. Others truncate data at the first '='. And other reject the value (the right think). base64 is silent on this and this causes problems. > Either there is, and the text is superfluous, or there isn't, and the > quoted text is a syntax difference of the kind I don't want. Cheers, Alexey __________________________________________ Isode Limited, http://www.isode.com Cell: +44 7753759732 IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html Personal Home Page: http://orthanc.ab.ca/mel __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EGThI7055100 for ; Tue, 14 Oct 2003 09:29:43 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EGTh1E055099 for ietf-imapext-bks; Tue, 14 Oct 2003 09:29:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EGTgI7055088 for ; Tue, 14 Oct 2003 09:29:43 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Message-Id: From: Arnt Gulbrandsen To: Mark Crispin Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt Cc: Rob Siemborski , IMAP extensions Mailing List References: <200310131515.LAA10872@ietf.org> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Tue, 14 Oct 2003 18:32:25 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: > On Tue, 14 Oct 2003, Arnt Gulbrandsen wrote: >> With SMTP, the server can know that the client supports initial responses. > > Say WHAT????? > > Where did you get THAT??? Too tired. I mixed "mandatory for SMTP servers" up with "mandatory in SMTP". Sorry. --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EGSbI7055006 for ; Tue, 14 Oct 2003 09:28:37 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EGSbLp055005 for ietf-imapext-bks; Tue, 14 Oct 2003 09:28:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EGSaI7055000 for ; Tue, 14 Oct 2003 09:28:36 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from LIN1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9EGSV1v024566; Tue, 14 Oct 2003 12:28:31 -0400 Date: Tue, 14 Oct 2003 12:28:31 -0400 (EDT) From: Rob Siemborski To: Arnt Gulbrandsen cc: IMAP extensions Mailing List , alexey.melnikov@isode.com Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt In-Reply-To: Message-ID: References: <200310131515.LAA10872@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 14 Oct 2003, Arnt Gulbrandsen wrote: > Good. They aren't the same as the document stands now. There are 2-3 > extra restrictions, both/all small. > > If the client needs to transmit an > initial response which is a zero-length string, it MUST transmit a > single equals sign ("="). This indicates that the response is > present, but is a zero-length string. > > There's a MUST here, although I'm not sure whether it represents an > additional requirement over and above RFC 3501. > > Let me suggest a rewording. "To send a zero-length initial response, the > client can send a single pad character ("="). When decoded, this will > result in a zero-length string on the server." Or perhaps use "AUTH > EXTERNAL =" as an example. Either way, it's the same meaning, no > additional restrictions. I think this needs to be "the client MUST" for interoperability purposes. But I am willing to rework this and add the EXTERNAL example (which is good). Note that this only refers to the SASL initial response (as it is included with the AUTHENTICATE command), not to any part of the negotiation that proceeds later. Do you perhaps want text to that effect? > If the server cannot decode the [BASE64] data > transmitted by the client, the server MUST fail the authentication > with a tagged BAD response. In particular, the server MUST reject > (and not ignore) any characters not explicitly allowed by the BASE64 > alphabet, and should reject any sequence of BASE64 characters that > contains the pad character ('=') anywhere other than the end of the > string (e.g. "=AAA" and "AAA=BBB" are not allowed). > > This stuff is over and above the restrictions imposed by RFC 3501 > section 6.2.2. I don't feel pedantic enough to look up the original > base64 RFC and see if there's equivalent text there. Either there is, > and the text is superfluous, or there isn't, and the quoted text is a > syntax difference of the kind I don't want. Since Alexey was the one who wanted me to add this, I'll ask him to comment here. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EGP3I7054659 for ; Tue, 14 Oct 2003 09:25:03 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EGP37C054658 for ietf-imapext-bks; Tue, 14 Oct 2003 09:25:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EGOwI7054639 for ; Tue, 14 Oct 2003 09:25:02 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Message-Id: From: Arnt Gulbrandsen To: Rob Siemborski Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt Cc: IMAP extensions Mailing List References: <200310131515.LAA10872@ietf.org> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Tue, 14 Oct 2003 18:27:40 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski writes: > On Tue, 14 Oct 2003, Arnt Gulbrandsen wrote: >> I'm proposing that whether or not the server supports your extension, >> the rules that govern the client's first response should be the >> same. > > I agree. Good. They aren't the same as the document stands now. There are 2-3 extra restrictions, both/all small. If the client needs to transmit an initial response which is a zero-length string, it MUST transmit a single equals sign ("="). This indicates that the response is present, but is a zero-length string. There's a MUST here, although I'm not sure whether it represents an additional requirement over and above RFC 3501. Let me suggest a rewording. "To send a zero-length initial response, the client can send a single pad character ("="). When decoded, this will result in a zero-length string on the server." Or perhaps use "AUTH EXTERNAL =" as an example. Either way, it's the same meaning, no additional restrictions. If the server cannot decode the [BASE64] data transmitted by the client, the server MUST fail the authentication with a tagged BAD response. In particular, the server MUST reject (and not ignore) any characters not explicitly allowed by the BASE64 alphabet, and should reject any sequence of BASE64 characters that contains the pad character ('=') anywhere other than the end of the string (e.g. "=AAA" and "AAA=BBB" are not allowed). This stuff is over and above the restrictions imposed by RFC 3501 section 6.2.2. I don't feel pedantic enough to look up the original base64 RFC and see if there's equivalent text there. Either there is, and the text is superfluous, or there isn't, and the quoted text is a syntax difference of the kind I don't want. Thanks for taking the trouble to write the spec. --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EG83I7054032 for ; Tue, 14 Oct 2003 09:08:03 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EG833O054031 for ietf-imapext-bks; Tue, 14 Oct 2003 09:08:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EG81I7054024 for ; Tue, 14 Oct 2003 09:08:01 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from LIN1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9EG7w1v023174; Tue, 14 Oct 2003 12:07:59 -0400 Date: Tue, 14 Oct 2003 12:07:58 -0400 (EDT) From: Rob Siemborski To: Mark Crispin cc: Arnt Gulbrandsen , IMAP extensions Mailing List Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt In-Reply-To: Message-ID: References: <200310131515.LAA10872@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 14 Oct 2003, Mark Crispin wrote: > On Tue, 14 Oct 2003, Rob Siemborski wrote: > > > Mandatory to implement. With SMTP, the server can know that the client > > > supports initial responses. > > Sure, it knows that it supports it, but that doesn't change the fact that > > the server still must deal with the client leaving off the initial > > response. That's part of the sasl specification. > > Huh??? > > The server must implement initial responses in POP3 and SMTP, but there is > no requirement that the client do so since the client can always omit it. Yes, this is correct. I misspoke. FWIW, I hope that draft-siemborski-rfc2554bis-00.txt clarifies this situation. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EG6qI7053970 for ; Tue, 14 Oct 2003 09:06:52 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EG6qFC053969 for ietf-imapext-bks; Tue, 14 Oct 2003 09:06:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout6.cac.washington.edu (mxout6.cac.washington.edu [140.142.33.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EG6pI7053954 for ; Tue, 14 Oct 2003 09:06:51 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout6.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9EG6W0Y000581; Tue, 14 Oct 2003 09:06:37 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9EG6WeW000517; Tue, 14 Oct 2003 09:06:32 -0700 Date: Tue, 14 Oct 2003 09:06:32 -0700 (PDT) From: Mark Crispin To: Rob Siemborski cc: Arnt Gulbrandsen , IMAP extensions Mailing List Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt In-Reply-To: Message-ID: References: <200310131515.LAA10872@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 14 Oct 2003, Rob Siemborski wrote: > > Mandatory to implement. With SMTP, the server can know that the client > > supports initial responses. > Sure, it knows that it supports it, but that doesn't change the fact that > the server still must deal with the client leaving off the initial > response. That's part of the sasl specification. Huh??? The server must implement initial responses in POP3 and SMTP, but there is no requirement that the client do so since the client can always omit it. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EG5aI7053891 for ; Tue, 14 Oct 2003 09:05:36 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EG5aZo053890 for ietf-imapext-bks; Tue, 14 Oct 2003 09:05:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EG5ZI7053885 for ; Tue, 14 Oct 2003 09:05:35 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout4.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9EG5Fmw015379; Tue, 14 Oct 2003 09:05:20 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9EG5FS7000452; Tue, 14 Oct 2003 09:05:15 -0700 Date: Tue, 14 Oct 2003 09:05:15 -0700 (PDT) From: Mark Crispin To: Arnt Gulbrandsen cc: Rob Siemborski , IMAP extensions Mailing List Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt In-Reply-To: Message-ID: References: <200310131515.LAA10872@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 14 Oct 2003, Arnt Gulbrandsen wrote: > With SMTP, the server can know that the client > supports initial responses. Say WHAT????? Where did you get THAT??? -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EG33I7053785 for ; Tue, 14 Oct 2003 09:03:03 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EG33jJ053784 for ietf-imapext-bks; Tue, 14 Oct 2003 09:03:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EG32I7053779 for ; Tue, 14 Oct 2003 09:03:02 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from LIN1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9EG311v022845; Tue, 14 Oct 2003 12:03:01 -0400 Date: Tue, 14 Oct 2003 12:03:01 -0400 (EDT) From: Rob Siemborski To: Arnt Gulbrandsen cc: IMAP extensions Mailing List Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt In-Reply-To: Message-ID: References: <200310131515.LAA10872@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 14 Oct 2003, Arnt Gulbrandsen wrote: > Rob Siemborski writes: > > So you're proposing a situation where an extension that has an empty > > string as an initial response is penalized a round trip: > > Not at all. > > I'm proposing that whether or not the server supports your extension, > the rules that govern the client's first response should be the same. I agree. > >> SMTP is different - initial responses are m-t-i there. > > > > I'm sorry, What is m-t-i? > > Mandatory to implement. With SMTP, the server can know that the client > supports initial responses. Sure, it knows that it supports it, but that doesn't change the fact that the server still must deal with the client leaving off the initial response. That's part of the sasl specification. > With IMAP that's not the case. With IMAP, > the first response may be an initial response, or it may be a response > to an empty challenge. Either way, the syntax should be the same. Either way, the syntax is the same. The sever doesn't care if the client supports initial response or not. At the application level, it's not even allowed to care! If the client doesn't support an initial response, *or* the client doesn't choose to send an initial response, then the negotiation proceeds the same way: there was no initial response. For example, in the DIGEST-MD5 case, where there *is* a difference (fast reauth or not) in both of the above cases, you proceed without fast reauth. The server doesn't care about the reason. FWIW, EXTERNAL is likely to send an empty initial response. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EFvYI7053522 for ; Tue, 14 Oct 2003 08:57:34 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EFvYYL053521 for ietf-imapext-bks; Tue, 14 Oct 2003 08:57:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EFvXI7053516 for ; Tue, 14 Oct 2003 08:57:33 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Message-Id: From: Arnt Gulbrandsen To: Rob Siemborski Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt Cc: IMAP extensions Mailing List References: <200310131515.LAA10872@ietf.org> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Tue, 14 Oct 2003 18:00:14 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski writes: > So you're proposing a situation where an extension that has an empty > string as an initial response is penalized a round trip: Not at all. I'm proposing that whether or not the server supports your extension, the rules that govern the client's first response should be the same. >> SMTP is different - initial responses are m-t-i there. > > I'm sorry, What is m-t-i? Mandatory to implement. With SMTP, the server can know that the client supports initial responses. With IMAP that's not the case. With IMAP, the first response may be an initial response, or it may be a response to an empty challenge. Either way, the syntax should be the same. --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EFsKI7053349 for ; Tue, 14 Oct 2003 08:54:20 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EFsKBK053348 for ietf-imapext-bks; Tue, 14 Oct 2003 08:54:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EFsJI7053343 for ; Tue, 14 Oct 2003 08:54:19 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from LIN1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9EFsI1v022251; Tue, 14 Oct 2003 11:54:18 -0400 Date: Tue, 14 Oct 2003 11:54:18 -0400 (EDT) From: Rob Siemborski To: Arnt Gulbrandsen cc: IMAP extensions Mailing List Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt In-Reply-To: Message-ID: References: <200310131515.LAA10872@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 14 Oct 2003, Rob Siemborski wrote: > clearly says "there is an initial response here, but it is the empty > string" > > vs > > AUTHENTICATE MUMBLE > > which is required to mean "no initial response" > > Without the "=", you're required to fall back to the old behavior. I suppose you could also do "AUTHENTICATE MUMBLE " to indicate an empty response. Is that what you were proposing instead? -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EFkOI7053076 for ; Tue, 14 Oct 2003 08:46:24 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EFkOAX053075 for ietf-imapext-bks; Tue, 14 Oct 2003 08:46:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EFkMI7053069 for ; Tue, 14 Oct 2003 08:46:22 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from LIN1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9EFkL1v021716; Tue, 14 Oct 2003 11:46:21 -0400 Date: Tue, 14 Oct 2003 11:46:21 -0400 (EDT) From: Rob Siemborski To: Arnt Gulbrandsen cc: IMAP extensions Mailing List Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt In-Reply-To: Message-ID: References: <200310131515.LAA10872@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 14 Oct 2003, Arnt Gulbrandsen wrote: > I can see that empty responses may one day be meaningful. However, I > cannot see what's special about the combination of empty responses and > this extension. > > Suppose AUTH=MUMBLE has some feature whereby an empty response makes > sense. Shouldn't it work basically the same way whether this extension > is present or not? > > C: a AUTHENTICATE MUMBLE > S: + > C: = > ... No, in this case you'd use the normal SASL negotiation, you wouldn't have an =. > or > > C: a AUTHENTICATE MUMBLE = > ... > > IMO, the "=" should be governed by the same syntax in both cases, so the > extension should avoid specifying new rules. Now that I think about it, > I suppose that argument covers my base64 queasiness too - the argument > should use the same rules as the same response would follow in the > absence of the extension. So you're proposing a situation where an extension that has an empty string as an initial response is penalized a round trip: AUTHENTICATE MUMBLE = clearly says "there is an initial response here, but it is the empty string" vs AUTHENTICATE MUMBLE which is required to mean "no initial response" Without the "=", you're required to fall back to the old behavior. > > FWIW, SMTP does this. > > SMTP is different - initial responses are m-t-i there. I'm sorry, What is m-t-i? -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EFftI7052923 for ; Tue, 14 Oct 2003 08:41:55 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EFft1N052922 for ietf-imapext-bks; Tue, 14 Oct 2003 08:41:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EFfsI7052916 for ; Tue, 14 Oct 2003 08:41:55 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Message-Id: From: Arnt Gulbrandsen To: Rob Siemborski Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt Cc: IMAP extensions Mailing List References: <200310131515.LAA10872@ietf.org> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Tue, 14 Oct 2003 17:44:32 +0200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9EFftI7052918 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski writes: > On Tue, 14 Oct 2003, Arnt Gulbrandsen wrote: >> 2. The extension's capability name sounds a little inappropriate. >> This extension isn't "the SASL extension". I suggest SASL-IR >> instead. > > I was originally using SASLINITIAL, but it was suggested that I use > "SASL" instead because IMAP now "fully supports SASL" (well, as much > as it can without a client-side-capability extension, which would be > needed for server-last-sends). "PRACTICALLYSASL"? Please not ;) > Frankly, I don't really care what capability name is used, but I'd > like this to not be a continual point of argument. I'd rather see your initial name than the current, but either way I've had my say about it. > Whaile it is true that no current mechanisms have a situation where > they can send an empty initial response, a mechanism might be > developed where there may be something distinguising about the client > sending an empty initial send and the client omiting the initial send > (think of behavior like DIGEST-MD5 fast reauth). We need to handle > the two cases separately. I can see that empty responses may one day be meaningful. However, I cannot see what's special about the combination of empty responses and this extension. Suppose AUTH=MUMBLE has some feature whereby an empty response makes sense. Shouldn't it work basically the same way whether this extension is present or not? C: a AUTHENTICATE MUMBLE S: + C: = ... or C: a AUTHENTICATE MUMBLE = ... IMO, the "=" should be governed by the same syntax in both cases, so the extension should avoid specifying new rules. Now that I think about it, I suppose that argument covers my base64 queasiness too - the argument should use the same rules as the same response would follow in the absence of the extension. > FWIW, SMTP does this. SMTP is different - initial responses are m-t-i there. --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EFCfI7051731 for ; Tue, 14 Oct 2003 08:12:41 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EFCf7H051730 for ietf-imapext-bks; Tue, 14 Oct 2003 08:12:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EFCZI7051724 for ; Tue, 14 Oct 2003 08:12:36 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9EFCV1v019416; Tue, 14 Oct 2003 11:12:31 -0400 Date: Tue, 14 Oct 2003 11:12:30 -0400 (EDT) From: Rob Siemborski To: Arnt Gulbrandsen cc: IMAP extensions Mailing List Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt In-Reply-To: Message-ID: References: <200310131515.LAA10872@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 14 Oct 2003, Arnt Gulbrandsen wrote: > 1. The server must reject, not ignore, any characters outside the base64 > alphabet. Ditto = before the end. > > Why that? I can see it makes sense, but I'm tired of minor differences. > Won't stock base64 do? This was Alexey's suggestion due to bugs in base64 parsers. > 2. The extension's capability name sounds a little inappropriate. This > extension isn't "the SASL extension". I suggest SASL-IR instead. I was originally using SASLINITIAL, but it was suggested that I use "SASL" instead because IMAP now "fully supports SASL" (well, as much as it can without a client-side-capability extension, which would be needed for server-last-sends). Frankly, I don't really care what capability name is used, but I'd like this to not be a continual point of argument. > 3. The draft makes mandates specific syntax for empty initial responses. > I don't lik that. For one thing, under what circumstances would a > client _need_ to send an empty initial response? That is, as opposed to > sending no initial response at all? For another, why shouldn't the same > rules as for other empty responses apply? (I confess I didn't look > those up.) There is a difference between "" and NULL, as there is a difference between omiting the initial response and encoding an empty string. Whaile it is true that no current mechanisms have a situation where they can send an empty initial response, a mechanism might be developed where there may be something distinguising about the client sending an empty initial send and the client omiting the initial send (think of behavior like DIGEST-MD5 fast reauth). We need to handle the two cases separately. FWIW, SMTP does this. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EC6DI7042532 for ; Tue, 14 Oct 2003 05:06:13 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EC6D48042531 for ietf-imapext-bks; Tue, 14 Oct 2003 05:06:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from melkebalanse.gulbrandsen.priv.no (melkebalanse.gulbrandsen.priv.no [217.19.171.131]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EC68I7042512 for ; Tue, 14 Oct 2003 05:06:12 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Message-Id: From: Arnt Gulbrandsen To: IMAP extensions Mailing List Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt References: <200310131515.LAA10872@ietf.org> In-Reply-To: <200310131515.LAA10872@ietf.org> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Tue, 14 Oct 2003 14:08:54 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Internet-Drafts@ietf.org writes: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : IMAP Extension for SASL Initial Client Response > Author(s) : R. Siemborski > Filename : draft-siemborski-imap-sasl-initial-response-00.txt I'll skip the big issue and comment on some small ones. 1. The server must reject, not ignore, any characters outside the base64 alphabet. Ditto = before the end. Why that? I can see it makes sense, but I'm tired of minor differences. Won't stock base64 do? 2. The extension's capability name sounds a little inappropriate. This extension isn't "the SASL extension". I suggest SASL-IR instead. 3. The draft makes mandates specific syntax for empty initial responses. I don't lik that. For one thing, under what circumstances would a client _need_ to send an empty initial response? That is, as opposed to sending no initial response at all? For another, why shouldn't the same rules as for other empty responses apply? (I confess I didn't look those up.) --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DFFZI7036207 for ; Mon, 13 Oct 2003 08:15:35 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9DFFZqS036206 for ietf-imapext-bks; Mon, 13 Oct 2003 08:15:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DFFYI7036200 for ; Mon, 13 Oct 2003 08:15:34 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10872; Mon, 13 Oct 2003 11:15:25 -0400 (EDT) Message-Id: <200310131515.LAA10872@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt Date: Mon, 13 Oct 2003 11:15:25 -0400 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IMAP Extension for SASL Initial Client Response Author(s) : R. Siemborski Filename : draft-siemborski-imap-sasl-initial-response-00.txt Pages : 7 Date : 2003-10-10 To date, the Internet Message Access Protocol (IMAP) has used a Simple Authentication and Security Layer (SASL) profile which always required at least one complete round trip for an authentication, as it did not support an initial client response argument. This additional round trip at the beginning of the session is undesirable, especially when round trip costs are high. This document defines an extension to IMAP which allows clients and servers to avoid this round trip by allowing an initial client response argument to the IMAP AUTHENTICATE command. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-siemborski-imap-sasl-initial-response-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-siemborski-imap-sasl-initial-response-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-siemborski-imap-sasl-initial-response-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-10143126.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-siemborski-imap-sasl-initial-response-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-siemborski-imap-sasl-initial-response-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-10143126.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h981XrKP055935 for ; Tue, 7 Oct 2003 18:33:53 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h981XriM055934 for ietf-imapext-bks; Tue, 7 Oct 2003 18:33:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout6.cac.washington.edu (mxout6.cac.washington.edu [140.142.33.20]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h981XqKP055926 for ; Tue, 7 Oct 2003 18:33:52 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout6.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h981Xp0Y027924; Tue, 7 Oct 2003 18:33:51 -0700 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h981Xp93021628; Tue, 7 Oct 2003 18:33:51 -0700 Date: Tue, 7 Oct 2003 18:33:51 -0700 (PDT) From: Mark Crispin To: Ken Murchison cc: IMAP Extensions WG Subject: Re: SASL Initial Response? In-Reply-To: <3F8305BF.2050706@oceana.com> Message-ID: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> <3F8305BF.2050706@oceana.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 7 Oct 2003, Ken Murchison wrote: > I don't see why implementations which are clearly broken and in > violation of the specs (regardless of how poorly written those specs may > or may not be), should prevent the IMAP initial client response > extension from proceeding as long as it avoids/corrects the problems > with the SMTP AUTH and POP3 AUTH specs. Ken, I believe that you are are thinking about a specification whereas I am thinking more about human nature. We have to allow for Murphy's Law. The IMAP spec will be much more complicated than the SMTP or POP3 specs, because IMAP is server-optional on initial response. That is four support states, whereas SMTP and POP3 only have two > At the very least, shouldn't the IMAP initial response doc and revised > SMTP AUTH and POP3 AUTH docs be able to proceed in parallel, especially > if they all use similar language for the initial client response issue? The question is if the SMTP and POP3 documents are going to advance or not. This also depends upon the SASL document. I'd like to hear IESG feedback on this. Without some surety that the SMTP/POP3 situation is fixed, I feel like I am being asked to leap from a tall building, based upon unproven claims that the building is on fire and with equally unproven assurances that by the time I reach the ground, you will have contrived to have erected a net. I don't see any urgency for initial response in IMAP; it is cosmetic or a minor RTT savings at best. We can afford to take the time to do it right. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97KddKP044769 for ; Tue, 7 Oct 2003 13:39:39 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h97KddFc044768 for ietf-imapext-bks; Tue, 7 Oct 2003 13:39:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97KdbKP044761 for ; Tue, 7 Oct 2003 13:39:37 -0700 (PDT) (envelope-from steve.hole@messagingdirect.com) Received: from kepler.esys.ca (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h97KhRw09272; Tue, 7 Oct 2003 14:43:27 -0600 From: Steve Hole Date: Tue, 7 Oct 2003 14:43:35 -0600 To: Mark Crispin Subject: Re: SASL Initial Response? Cc: IMAP Extensions WG In-Reply-To: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> Message-ID: X-Mailer: Execmail for Linux 6.0.0 alpha Build (1) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h97KdbKP044762 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 7 Oct 2003 10:52:59 -0700 (Pacific Daylight Time) Mark Crispin wrote: > Hi Steve - > > I'm afraid that you misunderstood the issue. The problem is not broken > server interoperability with clients that send initial responses to SMTP > and POP3 servers; rather, it is broken server interoperability with > clients that do NOT send the initial responses. Ah! Sorry about that. --- Steve Hole Chief Technology Officer - Billing and Payment Systems ACI Worldwide Phone: 780-424-4922 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97IPjKP039783 for ; Tue, 7 Oct 2003 11:25:45 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h97IPjn4039782 for ietf-imapext-bks; Tue, 7 Oct 2003 11:25:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97IPhKP039770 for ; Tue, 7 Oct 2003 11:25:44 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id h97IPao5001170; Tue, 7 Oct 2003 14:25:36 -0400 (EDT) Message-ID: <3F8305BF.2050706@oceana.com> Date: Tue, 07 Oct 2003 14:28:15 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030916 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Mark Crispin CC: IMAP Extensions WG Subject: Re: SASL Initial Response? References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > It is for this reason that I think that the proponents of an initial > response on the command line should back off until the specifications are > clarified such that these broken SMTP and POP3 servers stop happening. I don't see why implementations which are clearly broken and in violation of the specs (regardless of how poorly written those specs may or may not be), should prevent the IMAP initial client response extension from proceeding as long as it avoids/corrects the problems with the SMTP AUTH and POP3 AUTH specs. At the very least, shouldn't the IMAP initial response doc and revised SMTP AUTH and POP3 AUTH docs be able to proceed in parallel, especially if they all use similar language for the initial client response issue? -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97I0NKP038166 for ; Tue, 7 Oct 2003 11:00:23 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h97I0Np0038165 for ietf-imapext-bks; Tue, 7 Oct 2003 11:00:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97I0LKP038160 for ; Tue, 7 Oct 2003 11:00:21 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h97I0K5t011313; Tue, 7 Oct 2003 14:00:20 -0400 Date: Tue, 7 Oct 2003 14:00:20 -0400 (EDT) From: Rob Siemborski To: Steve Hole cc: Mark Crispin , IMAP Extensions WG Subject: Re: SASL Initial Response? In-Reply-To: Message-ID: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 7 Oct 2003, Steve Hole wrote: > Perhaps the larger surprise is why people suddenly feel this important. > Cutting a round trip is nice if you're connecting/reconnecting a lot, but > I'm not sure why you would want to do that. In general, the cost of > select/examine is pretty high and part of the channel setup. It more or > less mandates efficient use of connection pooling and maintenance. Over > highly latent connections, anything that reduces roundtrips is useful > though. Personally, I don't think its "suddenly important." I just think that the lack of initial response here is unfortunate given that it violates a SASL SHOULD. Of course, the reason for this is because IMAP AUTHENTICATE came before SASL, but that doesn't preclude it being fixed by an extension. > Personally I'd be thinking about synchronization optimizations > first. Let's see ... which set of message had flags that have changed > since this time?? Doesn't CONDSTORE (which is in IETF Last Call) handle this? e.g. C: s100 UID FETCH 1:* (FLAGS) (CHANGEDSINCE 12345) S: * 1 FETCH (UID 4 MODSEQ (65402) FLAGS (\Seen)) S: * 2 FETCH (UID 6 MODSEQ (75403) FLAGS (\Deleted)) S: * 4 FETCH (UID 8 MODSEQ (29738) FLAGS ($NoJunk $AutoJunk $MDNSent)) S: s100 OK FETCH completed -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97HrDKP037911 for ; Tue, 7 Oct 2003 10:53:13 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h97HrD2w037910 for ietf-imapext-bks; Tue, 7 Oct 2003 10:53:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97Hr8KP037904 for ; Tue, 7 Oct 2003 10:53:08 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h97HqwaZ004351; Tue, 7 Oct 2003 10:53:03 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h97Hqvx0024395 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 7 Oct 2003 10:52:58 -0700 Date: Tue, 7 Oct 2003 10:52:59 -0700 (Pacific Daylight Time) From: Mark Crispin To: Steve Hole cc: IMAP Extensions WG Subject: Re: SASL Initial Response? In-Reply-To: Message-ID: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Steve - I'm afraid that you misunderstood the issue. The problem is not broken server interoperability with clients that send initial responses to SMTP and POP3 servers; rather, it is broken server interoperability with clients that do NOT send the initial responses. There are multiple SMTP and POP3 servers, some running at large ISPs, which do NOT respond correctly when a client does not provide an initial response to the PLAIN authenticator. The most common offenses are 334 ok, go on from an SMTP server and + ok, go on from a POP3 server. Another common offense is to respond with something like: 334 VXNlciBOYW1lAA== (that is, treating AUTH PLAIN with no initial response as if it was AUTH LOGIN). Yet another variation does this, but has an extra CRLF. These problems occur both with open source and vendor servers. Once again, we hear the old tired story of "our server works with Netscape [or Outlook], so your client must be broken." As for "why is this important" for IMAP; I agree with you in thinking that AUTHENTICATE command line initial response is not all that important for IMAP, since IMAP sessions generally are much longer-lived than POP3 or SMTP sessions. It is for this reason that I think that the proponents of an initial response on the command line should back off until the specifications are clarified such that these broken SMTP and POP3 servers stop happening. *AFTER* the specifications are fixed, I promise in return that I will not only stop opposing initial response on the AUTHENTICATE command line, but will also promptly implement support for it in UW imapd. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97HLsKP036582 for ; Tue, 7 Oct 2003 10:21:54 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h97HLs4e036581 for ietf-imapext-bks; Tue, 7 Oct 2003 10:21:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97HLrKP036575 for ; Tue, 7 Oct 2003 10:21:53 -0700 (PDT) (envelope-from steve.hole@messagingdirect.com) Received: from kepler.esys.ca (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h97HPfw06770; Tue, 7 Oct 2003 11:25:41 -0600 From: Steve Hole Date: Tue, 7 Oct 2003 11:25:49 -0600 To: Mark Crispin Subject: Re: SASL Initial Response? Cc: IMAP Extensions WG In-Reply-To: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> Message-ID: X-Mailer: Execmail for Linux 6.0.0 alpha Build (1) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h97HLrKP036577 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 6 Oct 2003 15:55:30 -0700 (Pacific Daylight Time) Mark Crispin wrote: > > > The second most common offense is "334 ok, go on" or "+ ok, go on". > > > Somtimes you also find extra CRLFs in the responses. > > This might be an ambiguous/incomplete specification for SMTP AUTH. I'll > > take a look. > > It's not ambiguous, but you have to read three separate documents (RFCs > 2222, 2554, and 2595) to work out how to handle an AUTH PLAIN command in > SMTP. For POP3, you just need to read 2222 and 2595. > > There is no single document, and *NO* examples, that explains this. RFC > 2554 is a bit better in talking about empty challenges than 2595 (see > first paragraph of page 3, RFC 2554) but without the context of RFC 2222 > it makes no sense. Yes, you do have to look at more than one document, and I think that this did cause some problems in the beginning. I have to admit to being a bit surprised though Mark. We have been sending out initial responses to SMTP and POP3 servers for a number of years without too much in the way of interoperability problems. There were some in the beginning, but most of those sorted out during the first IMC interop testing. Many implementations use the Cyrus SASL library which provides good examples for usage and clearly supports initial response for those mechanisms that support it. Perhaps the larger surprise is why people suddenly feel this important. Cutting a round trip is nice if you're connecting/reconnecting a lot, but I'm not sure why you would want to do that. In general, the cost of select/examine is pretty high and part of the channel setup. It more or less mandates efficient use of connection pooling and maintenance. Over highly latent connections, anything that reduces roundtrips is useful though. Personally I'd be thinking about synchronization optimizations first. Let's see ... which set of message had flags that have changed since this time?? Cheers. --- Steve Hole Chief Technology Officer - Billing and Payment Systems ACI Worldwide Phone: 780-424-4922 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96ND4KP077752 for ; Mon, 6 Oct 2003 16:13:04 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96ND4Gv077750 for ietf-imapext-bks; Mon, 6 Oct 2003 16:13:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96ND2KP077741 for ; Mon, 6 Oct 2003 16:13:02 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout5.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h96NCvMk031402; Mon, 6 Oct 2003 16:12:57 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h96NCvSS002563 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 6 Oct 2003 16:12:57 -0700 Date: Mon, 6 Oct 2003 16:12:58 -0700 (Pacific Daylight Time) From: Mark Crispin To: Rob Siemborski cc: "RL 'Bob' Morgan" , IMAP Extensions WG Subject: Re: SASL Initial Response? In-Reply-To: Message-ID: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 6 Oct 2003, Rob Siemborski wrote: > I agree. I also suspect an example or two could help the appropriate > sections of 2222bis. But further discussion of this should probably move > to the ietf-sasl list. I'm not on the ietf-sasl list, so would appreciate this being passed on. I guess that I should be at the SASL session in Minneapolis (assuming I go there which seems likely). Examples are always helpful. Section 6.1 of 2222bis should give examples of AUTH PLAIN in SMTP both with and without initial client data. Similar examples should appear in the specification for the PLAIN mechanism (which currently is hidden in the IMAP/POP3/ACAP TLS spec!) *and* in the specifications for POP3 SASL and SMTP SASL. > Obviously. But currently it seems that the primary reason that we don't > have an initial SASL response in IMAP is concerns over clarity of the > SASL specification. Actually, the primary reason was compatibility with the past; IMAP SASL is older than SASL. I'm willing to go along with it as a server-optional extension *IF* the problems with the current client-optional server-mandatory initial client data POP3/SMTP SASL are fixed. Since implementation of initial client data will be server-optional in IMAP, it will be more complex than in POP3/SMTP. This is because it's mandatory to implement in POP3/SMTP servers. > If fixing *that* specification still isn't good enough, I'm totally > willing to supply text in the draft for the IMAP extention to the effect > of "pay careful attention to the fact that initial responses are > *optional*," even to the point of making it a Security Consideration. We will need that text, and much more. > And indeed, any IMAP server that didn't get this right would immediately > have a large number of old-style clients fail to work against it anyway, > since it is an extention and not part of the base protocol. It's not just IMAP servers we have to worry about. It's also IMAP clients. We already have clients which fail to interoperate with a server that does not have a particular extension and/or declare such servers to be "broken." The offenders know who they are. We have to concern ourselves about the possibility of clients that think that initial data is mandatory to implement in the server (since it is mandatory in POP3 and SMTP). Thus, the situation is *worse* with IMAP than with POP3 or SMTP. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96MtZKP077022 for ; Mon, 6 Oct 2003 15:55:35 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96MtZVb077021 for ietf-imapext-bks; Mon, 6 Oct 2003 15:55:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout6.cac.washington.edu (mxout6.cac.washington.edu [140.142.33.20]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96MtYKP077014 for ; Mon, 6 Oct 2003 15:55:34 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout6.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h96MtT0Y001280; Mon, 6 Oct 2003 15:55:29 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h96MtTx0011345 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 6 Oct 2003 15:55:29 -0700 Date: Mon, 6 Oct 2003 15:55:30 -0700 (Pacific Daylight Time) From: Mark Crispin To: Ken Murchison cc: Rob Siemborski , IMAP Extensions WG Subject: Re: SASL Initial Response? In-Reply-To: <3F81B45E.6050909@oceana.com> Message-ID: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 6 Oct 2003, Ken Murchison wrote: > Was there a broken Sendmail patch? For all mechs, or just one in > particular? I don't know. I know that sendmail at UW works correctly for GSSAPI and PLAIN. > > The most common offense is to implement PLAIN and LOGIN as the same thing, > > thus giving LOGIN challenges to PLAIN with no initial response. > That's inexcusable, since they are clearly NOT the same thing, and PLAIN > has always had a standardized SPEC. Obviously we can't make people read > the specs correctly, all we can do is make them clear and unambiguous. Agreed completely. However, multiple commercial implementations have done this blunder. > > The second most common offense is "334 ok, go on" or "+ ok, go on". > > Somtimes you also find extra CRLFs in the responses. > This might be an ambiguous/incomplete specification for SMTP AUTH. I'll > take a look. It's not ambiguous, but you have to read three separate documents (RFCs 2222, 2554, and 2595) to work out how to handle an AUTH PLAIN command in SMTP. For POP3, you just need to read 2222 and 2595. There is no single document, and *NO* examples, that explains this. RFC 2554 is a bit better in talking about empty challenges than 2595 (see first paragraph of page 3, RFC 2554) but without the context of RFC 2222 it makes no sense. > > Over and over again, I get told "just make Pine send the initial > > challenge"; in other words, that the initial challenge is mandatory. But > > the SASL specification does not say that; and the idea of inflicting the > > non-interoperable brokenness of POP/SMTP on IMAP repels me. > So, you would like to see section 6.1 of RFC 2222bis use a MUST instead > of SHOULD? For some mechs (e.g. DIGEST-MD5) this could become > problematic because the initial response truely is optional. Actually, I would like the SHOULD to become a MAY, and it be emphasized that servers MUST implement the correct empty challenge behavior. However, a MUST is preferable to the status quo, which is a de jure SHOULD but (at least according to certain individuals) a de facto MUST. > I will do this. Just to be clear, we are only talking about > client-first mechanisms in which the client chooses to not send an > initial response, correct? Correct. SMTP is the worst case, since you have to read three RFCs to work out how to implement PLAIN in SMTP. Note that there are no examples. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96IQFKP064945 for ; Mon, 6 Oct 2003 11:26:15 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96IQFho064944 for ietf-imapext-bks; Mon, 6 Oct 2003 11:26:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96IQEKP064934 for ; Mon, 6 Oct 2003 11:26:14 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id h96IQ8o5000645; Mon, 6 Oct 2003 14:26:08 -0400 (EDT) Message-ID: <3F81B45E.6050909@oceana.com> Date: Mon, 06 Oct 2003 14:28:46 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030916 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Mark Crispin CC: Rob Siemborski , IMAP Extensions WG Subject: Re: SASL Initial Response? References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > On Mon, 6 Oct 2003, Ken Murchison wrote: > >>Can you list the broken implementations? Are there any current versions >>of servers which are broken, or just old/deprecated/unsupported code? > > > It's easier to list the non-broken implementations: UW, Cyrus, and one of > the SASL patches to sendmail. Was there a broken Sendmail patch? For all mechs, or just one in particular? > The most common offense is to implement PLAIN and LOGIN as the same thing, > thus giving LOGIN challenges to PLAIN with no initial response. That's inexcusable, since they are clearly NOT the same thing, and PLAIN has always had a standardized SPEC. Obviously we can't make people read the specs correctly, all we can do is make them clear and unambiguous. > The second most common offense is "334 ok, go on" or "+ ok, go on". > Somtimes you also find extra CRLFs in the responses. This might be an ambiguous/incomplete specification for SMTP AUTH. I'll take a look. > Over and over again, I get told "just make Pine send the initial > challenge"; in other words, that the initial challenge is mandatory. But > the SASL specification does not say that; and the idea of inflicting the > non-interoperable brokenness of POP/SMTP on IMAP repels me. So, you would like to see section 6.1 of RFC 2222bis use a MUST instead of SHOULD? For some mechs (e.g. DIGEST-MD5) this could become problematic because the initial response truely is optional. > The text is NOT clear as to how a non-specified client response is to be > handled. You have to go through multiple documents to work it out. > > The best way to understand the problem is to go through the exercise > yourself. Pretend that you don't know how SASL works. The client gives > an "AUTH PLAIN" command to an SMTP server without the initial response. > Now, go through the steps of going through the RFCs to interpret that > command, and determine the proper response. I will do this. Just to be clear, we are only talking about client-first mechanisms in which the client chooses to not send an initial response, correct? -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96I0DKP063756 for ; Mon, 6 Oct 2003 11:00:13 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96I0D68063755 for ietf-imapext-bks; Mon, 6 Oct 2003 11:00:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96I0BKP063749 for ; Mon, 6 Oct 2003 11:00:11 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOLARIS8.WASH.andrew.cmu.edu (SOLARIS8.WASH.andrew.cmu.edu [128.2.11.123]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h96I0A5t009390; Mon, 6 Oct 2003 14:00:10 -0400 Date: Mon, 6 Oct 2003 14:00:10 -0400 (EDT) From: Rob Siemborski X-X-Sender: rjs3@solaris8.wash.andrew.cmu.edu To: "RL 'Bob' Morgan" cc: Mark Crispin , IMAP Extensions WG Subject: Re: SASL Initial Response? In-Reply-To: Message-ID: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 6 Oct 2003, RL 'Bob' Morgan wrote: > On Mon, 6 Oct 2003, Mark Crispin wrote: > > > > If there is a problem, it should > > > probably be raised in the SASL WG. (Of course, that document's WG last > > > call allegedly finished on Sep 30, but it looks like comments are still > > > being made). > > > > Well, there's a problem right there; it's probably too late to raise it > > in the SASL WG. I agree that that is where it should have been raised. > > WG Last Call is only the first of many hurdles, including IETF-wide Last > Call. There is still lots of time to comment on > draft-ietf-sasl-rfc2222bis-02.txt. I agree. I also suspect an example or two could help the appropriate sections of 2222bis. But further discussion of this should probably move to the ietf-sasl list. > > So it becomes an IMAP question again. > > Any change to the IMAP protocol is of course an IMAP(ext) WG question, > even if the SASL text is perfect. Obviously. But currently it seems that the primary reason that we don't have an initial SASL response in IMAP is concerns over clarity of the SASL specification. If fixing *that* specification still isn't good enough, I'm totally willing to supply text in the draft for the IMAP extention to the effect of "pay careful attention to the fact that initial responses are *optional*," even to the point of making it a Security Consideration. And indeed, any IMAP server that didn't get this right would immediately have a large number of old-style clients fail to work against it anyway, since it is an extention and not part of the base protocol. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96HVEKP062458 for ; Mon, 6 Oct 2003 10:31:14 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96HVE2m062457 for ietf-imapext-bks; Mon, 6 Oct 2003 10:31:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96HVDKP062449 for ; Mon, 6 Oct 2003 10:31:13 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout5.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h96HV7Mk032550; Mon, 6 Oct 2003 10:31:08 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h96HV7Os002133; Mon, 6 Oct 2003 10:31:07 -0700 Date: Mon, 6 Oct 2003 10:31:07 -0700 (PDT) From: Mark Crispin To: Ken Murchison cc: Rob Siemborski , IMAP Extensions WG Subject: Re: SASL Initial Response? In-Reply-To: <3F8198A2.3070105@oceana.com> Message-ID: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 6 Oct 2003, Ken Murchison wrote: > Can you list the broken implementations? Are there any current versions > of servers which are broken, or just old/deprecated/unsupported code? It's easier to list the non-broken implementations: UW, Cyrus, and one of the SASL patches to sendmail. I'm encountering broken server implementations all the time, and big providers run them. I've seen little progress in getting it fixed. It's pretty high on my FAQ list, second only to the PC Pine crashes caused by Microsoft's persistant failure to fix the bug in SSPI that they've known about for years (they fixed it in Win2K but not WinXP). The most common offense is to implement PLAIN and LOGIN as the same thing, thus giving LOGIN challenges to PLAIN with no initial response. The second most common offense is "334 ok, go on" or "+ ok, go on". Somtimes you also find extra CRLFs in the responses. Over and over again, I get told "just make Pine send the initial challenge"; in other words, that the initial challenge is mandatory. But the SASL specification does not say that; and the idea of inflicting the non-interoperable brokenness of POP/SMTP on IMAP repels me. IMAP currently forces a correct implementation of null server challenges. Before this protection is removed, something must be done to fix the broken situation in those protocols which lack this protection. > Based on RFC 2222(bis), RFC 1734/2449 and RFC 2554, do you have any > insight? I think the text is pretty clear, but maybe others don't. The text is NOT clear as to how a non-specified client response is to be handled. You have to go through multiple documents to work it out. The best way to understand the problem is to go through the exercise yourself. Pretend that you don't know how SASL works. The client gives an "AUTH PLAIN" command to an SMTP server without the initial response. Now, go through the steps of going through the RFCs to interpret that command, and determine the proper response. I've done this tedious exercise multiple times with server implementors who simply refuse to believe that I know what I am talking about. It would be helpful if you (Ken and Rob) went through it yourselves. I agree that the specification is complete and precise. The problem is that too many implementors fail to understand it. Incidentally, it would be an acceptable answer to me to declare "on January 1, 2004, the initial challenge becomes mandatory in all protocols." I would not *like* it, but it would be better than the status quo with POP3/SMTP. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96HT7KP062381 for ; Mon, 6 Oct 2003 10:29:07 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96HT6QH062380 for ietf-imapext-bks; Mon, 6 Oct 2003 10:29:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96HT5KP062375 for ; Mon, 6 Oct 2003 10:29:05 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Mon, 6 Oct 2003 18:28:55 +0100 Message-ID: <3F81A654.5070408@isode.com> Date: Mon, 06 Oct 2003 18:28:52 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Crispin CC: Rob Siemborski , Ken Murchison , IMAP Extensions WG Subject: Re: SASL Initial Response? References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus mentioned this extension during a private talk at least 6 month ago. Unless there is a compeling reason not to add this, I am in full support for this extension. Mark Crispin wrote: >On Mon, 6 Oct 2003, Rob Siemborski wrote: > > >>I agree -- this sounds like an issue with initial responses in general, >>not with a specific use of them in IMAP. >> >> >I agree. However, the question at hand is whether to reverse an earlier >decision NOT to add this facility to IMAP. > Mark, coould you remind me when this has taken place? > Thus, it is an IMAP question. > > >>If there is a problem, it should >>probably be raised in the SASL WG. (Of course, that document's WG last >>call allegedly finished on Sep 30, but it looks like comments are still >>being made). >> >> > >Well, there's a problem right there; it's probably too late to raise it in >the SASL WG. I agree that that is where it should have been raised. > As the editor of RFC2222bis, I can say that it is not too late. >So it becomes an IMAP question again. > Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96HCqKP061400 for ; Mon, 6 Oct 2003 10:12:52 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96HCqdr061399 for ietf-imapext-bks; Mon, 6 Oct 2003 10:12:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout6.cac.washington.edu (mxout6.cac.washington.edu [140.142.33.20]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96HCpKP061391 for ; Mon, 6 Oct 2003 10:12:51 -0700 (PDT) (envelope-from rlmorgan@washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout6.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h96HCf0Y002700; Mon, 6 Oct 2003 10:12:46 -0700 Received: from D-140-142-21-78.dhcp4.washington.edu (D-140-142-21-78.dhcp4.washington.edu [140.142.21.78]) (authenticated bits=0) by smtp.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h96HCex0010547 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 6 Oct 2003 10:12:40 -0700 Date: Mon, 6 Oct 2003 10:12:32 -0700 (PDT) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@perp.cac.washington.edu To: Mark Crispin cc: IMAP Extensions WG Subject: Re: SASL Initial Response? In-Reply-To: Message-ID: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 6 Oct 2003, Mark Crispin wrote: > > If there is a problem, it should > > probably be raised in the SASL WG. (Of course, that document's WG last > > call allegedly finished on Sep 30, but it looks like comments are still > > being made). > > Well, there's a problem right there; it's probably too late to raise it > in the SASL WG. I agree that that is where it should have been raised. WG Last Call is only the first of many hurdles, including IETF-wide Last Call. There is still lots of time to comment on draft-ietf-sasl-rfc2222bis-02.txt. > So it becomes an IMAP question again. Any change to the IMAP protocol is of course an IMAP(ext) WG question, even if the SASL text is perfect. - RL "Bob" Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96H3XKP060945 for ; Mon, 6 Oct 2003 10:03:33 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96H3XfJ060944 for ietf-imapext-bks; Mon, 6 Oct 2003 10:03:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96H3WKP060938 for ; Mon, 6 Oct 2003 10:03:32 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout3.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h96H3QC2018267; Mon, 6 Oct 2003 10:03:26 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h96H3PWF000441; Mon, 6 Oct 2003 10:03:25 -0700 Date: Mon, 6 Oct 2003 10:03:25 -0700 (PDT) From: Mark Crispin To: Rob Siemborski cc: Ken Murchison , IMAP Extensions WG Subject: Re: SASL Initial Response? In-Reply-To: Message-ID: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 6 Oct 2003, Rob Siemborski wrote: > I agree -- this sounds like an issue with initial responses in general, > not with a specific use of them in IMAP. I agree. However, the question at hand is whether to reverse an earlier decision NOT to add this facility to IMAP. Thus, it is an IMAP question. > If there is a problem, it should > probably be raised in the SASL WG. (Of course, that document's WG last > call allegedly finished on Sep 30, but it looks like comments are still > being made). Well, there's a problem right there; it's probably too late to raise it in the SASL WG. I agree that that is where it should have been raised. So it becomes an IMAP question again. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96GUKKP058666 for ; Mon, 6 Oct 2003 09:30:20 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96GUKoA058665 for ietf-imapext-bks; Mon, 6 Oct 2003 09:30:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96GUIKP058660 for ; Mon, 6 Oct 2003 09:30:19 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOLARIS8.WASH.andrew.cmu.edu (SOLARIS8.WASH.andrew.cmu.edu [128.2.11.123]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h96GUH5t009250; Mon, 6 Oct 2003 12:30:17 -0400 Date: Mon, 6 Oct 2003 12:30:17 -0400 (EDT) From: Rob Siemborski X-X-Sender: rjs3@solaris8.wash.andrew.cmu.edu To: Ken Murchison cc: Mark Crispin , IMAP Extensions WG Subject: Re: SASL Initial Response? In-Reply-To: <3F8198A2.3070105@oceana.com> Message-ID: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 6 Oct 2003, Ken Murchison wrote: > > 4) Would a change of wording in the specification help? > > Based on RFC 2222(bis), RFC 1734/2449 and RFC 2554, do you have any > insight? I think the text is pretty clear, but maybe others don't. I agree -- this sounds like an issue with initial responses in general, not with a specific use of them in IMAP. If there is a problem, it should probably be raised in the SASL WG. (Of course, that document's WG last call allegedly finished on Sep 30, but it looks like comments are still being made). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96GRuKP058525 for ; Mon, 6 Oct 2003 09:27:56 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96GRujM058524 for ietf-imapext-bks; Mon, 6 Oct 2003 09:27:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96GRsKP058513 for ; Mon, 6 Oct 2003 09:27:55 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id h96GRlo5025878; Mon, 6 Oct 2003 12:27:48 -0400 (EDT) Message-ID: <3F8198A2.3070105@oceana.com> Date: Mon, 06 Oct 2003 12:30:26 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030916 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Mark Crispin CC: Rob Siemborski , IMAP Extensions WG Subject: Re: SASL Initial Response? References: <3F81908D.5000101@oceana.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > On Mon, 6 Oct 2003, Ken Murchison wrote: > >>This might be true, but it doesn't seem like a compelling technical >>argument against allowing this in IMAP. Existing or future poor >>implementations should not stand in the way of progress, unless the >>specification is so complex that it is part of the implementation problem. > > > Well, I think that the example of POP and SMTP suggests that it may well > be too complex. Before proceeding, I think that the POP/SMTP experience > needs to be carefully reviewed. > > >>Are you saying that you would oppose such an extension, or just saying >>that based on past experience it might cause some heartburn? > > > It will cause some heartburn. The proof is out there. Can you list the broken implementations? Are there any current versions of servers which are broken, or just old/deprecated/unsupported code? > > As for support or opposition, I haven't taken a position; but if it is > proposed without any attempt to study or learn from the POP/SMTP > experience I probably will oppose it. > > Suggested topics for study: > > 1) Why is it difficult to understand that the initial response is > optional? > > 2) Why do server implementors have trouble in generating appropriate > initial challenges ("ok, go ahead" in plaintext is not appropriate)? > > 3) Why are incorrect implementations so widespread in the POP/SMTP world? > > 4) Would a change of wording in the specification help? Based on RFC 2222(bis), RFC 1734/2449 and RFC 2554, do you have any insight? I think the text is pretty clear, but maybe others don't. > If these questions are answered in a reasonable way, I will either support > or be neutral on the proposal. Glad to hear it. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96GIJKP058083 for ; Mon, 6 Oct 2003 09:18:19 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96GIJv0058082 for ietf-imapext-bks; Mon, 6 Oct 2003 09:18:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96GIIKP058072 for ; Mon, 6 Oct 2003 09:18:18 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout5.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h96GI7Mk017758; Mon, 6 Oct 2003 09:18:12 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h96GI7B3030349; Mon, 6 Oct 2003 09:18:07 -0700 Date: Mon, 6 Oct 2003 09:18:07 -0700 (PDT) From: Mark Crispin To: Ken Murchison cc: Rob Siemborski , IMAP Extensions WG Subject: Re: SASL Initial Response? In-Reply-To: <3F81908D.5000101@oceana.com> Message-ID: References: <3F81908D.5000101@oceana.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 6 Oct 2003, Ken Murchison wrote: > This might be true, but it doesn't seem like a compelling technical > argument against allowing this in IMAP. Existing or future poor > implementations should not stand in the way of progress, unless the > specification is so complex that it is part of the implementation problem. Well, I think that the example of POP and SMTP suggests that it may well be too complex. Before proceeding, I think that the POP/SMTP experience needs to be carefully reviewed. > Are you saying that you would oppose such an extension, or just saying > that based on past experience it might cause some heartburn? It will cause some heartburn. The proof is out there. As for support or opposition, I haven't taken a position; but if it is proposed without any attempt to study or learn from the POP/SMTP experience I probably will oppose it. Suggested topics for study: 1) Why is it difficult to understand that the initial response is optional? 2) Why do server implementors have trouble in generating appropriate initial challenges ("ok, go ahead" in plaintext is not appropriate)? 3) Why are incorrect implementations so widespread in the POP/SMTP world? 4) Would a change of wording in the specification help? If these questions are answered in a reasonable way, I will either support or be neutral on the proposal. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96FrXKP056715 for ; Mon, 6 Oct 2003 08:53:33 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96FrXpB056714 for ietf-imapext-bks; Mon, 6 Oct 2003 08:53:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96FrWKP056708 for ; Mon, 6 Oct 2003 08:53:32 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id h96FrJo5017536; Mon, 6 Oct 2003 11:53:19 -0400 (EDT) Message-ID: <3F81908D.5000101@oceana.com> Date: Mon, 06 Oct 2003 11:55:57 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030916 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Mark Crispin CC: Rob Siemborski , ietf-imapext@imc.org Subject: Re: SASL Initial Response? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > On Mon, 6 Oct 2003, Rob Siemborski wrote: > >>Is there any reason no one has ever proposed an IMAP extention to support >>SASL initial client responses? > > > Experience with POP and SMTP suggests that if the protcol supports initial > client responses, server implementors will never correctly implement the > case when the client does not supply one. > > This has been an ongoing problem which, to date, IMAP has had blissful > immunity. This might be true, but it doesn't seem like a compelling technical argument against allowing this in IMAP. Existing or future poor implementations should not stand in the way of progress, unless the specification is so complex that it is part of the implementation problem. Are you saying that you would oppose such an extension, or just saying that based on past experience it might cause some heartburn? -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96FRrKP055595 for ; Mon, 6 Oct 2003 08:27:53 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96FRrwm055594 for ietf-imapext-bks; Mon, 6 Oct 2003 08:27:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96FRqKP055586 for ; Mon, 6 Oct 2003 08:27:52 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout4.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h96FRkmw027328; Mon, 6 Oct 2003 08:27:51 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h96FRkLn027836; Mon, 6 Oct 2003 08:27:46 -0700 Date: Mon, 6 Oct 2003 08:27:46 -0700 (PDT) From: Mark Crispin To: Rob Siemborski cc: ietf-imapext@imc.org Subject: Re: SASL Initial Response? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 6 Oct 2003, Rob Siemborski wrote: > Is there any reason no one has ever proposed an IMAP extention to support > SASL initial client responses? Experience with POP and SMTP suggests that if the protcol supports initial client responses, server implementors will never correctly implement the case when the client does not supply one. This has been an ongoing problem which, to date, IMAP has had blissful immunity. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96EocKP053754 for ; Mon, 6 Oct 2003 07:50:38 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96Eoc1B053753 for ietf-imapext-bks; Mon, 6 Oct 2003 07:50:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96EoaKP053745 for ; Mon, 6 Oct 2003 07:50:37 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from MAIL5.andrew.cmu.edu (MAIL5.andrew.cmu.edu [128.2.10.135]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h96Eob5t009084 for ; Mon, 6 Oct 2003 10:50:37 -0400 Date: Mon, 6 Oct 2003 10:50:37 -0400 (EDT) From: Rob Siemborski To: ietf-imapext@imc.org Subject: SASL Initial Response? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Is there any reason no one has ever proposed an IMAP extention to support SASL initial client responses? My basic idea would be that the server would advertise another (sigh) capability, and would then accept a second argument to the AUTHENTICATE command which would contain the initial SASL blob (if applicable). Can anyone offhand see why this would be an outright bad idea? Certainly, I can understand not being able to do this for server-last-sends currently (since that seems to require a client-side capability mechanism of some sort), but it seems like initial client responses would be both easy to add, and beneficial (in terms of the number of round trips required at startup). If there aren't significant initial objections, I'm willing to put together an individual ID for this. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h94JtTKP044138 for ; Sat, 4 Oct 2003 12:55:31 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h94JtT9M044137 for ietf-imapext-bks; Sat, 4 Oct 2003 12:55:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from melkebalanse.gulbrandsen.priv.no (melkebalanse.gulbrandsen.priv.no [217.19.171.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h94JtSKP044131 for ; Sat, 4 Oct 2003 12:55:29 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Message-Id: From: Arnt Gulbrandsen To: Mark Crispin Subject: Re: two ACL2 points Cc: IMAP extensions Mailing List References: In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Sat, 4 Oct 2003 21:57:58 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: > On Sat, 4 Oct 2003, Arnt Gulbrandsen wrote: >> What I'd like is a requirement that the server MAY send unsolicited >> LIST (ACL) responses for any mailbox for which the client has issued >> an ACL command, and that the client MUST handle such responses. > > That is already a requirement of IMAP, and always has been. Yes, I've seen the half-sentence in 2.2.2. But I don't see much about "client MUST handle", except specific requirements such as that in 7.2.6. A nudge and a wink doesn't seem out of place in the ACL2 document. Perhaps in the form of a stated "client MUST handle", or perhaps in the form of an example that draws attention to rules that are in the base RFC. (I ran into this while fooling with an ACL dialog and thinking, what if this is run by two IMAP clients at the same time, e.g. two people responding to the same e-mailed request?) --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h94J6rKP042772 for ; Sat, 4 Oct 2003 12:06:53 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h94J6r32042771 for ietf-imapext-bks; Sat, 4 Oct 2003 12:06:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h94J6kKP042764 for ; Sat, 4 Oct 2003 12:06:47 -0700 (PDT) (envelope-from tss@iki.fi) Received: by danu.procontrol.fi (Postfix, from userid 106) id 082A9238C6; Sat, 4 Oct 2003 22:06:39 +0300 (EEST) Received: from iki.fi (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id 1A068238B6; Sat, 4 Oct 2003 22:06:26 +0300 (EEST) Date: Sat, 4 Oct 2003 22:06:36 +0300 Subject: Re: two ACL2 points Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: IMAP extensions Mailing List To: Arnt Gulbrandsen From: Timo Sirainen In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-5.8 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES, USER_AGENT_APPLEMAIL version=2.54 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Saturday, Oct 4, 2003, at 20:41 Europe/Helsinki, Arnt Gulbrandsen wrote: > 1. The SELECT command looks at ACL, says the draft, but as soon as a > client has selected a mailbox that's it. The security considerations > should probably note that if an ACL is restricted, any client that > already has selected the mailbox keeps its access indefinitely. > > Perhaps the server should be explicitly allowed to kick the client out > in this case. This is mail store dependent. If you drop access to maildir in filesystem level, you can't open mails anymore. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h94IgkKP042132 for ; Sat, 4 Oct 2003 11:42:46 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h94IgklB042131 for ietf-imapext-bks; Sat, 4 Oct 2003 11:42:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h94IgjKP042123 for ; Sat, 4 Oct 2003 11:42:45 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout3.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h94IgRC2028566; Sat, 4 Oct 2003 11:42:32 -0700 Received: from Shimo-Tomobiki.Panda.COM (panda.com [206.124.149.114]) (authenticated bits=0) by smtp.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h94IgKx0008663 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 4 Oct 2003 11:42:26 -0700 Date: Sat, 4 Oct 2003 11:42:20 -0700 (Pacific Daylight Time) From: Mark Crispin To: Arnt Gulbrandsen cc: IMAP extensions Mailing List Subject: Re: two ACL2 points In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sat, 4 Oct 2003, Arnt Gulbrandsen wrote: > 1. The SELECT command looks at ACL, says the draft, but as soon as a > client has selected a mailbox that's it. The security considerations > should probably note that if an ACL is restricted, any client that > already has selected the mailbox keeps its access indefinitely. I agree. > 2. A client that has run LIST ACL isn't told about later changes. Similarly, a client that does a LIST isn't told when mailboxes are created or deleted. > What I'd like is a requirement that the server MAY send unsolicited LIST > (ACL) responses for any mailbox for which the client has issued an ACL > command, and that the client MUST handle such responses. That is already a requirement of IMAP, and always has been. For example, a server can send an untagged SEARCH even if the client never issued a SEARCH command. However, there is no reason to believe that any client will do anything with such responses. The unsolicited data model only requires that clients keep track of state changes in the selected mailbox, and is silent about other data. It neither mandates nor forbids it. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h94Hd4KP040824 for ; Sat, 4 Oct 2003 10:39:04 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h94Hd4BD040823 for ietf-imapext-bks; Sat, 4 Oct 2003 10:39:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from melkebalanse.gulbrandsen.priv.no (melkebalanse.gulbrandsen.priv.no [217.19.171.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h94HcvKP040818 for ; Sat, 4 Oct 2003 10:39:04 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Message-Id: From: Arnt Gulbrandsen To: IMAP extensions Mailing List Subject: two ACL2 points Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Sat, 4 Oct 2003 19:41:21 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [ As I write this mail I have a deja vu feeling. Have I already noted these things? I don't see anything in my mail archive. ] Both points relate to changes in ACLs done by one client that affect another. 1. The SELECT command looks at ACL, says the draft, but as soon as a client has selected a mailbox that's it. The security considerations should probably note that if an ACL is restricted, any client that already has selected the mailbox keeps its access indefinitely. Perhaps the server should be explicitly allowed to kick the client out in this case. 2. A client that has run LIST ACL isn't told about later changes. IMO, the server has the right to send any and all unsolicited responses during IDLE mode, and also as side effects for most commands. But I suspect many clients don't handle that very well... What I'd like is a requirement that the server MAY send unsolicited LIST (ACL) responses for any mailbox for which the client has issued an ACL command, and that the client MUST handle such responses. --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93EGxKP022544 for ; Fri, 3 Oct 2003 07:16:59 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h93EGwnj022543 for ietf-imapext-bks; Fri, 3 Oct 2003 07:16:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93EGvKP022538 for ; Fri, 3 Oct 2003 07:16:58 -0700 (PDT) (envelope-from apache@asgard.ietf.org) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1A5Qjn-0001EU-CT; Fri, 03 Oct 2003 10:16:55 -0400 X-test-idtracker: no To: IETF-Announce :; Cc: ietf-imapext@imc.org From: The IESG Subject: Last Call: 'IMAP Extension for Conditional STORE operation' to Proposed Standard Reply-to: iesg@ietf.org Message-Id: Date: Fri, 03 Oct 2003 10:16:55 -0400 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has received a request from the Internet Message Access Protocol Extension WG to consider the following document: - 'IMAP Extension for Conditional STORE operation ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-10-17. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-imapext-condstore-04.txt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92GvCKP003955 for ; Thu, 2 Oct 2003 09:57:12 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h92GvCts003954 for ietf-imapext-bks; Thu, 2 Oct 2003 09:57:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92Gv6KP003945 for ; Thu, 2 Oct 2003 09:57:06 -0700 (PDT) (envelope-from ned+imapext@innosoft.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01L1CHPORFMO002O3W@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf-imapext@imc.org; Thu, 02 Oct 2003 09:56:44 -0700 (PDT) Date: Thu, 02 Oct 2003 09:55:35 -0700 (PDT) From: ned+imapext@INNOSOFT.COM Subject: Re: AD review comments on draft-ietf-imapext-condstore In-reply-to: "Your message dated Thu, 02 Oct 2003 10:01:45 +0100" <3F7BE979.3040401@isode.com> To: Alexey Melnikov Cc: ned+imapext@INNOSOFT.COM, Pete Resnick , ietf-imapext@imc.org, Ned Freed , hardie@qualcomm.com Message-id: <01L1CKZ0MGMY002O3W@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <01L1BYWZM9P200UICS@mauve.mrochek.com> <3F7BE979.3040401@isode.com> Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > The production: > > > > fetch = "FETCH" SP sequence-set SP ("ALL" / "FULL" / > > "FAST" / fetch-att / > > "(" fetch-att *(SP fetch-att) ")") > > [SPfetch-modifiers] > > > > should read: > > > > fetch = "FETCH" SP sequence-set SP ("ALL" / "FULL" / > > "FAST" / fetch-att / > > "(" fetch-att *(SP fetch-att) ")") [SP > > fetch-modifiers] > Actually, this production is correct (there is a space between SP and > fetch-modifiers. Some sort of wierd cut and paste error on my part then. Sorry about that. > I've updated the document. Yes, thanks, and now that the revision has hit the repository I'll ask for a last call. Ned Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92EobKP098892 for ; Thu, 2 Oct 2003 07:50:37 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h92Eob2N098890 for ietf-imapext-bks; Thu, 2 Oct 2003 07:50:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92EoZKP098884 for ; Thu, 2 Oct 2003 07:50:36 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23139; Thu, 2 Oct 2003 10:50:27 -0400 (EDT) Message-Id: <200310021450.KAA23139@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-condstore-04.txt Date: Thu, 02 Oct 2003 10:50:27 -0400 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF. Title : IMAP Extension for Conditional STORE operation Author(s) : A. Melnikov, S. Hole Filename : draft-ietf-imapext-condstore-04.txt Pages : 16 Date : 2003-10-2 Often, multiple IMAP clients need to coordinate changes to a common IMAP mailbox. Examples include different clients for the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to synchronize state changes for messages within the mailbox. They must be able to guarantee that only one client can change message state (e.g., message flags or annotations) at any time. An example of such an application is use of an IMAP mailbox as a message queue with multiple dequeueing clients. The Conditional Store facility provides a protected update mechanism for message state information that can detect and resolve conflicts between multiple writing mail clients. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-condstore-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-imapext-condstore-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imapext-condstore-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-2105852.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-condstore-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-condstore-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-2105852.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92929KP084522 for ; Thu, 2 Oct 2003 02:02:09 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h92929mU084521 for ietf-imapext-bks; Thu, 2 Oct 2003 02:02:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92922KP084508 for ; Thu, 2 Oct 2003 02:02:07 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Thu, 2 Oct 2003 10:01:47 +0100 Message-ID: <3F7BE979.3040401@isode.com> Date: Thu, 02 Oct 2003 10:01:45 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ned+imapext@INNOSOFT.COM CC: Pete Resnick , ietf-imapext@imc.org, Ned Freed , hardie@qualcomm.com Subject: Re: AD review comments on draft-ietf-imapext-condstore References: <01L1BYWZM9P200UICS@mauve.mrochek.com> In-Reply-To: <01L1BYWZM9P200UICS@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ned+imapext@INNOSOFT.COM wrote: > > Pete asked me to last call this document. However, my AD review turned up > a number of errors, mostly editorial in nature. There are enough of these > that I think they need to be corrected in a revised I-D before > proceeding. > > - - - - - - > > Section 2, fifth paragraph: A reference to [ANNOTATE] should be added. > > Section 2, seventh paragraph: extention -> extension > > Section 4, second paragraph: "[IMAP4]" -> "[IMAP4] or [ANNOTATE]" > > There are lots of ABNF errors. The production: > > entry-name = entry-name-flag / entry-annotate-name > should be: > > entry-name = entry-flag-name / entry-annotate-name > (There is no entry-name-flag production.) The production: > > entry-flag-name = '"' "/flags/" attr-flag '"' > > isn't syntactically valid and needs to be changed to: > > entry-flag-name = DQUOTE "/flags/" attr-flag DQUOTE > > (The DQUOTE production is used in RFC 3501, whose ABNF is available to > this document.) The production: > > entry-type-resp = "priv" | "shared" > > should be: > > entry-type-resp = "priv" / "shared" > > The production: > > entry-type-req = entry-type-resp | "all" > > should be: > > entry-type-req = entry-type-resp / "all" > > The production: > > store = "STORE" SP set store-modifiers SP > store-att-flags > > should read: > > store = "STORE" SP sequence-set store-modifiers > SP store-att-flags > The production: > > fetch = "FETCH" SP sequence-set SP ("ALL" / "FULL" / > "FAST" / fetch-att / > "(" fetch-att *(SP fetch-att) ")") > [SPfetch-modifiers] > > should read: > > fetch = "FETCH" SP sequence-set SP ("ALL" / "FULL" / > "FAST" / fetch-att / > "(" fetch-att *(SP fetch-att) ")") [SP > fetch-modifiers] Actually, this production is correct (there is a space between SP and fetch-modifiers. > The production: > > mod-sequence-valzer = "0" | mod-sequence-value > > should be: > > mod-sequence-valzer = "0" / mod-sequence-value > > The production name "search_sort_mod_seq" needs to be changed to > "search-sort-mod-seq" everywhere. (Underscors aren't allowed in > production > names.) > > Security considerations: > > The statement "It is believed that the Conditional STORE extension > doesn't raise any new security concerns that are not already discussed > in [IMAP4]" is correct as far as it goes. However, this extension > provides a means by which an IMAP store can be used for potentially > criticial applications involving multiple clients that could not be > supported before. This may have the effect of making correct IMAP > server behavior more important. Accordingly, I suggest amending the > section to read: > > It is believed that the Conditional STORE extension doesn't raise > any new security concerns that are not already discussed in [IMAP4]. > However, the availability of this extension may make it possible > for IMAP4 to be used in critical applications it could not be used > for previously, making correct IMAP server implementation and > operation in even more important. > > Section 7: The wording here is awkward. I suggest changing it to read: > "This document defines the CONDSTORE and SORT=MODSEQ IMAP capabilities. > IANA should add them to the registry accordingly." > > Acknowledgements, third paragraph: "Authors" -> "The authors" > > That's it! > > Ned Thank you Ned. I've updated the document. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h926PQKP049702 for ; Wed, 1 Oct 2003 23:25:26 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h926PQPj049701 for ietf-imapext-bks; Wed, 1 Oct 2003 23:25:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h926PMKP049680 for ; Wed, 1 Oct 2003 23:25:25 -0700 (PDT) (envelope-from ned+imapext@innosoft.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01L1BYJ8S38000UICS@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf-imapext@imc.org; Wed, 01 Oct 2003 23:25:09 -0700 (PDT) Date: Wed, 01 Oct 2003 23:15:36 -0700 (PDT) From: ned+imapext@INNOSOFT.COM Subject: AD review comments on draft-ietf-imapext-condstore In-reply-to: "Your message dated Wed, 01 Oct 2003 15:34:52 -0500" To: Pete Resnick , ietf-imapext@imc.org Cc: Ned Freed , hardie@qualcomm.com Message-id: <01L1BYWZM9P200UICS@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Pete asked me to last call this document. However, my AD review turned up a number of errors, mostly editorial in nature. There are enough of these that I think they need to be corrected in a revised I-D before proceeding. - - - - - - Section 2, fifth paragraph: A reference to [ANNOTATE] should be added. Section 2, seventh paragraph: extention -> extension Section 4, second paragraph: "[IMAP4]" -> "[IMAP4] or [ANNOTATE]" There are lots of ABNF errors. The production: entry-name = entry-name-flag / entry-annotate-name should be: entry-name = entry-flag-name / entry-annotate-name (There is no entry-name-flag production.) The production: entry-flag-name = '"' "/flags/" attr-flag '"' isn't syntactically valid and needs to be changed to: entry-flag-name = DQUOTE "/flags/" attr-flag DQUOTE (The DQUOTE production is used in RFC 3501, whose ABNF is available to this document.) The production: entry-type-resp = "priv" | "shared" should be: entry-type-resp = "priv" / "shared" The production: entry-type-req = entry-type-resp | "all" should be: entry-type-req = entry-type-resp / "all" The production: store = "STORE" SP set store-modifiers SP store-att-flags should read: store = "STORE" SP sequence-set store-modifiers SP store-att-flags The production: fetch = "FETCH" SP sequence-set SP ("ALL" / "FULL" / "FAST" / fetch-att / "(" fetch-att *(SP fetch-att) ")") [SPfetch-modifiers] should read: fetch = "FETCH" SP sequence-set SP ("ALL" / "FULL" / "FAST" / fetch-att / "(" fetch-att *(SP fetch-att) ")") [SP fetch-modifiers] The production: mod-sequence-valzer = "0" | mod-sequence-value should be: mod-sequence-valzer = "0" / mod-sequence-value The production name "search_sort_mod_seq" needs to be changed to "search-sort-mod-seq" everywhere. (Underscors aren't allowed in production names.) Security considerations: The statement "It is believed that the Conditional STORE extension doesn't raise any new security concerns that are not already discussed in [IMAP4]" is correct as far as it goes. However, this extension provides a means by which an IMAP store can be used for potentially criticial applications involving multiple clients that could not be supported before. This may have the effect of making correct IMAP server behavior more important. Accordingly, I suggest amending the section to read: It is believed that the Conditional STORE extension doesn't raise any new security concerns that are not already discussed in [IMAP4]. However, the availability of this extension may make it possible for IMAP4 to be used in critical applications it could not be used for previously, making correct IMAP server implementation and operation in even more important. Section 7: The wording here is awkward. I suggest changing it to read: "This document defines the CONDSTORE and SORT=MODSEQ IMAP capabilities. IANA should add them to the registry accordingly." Acknowledgements, third paragraph: "Authors" -> "The authors" That's it! Ned Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VLURkT009076 for ; Fri, 31 Oct 2003 13:30:27 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VLURLb009075 for ietf-imapext-bks; Fri, 31 Oct 2003 13:30:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VLUPkT009068 for ; Fri, 31 Oct 2003 13:30:26 -0800 (PST) (envelope-from ned+imapext@innosoft.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01L2DSJNECA800Q4RU@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf-imapext@imc.org; Fri, 31 Oct 2003 13:30:26 -0800 (PST) Date: Fri, 31 Oct 2003 13:13:41 -0800 (PST) From: ned+imapext@INNOSOFT.COM Subject: Re: Jabbering - imapext@ietf.xmpp.org In-reply-to: "Your message dated Fri, 31 Oct 2003 13:47:06 -0700" <2147483647.1067608026@[192.168.42.6]> To: Lyndon Nerenberg Cc: Pete Resnick , ietf-imapext@imc.org Message-id: <01L2HAW0NET800Q4RU@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <2147483647.1067597124@[10.0.1.10]> <1476766497.1067594028@[192.168.42.6]> <2147483647.1067608026@[192.168.42.6]> Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > Did you have tool > > problems, or was the jabber scribe simply not saying anything > > comprehensible enough for you? > The problem with Jabber is that the scribe cannot keep up with the > discussion in real time. Well, it pretty much depends on how fast a typist you are. I've done this a couple of times, including one very busy ASRG meeting, and I think I've managed to keep up and cover the relevant points, but then again I'm a very fast typist. And if you do this you most certainly aren't going to be able to do much in the way of contributing to the discussion. It is also hard work by any measure, and not something I'd be willing to do for more than a couple of sessions at any given IETF. > And neither can the remote correspondents. Speaking as someone who has tried to participate remotely on a couple of occasions, the problem is usually not having enough information to keep up with rather than having too much. > And it > is impossible to transcribe the nuances of the conversation on the fly, and > without that context it's very easy to misinterpret what's really being > said. (I used to work for a court reporting company. There is a reason > those people get paid as much as they do.) Indeed. Transcription is in all its various forms is clearly an art, and it is silly to believe that any random person will be able to do it well. (Not even when we're talking about random IETF attendees.) Clearly this is no real substitute for actually being there. > > > The mailing lists are not broken -- let's not try to fix them. > > And this has what to do with the existence of the jabber room? > Everything. We're talking about communication within the WG. I am making > the claim that the mailing list is a useful and appropriate tool for the WG > members to communicate -- accurately -- their thoughts. I am also making > the claim that Jabber does not allow for accurate communication, and is the > wrong tool to solve this problem (if indeed there really is a problem here > that needs solving). Hmm. Well, I think I see your point, but on the other hand, the ability to talk to the chair right away when issues come up is an intriguing one that may have some real advantages. I think it is worth trying at least. If it helps, great, and if it sucks we'll at least have learned something. Ned Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VKlDkT007388 for ; Fri, 31 Oct 2003 12:47:14 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VKlDRk007387 for ietf-imapext-bks; Fri, 31 Oct 2003 12:47:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VKlCkT007382 for ; Fri, 31 Oct 2003 12:47:12 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from [192.168.42.6] (peregrin.orthanc.ca [192.168.42.6]) by orthanc.ca (8.12.9p1/8.12.9) with ESMTP id h9VKlAP5033354; Fri, 31 Oct 2003 13:47:11 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Fri, 31 Oct 2003 13:47:06 -0700 From: Lyndon Nerenberg To: Pete Resnick cc: ietf-imapext@imc.org Subject: Re: Jabbering - imapext@ietf.xmpp.org Message-ID: <2147483647.1067608026@[192.168.42.6]> In-Reply-To: References: <2147483647.1067597124@[10.0.1.10]> <1476766497.1067594028@[192.168.42.6]> X-Mailer: Mulberry/3.1.0b9 (Mac OS X Demo) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Did you have tool > problems, or was the jabber scribe simply not saying anything > comprehensible enough for you? The problem with Jabber is that the scribe cannot keep up with the discussion in real time. And neither can the remote correspondents. And it is impossible to transcribe the nuances of the conversation on the fly, and without that context it's very easy to misinterpret what's really being said. (I used to work for a court reporting company. There is a reason those people get paid as much as they do.) >> The mailing lists are not broken -- let's not try to fix them. > > And this has what to do with the existence of the jabber room? Everything. We're talking about communication within the WG. I am making the claim that the mailing list is a useful and appropriate tool for the WG members to communicate -- accurately -- their thoughts. I am also making the claim that Jabber does not allow for accurate communication, and is the wrong tool to solve this problem (if indeed there really is a problem here that needs solving). --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VHXikT099203 for ; Fri, 31 Oct 2003 09:33:44 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VHXi0T099202 for ietf-imapext-bks; Fri, 31 Oct 2003 09:33:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from episteme-software.com (216-43-25-66.ip.mcleodusa.net [216.43.25.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VHXhkT099197 for ; Fri, 31 Oct 2003 09:33:43 -0800 (PST) (envelope-from presnick@qualcomm.com) Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b1); Fri, 31 Oct 2003 11:33:44 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <1476766497.1067594028@[192.168.42.6]> References: <2147483647.1067597124@[10.0.1.10]> <1476766497.1067594028@[192.168.42.6]> X-Mailer: Eudora [Macintosh version 6.1a2] Date: Fri, 31 Oct 2003 11:33:42 -0600 To: Lyndon Nerenberg From: Pete Resnick Subject: Re: Jabbering - imapext@ietf.xmpp.org Cc: ietf-imapext@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 10/31/03 at 9:53 AM -0700, Lyndon Nerenberg wrote: >My experience with jabber over the last few IETFs is that it's >nothing more than a pain in the a**. I've successfully used jabber during the face-to-face, both for watching side commentary while in a large session (to ask questions for simple things while the session is going on) as well as watching what was going on in a session I couldn't be at while in another room. Did you have tool problems, or was the jabber scribe simply not saying anything comprehensible enough for you? >The mailing lists are not broken -- let's not try to fix them. And this has what to do with the existence of the jabber room? Again, the jabber room is NOT trying to fix anything about the mailing list, and it's CERTAINLY NOT trying to replace it for official business. It's another channel of communication (just like private e-mail between members of a working group) where people can work minor things out without wasting the time of the entire working group. Is there some problem with that? pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VGrvkT097820 for ; Fri, 31 Oct 2003 08:53:57 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VGrvLm097819 for ietf-imapext-bks; Fri, 31 Oct 2003 08:53:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VGrukT097807 for ; Fri, 31 Oct 2003 08:53:56 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from [192.168.42.6] (peregrin.orthanc.ca [192.168.42.6]) by orthanc.ca (8.12.9p1/8.12.9) with ESMTP id h9VGrrP5032257 for ; Fri, 31 Oct 2003 09:53:54 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Fri, 31 Oct 2003 09:53:48 -0700 From: Lyndon Nerenberg To: ietf-imapext@imc.org Subject: Re: Jabbering - imapext@ietf.xmpp.org Message-ID: <1476766497.1067594028@[192.168.42.6]> In-Reply-To: References: <2147483647.1067597124@[10.0.1.10]> X-Mailer: Mulberry/3.1.0b9 (Mac OS X Demo) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Absolutely, though my feeling is that serious discussions should *not* > take place in jabber at this point. My experience with jabber over the last few IETFs is that it's nothing more than a pain in the a**. The mailing lists are not broken -- let's not try to fix them. --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VFoJkT095439 for ; Fri, 31 Oct 2003 07:50:19 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VFoIBR095438 for ietf-imapext-bks; Fri, 31 Oct 2003 07:50:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from episteme-software.com (216-43-25-66.ip.mcleodusa.net [216.43.25.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VFoHkT095424 for ; Fri, 31 Oct 2003 07:50:17 -0800 (PST) (envelope-from presnick@qualcomm.com) Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b1); Fri, 31 Oct 2003 09:50:17 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <2147483647.1067597124@[10.0.1.10]> References: <2147483647.1067597124@[10.0.1.10]> X-Mailer: Eudora [Macintosh version 6.1a2] Date: Fri, 31 Oct 2003 09:50:15 -0600 To: Cyrus Daboo From: Pete Resnick Subject: Re: Jabbering - imapext@ietf.xmpp.org Cc: ietf-imapext@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 10/31/03 at 10:45 AM -0500, Cyrus Daboo wrote: >If serious discussions are going to take place on the jabber list, >is it possible to have some summary of those posted to the email list Absolutely, though my feeling is that serious discussions should *not* take place in jabber at this point. Jabber might be a nice way, if someone happens to be around, to ask a quick "Hey, what's the status of my draft?" or "I don't understand a piece of this draft. Can someone explain what I'm missing, or should I bring this to the author as a problem?" kind of question. I expect serious issue discussions to always be on the list. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VFjPkT095289 for ; Fri, 31 Oct 2003 07:45:25 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VFjOY3095288 for ietf-imapext-bks; Fri, 31 Oct 2003 07:45:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VFjKkT095279 for ; Fri, 31 Oct 2003 07:45:23 -0800 (PST) (envelope-from daboo@cyrusoft.com) Received: from [63.163.82.24] (socrates.cyrusoft.com [63.163.82.24]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id h9VFbNEG017283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Oct 2003 10:37:23 -0500 Date: Fri, 31 Oct 2003 10:45:24 -0500 From: Cyrus Daboo To: Pete Resnick , ietf-imapext@imc.org Subject: Re: Jabbering - imapext@ietf.xmpp.org Message-ID: <2147483647.1067597124@[10.0.1.10]> In-Reply-To: References: X-Mailer: Mulberry/3.1.0b9 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Pete, - --On Thursday, October 30, 2003 23:21 -0600 Pete Resnick wrote: | Just to let folks know: I plan to "hang out" in the IMAPEXT room on the | new jabber server that Marshall recently announced. Everyone should feel | free to "hang out" or drop in for group related questions. Frankly, right now I have enough trouble keeping up with email, let alone anything that's more 'real-time' than that. If serious discussions are going to take place on the jabber list, is it possible to have some summary of those posted to the email list (I'm not talking about a URL to jabber archive but a real email message with any jabber discussions from the last week, say). - -- Cyrus Daboo -----BEGIN PGP SIGNATURE----- Version: Mulberry PGP Plugin v3.0 Comment: processed by Mulberry PGP Plugin iQA/AwUBP6KDmSK4BGrbmMvFEQIjzwCbBS96sJcnI6ZBXWQMUz6MXjVK1BYAoIV4 mDmg+d51OEgdWj4FB6e6u9V+ =wL9q -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9V5LFkT005158 for ; Thu, 30 Oct 2003 21:21:15 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9V5LFLl005157 for ietf-imapext-bks; Thu, 30 Oct 2003 21:21:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from episteme-software.com (216-43-25-66.ip.mcleodusa.net [216.43.25.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9V5LEkT005152 for ; Thu, 30 Oct 2003 21:21:14 -0800 (PST) (envelope-from presnick@qualcomm.com) Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b1) for ; Thu, 30 Oct 2003 23:21:16 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: X-Mailer: Eudora [Macintosh version 6.1a2] Date: Thu, 30 Oct 2003 23:21:14 -0600 To: ietf-imapext@imc.org From: Pete Resnick Subject: Jabbering - imapext@ietf.xmpp.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Just to let folks know: I plan to "hang out" in the IMAPEXT room on the new jabber server that Marshall recently announced. Everyone should feel free to "hang out" or drop in for group related questions. -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UHnCkT075986 for ; Thu, 30 Oct 2003 09:49:12 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UHnC1V075985 for ietf-imapext-bks; Thu, 30 Oct 2003 09:49:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UHnBkT075979 for ; Thu, 30 Oct 2003 09:49:11 -0800 (PST) (envelope-from ned+imapext@innosoft.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01L2FM9SPCDS00D1EZ@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf-imapext@imc.org; Thu, 30 Oct 2003 09:49:11 -0800 (PST) Date: Thu, 30 Oct 2003 09:28:58 -0800 (PST) From: ned+imapext@INNOSOFT.COM Subject: IESG review of draft-ietf-imapext-condstore-04.txt To: IMAP extensions Mailing List Message-id: <01L2FOVDLGWI00D1EZ@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG reviewed this document today, and Ted Hardie has recorded the following discuss comments: ---- Section 3.2 says: Note: A client trying to make an atomic change to the state of a particular metadata item (or a set of metadata items) should be prepared to deal with the case when the server returns MODIFIED response code if the state of the metadata item being watched hasn't changed (but the state of some other metadata item has). This is necessary, because some servers don't store separate mod-sequences for different metadata items. However, a server implementation SHOULD avoid generating spurious MODIFIED responses for +FLAGS/-FLAGS STORE operations, even when the server stores a single mod-sequence per message. Upon the receipt of MODIFIED response code the client SHOULD try to figure out if the required metadata items have indeed changed. If they haven't the client SHOULD retry the command. First, this is a classic case of IMAP being so server focused as to make a client's life hell. In order to avoid keeping per-metadatum state, the protocol now forces client round trips to check that what it wants to change isn't the bit that has already been changed. While I won't challenge that design choice based on my own preference, I'm not sure that I believe "SHOULD try to figure out" is a realistic piece of protocol specification, and seeing it in a document about conditional storage makes my head hurt. Cleaning up the language so it is clear exactly what the client has to do would be useful. I also think the sentence "a server implementation SHOULD avoid generating spurious MODIFIED responses for +FLAGS/-FLAGS STORE operations, even when the server stores a single mod-sequence per message" doesn't make any sense. What is the server supposed to do here? Not send a modified response even though it knows something changed and doesn't know what, based on some extra-protocol knowledge? This doesn't seem like a win for interoperability. If it doesn't know what changed (because it is using a single mod-sequence) it's not spurious, just lame. I believe we normally have documents that update other RFCs mention that in the abstract, and since this does, it probably ought to. ---- Ned Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TNfnkT052344 for ; Wed, 29 Oct 2003 15:41:49 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TNfnaJ052338 for ietf-imapext-bks; Wed, 29 Oct 2003 15:41:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from sentosa.post1.com (sentosa.post1.com [202.27.17.100]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9TNfikT052305 for ; Wed, 29 Oct 2003 15:41:44 -0800 (PST) (envelope-from jseng@pobox.org.sg) Received: (qmail 42733 invoked from network); 30 Oct 2003 00:00:08 -0000 Received: from p5200-ipad75marunouchi.tokyo.ocn.ne.jp (HELO pobox.org.sg) (220.107.220.200) by sentosa.post1.com with SMTP; 30 Oct 2003 00:00:08 -0000 Message-ID: <3FA04E1E.9070906@pobox.org.sg> Date: Thu, 30 Oct 2003 07:32:46 +0800 From: James Seng User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: Mark Crispin CC: Abhijit Menon-Sen , ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, ietf-imapext@imc.org, ietf-smtp@imc.org Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) References: <00fd01c39ce8$b6f19fe0$79d52b09@DAVIS1> <014c01c39cf4$5675cd60$79d52b09@DAVIS1> <20031028095243.A1525@lustre.dyn.wiw.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > I do not believe that this is true for Chinese. AFAIK, Chinese primary > school kids use Latin script with hanyu-pinyin as a stopgap prior to their > mastery of Han script (which takes many years). Nope. Hanyu Pinyin was designed to replace the Han ideograph but it never did. > Note that when I say "recognize Latin script", I mean the ability to > determine that "dog" is a three-letter word that has the letters "d", "o", > and "g", each of which the individual recognizes and can name. This does > not include the ability to recognize that this refers to a domesticated > canine. Based on your reasonings, I think we should all reverted back to numbers, because that is the only universal recongizable set of symbols we have. We have this argument in IDN before and we certainly dont need this again. If you feel we should all stick to Latin, yes, you are entitled to your opinion but please do so in other place, and not here. The group is suppose to work on Internationalization of Email address (identifiers), not debate whether we need it or not. -James Seng Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TNfVkT052285 for ; Wed, 29 Oct 2003 15:41:31 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TNfVi5052280 for ietf-imapext-bks; Wed, 29 Oct 2003 15:41:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from sentosa.post1.com (sentosa.post1.com [202.27.17.100]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9TNfQkT052246 for ; Wed, 29 Oct 2003 15:41:26 -0800 (PST) (envelope-from jseng@pobox.org.sg) Received: (qmail 42705 invoked from network); 29 Oct 2003 23:59:48 -0000 Received: from p5200-ipad75marunouchi.tokyo.ocn.ne.jp (HELO pobox.org.sg) (220.107.220.200) by sentosa.post1.com with SMTP; 29 Oct 2003 23:59:48 -0000 Message-ID: <3FA04CA4.6050409@pobox.org.sg> Date: Thu, 30 Oct 2003 07:26:28 +0800 From: James Seng User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: Mark Crispin CC: Mark Davis , Keith Moore , dcrocker@brandenburg.com, paf@cisco.com, ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, IMAP Extensions WG , ietf-smtp@imc.org, presnick@qualcomm.com, hardie@qualcomm.com, ned.freed@mrochek.com Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA) References: <00fd01c39ce8$b6f19fe0$79d52b09@DAVIS1> <014c01c39cf4$5675cd60$79d52b09@DAVIS1> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Crispin, You need to get out of US (or Wsshington) more often. -James Seng > I am not convinced that it is possible to use a computer on the Internet > anywhere in the world without at least a basic acquaintance with Latin > script. > > I do not believe many individuals (other than primary school children) are > literate in their native language but are completely illiterate in Latin > script. This does not mean "being able to read or write the English > language"; rather, this simply means knowing the Latin script alphabet. > > Put another way, individuals who are completely illiterate in Latin script > are also likely to be illiterate in their native language script as well. > > No other script on the planet has such international recognition. > > There is undoubtably a *preference* for one's native script; and that > preference should be respected as much as possible. > > -- Mark -- > > http://staff.washington.edu/mrc > Science does not emerge from voting, party politics, or public debate. > Si vis pacem, para bellum. > > > > > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TNIvkT050958 for ; Wed, 29 Oct 2003 15:18:57 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TNIv96050957 for ietf-imapext-bks; Wed, 29 Oct 2003 15:18:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TNIqkT050926; Wed, 29 Oct 2003 15:18:52 -0800 (PST) (envelope-from michelsu@windows.microsoft.com) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 29 Oct 2003 15:18:49 -0800 Received: from 157.54.8.109 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 29 Oct 2003 15:18:49 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 29 Oct 2003 15:18:49 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 29 Oct 2003 15:19:48 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 29 Oct 2003 15:18:47 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [idn] FYI: BOF on Internationalized Email Addresses (IEA) Date: Wed, 29 Oct 2003 15:18:45 -0800 Message-ID: <84DD35E3DD87D5489AC42A59926DABE9046E700D@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [idn] FYI: BOF on Internationalized Email Addresses (IEA) thread-index: AcOc5UacENkLjcQgTxGePqP067EdhwBjOJ7A From: "Michel Suignard" To: "James Seng" , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: , , , , , , , , , "Pete Resnick" , "Ted Hardie" , "Ned Freed" X-OriginalArrivalTime: 29 Oct 2003 23:18:47.0668 (UTC) FILETIME=[014BD340:01C39E73] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9TNIqkU050935 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: JS>I seen John and Paul proposal but I have not seen Michel. Is there a draft that I can read JS>up? I don't have a proposal. I am listed there as a co-editor of the IRI spec which has a peripheral impact on the IEA (such as extending the URI mailto scheme). Like many I am listening with interest to the points made for or against the two proposals. Michel Suignard Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TLIakT045160 for ; Wed, 29 Oct 2003 13:18:36 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TLIaLf045157 for ietf-imapext-bks; Wed, 29 Oct 2003 13:18:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp1.andrew.cmu.edu (SMTP1.andrew.cmu.edu [128.2.10.81]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TLIZkT045147 for ; Wed, 29 Oct 2003 13:18:35 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9TLIaE7008121; Wed, 29 Oct 2003 16:18:36 -0500 Date: Wed, 29 Oct 2003 16:18:35 -0500 (EST) From: Rob Siemborski To: Cyrus Daboo cc: ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt In-Reply-To: <2147483647.1067444221@[10.0.1.5]> Message-ID: References: <200310131515.LAA10872@ietf.org> <2147483647.1067444221@[10.0.1.5]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 29 Oct 2003, Cyrus Daboo wrote: > | This version includes the change in the capability name as well as the > | revised base64 text. > > Minor point from the protocol police: the examples are all missing the > tagged OK for the CAPABILITY command. Oh! How embarrassing. Thanks, this will be fixed. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TLH1kT045063 for ; Wed, 29 Oct 2003 13:17:01 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TLH1go045062 for ietf-imapext-bks; Wed, 29 Oct 2003 13:17:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TLGxkT045055 for ; Wed, 29 Oct 2003 13:17:00 -0800 (PST) (envelope-from daboo@cyrusoft.com) Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [63.163.82.24]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id h9TL9HEG020889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2003 16:09:20 -0500 Date: Wed, 29 Oct 2003 16:17:01 -0500 From: Cyrus Daboo To: Rob Siemborski , ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt Message-ID: <2147483647.1067444221@[10.0.1.5]> In-Reply-To: References: <200310131515.LAA10872@ietf.org> X-Mailer: Mulberry/3.1.0b9 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Rob, --On Wednesday, October 29, 2003 16:02 -0500 Rob Siemborski wrote: | Since the ID editor apparently ate the update I tried to post to this | document, I have posted an updated version of it here: | | http://www.contrib.andrew.cmu.edu/~rjs3/ietf/draft-siemborski-imap-sasl-i | nitial-response-01b.txt | | This version includes the change in the capability name as well as the | revised base64 text. Minor point from the protocol police: the examples are all missing the tagged OK for the CAPABILITY command. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TL2VkT044405 for ; Wed, 29 Oct 2003 13:02:31 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TL2VsJ044404 for ietf-imapext-bks; Wed, 29 Oct 2003 13:02:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp1.andrew.cmu.edu (SMTP1.andrew.cmu.edu [128.2.10.81]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TL2UkT044397 for ; Wed, 29 Oct 2003 13:02:30 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from CYRUS.andrew.cmu.edu (CYRUS.andrew.cmu.edu [128.2.10.175]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9TL2WE7007334 for ; Wed, 29 Oct 2003 16:02:32 -0500 Date: Wed, 29 Oct 2003 16:02:30 -0500 (EST) From: Rob Siemborski To: ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt In-Reply-To: <200310131515.LAA10872@ietf.org> Message-ID: References: <200310131515.LAA10872@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 13 Oct 2003 Internet-Drafts@ietf.org wrote: > Title : IMAP Extension for SASL Initial Client Response > Author(s) : R. Siemborski > Filename : draft-siemborski-imap-sasl-initial-response-00.txt > Pages : 7 > Date : 2003-10-10 Since the ID editor apparently ate the update I tried to post to this document, I have posted an updated version of it here: http://www.contrib.andrew.cmu.edu/~rjs3/ietf/draft-siemborski-imap-sasl-initial-response-01b.txt This version includes the change in the capability name as well as the revised base64 text. So, who's coming to IETF-58? -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TGjSkT028908 for ; Wed, 29 Oct 2003 08:45:28 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TGjREH028907 for ietf-imapext-bks; Wed, 29 Oct 2003 08:45:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from relay-6m.club-internet.fr (relay-6m.club-internet.fr [194.158.104.45]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TGjMkT028887; Wed, 29 Oct 2003 08:45:22 -0800 (PST) (envelope-from jefsey@club-internet.fr) Received: from jfc2.club-internet.fr (f02v-21-20.d0.club-internet.fr [212.195.240.20]) by relay-6m.club-internet.fr (Postfix) with ESMTP id A66FC2567A; Wed, 29 Oct 2003 17:45:14 +0100 (CET) Message-Id: <6.0.0.22.2.20031029163607.04355ba0@mail.club-internet.fr> X-Sender: jefsey@mail.club-internet.fr X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 29 Oct 2003 16:50:39 +0100 To: Zefram From: "J-F C. (Jefsey) Morfin" Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) Cc: Dave Crocker , ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, ietf-imapext@imc.org, ietf-smtp@imc.org In-Reply-To: <20031028093114.GC20198@fysh.org> References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com> <12228881609.20031027074111@brandenburg.com> <20031027105222.4eae54fd.moore@cs.utk.edu> <355752681.20031027161925@brandenburg.com> <20031028093114.GC20198@fysh.org> Mime-Version: 1.0 Content-Type: text/plain; x-avg-checked=avg-ok-6A73736C; charset=us-ascii; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 10:31 28/10/03, Zefram said: >I think the first task in this area should be to investigate the nature >and degree of desire for non-ASCII local parts. This desire needs to be >weighed against the benefits we derive from writing all local parts in a >small, fixed alphabet (ASCII printables). May I ask which part of the world you come from? This being said only Americans want/are satisfied with "internationalized" (sic) names (the artificial extension of the American character set with most of the American foreign scripting, within an ascii frame). No one really wants multilingual names (a totally internationalized (sic) frame supporting languages and therefore some language oriented rules - at least ni management and user support). The users need vernacular support, that is to be able to freely do in the mail what they use to do elsewhere. I note that for non-American writers "international names" means names that everyone from every nation will understand. It happens to be the ascii character set limited to the DNS used names (they were selected for that reason). jfc Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T1fGI7016916 for ; Tue, 28 Oct 2003 17:41:16 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T1fGmp016915 for ietf-imapext-bks; Tue, 28 Oct 2003 17:41:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from [63.202.92.152] (adsl-66-125-125-69.dsl.pltn13.pacbell.net [66.125.125.69]) (authenticated bits=0) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T1f6I8016895; Tue, 28 Oct 2003 17:41:06 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Tue, 28 Oct 2003 17:41:55 -0800 To: Margaret.Wasserman@nokia.com, , , , , , , , , From: Paul Hoffman / IMC Subject: Location of the IMAA list (was: RE: FYI: BOF on Internationalized Email Addresses (IEA)) Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:54 AM -0500 10/28/03, Margaret.Wasserman@nokia.com wrote: >The BOF description lists imaa@imc.org as the >discussion list, but this discussion is being >cc:ed to ietf-imaa@imc.org. I'd suggest that you >move this discussion to whichever of those lists >is actually correct. It is ietf-imaa@imc.org, although because Patrik sent out the wrong address, I have made sure that both addresses work. An archive of the list, and links to the current versions of the drafts, can be found at . No more messages to all lists: that's what the IMAA list is for. --Paul Hoffman, Director --Internet Mail Consortium Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T08MI7012949 for ; Tue, 28 Oct 2003 16:08:22 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T08Mhv012948 for ietf-imapext-bks; Tue, 28 Oct 2003 16:08:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from hatl0ms21.CORP.COX.COM (lakehearnglobal.coxinc.com [206.157.224.254]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T08FI7012920; Tue, 28 Oct 2003 16:08:16 -0800 (PST) (envelope-from Valdis.Kletnieks@vt.edu) Received: from catl0ms22.corp.cox.com ([10.62.200.101]) by hatl0ms21.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Tue, 28 Oct 2003 19:08:13 -0500 Received: from mail pickup service by catl0ms22.corp.cox.com with Microsoft SMTPSVC; Tue, 28 Oct 2003 18:58:56 -0500 Received: from hatl0ms22.CORP.COX.COM ([10.62.201.69]) by catl0ms22.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 28 Oct 2003 16:35:02 -0500 Received: from bastion2.cox.com ([10.225.2.51]) by hatl0ms22.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Tue, 28 Oct 2003 16:28:31 -0500 Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by bastion2.cox.com (8.11.7p1+Sun/8.11.6) with SMTP id h9SLSRO10130; Tue, 28 Oct 2003 16:28:28 -0500 (EST) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1AEajF-0001VS-2l for ietf-list@asgard.ietf.org; Tue, 28 Oct 2003 15:46:13 -0500 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1AEa7u-00033N-AZ for ietf@asgard.ietf.org; Tue, 28 Oct 2003 15:07:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20519; Tue, 28 Oct 2003 15:07:26 -0500 (EST) From: Valdis.Kletnieks@vt.edu Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEa7s-0005if-00; Tue, 28 Oct 2003 15:07:36 -0500 Received: from turing-police.cc.vt.edu ([128.173.14.107]) by ietf-mx with esmtp (Exim 4.12) id 1AEa7r-0005iU-00; Tue, 28 Oct 2003 15:07:35 -0500 Received: from turing-police.cc.vt.edu (IDENT:valdis@localhost [127.0.0.1]) by turing-police.cc.vt.edu (8.12.10/8.12.10) with ESMTP id h9SK7J6P004972; Tue, 28 Oct 2003 15:07:19 -0500 Message-Id: <200310282007.h9SK7J6P004972@turing-police.cc.vt.edu> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4+dev To: Mark Davis Cc: Mark Crispin , Keith Moore , dcrocker@brandenburg.com, paf@cisco.com, ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, IMAP Extensions WG , ietf-smtp@imc.org, presnick@qualcomm.com, hardie@qualcomm.com, ned.freed@mrochek.com Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA) In-Reply-To: Your message of "Mon, 27 Oct 2003 17:39:32 PST." <014c01c39cf4$5675cd60$79d52b09@DAVIS1> References: <00fd01c39ce8$b6f19fe0$79d52b09@DAVIS1> <014c01c39cf4$5675cd60$79d52b09@DAVIS1> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1503687178P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Tue, 28 Oct 2003 15:07:19 -0500 X-OriginalArrivalTime: 28 Oct 2003 21:28:31.0955 (UTC) FILETIME=[6F9C6230:01C39D9A] Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --==_Exmh_-1503687178P Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, 27 Oct 2003 17:39:32 PST, Mark Davis said: > email addresses. Mr. Tanaka can have one with Latin letters and one wit= h > Japanese (e.g. =E3=83=A0=E3=83=AB=E3=82=AF@=E3=82=AB=E3=82=AF.=E3=83=AF= =E3=82=B7=E3=83=B3=E3=82=B0=E3=83=88=E3=83=B3.=E3=82=A8=E3=83=87=E3=82=A5= ). This gets interesting in the context of a "reply all". Apologies for breaking the UTF-8 in the quote, but it's illustrative - if= the breakage had been in the To/Cc lines, things would have broken even worse= unless whatever scheme we end up using is ASCII-transparent. --==_Exmh_-1503687178P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQE/nsx3cC3lWbTT17ARAlD1AKC74t7EwonvMVVb4YcOTjs6cE9mCwCfX9xR fx4FhsH1KZDlHM6R8Ip+I+A= =61XB -----END PGP SIGNATURE----- --==_Exmh_-1503687178P-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SNH9I7011150 for ; Tue, 28 Oct 2003 15:17:09 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SNH92m011149 for ietf-imapext-bks; Tue, 28 Oct 2003 15:17:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from hatl0ms21.CORP.COX.COM (lakehearnglobal.coxinc.com [206.157.224.254]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SNH5I7011103; Tue, 28 Oct 2003 15:17:05 -0800 (PST) (envelope-from klensin@jck.com) Received: from CATL0MS81.corp.cox.com ([10.62.200.231]) by hatl0ms21.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Tue, 28 Oct 2003 18:16:29 -0500 Received: from mail pickup service by CATL0MS81.corp.cox.com with Microsoft SMTPSVC; Tue, 28 Oct 2003 18:16:28 -0500 Received: from hatl0ms23.corp.cox.com ([10.64.200.56]) by catl0ms23.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 28 Oct 2003 15:52:19 -0500 Received: from bastion2.cox.com ([10.225.2.51]) by hatl0ms23.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 28 Oct 2003 15:37:56 -0500 Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by bastion2.cox.com (8.11.7p1+Sun/8.11.6) with SMTP id h9SKbmv16600; Tue, 28 Oct 2003 15:37:49 -0500 (EST) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1AEZlm-0004nU-3B for ietf-list@asgard.ietf.org; Tue, 28 Oct 2003 14:44:46 -0500 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1AEXlX-00008u-Kd for ietf@asgard.ietf.org; Tue, 28 Oct 2003 12:36:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11141; Tue, 28 Oct 2003 12:36:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEXlV-0002Hm-00; Tue, 28 Oct 2003 12:36:22 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx with esmtp (Exim 4.12) id 1AEXlV-0002Hi-00; Tue, 28 Oct 2003 12:36:21 -0500 Received: from bs.jck.com ([209.187.148.211] helo=localhost) by bs.jck.com with esmtp (Exim 4.10) id 1AEXlK-000NIP-00; Tue, 28 Oct 2003 12:36:11 -0500 Date: Tue, 28 Oct 2003 12:36:07 -0500 From: John C Klensin To: Marc Blanchet , Mark Davis , Mark Crispin , Abhijit Menon-Sen cc: "ietf-imaa@imc.org" , "idn@ops.ietf.org" , "ietf-822@imc.org" , "ietf@ietf.org" , "ietf-pop3ext@imc.org" , "lemonade@ietf.org" , "discuss@apps.ietf.org" , "ietf-imapext@imc.org" , "ietf-smtp@imc.org" Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA) Message-ID: <12344770.1067344567@KLENSIN-TP> In-Reply-To: <280960000.1067357574@classic.viagenie.qc.ca> References: <00fd01c39ce8$b6f19fe0$79d52b09@DAVIS1> <014c01c39cf4$5675cd60$79d52b09@DAVIS1> <20031028095243.A1525@lustre.dyn.wiw.org> <00a001c39d65$b23177f0$7900a8c0@DAVIS1> <280960000.1067357574@classic.viagenie.qc.ca> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Oct 2003 20:37:57.0507 (UTC) FILETIME=[5EF05D30:01C39D93] Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Tuesday, October 28, 2003 11:12 -0500 Marc Blanchet wrote: > it appears to me that this thread is not very different from > the idn considerations on usage of idn in the world. So what > is really new in this discussion? See the draft. Quick answer: DNS interfaces really exist at the protocol level, and a large part of the hypothesis behind IDNA was that it would be possible, after we had enough implementations, to prevent an end-user from ever seeing an encoded domain name. That story just doesn't hold for a special encoding-based (aka MUA-only) email local part implementation, and maybe not for email generally. For example, under current rules, an MTA is required to stuff the name it actually sees in HELO/EHLO and the MAIL command into various headers. If it is expected to notice that they have special encodings and decodes them, we've gone rather far into "the infrastructure is involved", even if the actual on-the-wire transport is not impacted. If it doesn't do that, the encodings --both the IDNA domain parts and the special mail encoding-- are going to be in the user's face, in the most literal sense of that term. The similarity of that situation to the early IDN discussions is the importance of the "what problem are you solving" question. And it is very clear to me that, for email addresses, the answer has got to "user sees their own characters in their email addresses and the email addresses of those whose languages they speak/ recognize. Users typically don't actually see envelopes. But seeing, e.g., different forms/codings of an address in the header "From:" field than appears in "Return-path:" or than appears in a signature line in the message body, is going to create real unhappiness. Similarly as has been pointed out in another context, seeing an address in different from when it appears in a header than when it (and that header) are encapsulated in a message/?? body part is just not going to amuse any user to whom we've said "ok, now you have i18n strings, enjoy your new found local language capabilities". And I guess that tells you what I think the problem is that we need to solve. YMMD. john Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SK7eI7002513 for ; Tue, 28 Oct 2003 12:07:40 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SK7eQW002512 for ietf-imapext-bks; Tue, 28 Oct 2003 12:07:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from turing-police.cc.vt.edu (turing-police.cc.vt.edu [128.173.14.107]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SK7bI7002497; Tue, 28 Oct 2003 12:07:37 -0800 (PST) (envelope-from Valdis.Kletnieks@vt.edu) Received: from turing-police.cc.vt.edu (IDENT:valdis@localhost [127.0.0.1]) by turing-police.cc.vt.edu (8.12.10/8.12.10) with ESMTP id h9SK7J6P004972; Tue, 28 Oct 2003 15:07:19 -0500 Message-Id: <200310282007.h9SK7J6P004972@turing-police.cc.vt.edu> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4+dev To: Mark Davis Cc: Mark Crispin , Keith Moore , dcrocker@brandenburg.com, paf@cisco.com, ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, IMAP Extensions WG , ietf-smtp@imc.org, presnick@qualcomm.com, hardie@qualcomm.com, ned.freed@mrochek.com Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA) In-Reply-To: Your message of "Mon, 27 Oct 2003 17:39:32 PST." <014c01c39cf4$5675cd60$79d52b09@DAVIS1> From: Valdis.Kletnieks@vt.edu References: <00fd01c39ce8$b6f19fe0$79d52b09@DAVIS1> <014c01c39cf4$5675cd60$79d52b09@DAVIS1> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1503687178P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Tue, 28 Oct 2003 15:07:19 -0500 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --==_Exmh_-1503687178P Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, 27 Oct 2003 17:39:32 PST, Mark Davis said: > email addresses. Mr. Tanaka can have one with Latin letters and one wit= h > Japanese (e.g. =E3=83=A0=E3=83=AB=E3=82=AF@=E3=82=AB=E3=82=AF.=E3=83=AF= =E3=82=B7=E3=83=B3=E3=82=B0=E3=83=88=E3=83=B3.=E3=82=A8=E3=83=87=E3=82=A5= ). This gets interesting in the context of a "reply all". Apologies for breaking the UTF-8 in the quote, but it's illustrative - if= the breakage had been in the To/Cc lines, things would have broken even worse= unless whatever scheme we end up using is ASCII-transparent. --==_Exmh_-1503687178P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQE/nsx3cC3lWbTT17ARAlD1AKC74t7EwonvMVVb4YcOTjs6cE9mCwCfX9xR fx4FhsH1KZDlHM6R8Ip+I+A= =61XB -----END PGP SIGNATURE----- --==_Exmh_-1503687178P-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SJ02I7099534 for ; Tue, 28 Oct 2003 11:00:02 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SJ02A0099531 for ietf-imapext-bks; Tue, 28 Oct 2003 11:00:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SJ01I7099526 for ; Tue, 28 Oct 2003 11:00:01 -0800 (PST) (envelope-from jeffstep@exchange.microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 28 Oct 2003 11:00:02 -0800 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 28 Oct 2003 11:00:02 -0800 Received: from df-muttley.platinum.corp.microsoft.com ([10.197.1.66]) by DF-BEG.platinum.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 28 Oct 2003 11:00:02 -0800 Received: from df-benji.platinum.corp.microsoft.com ([10.197.0.89]) by df-muttley.platinum.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 28 Oct 2003 11:00:01 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7112.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Exchange server has a broken SASL implementation Date: Tue, 28 Oct 2003 11:00:01 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Exchange server has a broken SASL implementation Thread-Index: AcOcsrFYHGy95BGDR+agHFpyl8JBeQA0Ry3w From: "Jeff Stephenson" To: "IMAP Interest List" , "IMAP Extensions WG" X-OriginalArrivalTime: 28 Oct 2003 19:00:01.0541 (UTC) FILETIME=[B0971B50:01C39D85] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9SJ02I7099527 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Actually, Exchange didn't get around to implementing this recently - it's been in Windows 2000 SMTP (which is what Exchange uses) since the release of Windows 2K. I'm dredging my memory here, but I believe that the code for this was locked down during the ID stage of RFC 2554, before the RFC was released. As I recall, it was interop-tested at the time, but there wasn't a lot to test against and I don't recall the results. I've passed this along to the Exchange folks, who say it's a known issue that wasn't fixed when discovered out of fear of breaking anything that might have relied on this behavior. If this behavior is breaking other apps, that would increase the impetus to fix it. -- jeff Jeff Stephenson Software Developer Microsoft Outlook > -----Original Message----- > From: Ken Murchison > Subject: Re: Exchange server has a broken SASL implementation ... > However, if there is/was any question about the specs, there > are mailing lists that can be contacted for clarification. > Interop testing could be done with non-MS products. The CMU > SASL library comes with test harnesses which can be used for > testing. There are at least 2 major MTAs (sendmail, postfix) > which use CMU SASL that could have been consulted for comparison. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SHaNI7096288 for ; Tue, 28 Oct 2003 09:36:23 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SHaMpH096287 for ietf-imapext-bks; Tue, 28 Oct 2003 09:36:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SHaII7096263; Tue, 28 Oct 2003 09:36:18 -0800 (PST) (envelope-from klensin@jck.com) Received: from bs.jck.com ([209.187.148.211] helo=localhost) by bs.jck.com with esmtp (Exim 4.10) id 1AEXlK-000NIP-00; Tue, 28 Oct 2003 12:36:11 -0500 Date: Tue, 28 Oct 2003 12:36:07 -0500 From: John C Klensin To: Marc Blanchet , Mark Davis , Mark Crispin , Abhijit Menon-Sen cc: "ietf-imaa@imc.org" , "idn@ops.ietf.org" , "ietf-822@imc.org" , "ietf@ietf.org" , "ietf-pop3ext@imc.org" , "lemonade@ietf.org" , "discuss@apps.ietf.org" , "ietf-imapext@imc.org" , "ietf-smtp@imc.org" Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA) Message-ID: <12344770.1067344567@KLENSIN-TP> In-Reply-To: <280960000.1067357574@classic.viagenie.qc.ca> References: <00fd01c39ce8$b6f19fe0$79d52b09@DAVIS1> <014c01c39cf4$5675cd60$79d52b09@DAVIS1> <20031028095243.A1525@lustre.dyn.wiw.org> <00a001c39d65$b23177f0$7900a8c0@DAVIS1> <280960000.1067357574@classic.viagenie.qc.ca> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Tuesday, October 28, 2003 11:12 -0500 Marc Blanchet wrote: > it appears to me that this thread is not very different from > the idn considerations on usage of idn in the world. So what > is really new in this discussion? See the draft. Quick answer: DNS interfaces really exist at the protocol level, and a large part of the hypothesis behind IDNA was that it would be possible, after we had enough implementations, to prevent an end-user from ever seeing an encoded domain name. That story just doesn't hold for a special encoding-based (aka MUA-only) email local part implementation, and maybe not for email generally. For example, under current rules, an MTA is required to stuff the name it actually sees in HELO/EHLO and the MAIL command into various headers. If it is expected to notice that they have special encodings and decodes them, we've gone rather far into "the infrastructure is involved", even if the actual on-the-wire transport is not impacted. If it doesn't do that, the encodings --both the IDNA domain parts and the special mail encoding-- are going to be in the user's face, in the most literal sense of that term. The similarity of that situation to the early IDN discussions is the importance of the "what problem are you solving" question. And it is very clear to me that, for email addresses, the answer has got to "user sees their own characters in their email addresses and the email addresses of those whose languages they speak/ recognize. Users typically don't actually see envelopes. But seeing, e.g., different forms/codings of an address in the header "From:" field than appears in "Return-path:" or than appears in a signature line in the message body, is going to create real unhappiness. Similarly as has been pointed out in another context, seeing an address in different from when it appears in a header than when it (and that header) are encapsulated in a message/?? body part is just not going to amuse any user to whom we've said "ok, now you have i18n strings, enjoy your new found local language capabilities". And I guess that tells you what I think the problem is that we need to solve. YMMD. john Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SGMhI7092036 for ; Tue, 28 Oct 2003 08:22:43 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SGMh5W092030 for ietf-imapext-bks; Tue, 28 Oct 2003 08:22:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from w1309.hostcentric.net (w1309.hostcentric.net [66.40.78.254]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9SGMcI7092008 for ; Tue, 28 Oct 2003 08:22:39 -0800 (PST) (envelope-from mark.davis@jtcsv.com) Received: (qmail 2789 invoked by alias); 28 Oct 2003 16:22:38 -0000 Received: from unknown (HELO DAVIS1) (12.235.201.242) by 0 with SMTP; 28 Oct 2003 16:22:38 -0000 Message-ID: <00fb01c39d6f$b46cdd70$7900a8c0@DAVIS1> From: "Mark Davis" To: "Marc Blanchet" , "Mark Crispin" , "Abhijit Menon-Sen" Cc: , , , , , , , , References: <00fd01c39ce8$b6f19fe0$79d52b09@DAVIS1> <014c01c39cf4$5675cd60$79d52b09@DAVIS1> <20031028095243.A1525@lustre.dyn.wiw.org> <00a001c39d65$b23177f0$7900a8c0@DAVIS1> <280960000.1067357574@classic.viagenie.qc.ca> Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA) Date: Tue, 28 Oct 2003 08:22:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I wouldn't have thought so either, but at least some people questioned the need for non-Latin characters, and went so far as to exclude them from a proposed problem statement: > ... There is a growing need to use additional > characters, specifically Latin characters with diacriticals and non-Latin > characters, in email addresses to better serve the needs of the > multi-national Internet community... Mark __________________________________ http://www.macchiato.com â–º शिषà¥à¤¯à¤¾à¤¦à¤¿à¤šà¥à¤›à¥‡à¤¤à¥à¤ªà¤°à¤¾à¤œà¤¯à¤®à¥ â—„ ----- Original Message ----- From: "Marc Blanchet" To: "Mark Davis" ; "Mark Crispin" ; "Abhijit Menon-Sen" Cc: ; ; ; ; ; ; ; ; Sent: Tue, 2003 Oct 28 08:12 Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA) > > it appears to me that this thread is not very different from the idn > considerations on usage of idn in the world. So what is really new in this > discussion? > > Marc. > > -- Tuesday, October 28, 2003 07:10:59 -0800 Mark Davis > wrote/a ecrit: > > >> > (I agree that it's currently nearly impossible to use computers if one > >> > isn't familiar with the Latin script, of course.) > >> > >> Which probably makes the rest of this discussion academic, unless we're > >> going to undertake solving *that* problem for Microsoft and the various > >> UNIX/Linux vendors... > > > > It is currently impossible to use the Internet without knowing the Latin > > script. However, the goal of most well-designed client software and > > operating systems is to permit the user to work entirely within their > > native language, with a fully localized system. This is reaching to India > > and other countries; Microsoft has introduced fully localized versions of > > Indic Windows just recently, and Linux vendors are hard at work to > > produce fully localized versions of their software. > > > > Email and Web addresses are the big remaining holdouts for most people. > > People should not be forced to use a script that they are unfamiliar > > with, just to use email addresses and sites in their own countries. Even > > if they are familiar with the Latin script, it is very often a very bad > > match for their languages, making it very difficult to figure out how > > native words would be spelled in it. > > > > Mark > > > > > > ------------------------------------------ > Marc Blanchet > Hexago > tel: +1-418-266-5533x225 > ------------------------------------------ > http://www.freenet6.net: IPv6 connectivity > ------------------------------------------ > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SGEnI7091339 for ; Tue, 28 Oct 2003 08:14:49 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SGEnxK091338 for ietf-imapext-bks; Tue, 28 Oct 2003 08:14:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from panoramix.hexago.com ([209.71.226.3]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SGEjI7091273; Tue, 28 Oct 2003 08:14:45 -0800 (PST) (envelope-from Marc.Blanchet@viagenie.qc.ca) Received: from localhost (retro.viagenie.qc.ca [IPv6:3ffe:b00:c18:3::22]) (authenticated bits=0) by panoramix.hexago.com (8.12.8/8.12.8) with ESMTP id h9SGD66r006992; Tue, 28 Oct 2003 11:13:14 -0500 (EST) Date: Tue, 28 Oct 2003 11:12:54 -0500 From: Marc Blanchet To: Mark Davis , Mark Crispin , Abhijit Menon-Sen cc: ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, ietf-imapext@imc.org, ietf-smtp@imc.org Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA) Message-ID: <280960000.1067357574@classic.viagenie.qc.ca> In-Reply-To: <00a001c39d65$b23177f0$7900a8c0@DAVIS1> References: <00fd01c39ce8$b6f19fe0$79d52b09@DAVIS1> <014c01c39cf4$5675cd60$79d52b09@DAVIS1> <20031028095243.A1525@lustre.dyn.wiw.org> <00a001c39d65$b23177f0$7900a8c0@DAVIS1> X-Mailer: Mulberry/3.1.0b9 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: it appears to me that this thread is not very different from the idn considerations on usage of idn in the world. So what is really new in this discussion? Marc. -- Tuesday, October 28, 2003 07:10:59 -0800 Mark Davis wrote/a ecrit: >> > (I agree that it's currently nearly impossible to use computers if one >> > isn't familiar with the Latin script, of course.) >> >> Which probably makes the rest of this discussion academic, unless we're >> going to undertake solving *that* problem for Microsoft and the various >> UNIX/Linux vendors... > > It is currently impossible to use the Internet without knowing the Latin > script. However, the goal of most well-designed client software and > operating systems is to permit the user to work entirely within their > native language, with a fully localized system. This is reaching to India > and other countries; Microsoft has introduced fully localized versions of > Indic Windows just recently, and Linux vendors are hard at work to > produce fully localized versions of their software. > > Email and Web addresses are the big remaining holdouts for most people. > People should not be forced to use a script that they are unfamiliar > with, just to use email addresses and sites in their own countries. Even > if they are familiar with the Latin script, it is very often a very bad > match for their languages, making it very difficult to figure out how > native words would be spelled in it. > > Mark > ------------------------------------------ Marc Blanchet Hexago tel: +1-418-266-5533x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SFB5I7086579 for ; Tue, 28 Oct 2003 07:11:05 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SFB5bp086575 for ietf-imapext-bks; Tue, 28 Oct 2003 07:11:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from w1309.hostcentric.net (w1309.hostcentric.net [66.40.78.254]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9SFB0I7086537 for ; Tue, 28 Oct 2003 07:11:00 -0800 (PST) (envelope-from mark.davis@jtcsv.com) Received: (qmail 31822 invoked by alias); 28 Oct 2003 15:10:59 -0000 Received: from unknown (HELO DAVIS1) (12.235.201.242) by 0 with SMTP; 28 Oct 2003 15:10:59 -0000 Message-ID: <00a001c39d65$b23177f0$7900a8c0@DAVIS1> From: "Mark Davis" To: "Mark Crispin" , "Abhijit Menon-Sen" Cc: , , , , , , , , References: <00fd01c39ce8$b6f19fe0$79d52b09@DAVIS1> <014c01c39cf4$5675cd60$79d52b09@DAVIS1> <20031028095243.A1525@lustre.dyn.wiw.org> Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) Date: Tue, 28 Oct 2003 07:10:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > (I agree that it's currently nearly impossible to use computers if one > > isn't familiar with the Latin script, of course.) > > Which probably makes the rest of this discussion academic, unless we're > going to undertake solving *that* problem for Microsoft and the various > UNIX/Linux vendors... It is currently impossible to use the Internet without knowing the Latin script. However, the goal of most well-designed client software and operating systems is to permit the user to work entirely within their native language, with a fully localized system. This is reaching to India and other countries; Microsoft has introduced fully localized versions of Indic Windows just recently, and Linux vendors are hard at work to produce fully localized versions of their software. Email and Web addresses are the big remaining holdouts for most people. People should not be forced to use a script that they are unfamiliar with, just to use email addresses and sites in their own countries. Even if they are familiar with the Latin script, it is very often a very bad match for their languages, making it very difficult to figure out how native words would be spelled in it. Mark Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SEspI7085643 for ; Tue, 28 Oct 2003 06:54:51 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SEspVG085639 for ietf-imapext-bks; Tue, 28 Oct 2003 06:54:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from w1309.hostcentric.net (w1309.hostcentric.net [66.40.78.254]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9SEskI7085608 for ; Tue, 28 Oct 2003 06:54:46 -0800 (PST) (envelope-from mark.davis@jtcsv.com) Received: (qmail 23826 invoked by alias); 28 Oct 2003 14:54:45 -0000 Received: from unknown (HELO DAVIS1) (12.235.201.242) by 0 with SMTP; 28 Oct 2003 14:54:45 -0000 Message-ID: <006b01c39d63$6d928d70$7900a8c0@DAVIS1> From: "Mark Davis" To: "Stephane Bortzmeyer" Cc: "Mark Crispin" , "Keith Moore" , , , , , , , , , , "IMAP Extensions WG" , , , , References: <00fd01c39ce8$b6f19fe0$79d52b09@DAVIS1> <014c01c39cf4$5675cd60$79d52b09@DAVIS1> <20031028085023.GB6617@nic.fr> Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA) Date: Tue, 28 Oct 2003 06:54:45 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0068_01C39D20.5EDF9090" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0068_01C39D20.5EDF9090 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sigh. I used "Greek" in an analogy because I was hoping that some of the = Latin-only folks out there would at least recognize the name of one = other script. But how comforable would you really be, if = =D9=8A=D9=8F=D9=8F =D9=88=D9=90=D8=B1=D9=90 = =D9=81=D9=8F=D8=B1=D8=B3=D9=90=D8=AF =D8=AA=D9=8F = =D8=B1=D9=8E=D9=90=D8=AF =D9=8E=D9=86 = =D9=90=D9=86=D8=AA=D9=90=D8=B1=D9=90=D9=84=D9=8A = =D8=AF=D9=90=D9=81=D9=81=D9=90=D8=B1=D9=90=D9=86=D8=AA = =D8=B3=D9=83=D8=B1=D9=90=D9=BE=D8=AA=D8=8C = =D8=B3=D9=90=D9=85=D9=BE=D9=84=D9=8A =D8=AA=D9=8F = =D9=8F=D9=86=D8=AF=D9=90=D8=B1=D8=B3=D8=AA=D9=8E=D9=86=D8=AF = =D9=90=D9=85=D9=8E=D9=90=D9=84 = =D9=8E=D8=AF=D8=AF=D8=B1=D9=90=D8=B3=D8=B3=D9=90=D8=B3=D8=8C = =D9=8E=D9=86=D8=AF =D9=8E =D8=B3=D9=83=D8=B1=D9=90=D9=BE=D8=AA = =D8=AA=D9=87=D9=8E=D8=AA =D9=83=D9=8F=D9=8F=D9=84=D8=AF = =D9=8F=D9=86=D9=84=D9=8A = =D9=BE=D9=8E=D8=B1=D8=AA=D9=8E=D9=90=D9=84=D9=84=D9=8A = =D8=B1=D9=90=D9=81=D9=84=D9=90=D9=83=D8=AA =D8=AA=D9=87=D9=90 = =D8=B1=D9=8E=D9=90=D9=84 = =D8=B3=D9=BE=D9=90=D9=84=D9=84=D9=90=D9=86=DA=AF =D9=8F=D9=81 = =D9=8A=D9=8F=D9=8F=D8=B1 =D9=88=D9=8F=D8=B1=D8=AF=D8=B3? Mark __________________________________ =20 ----- Original Message -----=20 From: "Stephane Bortzmeyer" To: "Mark Davis" Cc: "Mark Crispin" ; "Keith Moore" = ; ; ; = ; ; ; = ; ; ; = ; "IMAP Extensions WG" ; = ; ; ; = Sent: Tue, 2003 Oct 28 00:50 Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses = (IEA) > On Mon, Oct 27, 2003 at 05:39:32PM -0800, > Mark Davis wrote=20 > a message of 76 lines which said: >=20 > > We should remember that for a great many people in the world, Latin = letters are > > quite unnatural; it'd be a bit like if we had to use Greek letters = in all email > > addresses.=20 >=20 > It would be a bit like if we had to use Greek letters in mathematics > :-) >=20 > ------=_NextPart_000_0068_01C39D20.5EDF9090 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Sigh. I used "Greek" in an analogy = because I=20 was hoping that some of the Latin-only folks out there would at least=20 recognize the name of one other script. But how comforable = would you=20 really be, if =D9=8A=D9=8F=D9=8F =D9=88=D9=90=D8=B1=D9=90 = =D9=81=D9=8F=D8=B1=D8=B3=D9=90=D8=AF =D8=AA=D9=8F = =D8=B1=D9=8E=D9=90=D8=AF =D9=8E=D9=86 = =D9=90=D9=86=D8=AA=D9=90=D8=B1=D9=90=D9=84=D9=8A = =D8=AF=D9=90=D9=81=D9=81=D9=90=D8=B1=D9=90=D9=86=D8=AA = =D8=B3=D9=83=D8=B1=D9=90=D9=BE=D8=AA=D8=8C = =D8=B3=D9=90=D9=85=D9=BE=D9=84=D9=8A =D8=AA=D9=8F=20 =D9=8F=D9=86=D8=AF=D9=90=D8=B1=D8=B3=D8=AA=D9=8E=D9=86=D8=AF = =D9=90=D9=85=D9=8E=D9=90=D9=84 = =D9=8E=D8=AF=D8=AF=D8=B1=D9=90=D8=B3=D8=B3=D9=90=D8=B3=D8=8C = =D9=8E=D9=86=D8=AF =D9=8E =D8=B3=D9=83=D8=B1=D9=90=D9=BE=D8=AA = =D8=AA=D9=87=D9=8E=D8=AA =D9=83=D9=8F=D9=8F=D9=84=D8=AF = =D9=8F=D9=86=D9=84=D9=8A = =D9=BE=D9=8E=D8=B1=D8=AA=D9=8E=D9=90=D9=84=D9=84=D9=8A = =D8=B1=D9=90=D9=81=D9=84=D9=90=D9=83=D8=AA =D8=AA=D9=87=D9=90=20 =D8=B1=D9=8E=D9=90=D9=84 = =D8=B3=D9=BE=D9=90=D9=84=D9=84=D9=90=D9=86=DA=AF =D9=8F=D9=81 = =D9=8A=D9=8F=D9=8F=D8=B1 =D9=88=D9=8F=D8=B1=D8=AF=D8=B3?

Mark
__________________________________

 <= /DIV>
----- Original Message -----
From: "Stephane Bortzmeyer" <bortzmeyer@nic.fr>
To: "Mark Davis" <mark.davis@jtcsv.com>
Cc: "Mark Crispin" <MRC@CAC.Washington.EDU>; "Keith = Moore"=20 <moore@cs.utk.edu>; <dcrocker@brandenburg.com>; = <paf@cisco.com>; <ietf-imaa@imc.org>; <idn@ops.ietf.org>; <ietf-822@imc.org>; <ietf@ietf.org>; <ietf-pop3ext@imc.org>; = <lemonade@ietf.org>; <discuss@apps.ietf.org>; "IMAP = Extensions WG"=20 <ietf-imapext@imc.org>; = <ietf-smtp@imc.org>; <presnick@qualcomm.com>; = <hardie@qualcomm.com>; = <ned.freed@mrochek.com>
Sent: Tue, 2003 Oct 28 00:50
Subject: Re: [idn] Re: FYI: BOF on Internationalized = Email=20 Addresses (IEA)

> On Mon, Oct 27, = 2003 at=20 05:39:32PM -0800,
>  Mark Davis <mark.davis@jtcsv.com> wrote =
>  a=20 message of 76 lines which said:
>
> > We should remember = that=20 for a great many people in the world, Latin letters are
> > = quite=20 unnatural; it'd be a bit like if we had to use Greek letters in all=20 email
> > addresses.
>
> It would be a bit like = if we had=20 to use Greek letters in mathematics
> :-)
>
>=20 ------=_NextPart_000_0068_01C39D20.5EDF9090-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SABtI7071606 for ; Tue, 28 Oct 2003 02:11:55 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SABtK7071605 for ietf-imapext-bks; Tue, 28 Oct 2003 02:11:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from melkebalanse.gulbrandsen.priv.no (melkebalanse.gulbrandsen.priv.no [217.19.171.131]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SABlI7071585; Tue, 28 Oct 2003 02:11:51 -0800 (PST) (envelope-from arnt@gulbrandsen.priv.no) Message-Id: From: Arnt Gulbrandsen To: Mark Crispin Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) Cc: ietf@ietf.org, lemonade@ietf.org, IETF RFC-822 list , IMAA list , IMAP Extensions WG , ietf-pop3ext@imc.org, ietf-smtp@imc.org, Abhijit Menon-Sen , discuss@apps.ietf.org, IETF/IDN WG References: <00fd01c39ce8$b6f19fe0$79d52b09@DAVIS1> <014c01c39cf4$5675cd60$79d52b09@DAVIS1> <20031028095243.A1525@lustre.dyn.wiw.org> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Tue, 28 Oct 2003 11:15:17 +0100 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: > On Tue, 28 Oct 2003, Abhijit Menon-Sen wrote: >> (I agree that it's currently nearly impossible to use computers if >> one isn't familiar with the Latin script, of course.) > > Which probably makes the rest of this discussion academic, unless > we're going to undertake solving *that* problem for Microsoft and the > various UNIX/Linux vendors... You're not appreciating the full complexity of the problem. ;) Not only should the email standards permit MUAs and MTAs of the year 2020 to solve the problem Abhijit mentions, but they should even permit such future programs to interoperate with latinate ones of the present and near future. And if it's too hard for latinate MUAs to implement the IEA standard, that won't happen. --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S9dsI7070478 for ; Tue, 28 Oct 2003 01:39:54 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9S9dsXL070477 for ietf-imapext-bks; Tue, 28 Oct 2003 01:39:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S9drI7070465; Tue, 28 Oct 2003 01:39:53 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h9S9jrf12762; Tue, 28 Oct 2003 01:45:54 -0800 Date: Tue, 28 Oct 2003 01:13:50 -0800 From: Dave Crocker X-Mailer: The Bat! (v2.00.22) Reply-To: dcrocker@brandenburg.com Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <2337816887.20031028011350@brandenburg.com> To: Pete Resnick CC: ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, , , , , Dave Crocker Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) In-Reply-To: References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com> <12228881609.20031027074111@brandenburg.com> <20031027105222.4eae54fd.moore@cs.utk.edu> <355752681.20031027161925@brandenburg.com> <16285.48493.496028.516294@moriarty.gnomon.org.uk> <14814332829.20031027184226@brandenburg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Pete, >>RB> Restricting the disucssion to local-parts runs the risk of excluding >>RB> other potentially relevent issues. PR> I agree. Limiting discussion at this point to local-part does not PR> take into account some of the possibilities. That was exactly the intent of the text. We have already seen how nicely the text served to bring into pretty stark relief one bit of expectation from one of the proposals. It is only fitting to have it serve the same purpose for another one. IETF BOF time is pretty lousy for an open-ended chat. Having specifications to chat about is only marginally better than not having them. What makes the real difference is having serious focus to the meeting. If we go into this meeting without even having a clear sense of the scope of the problem to be tackled, then the chance of having a productive meeting is pretty small. At the moment, it appears that the focus of the meeting is likely to be: Shall we break existing Internet mail or shall we lay an enhancement on top of it that preserves the installed base. (I'm sure that everyone else who was present at the pre-MIME/ESMTP discussions is really looking forward to repeating the experience.) d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S8pFI7057432 for ; Tue, 28 Oct 2003 00:51:15 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9S8pF4N057431 for ietf-imapext-bks; Tue, 28 Oct 2003 00:51:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S8pCI7057400; Tue, 28 Oct 2003 00:51:13 -0800 (PST) (envelope-from bortzmeyer@nic.fr) Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id h9S8oNQW1526872; Tue, 28 Oct 2003 09:50:23 +0100 (CET) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 5FF63FF47; Tue, 28 Oct 2003 09:50:23 +0100 (CET) Date: Tue, 28 Oct 2003 09:50:23 +0100 From: Stephane Bortzmeyer To: Mark Davis Cc: Mark Crispin , Keith Moore , dcrocker@brandenburg.com, paf@cisco.com, ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, IMAP Extensions WG , ietf-smtp@imc.org, presnick@qualcomm.com, hardie@qualcomm.com, ned.freed@mrochek.com Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA) Message-ID: <20031028085023.GB6617@nic.fr> References: <00fd01c39ce8$b6f19fe0$79d52b09@DAVIS1> <014c01c39cf4$5675cd60$79d52b09@DAVIS1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <014c01c39cf4$5675cd60$79d52b09@DAVIS1> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.21-3-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.4i Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, Oct 27, 2003 at 05:39:32PM -0800, Mark Davis wrote a message of 76 lines which said: > We should remember that for a great many people in the world, Latin letters are > quite unnatural; it'd be a bit like if we had to use Greek letters in all email > addresses. It would be a bit like if we had to use Greek letters in mathematics :-) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S7LEI7028878 for ; Mon, 27 Oct 2003 23:21:14 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9S7LEvD028877 for ietf-imapext-bks; Mon, 27 Oct 2003 23:21:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from episteme-software.com (216-43-25-66.ip.mcleodusa.net [216.43.25.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S7L7I7028794; Mon, 27 Oct 2003 23:21:07 -0800 (PST) (envelope-from presnick@qualcomm.com) Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b1); Tue, 28 Oct 2003 01:21:01 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <14814332829.20031027184226@brandenburg.com> References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com> <12228881609.20031027074111@brandenburg.com> <20031027105222.4eae54fd.moore@cs.utk.edu> <355752681.20031027161925@brandenburg.com> <16285.48493.496028.516294@moriarty.gnomon.org.uk> <14814332829.20031027184226@brandenburg.com> X-Mailer: Eudora [Macintosh version 6.1a2] Date: Tue, 28 Oct 2003 01:20:58 -0600 To: dcrocker@brandenburg.com From: Pete Resnick Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) Cc: Roy Badami , ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, , , , , Dave Crocker Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 10/27/03 at 6:42 PM -0800, Dave Crocker wrote: >RB> Even though, given IDNA now exists as a proposed standard, the main >RB> issues relate to the local part, the issue under discussion is that of >RB> internationalized mail addresses, not just internationalized >RB> local-parts. > >Really? What work needs to be done, except for local part? IDNA takes care >of the right-hand side. Please review John Klensin's draft before making these kinds of assumptions. >RB> Restricting the disucssion to local-parts runs the risk of excluding >RB> other potentially relevent issues. I agree. Limiting discussion at this point to local-part does not take into account some of the possibilities. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S4gMI7092682 for ; Mon, 27 Oct 2003 20:42:22 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9S4gMwH092681 for ietf-imapext-bks; Mon, 27 Oct 2003 20:42:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S4gHI7092646; Mon, 27 Oct 2003 20:42:17 -0800 (PST) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9S4gHaZ024278; Mon, 27 Oct 2003 20:42:17 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9S4gHx0026302 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 27 Oct 2003 20:42:17 -0800 Date: Mon, 27 Oct 2003 20:42:19 -0800 (Pacific Standard Time) From: Mark Crispin To: Abhijit Menon-Sen cc: ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, ietf-imapext@imc.org, ietf-smtp@imc.org Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) In-Reply-To: <20031028095243.A1525@lustre.dyn.wiw.org> Message-ID: References: <00fd01c39ce8$b6f19fe0$79d52b09@DAVIS1> <014c01c39cf4$5675cd60$79d52b09@DAVIS1> <20031028095243.A1525@lustre.dyn.wiw.org> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 28 Oct 2003, Abhijit Menon-Sen wrote: > The number of people in India who can read and write only their native > language, but have no usable knowledge of Latin script, is much larger > than the tiny number who are familiar with both. I'm told that this is > true for many native speakers of Chinese and Arabic as well. I defer to your superior knowledge about India. I do not believe that this is true for Chinese. AFAIK, Chinese primary school kids use Latin script with hanyu-pinyin as a stopgap prior to their mastery of Han script (which takes many years). > The use of local scripts is much more than just a "preference" for the > numerous localisation efforts in India which focus on making computing > more accessible to poor farmers and people in villages. A poor farmer or villager in China is more likely to be totally illiterate than to be literate in Han script but unable to recognize Latin script. Note that when I say "recognize Latin script", I mean the ability to determine that "dog" is a three-letter word that has the letters "d", "o", and "g", each of which the individual recognizes and can name. This does not include the ability to recognize that this refers to a domesticated canine. > (I agree that it's currently nearly impossible to use computers if one > isn't familiar with the Latin script, of course.) Which probably makes the rest of this discussion academic, unless we're going to undertake solving *that* problem for Microsoft and the various UNIX/Linux vendors... -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S4MmI7091588 for ; Mon, 27 Oct 2003 20:22:48 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9S4Mm9O091586 for ietf-imapext-bks; Mon, 27 Oct 2003 20:22:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from miranda.org (IDENT:qmailr@miranda.org [209.58.150.153]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9S4MlI7091575 for ; Mon, 27 Oct 2003 20:22:47 -0800 (PST) (envelope-from ams@wiw.org) Received: (qmail 21999 invoked from network); 28 Oct 2003 04:22:45 -0000 Received: from miranda.org (HELO lustre.dyn.wiw.org) (ams@209.58.150.153) by miranda.org with SMTP; 28 Oct 2003 04:22:45 -0000 Received: from ams by lustre.dyn.wiw.org with local (Exim 4.20) id 1AELNT-0000RV-Fn; Tue, 28 Oct 2003 09:52:43 +0530 Date: Tue, 28 Oct 2003 09:52:43 +0530 From: Abhijit Menon-Sen To: Mark Crispin Cc: ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, ietf-imapext@imc.org, ietf-smtp@imc.org Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) Message-ID: <20031028095243.A1525@lustre.dyn.wiw.org> References: <00fd01c39ce8$b6f19fe0$79d52b09@DAVIS1> <014c01c39cf4$5675cd60$79d52b09@DAVIS1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 2003-10-27 19:37:37 -0800, MRC@CAC.Washington.EDU wrote: > > I do not believe many individuals (other than primary school children) are > literate in their native language but are completely illiterate in Latin > script. This does not mean "being able to read or write the English > language"; rather, this simply means knowing the Latin script alphabet. Mark, The number of people in India who can read and write only their native language, but have no usable knowledge of Latin script, is much larger than the tiny number who are familiar with both. I'm told that this is true for many native speakers of Chinese and Arabic as well. The use of local scripts is much more than just a "preference" for the numerous localisation efforts in India which focus on making computing more accessible to poor farmers and people in villages. (I agree that it's currently nearly impossible to use computers if one isn't familiar with the Latin script, of course.) -- ams Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S3bmI7089708 for ; Mon, 27 Oct 2003 19:37:48 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9S3bmiK089707 for ietf-imapext-bks; Mon, 27 Oct 2003 19:37:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S3bgI7089683; Mon, 27 Oct 2003 19:37:43 -0800 (PST) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout5.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9S3baMk024515; Mon, 27 Oct 2003 19:37:36 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9S3bZSS003692 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 27 Oct 2003 19:37:35 -0800 Date: Mon, 27 Oct 2003 19:37:37 -0800 (Pacific Standard Time) From: Mark Crispin To: Mark Davis cc: Keith Moore , dcrocker@brandenburg.com, paf@cisco.com, ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, IMAP Extensions WG , ietf-smtp@imc.org, presnick@qualcomm.com, hardie@qualcomm.com, ned.freed@mrochek.com Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA) In-Reply-To: <014c01c39cf4$5675cd60$79d52b09@DAVIS1> Message-ID: References: <00fd01c39ce8$b6f19fe0$79d52b09@DAVIS1> <014c01c39cf4$5675cd60$79d52b09@DAVIS1> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 27 Oct 2003, Mark Davis wrote: > Based on what I've seen, I think it quite likely that people will want email > addresses in their native script, even if that means that outsiders can't > (easily) use those email address. That may well be the case. > We should remember that for a great many people in the world, Latin > letters are quite unnatural; it'd be a bit like if we had to use Greek > letters in all email addresses. And there are many projects underway in > less-developed countries to bring computers to masses of people that > will even less familiarity with Latin letters. I am not convinced that it is possible to use a computer on the Internet anywhere in the world without at least a basic acquaintance with Latin script. I do not believe many individuals (other than primary school children) are literate in their native language but are completely illiterate in Latin script. This does not mean "being able to read or write the English language"; rather, this simply means knowing the Latin script alphabet. Put another way, individuals who are completely illiterate in Latin script are also likely to be illiterate in their native language script as well. No other script on the planet has such international recognition. There is undoubtably a *preference* for one's native script; and that preference should be respected as much as possible. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S2gUI7087955 for ; Mon, 27 Oct 2003 18:42:30 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9S2gUTA087954 for ietf-imapext-bks; Mon, 27 Oct 2003 18:42:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S2gSI7087943; Mon, 27 Oct 2003 18:42:28 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h9S2mVf18218; Mon, 27 Oct 2003 18:48:31 -0800 Date: Mon, 27 Oct 2003 18:42:26 -0800 From: Dave Crocker X-Mailer: The Bat! (v2.00.22) Reply-To: dcrocker@brandenburg.com Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <14814332829.20031027184226@brandenburg.com> To: Roy Badami CC: ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, , , , Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) In-Reply-To: <16285.48493.496028.516294@moriarty.gnomon.org.uk> References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com> <12228881609.20031027074111@brandenburg.com> <20031027105222.4eae54fd.moore@cs.utk.edu> <355752681.20031027161925@brandenburg.com> <16285.48493.496028.516294@moriarty.gnomon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Roy, >> Mail Internationalised Local-Part (MILP) RB> Even though, given IDNA now exists as a proposed standard, the main RB> issues relate to the local part, the issue under discussion is that of RB> internationalized mail addresses, not just internationalized RB> local-parts. Really? What work needs to be done, except for local part? IDNA takes care of the right-hand side. So what is there to do about "internationalized mail addresses" other than the local part? RB> Restricting the disucssion to local-parts runs the risk of excluding RB> other potentially relevent issues. For instance, one of the issues RB> that has been discussed on the IMAA list is whether full-width at RB> should be recognized in an internationalized mail address. full-width _where_? somewhere other than local part? if yes, then how can that be practical? if no, then the charter does not preclude their use. (if you think otherwise, please explain.) d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S1dbI7085759 for ; Mon, 27 Oct 2003 17:39:37 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9S1da1v085756 for ietf-imapext-bks; Mon, 27 Oct 2003 17:39:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from w1309.hostcentric.net (w1309.hostcentric.net [66.40.78.254]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9S1dWI7085729 for ; Mon, 27 Oct 2003 17:39:32 -0800 (PST) (envelope-from mark.davis@jtcsv.com) Received: (qmail 22048 invoked by alias); 28 Oct 2003 01:39:33 -0000 Received: from unknown (HELO DAVIS1) (129.42.184.35) by 0 with SMTP; 28 Oct 2003 01:39:33 -0000 Message-ID: <014c01c39cf4$5675cd60$79d52b09@DAVIS1> From: "Mark Davis" To: "Mark Crispin" Cc: "Keith Moore" , , , , , , , , , , "IMAP Extensions WG" , , , , References: <00fd01c39ce8$b6f19fe0$79d52b09@DAVIS1> Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA) Date: Mon, 27 Oct 2003 17:39:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ok, I understand more about the context. Based on what I've seen, I think it quite likely that people will want email addresses in their native script, even if that means that outsiders can't (easily) use those email address. After all, it is quite easy to have multiple email addresses. Mr. Tanaka can have one with Latin letters and one with Japanese (e.g. ムルク@カク.ワシングトン.エデゥ). We should remember that for a great many people in the world, Latin letters are quite unnatural; it'd be a bit like if we had to use Greek letters in all email addresses. And there are many projects underway in less-developed countries to bring computers to masses of people that will even less familiarity with Latin letters. Mark __________________________________ http://www.macchiato.com â–º शिषà¥à¤¯à¤¾à¤¦à¤¿à¤šà¥à¤›à¥‡à¤¤à¥à¤ªà¤°à¤¾à¤œà¤¯à¤®à¥ â—„ ----- Original Message ----- From: "Mark Crispin" To: "Mark Davis" Cc: "Keith Moore" ; ; ; ; ; ; ; ; ; ; "IMAP Extensions WG" ; ; ; ; Sent: Mon, 2003 Oct 27 17:15 Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA) > On Mon, 27 Oct 2003, Mark Davis wrote: > > I'm curious: why do you think that everyone would be satisfied with Latin > > characters only, and no non-Latin characters? > > I didn't say that. I stated my belief that, for reasons of practicality, > most individuals in regions which do not use Latin script accept the use > of Latin script for multinational exchange. > > It does not work well for an individual in Japan with surname Tanaka to > expect the overwhelming majority of non-Japanese individuals worldwide to > know his surname is written with the Han characters for "rice paddy" and > "middle", or what those characters look like, or how to enter those > characters on the computer. > > It does, however, work for him to expect that the overwhelming majority of > individuals worldwide to know how to deal with the 6 Latin letters that > form the romanization "Tanaka". > > Nor is it very likely that this situation will change in the future. I > doubt that many individuals in the world are literate in all the world's > active scripts. Literacy in one's native script and basic Latin script is > something that most computer users possess today. > > For domestic exchange only, that pair of Han characters are probably > alright. Within Western Europe, it's probably alright to use Latin > characters with diacriticals. > > Perhaps the main problem that needs to be decided in any IEA effort is if > it is alright to have email addresses that are only usable in limited > areas of the world; or if not, how to represent internationalized email > addresses in a usable fashion when (not if) the email address needs to be > represented for a person and/or computer is illiterate in that script. > > A likely side issue is whether it is "good enough" to promote Latin > characters with diacriticals to the same status of "everybody must know > how to do these" that is required for ASCII. > > -- Mark -- > > http://staff.washington.edu/mrc > Science does not emerge from voting, party politics, or public debate. > Si vis pacem, para bellum. > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S1FYI7084848 for ; Mon, 27 Oct 2003 17:15:34 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9S1FYgT084847 for ietf-imapext-bks; Mon, 27 Oct 2003 17:15:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S1FTI7084821; Mon, 27 Oct 2003 17:15:30 -0800 (PST) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9S1EwaZ010323; Mon, 27 Oct 2003 17:14:59 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9S1Ewx0018732 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 27 Oct 2003 17:14:58 -0800 Date: Mon, 27 Oct 2003 17:15:00 -0800 (Pacific Standard Time) From: Mark Crispin To: Mark Davis cc: Keith Moore , dcrocker@brandenburg.com, paf@cisco.com, ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, IMAP Extensions WG , ietf-smtp@imc.org, presnick@qualcomm.com, hardie@qualcomm.com, ned.freed@mrochek.com Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA) In-Reply-To: <00fd01c39ce8$b6f19fe0$79d52b09@DAVIS1> Message-ID: References: <00fd01c39ce8$b6f19fe0$79d52b09@DAVIS1> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 27 Oct 2003, Mark Davis wrote: > I'm curious: why do you think that everyone would be satisfied with Latin > characters only, and no non-Latin characters? I didn't say that. I stated my belief that, for reasons of practicality, most individuals in regions which do not use Latin script accept the use of Latin script for multinational exchange. It does not work well for an individual in Japan with surname Tanaka to expect the overwhelming majority of non-Japanese individuals worldwide to know his surname is written with the Han characters for "rice paddy" and "middle", or what those characters look like, or how to enter those characters on the computer. It does, however, work for him to expect that the overwhelming majority of individuals worldwide to know how to deal with the 6 Latin letters that form the romanization "Tanaka". Nor is it very likely that this situation will change in the future. I doubt that many individuals in the world are literate in all the world's active scripts. Literacy in one's native script and basic Latin script is something that most computer users possess today. For domestic exchange only, that pair of Han characters are probably alright. Within Western Europe, it's probably alright to use Latin characters with diacriticals. Perhaps the main problem that needs to be decided in any IEA effort is if it is alright to have email addresses that are only usable in limited areas of the world; or if not, how to represent internationalized email addresses in a usable fashion when (not if) the email address needs to be represented for a person and/or computer is illiterate in that script. A likely side issue is whether it is "good enough" to promote Latin characters with diacriticals to the same status of "everybody must know how to do these" that is required for ASCII. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S1A0I7084626 for ; Mon, 27 Oct 2003 17:10:00 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9S1A0Ct084625 for ietf-imapext-bks; Mon, 27 Oct 2003 17:10:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from panoramix.hexago.com ([209.71.226.3]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S19rI7084577; Mon, 27 Oct 2003 17:09:58 -0800 (PST) (envelope-from Marc.Blanchet@viagenie.qc.ca) Received: from localhost (retro.viagenie.qc.ca [IPv6:3ffe:b00:c18:3::22]) (authenticated bits=0) by panoramix.hexago.com (8.12.8/8.12.8) with ESMTP id h9S18c6r006354; Mon, 27 Oct 2003 20:08:39 -0500 (EST) Date: Mon, 27 Oct 2003 20:08:25 -0500 From: Marc Blanchet To: Dave Crocker , ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, ietf-imapext@imc.org, ietf-smtp@imc.org Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA) Message-ID: <839550000.1067303305@classic.viagenie.qc.ca> In-Reply-To: <355752681.20031027161925@brandenburg.com> References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com> <12228881609.20031027074111@brandenburg.com> <20031027105222.4eae54fd.moore@cs.utk.edu> <355752681.20031027161925@brandenburg.com> X-Mailer: Mulberry/3.1.0b8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: - good start! - timeline seems pretty agressive... will see. - would probably good to have a requirement document upfront. Might not the same way that idn requirement ends up, but a narrow-implementable requirement would help to have a concensus (hopefully) on what needs to be done. - while the idn req went not that good, now that we have experience, I think we should try to be better and have one. I know I might start some debate with this, but still think it is the best way to go... - would be useful to have some reference to idn (idna) in the charter, as background work. the developers and users will have to take care of "both" (ie. idn and imail) in the email infrastructure. Marc. -- Monday, October 27, 2003 16:19:25 -0800 Dave Crocker wrote/a ecrit: > Folks, > > On the theory that discussions go better when they have a concrete > deliverable, here is a proposed charter for a proposed working group. > > The following started with Mark Crispin's text, although it might not > look it. Besides the usual goals for a charter, the following text > attempts to specify the problem domain in the narrowest feasible form > that is valid. If anyone thinks the scope is too narrow, they need to > explain why. > > > > DRAFT CHARTER > > Mail Internationalised Local-Part (MILP) > --------------------------------- > > The portion of RFC2822 and portion of RFC2821 > mail addresses are restricted to a subset of ASCII. This poses a > fundamental barrier for users needing mail addresses to be expressed in a > richer set of characters, such as Latin characters with diacriticals and > the many Asian characters. The goal of the current work is to add > local-part support for these additional characters, while preserving the > large, installed base of ASCII usage. > > The group will take: > > draft-hoffman-imaa-03.txt > draft-klensin-emailaddr-i18n-01.txt > draft-duerst-iri-04.txt > > as input to discussions. > > The group will pay particular attention to barriers to adoption and > utility, as well as any impact the new scheme might have on the existing > base of Internet mail usage. > > > Milestones > ---------- > > Nov, 03: BOF > > Dec, 03: WG chartered > > Feb, 03: Initial draft of working group specifications. > > Jun, 03: Specifications submitted for IETF approval > > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA > ------------------------------------------ Marc Blanchet Hexago tel: +1-418-266-5533x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S0pGI7083785 for ; Mon, 27 Oct 2003 16:51:16 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9S0pGwh083784 for ietf-imapext-bks; Mon, 27 Oct 2003 16:51:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from willow.gnomon.org.uk (willow.gnomon.org.uk [69.10.132.76]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S0pEI7083774 for ; Mon, 27 Oct 2003 16:51:14 -0800 (PST) (envelope-from roy+dated+1069894271.45404d@gnomon.org.uk) Received: from moriarty.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by willow.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9S0pDRX014098 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Tue, 28 Oct 2003 00:51:16 GMT Received: from moriarty.gnomon.org.uk (roy@localhost [127.0.0.1]) by moriarty.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9S0pCZe008703 for ; Tue, 28 Oct 2003 00:51:12 GMT Received: by moriarty.gnomon.org.uk (tmda-sendmail, from uid 559); Tue, 28 Oct 2003 00:50:59 +0000 (GMT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16285.48493.496028.516294@moriarty.gnomon.org.uk> Date: Tue, 28 Oct 2003 00:50:53 +0000 To: Dave Crocker Cc: ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, , , , Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) In-Reply-To: <355752681.20031027161925@brandenburg.com> References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com> <12228881609.20031027074111@brandenburg.com> <20031027105222.4eae54fd.moore@cs.utk.edu> <355752681.20031027161925@brandenburg.com> X-Mailer: VM 7.03 under Emacs 20.7.2 From: Roy Badami X-Delivery-Agent: TMDA/0.81 (Swaps) X-Primary-Address: roy@gnomon.org.uk Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Mail Internationalised Local-Part (MILP) Even though, given IDNA now exists as a proposed standard, the main issues relate to the local part, the issue under discussion is that of internationalized mail addresses, not just internationalized local-parts. Restricting the disucssion to local-parts runs the risk of excluding other potentially relevent issues. For instance, one of the issues that has been discussed on the IMAA list is whether full-width at should be recognized in an internationalized mail address. IMHO, the charter shouldn't be framed in a way that is sufficiently narrow as to render such questions out of scope. -roy Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S0KYI7082575 for ; Mon, 27 Oct 2003 16:20:34 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9S0KY5V082574 for ietf-imapext-bks; Mon, 27 Oct 2003 16:20:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S0KWI7082563; Mon, 27 Oct 2003 16:20:32 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h9S0Qaf09143; Mon, 27 Oct 2003 16:26:36 -0800 Date: Mon, 27 Oct 2003 16:19:25 -0800 From: Dave Crocker X-Mailer: The Bat! (v2.00.22) Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <355752681.20031027161925@brandenburg.com> To: ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, , , , Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) In-Reply-To: References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com> <12228881609.20031027074111@brandenburg.com> <20031027105222.4eae54fd.moore@cs.utk.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Folks, On the theory that discussions go better when they have a concrete deliverable, here is a proposed charter for a proposed working group. The following started with Mark Crispin's text, although it might not look it. Besides the usual goals for a charter, the following text attempts to specify the problem domain in the narrowest feasible form that is valid. If anyone thinks the scope is too narrow, they need to explain why. DRAFT CHARTER Mail Internationalised Local-Part (MILP) --------------------------------- The portion of RFC2822 and portion of RFC2821 mail addresses are restricted to a subset of ASCII. This poses a fundamental barrier for users needing mail addresses to be expressed in a richer set of characters, such as Latin characters with diacriticals and the many Asian characters. The goal of the current work is to add local-part support for these additional characters, while preserving the large, installed base of ASCII usage. The group will take: draft-hoffman-imaa-03.txt draft-klensin-emailaddr-i18n-01.txt draft-duerst-iri-04.txt as input to discussions. The group will pay particular attention to barriers to adoption and utility, as well as any impact the new scheme might have on the existing base of Internet mail usage. Milestones ---------- Nov, 03: BOF Dec, 03: WG chartered Feb, 03: Initial draft of working group specifications. Jun, 03: Specifications submitted for IETF approval d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S0GOI7082404 for ; Mon, 27 Oct 2003 16:16:24 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9S0GOjl082403 for ietf-imapext-bks; Mon, 27 Oct 2003 16:16:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from w1309.hostcentric.net (w1309.hostcentric.net [66.40.78.254]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9S0GKI7082376 for ; Mon, 27 Oct 2003 16:16:20 -0800 (PST) (envelope-from mark.davis@jtcsv.com) Received: (qmail 22319 invoked by alias); 28 Oct 2003 00:16:21 -0000 Received: from unknown (HELO DAVIS1) (129.42.184.35) by 0 with SMTP; 28 Oct 2003 00:16:21 -0000 Message-ID: <00fd01c39ce8$b6f19fe0$79d52b09@DAVIS1> From: "Mark Davis" To: "Mark Crispin" , "Keith Moore" Cc: , , , , , , , , , , , , , References: Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA) Date: Mon, 27 Oct 2003 16:16:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'm curious: why do you think that everyone would be satisfied with Latin characters only, and no non-Latin characters? Mark __________________________________ http://www.macchiato.com â–º शिषà¥à¤¯à¤¾à¤¦à¤¿à¤šà¥à¤›à¥‡à¤¤à¥à¤ªà¤°à¤¾à¤œà¤¯à¤®à¥ â—„ ----- Original Message ----- From: "Mark Crispin" To: "Keith Moore" Cc: ; ; ; ; ; ; ; ; ; ; ; ; ; Sent: Mon, 2003 Oct 27 11:10 Subject: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA) > On Mon, 27 Oct 2003, Keith Moore wrote: > > >> Thanks for taking a stab at a problem statement. I'd like to drill down > >> on this just a bit. > >> What is the source of the "growing need"? Is it: > >> [snip] > > > I agree that this needs to be stated, but someone other than me will have > to do it. > > I believe that the primary push for this functionality comes from regions > which use Latin alphabetics with diacriticals; and that most individuals > in regions which do not use Latin script are accept the use of Latin > script for multinational interchange. In many regions where Latin > diacriticals are used, there is no acceptable transform of a surname to a > form that does not use diacriticals. Simply omitting the diacritical > causes (at least to the inhabitants of those regions) a misspelling. > > This set of beliefs naturally biases how I approach the problem. The > problem statement must be free of bias, including mine. > > -- Mark -- > > http://staff.washington.edu/mrc > Science does not emerge from voting, party politics, or public debate. > Si vis pacem, para bellum. > > > > > > > > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RNhGI7081094 for ; Mon, 27 Oct 2003 15:43:16 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RNhGgw081090 for ietf-imapext-bks; Mon, 27 Oct 2003 15:43:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from sentosa.post1.com (sentosa.post1.com [202.27.17.100]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9RNh9I7081060 for ; Mon, 27 Oct 2003 15:43:12 -0800 (PST) (envelope-from jseng@pobox.org.sg) Received: (qmail 5838 invoked from network); 28 Oct 2003 00:01:35 -0000 Received: from rifcd-04p117.ppp.odn.ad.jp (HELO pobox.org.sg) (211.3.24.117) by sentosa.post1.com with SMTP; 28 Oct 2003 00:01:35 -0000 Message-ID: <3F9CFC5D.7060509@pobox.org.sg> Date: Mon, 27 Oct 2003 19:07:09 +0800 From: James Seng User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= CC: ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, ietf-imapext@imc.org, ietf-smtp@imc.org, Pete Resnick , Ted Hardie , Ned Freed Subject: Re: [idn] FYI: BOF on Internationalized Email Addresses (IEA) References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com> In-Reply-To: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I seen John and Paul proposal but I have not seen Michel. Is there a draft that I can read up? ps: I wont be able to join the meeting but I am interested in the subject. -James Seng Patrik Fältström wrote: > At the IETF in Minneapolis, there will be a BOF on Internationalized > Email Addresses (IEA). > > It is *preliminary* on the agenda on Monday, November 10, 2003 at > 1530-1730. > > Chairs: Pete Resnick, Patrik Fältström > Mailing list:imaa@imc.org (other salient lists include uri@w3.org) > Agenda: > > Agenda Bashing (Chairs) 5 min. > Topic Introduction (Chairs) 10 min. > Proposals > IDNA-Based (Paul Hoffman) 15 min. > Infrastructure-Based (John Klensin) 15 min. > IRI-Based (Michel Suignard) 15 min. > > Discussion 60 min. > > Topics for discussion: > > Are there other solutions which have been specified? > > The solutions present the problem at different scopes; > > Where should the IETF tackle it? > > Are some short-term, and other long-term? > > Can the solutions be staged or co-exist? > > If staged, how to migrate from one to another? > > What are the next steps for the IETF? > > > NB: This BoF is exploratory in nature, and it is not intended that the > IETF will finalize a decision in this venue. It was proposed to foster > a community discussion, not charter a working group or pick a winner. If > further work is required, step one would be identifying individuals > willing to carry that work forward. > > Reading material: > draft-hoffman-imaa-03.txt > draft-klensin-emailaddr-i18n-01.txt > draft-duerst-iri-04.txt > > Pete and myself hope people will come with a lot of constructive > comments and ideas. > > Patrik, co-chair of the bof > > > > > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJBNI7069325 for ; Mon, 27 Oct 2003 11:11:23 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RJBN5v069324 for ietf-imapext-bks; Mon, 27 Oct 2003 11:11:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJBII7069299; Mon, 27 Oct 2003 11:11:18 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout3.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9RJAtC2014056; Mon, 27 Oct 2003 11:10:56 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9RJAtOx022764; Mon, 27 Oct 2003 11:10:55 -0800 Date: Mon, 27 Oct 2003 11:10:55 -0800 (PST) From: Mark Crispin To: Keith Moore cc: dcrocker@brandenburg.com, paf@cisco.com, ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, ietf-imapext@imc.org, ietf-smtp@imc.org, presnick@qualcomm.com, hardie@qualcomm.com, ned.freed@mrochek.com Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) In-Reply-To: <20031027134403.5eaaee9e.moore@cs.utk.edu> Message-ID: References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com> <12228881609.20031027074111@brandenburg.com> <20031027105222.4eae54fd.moore@cs.utk.edu> <20031027134403.5eaaee9e.moore@cs.utk.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 27 Oct 2003, Keith Moore wrote: > Thanks for taking a stab at a problem statement. I'd like to drill down > on this just a bit. > What is the source of the "growing need"? Is it: > [snip] I agree that this needs to be stated, but someone other than me will have to do it. I believe that the primary push for this functionality comes from regions which use Latin alphabetics with diacriticals; and that most individuals in regions which do not use Latin script are accept the use of Latin script for multinational interchange. In many regions where Latin diacriticals are used, there is no acceptable transform of a surname to a form that does not use diacriticals. Simply omitting the diacritical causes (at least to the inhabitants of those regions) a misspelling. This set of beliefs naturally biases how I approach the problem. The problem statement must be free of bias, including mine. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RIjdI7067925 for ; Mon, 27 Oct 2003 10:45:39 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RIjdHM067924 for ietf-imapext-bks; Mon, 27 Oct 2003 10:45:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RIjXI7067898; Mon, 27 Oct 2003 10:45:33 -0800 (PST) (envelope-from moore@cs.utk.edu) Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 4F4301401D; Mon, 27 Oct 2003 13:45:34 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25223-11; Mon, 27 Oct 2003 13:45:33 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with ESMTP id 3AA6C13FEC; Mon, 27 Oct 2003 13:45:33 -0500 (EST) Date: Mon, 27 Oct 2003 13:44:03 -0500 From: Keith Moore To: Mark Crispin Cc: moore@cs.utk.edu, dcrocker@brandenburg.com, paf@cisco.com, ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, ietf-imapext@imc.org, ietf-smtp@imc.org, presnick@qualcomm.com, hardie@qualcomm.com, ned.freed@mrochek.com Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) Message-Id: <20031027134403.5eaaee9e.moore@cs.utk.edu> In-Reply-To: References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com> <12228881609.20031027074111@brandenburg.com> <20031027105222.4eae54fd.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark, Thanks for taking a stab at a problem statement. I'd like to drill down on this just a bit. What is the source of the "growing need"? Is it: a. for users of many languages (particularly those not using Latin alphabets) email addresses are difficult to remember b. for users of many languages (particularly those not using Latin alphabets) email addresses are difficult to transcribe or type c. users want to use their names in email addresses d. users are confused by apparently arbitrary restrictions on use of characters in email addresses, and this leads to mistakes e. on computer systems employing non-ASCII names for other purposes (e.g. login or account names) these do not map well to ASCII email addresses or something else that I don't see? > As presently constituted, email addresses are limited to the 26 Latin > alphabetics, 10 digits, and a limited number of special characters in > the ASCII character set. There is a growing need to use additional > characters, specifically Latin characters with diacriticals and > non-Latin characters, in email addresses to better serve the needs of > the multi-national Internet community. However, the restrictions of > ASCII email addresses have served as a "lingua franca" since everybody > can enter ASCII email addresses, and there is an ongoing need for this > as well. The problem to be solved is the resolution of these two > needs. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RHkjI7063911 for ; Mon, 27 Oct 2003 09:46:45 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RHkj7Q063910 for ietf-imapext-bks; Mon, 27 Oct 2003 09:46:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RHkiI7063899 for ; Mon, 27 Oct 2003 09:46:44 -0800 (PST) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id h9RHkXZl032388; Mon, 27 Oct 2003 12:46:33 -0500 (EST) Message-ID: <3F9D5AAB.2060606@oceana.com> Date: Mon, 27 Oct 2003 12:49:31 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Arnt Gulbrandsen CC: IMAP Interest List , Mark Crispin , IMAP Extensions WG Subject: Re: Exchange server has a broken SASL implementation References: <3F9D4469.6020008@oceana.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Arnt Gulbrandsen wrote: > Ken Murchison writes: > >> Mark Crispin wrote: >> >>> Yet more proof that the SASL specifications as currently constituted >>> are too complex, and why IMAP should not add initial-response until >>> the SASL specifications are fixed. >> >> >> Or its more proof that M$ doesn't care about specs and choose to >> [re]define then as they see fit. > > > Do not attribute to malice that which can be adequately explained by > ignorance/release pressure/lack of time/blah/blah. So far, every > Microsoft programmer I've spoken to seemed to try hard. (I'm not saying > they succeed, but I _am_ saying they don't seem a malicious bunch.) I didn't mean to imply that anything that doesn't meet the specs was done maliciously by the programmers (over frustration from replying to Outlook bug emails). I have no knowledge that any mistakes are anything other than just simple mistakes. However, if there is/was any question about the specs, there are mailing lists that can be contacted for clarification. Interop testing could be done with non-MS products. The CMU SASL library comes with test harnesses which can be used for testing. There are at least 2 major MTAs (sendmail, postfix) which use CMU SASL that could have been consulted for comparison. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RHUuI7062585 for ; Mon, 27 Oct 2003 09:30:56 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RHUuw2062584 for ietf-imapext-bks; Mon, 27 Oct 2003 09:30:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mx.spindry.com (p1.spindry.com [64.5.41.83]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RHUsI7062559; Mon, 27 Oct 2003 09:30:54 -0800 (PST) (envelope-from bill-imc@carpenter.ORG) Received: from filenet-gw.filenet.com ([198.3.8.1] helo=ATTABOY.carpenter.ORG) by mx.spindry.com with smtp (Exim 3.36 #2) id 1AEBCg-0005Z8-00; Mon, 27 Oct 2003 12:30:54 -0500 Date: Mon, 27 Oct 2003 09:30:46 -0800 Message-ID: <4027-Mon27Oct2003093046-0800-bill@carpenter.ORG> X-Mailer: 21.1 (patch 9) "Canyonlands" XEmacs Lucid (via feedmail 11-beta-2 I) wjc loop; VM 6.71 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: bill-imc@carpenter.ORG (WJCarpenter) To: ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, ietf-imapext@imc.org, ietf-smtp@imc.org Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) In-Reply-To: References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com> <12228881609.20031027074111@brandenburg.com> <20031027105222.4eae54fd.moore@cs.utk.edu> Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: mc> As presently constituted, email addresses are limited to the 26 mc> Latin alphabetics, 10 digits, and a limited number of special mc> characters in the ASCII character set. There is a growing need to upper and lower case alphabetics -- bill-imc@carpenter.ORG (WJCarpenter) PGP 0x91865119 38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RHIBI7061906 for ; Mon, 27 Oct 2003 09:18:11 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RHIBMu061905 for ietf-imapext-bks; Mon, 27 Oct 2003 09:18:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RHIAI7061897 for ; Mon, 27 Oct 2003 09:18:10 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout5.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9RHHsMk024887; Mon, 27 Oct 2003 09:17:59 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9RHHs2l015776; Mon, 27 Oct 2003 09:17:54 -0800 Date: Mon, 27 Oct 2003 09:17:54 -0800 (PST) From: Mark Crispin To: Arnt Gulbrandsen cc: Ken Murchison , IMAP Interest List , IMAP Extensions WG Subject: Re: Exchange server has a broken SASL implementation In-Reply-To: Message-ID: References: <3F9D4469.6020008@oceana.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 27 Oct 2003, Arnt Gulbrandsen wrote: > Do not attribute to malice that which can be adequately explained by > ignorance/release pressure/lack of time/blah/blah. So far, every > Microsoft programmer I've spoken to seemed to try hard. (I'm not saying > they succeed, but I _am_ saying they don't seem a malicious bunch.) I agree with Arnt on all three of the above points. > We're talking about a set of interrelated documents that are light on > examples and free of a test suite. I'm not greatly surprised that > people have trouble implementing them correctly. We have seen this happen over and over again. The documents are broken. If Microsoft programmers don't care about specs and redefine them as they see fit, then we can say the same thing about the programmers of almost every other SASL server. This is an *extremely* common blunder. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RHDtI7061696 for ; Mon, 27 Oct 2003 09:13:55 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RHDts6061695 for ietf-imapext-bks; Mon, 27 Oct 2003 09:13:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RHDpI7061670; Mon, 27 Oct 2003 09:13:51 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout2.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9RHDThu011833; Mon, 27 Oct 2003 09:13:30 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9RHDTew015664; Mon, 27 Oct 2003 09:13:29 -0800 Date: Mon, 27 Oct 2003 09:13:29 -0800 (PST) From: Mark Crispin To: Keith Moore cc: Dave Crocker , paf@cisco.com, ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, ietf-imapext@imc.org, ietf-smtp@imc.org, presnick@qualcomm.com, hardie@qualcomm.com, ned.freed@mrochek.com Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) In-Reply-To: <20031027105222.4eae54fd.moore@cs.utk.edu> Message-ID: References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com> <12228881609.20031027074111@brandenburg.com> <20031027105222.4eae54fd.moore@cs.utk.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 27 Oct 2003, Keith Moore wrote: > what problem are we trying to solve here? I agree with Keith. This isn't to say that I dispute that there is a problem to be solved -- indeed, I think that the problem is apparent to all -- but we must have a problem statement that we all agree upon before we even think about solutions. I don't think that references to drafts of proposed solutions suffice as a problem statement. Leaving aside questions of possible bias (= present a problem in such a way that this is the obvious best solution), having the problem statement in a draft (which by its nature is an ephemeral document) muddies the issues. The problem statement should consist of a single paragraph (and preferably in one or two sentences), separate from any proposed solution, and stated in a charter which is approved by everyone. Here's a start at such a statement: As presently constituted, email addresses are limited to the 26 Latin alphabetics, 10 digits, and a limited number of special characters in the ASCII character set. There is a growing need to use additional characters, specifically Latin characters with diacriticals and non-Latin characters, in email addresses to better serve the needs of the multi-national Internet community. However, the restrictions of ASCII email addresses have served as a "lingua franca" since everybody can enter ASCII email addresses, and there is an ongoing need for this as well. The problem to be solved is the resolution of these two needs. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RHB3I7061570 for ; Mon, 27 Oct 2003 09:11:03 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RHB32X061568 for ietf-imapext-bks; Mon, 27 Oct 2003 09:11:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RHB2I7061559 for ; Mon, 27 Oct 2003 09:11:02 -0800 (PST) (envelope-from arnt@gulbrandsen.priv.no) Message-Id: From: Arnt Gulbrandsen To: Ken Murchison Subject: Re: Exchange server has a broken SASL implementation Cc: IMAP Interest List , Mark Crispin , IMAP Extensions WG References: <3F9D4469.6020008@oceana.com> In-Reply-To: <3F9D4469.6020008@oceana.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Mon, 27 Oct 2003 18:14:44 +0100 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ken Murchison writes: > Mark Crispin wrote: >> Yet more proof that the SASL specifications as currently constituted >> are too complex, and why IMAP should not add initial-response until >> the SASL specifications are fixed. > > Or its more proof that M$ doesn't care about specs and choose to > [re]define then as they see fit. Do not attribute to malice that which can be adequately explained by ignorance/release pressure/lack of time/blah/blah. So far, every Microsoft programmer I've spoken to seemed to try hard. (I'm not saying they succeed, but I _am_ saying they don't seem a malicious bunch.) We're talking about a set of interrelated documents that are light on examples and free of a test suite. I'm not greatly surprised that people have trouble implementing them correctly. (Larry: if there were a test suite for SMTP/SASL, would Microsoft have used it?) --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RH1rI7061180 for ; Mon, 27 Oct 2003 09:01:53 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RH1r3U061179 for ietf-imapext-bks; Mon, 27 Oct 2003 09:01:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from panoramix.hexago.com ([209.71.226.3]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RH1oI7061125; Mon, 27 Oct 2003 09:01:50 -0800 (PST) (envelope-from Marc.Blanchet@viagenie.qc.ca) Received: from localhost (retro.viagenie.qc.ca [IPv6:3ffe:b00:c18:3::22]) (authenticated bits=0) by panoramix.hexago.com (8.12.8/8.12.8) with ESMTP id h9RH0M6r005886; Mon, 27 Oct 2003 12:00:22 -0500 (EST) Date: Mon, 27 Oct 2003 12:00:01 -0500 From: Marc Blanchet To: Keith Moore , Dave Crocker cc: paf@cisco.com, ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, ietf-imapext@imc.org, ietf-smtp@imc.org, presnick@qualcomm.com, hardie@qualcomm.com, ned.freed@mrochek.com Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) Message-ID: <575390000.1067274001@classic.viagenie.qc.ca> In-Reply-To: <20031027105222.4eae54fd.moore@cs.utk.edu> References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com> <12228881609.20031027074111@brandenburg.com> <20031027105222.4eae54fd.moore@cs.utk.edu> X-Mailer: Mulberry/3.1.0b8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: -- Monday, October 27, 2003 10:52:22 -0500 Keith Moore wrote/a ecrit: >> PF> What are the next steps for the IETF? >> >> Would it help to have a draft charter for the meeting? > > let's back up a step further. > > what problem are we trying to solve here? to me, that (problem we are trying to solve) would be part of the introduction in the charter... so I guess some initial proposal for: - what are we trying to solve - what would be the way to solve it would be a good starting point together with the "state-of-the-art" presentations. Marc. > > Keith ------------------------------------------ Marc Blanchet Hexago tel: +1-418-266-5533x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RGbWI7060051 for ; Mon, 27 Oct 2003 08:37:32 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RGbWa9060050 for ietf-imapext-bks; Mon, 27 Oct 2003 08:37:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from episteme-software.com (216-43-25-66.ip.mcleodusa.net [216.43.25.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RGbRI7060023; Mon, 27 Oct 2003 08:37:27 -0800 (PST) (envelope-from presnick@qualcomm.com) Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b1); Mon, 27 Oct 2003 10:37:25 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <20031027105222.4eae54fd.moore@cs.utk.edu> References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com> <12228881609.20031027074111@brandenburg.com> <20031027105222.4eae54fd.moore@cs.utk.edu> X-Mailer: Eudora [Macintosh version 6.1a2] Date: Mon, 27 Oct 2003 10:37:21 -0600 To: Keith Moore From: Pete Resnick Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) Cc: Dave Crocker , moore@cs.utk.edu, paf@cisco.com, ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, ietf-imapext@imc.org, ietf-smtp@imc.org, hardie@qualcomm.com, ned.freed@mrochek.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 10/27/03 at 10:52 AM -0500, Keith Moore wrote: >>DC: Would it help to have a draft charter for the meeting? As was mentioned in the draft agenda at , we want to simply start the discussion, not immediately attempt to charter a working group. >let's back up a step further. > >what problem are we trying to solve here? Please have a look at draft-hoffman-imaa, draft-klensin-emailaddr-i18n, and draft-duerst-iri. Certainly the first two have very explicit descriptions of the problem. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RGBnI7058337 for ; Mon, 27 Oct 2003 08:11:49 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RGBnrk058334 for ietf-imapext-bks; Mon, 27 Oct 2003 08:11:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RGBlI7058326 for ; Mon, 27 Oct 2003 08:11:48 -0800 (PST) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id h9RGBZZl030658; Mon, 27 Oct 2003 11:11:36 -0500 (EST) Message-ID: <3F9D4469.6020008@oceana.com> Date: Mon, 27 Oct 2003 11:14:33 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Mark Crispin CC: IMAP Interest List , IMAP Extensions WG Subject: Re: Exchange server has a broken SASL implementation References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > It looks like Microsoft finally implemented support for the GSSAPI SASL > mechanism. > > Unfortunately, they screwed it up. In their SMTP server, they respond to > the command "AUTH GSSAPI" with "334 gssapi supported". > > Yet more proof that the SASL specifications as currently constituted are > too complex, and why IMAP should not add initial-response until the SASL > specifications are fixed. Or its more proof that M$ doesn't care about specs and choose to [re]define then as they see fit. Can you show me where the SASL specs or SMTP SASL profile gives them license to put garbage in the challenge? -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RFrrI7057219 for ; Mon, 27 Oct 2003 07:53:53 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RFrraY057218 for ietf-imapext-bks; Mon, 27 Oct 2003 07:53:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RFrnI7057198; Mon, 27 Oct 2003 07:53:50 -0800 (PST) (envelope-from moore@cs.utk.edu) Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 812AC14142; Mon, 27 Oct 2003 10:53:50 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01580-02; Mon, 27 Oct 2003 10:53:49 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with ESMTP id 7D86C14094; Mon, 27 Oct 2003 10:53:49 -0500 (EST) Date: Mon, 27 Oct 2003 10:52:22 -0500 From: Keith Moore To: Dave Crocker Cc: moore@cs.utk.edu, paf@cisco.com, ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, ietf-imapext@imc.org, ietf-smtp@imc.org, presnick@qualcomm.com, hardie@qualcomm.com, ned.freed@mrochek.com Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) Message-Id: <20031027105222.4eae54fd.moore@cs.utk.edu> In-Reply-To: <12228881609.20031027074111@brandenburg.com> References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com> <12228881609.20031027074111@brandenburg.com> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > PF> What are the next steps for the IETF? > > Would it help to have a draft charter for the meeting? let's back up a step further. what problem are we trying to solve here? Keith Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RFipI7056728 for ; Mon, 27 Oct 2003 07:44:52 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RFipmG056727 for ietf-imapext-bks; Mon, 27 Oct 2003 07:44:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RFimI7056714; Mon, 27 Oct 2003 07:44:48 -0800 (PST) (envelope-from dcrocker@brandenburg.com) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h9RFokf29900; Mon, 27 Oct 2003 07:50:46 -0800 Date: Mon, 27 Oct 2003 07:41:11 -0800 From: Dave Crocker X-Mailer: The Bat! (v2.00.22) Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <12228881609.20031027074111@brandenburg.com> To: =?ISO-8859-1?B?UGF0cmlrIEbkbHRzdHL2bQ==?= CC: ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, , , , , Pete Resnick , Ted Hardie , Ned Freed Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) In-Reply-To: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com> References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Patrik, Thanks for putting this BOF together. PF> Where should the IETF tackle it? I am not sure I understand this question. Please clarify. PF> What are the next steps for the IETF? Would it help to have a draft charter for the meeting? (I realize that the presence of such different specifications makes a charter at least a bit challenging, but it seems to help to have a draft, to make things concrete.) d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RFZSI7056003 for ; Mon, 27 Oct 2003 07:35:28 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RFZSN2056002 for ietf-imapext-bks; Mon, 27 Oct 2003 07:35:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout6.cac.washington.edu (mxout6.cac.washington.edu [140.142.33.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RFZRI7055995 for ; Mon, 27 Oct 2003 07:35:27 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout6.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9RFZM0Y029502; Mon, 27 Oct 2003 07:35:27 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9RFZMLi011061; Mon, 27 Oct 2003 07:35:22 -0800 Date: Mon, 27 Oct 2003 07:35:22 -0800 (PST) From: Mark Crispin To: IMAP Interest List , IMAP Extensions WG Subject: Exchange server has a broken SASL implementation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It looks like Microsoft finally implemented support for the GSSAPI SASL mechanism. Unfortunately, they screwed it up. In their SMTP server, they respond to the command "AUTH GSSAPI" with "334 gssapi supported". Yet more proof that the SASL specifications as currently constituted are too complex, and why IMAP should not add initial-response until the SASL specifications are fixed. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9QJtRI7031768 for ; Sun, 26 Oct 2003 11:55:27 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9QJtRLs031767 for ietf-imapext-bks; Sun, 26 Oct 2003 11:55:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.74.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9QJtGI7031748; Sun, 26 Oct 2003 11:55:17 -0800 (PST) (envelope-from paf@cisco.com) Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 26 Oct 2003 20:53:10 +0100 Received: from xbe-ams-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h9QJt4l0006339; Sun, 26 Oct 2003 20:55:04 +0100 (MET) Received: from xfe-ams-311.cisco.com ([144.254.228.204]) by xbe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 26 Oct 2003 20:55:11 +0100 Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-311.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 26 Oct 2003 20:55:10 +0100 Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com> Cc: Pete Resnick , Ted Hardie , Ned Freed From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: FYI: BOF on Internationalized Email Addresses (IEA) Date: Sun, 26 Oct 2003 20:55:08 +0100 To: ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org, ietf-imapext@imc.org, ietf-smtp@imc.org X-Mailer: Apple Mail (2.606) X-OriginalArrivalTime: 26 Oct 2003 19:55:10.0612 (UTC) FILETIME=[101FC540:01C39BFB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9QJtIIA031751 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At the IETF in Minneapolis, there will be a BOF on Internationalized Email Addresses (IEA). It is *preliminary* on the agenda on Monday, November 10, 2003 at 1530-1730. Chairs: Pete Resnick, Patrik Fältström Mailing list:imaa@imc.org (other salient lists include uri@w3.org) Agenda: Agenda Bashing (Chairs) 5 min. Topic Introduction (Chairs) 10 min. Proposals IDNA-Based (Paul Hoffman) 15 min. Infrastructure-Based (John Klensin) 15 min. IRI-Based (Michel Suignard) 15 min. Discussion 60 min. Topics for discussion: Are there other solutions which have been specified? The solutions present the problem at different scopes; Where should the IETF tackle it? Are some short-term, and other long-term? Can the solutions be staged or co-exist? If staged, how to migrate from one to another? What are the next steps for the IETF? NB: This BoF is exploratory in nature, and it is not intended that the IETF will finalize a decision in this venue. It was proposed to foster a community discussion, not charter a working group or pick a winner. If further work is required, step one would be identifying individuals willing to carry that work forward. Reading material: draft-hoffman-imaa-03.txt draft-klensin-emailaddr-i18n-01.txt draft-duerst-iri-04.txt Pete and myself hope people will come with a lot of constructive comments and ideas. Patrik, co-chair of the bof Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MGNxI7049540 for ; Wed, 22 Oct 2003 09:23:59 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MGNxvj049539 for ietf-imapext-bks; Wed, 22 Oct 2003 09:23:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MGNwI7049534 for ; Wed, 22 Oct 2003 09:23:58 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [63.163.82.24] (socrates.cyrusoft.com [63.163.82.24]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id h9MGHHEG012831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Oct 2003 12:17:20 -0400 Date: Wed, 22 Oct 2003 12:24:05 -0400 From: Cyrus Daboo To: Rob Siemborski cc: Arnt Gulbrandsen , IMAP extensions Mailing List Subject: Re: I-D ACTION:draft-daboo-imap-annotatemore-04.txt Message-ID: <2147483647.1066825445@[10.0.1.12]> In-Reply-To: References: <200310211958.PAA04193@ietf.org> <1066798632.10244.6.camel@hurina> <2147483647.1066819234@[10.0.1.12]> <2147483647.1066824623@[10.0.1.12]> X-Mailer: Mulberry/3.1.0b8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Rob, --On Wednesday, October 22, 2003 12:14 -0400 Rob Siemborski wrote: | I did just notice (in the GETANNOTATION text): | | This command is only available in authenticated state [IMAP4]. | | Shouldn't it also be available in the selected state? AFAIK, they aren't | the same. OK - fixed in working copy. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MGECI7049151 for ; Wed, 22 Oct 2003 09:14:12 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MGECxd049150 for ietf-imapext-bks; Wed, 22 Oct 2003 09:14:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MGEAI7049143 for ; Wed, 22 Oct 2003 09:14:10 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9MGE8k4013781; Wed, 22 Oct 2003 12:14:08 -0400 Date: Wed, 22 Oct 2003 12:14:07 -0400 (EDT) From: Rob Siemborski To: Cyrus Daboo cc: Arnt Gulbrandsen , IMAP extensions Mailing List Subject: Re: I-D ACTION:draft-daboo-imap-annotatemore-04.txt In-Reply-To: <2147483647.1066824623@[10.0.1.12]> Message-ID: References: <200310211958.PAA04193@ietf.org> <1066798632.10244.6.camel@hurina> <2147483647.1066819234@[10.0.1.12]> <2147483647.1066824623@[10.0.1.12]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 22 Oct 2003, Cyrus Daboo wrote: > | I tend to agree that punting seems to be the safest option. > > Would you want to restrict GETANNOTATION in the same way? Not offhand, GETANNOTATION can safely suffer partial failures, e.g.: * ANNOTATION * ANNOTATION x NO Couldn't contact some backend servers I did just notice (in the GETANNOTATION text): This command is only available in authenticated state [IMAP4]. Shouldn't it also be available in the selected state? AFAIK, they aren't the same. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MGAGI7049031 for ; Wed, 22 Oct 2003 09:10:16 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MGAGRX049030 for ietf-imapext-bks; Wed, 22 Oct 2003 09:10:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MGAFI7049024 for ; Wed, 22 Oct 2003 09:10:15 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [63.163.82.24] (socrates.cyrusoft.com [63.163.82.24]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id h9MG3ZEG012670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Oct 2003 12:03:37 -0400 Date: Wed, 22 Oct 2003 12:10:23 -0400 From: Cyrus Daboo To: Rob Siemborski , Arnt Gulbrandsen cc: IMAP extensions Mailing List Subject: Re: I-D ACTION:draft-daboo-imap-annotatemore-04.txt Message-ID: <2147483647.1066824623@[10.0.1.12]> In-Reply-To: References: <200310211958.PAA04193@ietf.org> <1066798632.10244.6.camel@hurina> <2147483647.1066819234@[10.0.1.12]> X-Mailer: Mulberry/3.1.0b8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Rob, --On Wednesday, October 22, 2003 12:05 -0400 Rob Siemborski wrote: | On Wed, 22 Oct 2003, Arnt Gulbrandsen wrote: | |> Cyrus Daboo writes: |> > There could be client applications that require an all-or-nothing |> > change. That said having partial failure (or success) responses would |> > be OK too. Either that or we punt the whole question by disallowing |> > multi-mailbox operations in the first place. |> |> Punting seems like a good idea. If necessary, add language mentioning |> that clients can send several store commands at the same time. (That |> should be possible, as I remember the draft... right?) | | I tend to agree that punting seems to be the safest option. Would you want to restrict GETANNOTATION in the same way? -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MG5AI7048885 for ; Wed, 22 Oct 2003 09:05:10 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MG5AZQ048884 for ietf-imapext-bks; Wed, 22 Oct 2003 09:05:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MG56I7048877 for ; Wed, 22 Oct 2003 09:05:07 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9MG53k4013771; Wed, 22 Oct 2003 12:05:03 -0400 Date: Wed, 22 Oct 2003 12:05:02 -0400 (EDT) From: Rob Siemborski To: Arnt Gulbrandsen cc: Cyrus Daboo , IMAP extensions Mailing List Subject: Re: I-D ACTION:draft-daboo-imap-annotatemore-04.txt In-Reply-To: Message-ID: References: <200310211958.PAA04193@ietf.org> <1066798632.10244.6.camel@hurina> <2147483647.1066819234@[10.0.1.12]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 22 Oct 2003, Arnt Gulbrandsen wrote: > Cyrus Daboo writes: > > There could be client applications that require an all-or-nothing > > change. That said having partial failure (or success) responses would > > be OK too. Either that or we punt the whole question by disallowing > > multi-mailbox operations in the first place. > > Punting seems like a good idea. If necessary, add language mentioning > that clients can send several store commands at the same time. (That > should be possible, as I remember the draft... right?) I tend to agree that punting seems to be the safest option. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MFGNI7046110 for ; Wed, 22 Oct 2003 08:16:23 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MFGN9Q046109 for ietf-imapext-bks; Wed, 22 Oct 2003 08:16:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MFGHI7046102 for ; Wed, 22 Oct 2003 08:16:22 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Message-Id: From: Arnt Gulbrandsen To: Cyrus Daboo Subject: Re: I-D ACTION:draft-daboo-imap-annotatemore-04.txt Cc: Rob Siemborski , IMAP extensions Mailing List References: <200310211958.PAA04193@ietf.org> <1066798632.10244.6.camel@hurina> <2147483647.1066819234@[10.0.1.12]> In-Reply-To: <2147483647.1066819234@[10.0.1.12]> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Wed, 22 Oct 2003 17:19:37 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus Daboo writes: > There could be client applications that require an all-or-nothing > change. That said having partial failure (or success) responses would > be OK too. Either that or we punt the whole question by disallowing > multi-mailbox operations in the first place. Punting seems like a good idea. If necessary, add language mentioning that clients can send several store commands at the same time. (That should be possible, as I remember the draft... right?) --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MEeQI7043849 for ; Wed, 22 Oct 2003 07:40:26 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MEeQg7043848 for ietf-imapext-bks; Wed, 22 Oct 2003 07:40:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MEeOI7043843 for ; Wed, 22 Oct 2003 07:40:25 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [10.0.1.12] (socrates.cyrusoft.com [63.163.82.24]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id h9MEXkEG011576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Oct 2003 10:33:49 -0400 Date: Wed, 22 Oct 2003 10:40:34 -0400 From: Cyrus Daboo To: Rob Siemborski , ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-daboo-imap-annotatemore-04.txt Message-ID: <2147483647.1066819234@[10.0.1.12]> In-Reply-To: References: <200310211958.PAA04193@ietf.org> <1066798632.10244.6.camel@hurina> X-Mailer: Mulberry/3.1.0b8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Rob, --On Wednesday, October 22, 2003 10:10 -0400 Rob Siemborski wrote: |> > If the server is unable to store the annotations for one or more |> > mailboxes matching the mailbox-name pattern, then the SETANNOTATION |> > command MUST fail and there MUST NOT be any changes to any of the |> > matching mailboxes, even those for which annotations could have been |> > changed successfully. |> |> So you want to limit ANNOTATEMORE to work only with servers using |> transactional databases? | | This worries me, as it is a pretty severe implementation burden on IMAP | proxies as well. | |> Maybe SETANNOTATION could rather just send untagged replies for |> mailboxes it changes? | | Or perhaps untagged NO responses for those annotations it couldn't change. There could be client applications that require an all-or-nothing change. That said having partial failure (or success) responses would be OK too. Either that or we punt the whole question by disallowing multi-mailbox operations in the first place. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MEAwI7042643 for ; Wed, 22 Oct 2003 07:10:58 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MEAwHn042642 for ietf-imapext-bks; Wed, 22 Oct 2003 07:10:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MEAuI7042636 for ; Wed, 22 Oct 2003 07:10:56 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9MEAtk4013621 for ; Wed, 22 Oct 2003 10:10:55 -0400 Date: Wed, 22 Oct 2003 10:10:56 -0400 (EDT) From: Rob Siemborski To: ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-daboo-imap-annotatemore-04.txt In-Reply-To: <1066798632.10244.6.camel@hurina> Message-ID: References: <200310211958.PAA04193@ietf.org> <1066798632.10244.6.camel@hurina> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 22 Oct 2003, Timo Sirainen wrote: > > If the server is unable to store the annotations for one or more > > mailboxes matching the mailbox-name pattern, then the SETANNOTATION > > command MUST fail and there MUST NOT be any changes to any of the > > matching mailboxes, even those for which annotations could have been > > changed successfully. > > So you want to limit ANNOTATEMORE to work only with servers using > transactional databases? This worries me, as it is a pretty severe implementation burden on IMAP proxies as well. > Maybe SETANNOTATION could rather just send untagged replies for > mailboxes it changes? Or perhaps untagged NO responses for those annotations it couldn't change. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9M4vLI7054523 for ; Tue, 21 Oct 2003 21:57:21 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9M4vLOi054522 for ietf-imapext-bks; Tue, 21 Oct 2003 21:57:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9M4vJI7054513 for ; Tue, 21 Oct 2003 21:57:20 -0700 (PDT) (envelope-from tss@iki.fi) Received: from localhost.kpnqwest.fi (localhost [127.0.0.1]) by oma.irssi.org (Postfix) with ESMTP id 52F685C616E3 for ; Wed, 22 Oct 2003 07:57:13 +0300 (EEST) Subject: Re: I-D ACTION:draft-daboo-imap-annotatemore-04.txt From: Timo Sirainen To: ietf-imapext@imc.org In-Reply-To: <200310211958.PAA04193@ietf.org> References: <200310211958.PAA04193@ietf.org> Content-Type: text/plain Message-Id: <1066798632.10244.6.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Wed, 22 Oct 2003 07:57:12 +0300 Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > If the server is unable to store the annotations for one or more > mailboxes matching the mailbox-name pattern, then the SETANNOTATION > command MUST fail and there MUST NOT be any changes to any of the > matching mailboxes, even those for which annotations could have been > changed successfully. So you want to limit ANNOTATEMORE to work only with servers using transactional databases? Maybe SETANNOTATION could rather just send untagged replies for mailboxes it changes? Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LKpXI7039742 for ; Tue, 21 Oct 2003 13:51:33 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LKpX09039740 for ietf-imapext-bks; Tue, 21 Oct 2003 13:51:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LKpWI7039734 for ; Tue, 21 Oct 2003 13:51:33 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [63.163.82.24]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id h9LKj2EG031301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Oct 2003 16:45:06 -0400 Received: from mx3.andrew.cmu.edu (MX3.andrew.cmu.edu [128.2.10.113]) by mail1.andrew.cmu.edu (Cyrus v2.1.15-077) with LMTP; Tue, 21 Oct 2003 16:39:03 -0400 X-Sieve: CMU Sieve 2.2 Received: from mx3.andrew.cmu.edu ([unix socket]) by mx3.andrew.cmu.edu (Cyrus v2.1.12-075) with LMTP; Tue, 21 Oct 2003 16:39:02 -0400 Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx3.andrew.cmu.edu (8.12.10/8.12.9) with ESMTP id h9LKcu85001100; Tue, 21 Oct 2003 16:38:57 -0400 Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1AC2ls-0005Oy-1t for ietf-announce-list@asgard.ietf.org; Tue, 21 Oct 2003 16:06:24 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1AC2eR-0005AF-H0 for all-ietf@asgard.ietf.org; Tue, 21 Oct 2003 15:58:43 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04193 for ; Tue, 21 Oct 2003 15:58:32 -0400 (EDT) Message-Id: <200310211958.PAA04193@ietf.org> To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 21 Oct 2003 15:58:32 -0400 Subject: I-D ACTION:draft-daboo-imap-annotatemore-04.txt X-Resent-Mailer: Mulberry/3.1.0b8 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========1DDCBDEFA700D5D5269E==========" X-Spam-Level: **** Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --==========1DDCBDEFA700D5D5269E========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IMAP ANNOTATEMORE Extension Author(s) : C. Daboo Filename : draft-daboo-imap-annotatemore-04.txt Pages : 17 Date : 2003-10-21 The ANNOTATEMORE extension to the Internet Message Access Protocol [IMAP4] permits clients and servers to maintain 'metadata' on IMAP4 servers. It is possible to store data on a per-mailbox basis or on the server as a whole. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-daboo-imap-annotatemore-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-daboo-imap-annotatemore-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-daboo-imap-annotatemore-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --==========1DDCBDEFA700D5D5269E========== Content-Type: multipart/alternative; boundary="==========12F7B0FC35D353082042==========" --==========12F7B0FC35D353082042========== Content-Type: message/external-body; ACCESS-TYPE=mail-server; SERVER="mailserv@ietf.org" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-10-21153612.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-daboo-imap-annotatemore-04.txt --==========12F7B0FC35D353082042========== Content-Type: message/external-body; name="draft-daboo-imap-annotatemore-04.txt"; SITE="ftp.ietf.org"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-10-21153612.I-D@ietf.org> --==========12F7B0FC35D353082042==========-- --==========1DDCBDEFA700D5D5269E==========-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LK1KI7038236 for ; Tue, 21 Oct 2003 13:01:20 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LK1K30038235 for ietf-imapext-bks; Tue, 21 Oct 2003 13:01:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LK1II7038230 for ; Tue, 21 Oct 2003 13:01:19 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04903; Tue, 21 Oct 2003 16:01:09 -0400 (EDT) Message-Id: <200310212001.QAA04903@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-annotate-08.txt Date: Tue, 21 Oct 2003 16:01:09 -0400 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF. Title : IMAP ANNOTATE Extension Author(s) : R. Gellens, C. Daboo Filename : draft-ietf-imapext-annotate-08.txt Pages : 22 Date : 2003-10-21 The ANNOTATE extension to the Internet Message Access Protocol [IMAP4] permits clients and servers to maintain 'metadata' for messages stored in an IMAP4 mailbox. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-imapext-annotate-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imapext-annotate-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-21154123.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-annotate-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-annotate-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-21154123.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9KM8XI7011823 for ; Mon, 20 Oct 2003 15:08:33 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9KM8XWj011822 for ietf-imapext-bks; Mon, 20 Oct 2003 15:08:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from episteme-software.com (216-43-25-66.ip.mcleodusa.net [216.43.25.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9KM8WI7011817 for ; Mon, 20 Oct 2003 15:08:32 -0700 (PDT) (envelope-from presnick@qualcomm.com) Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b1); Mon, 20 Oct 2003 17:08:39 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: X-Mailer: Eudora [Macintosh version 6.1a2] Date: Mon, 20 Oct 2003 17:08:32 -0500 To: Lemonade From: Pete Resnick Subject: IMAP COMPOSE extension Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [Bcc'ed to IMAPEXT; please followup to LEMONADE] I didn't have time last week to finish an I-D before the deadline, but I figured I should at least start the conversation on the list before Minneapolis. When talking about IMAP Push vs. IMAP Pull for "forward without download" in Vienna, a lot of us thought that in either case, it would be handy to have an an IMAP COMPOSE command. The idea here would be COMPOSE would be pretty much like APPEND (with the mailbox in which to append, an optional flag list and optional date/time string), except that instead of a message literal, it would take as parameters any number of literals and "message part identifiers". All of the literals and the message parts would be appended together in the destination mailbox as one big message. The client would be responsible for providing the appropriate MIME boundaries in the literals. Having a composed message on the IMAP server would work for either IMAP push or IMAP pull, and this would obviously be useful for more than just "forward without download". However, I still have some issues with the exact nature of this command. Specifically, my big question is how to deal with the "message part identifiers". A message part identifier would clearly include a sequence number or UID followed by message data item names or a macro, just like FETCH. However, the downside to making it look exactly like the FETCH parameters is that you can only compose a message made up of parts that are contained in the currently selected mailbox. Maybe that is sufficient given the application for which LEMONADE wants this, but it's clearly a limitation. The other choice is that the message part identifier would also include a mailbox name. We could come up with some syntax for that or just use a relative IMAP URL. Of course, the upside is that you'd be able to collect together messages in different parts of the IMAP store. But there are a couple of really big downsides: 1. It breaks the assumption that you only ever have one mailbox selected. In effect, you'd be required on the server to access multiple mailboxes in the course of a single command execution. Maybe that's OK to require for this extension; maybe not. 2. If it is allowed to be other than a relative URL to *this* IMAP server, suddenly you get into the business of doing all of the IMAP client work that folks were so worried about when this discussion started. 3. Allowing it to be a URL might start us down the slippery slope of allowing *any* kind of URL, not just IMAP. The results of that are left as an exercise to the reader. Having the more general syntax (i.e., something that includes the mailbox) might be nice for folks who want to do fancier things in the future. We could allow any server to say "NO" if given something with another mailbox (or server, or scheme). Or maybe we don't want to do this at all. Feedback desired. I'll float a straw-man proposal to the list (which obviously won't make it as an I-D for Minneapolis) as soon as I can. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IA4MI7010149 for ; Sat, 18 Oct 2003 03:04:22 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9IA4M1o010148 for ietf-imapext-bks; Sat, 18 Oct 2003 03:04:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IA4KI7010143 for ; Sat, 18 Oct 2003 03:04:20 -0700 (PDT) (envelope-from mganesh@india.hp.com) Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by atlrel6.hp.com (Postfix) with ESMTP id EEA951C0111F; Sat, 18 Oct 2003 06:04:15 -0400 (EDT) Received: from nt23060 (nt23060.india.hp.com [15.42.230.60]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id PAA07255; Sat, 18 Oct 2003 15:33:04 +0530 (IST) From: "Madan Ganesh Velayudham" To: "'Lyndon Nerenberg'" Cc: "'IMAP Extensions WG'" Subject: RE: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt Date: Sat, 18 Oct 2003 15:34:13 +0530 Organization: Hewlett-Packard STSD Message-ID: <00dd01c3955f$2f998d90$3ce62a0f@nt23060> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <700090757.1066396251@[192.168.42.6]> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: owner-ietf-imapext@mail.imc.org > [mailto:owner-ietf-imapext@mail.imc.org] On Behalf Of Lyndon Nerenberg > Sent: Saturday, October 18, 2003 12:41 AM > To: Madan Ganesh Velayudham > Cc: 'IMAP Extensions WG' > Subject: RE: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt > > > > > I understand them clearly. My belif is that my solution > > would have some performance benefits compared having them > > externally. > > Then do the math and prove it. Definitely. > > > I will try to find some loop holes in sieve for arugments :-) > > Please stop wasting our time. We do engineering here. > Marketing is down > the hall. That was just a comment. Pls donot take it seriously. > > --lyndon > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9HJB3I7022434 for ; Fri, 17 Oct 2003 12:11:03 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9HJB362022433 for ietf-imapext-bks; Fri, 17 Oct 2003 12:11:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9HJB2I7022427 for ; Fri, 17 Oct 2003 12:11:02 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Received: from [192.168.42.6] (peregrin.orthanc.ca [192.168.42.6]) by orthanc.ca (8.12.9p1/8.12.9) with ESMTP id h9HJB0P5058981; Fri, 17 Oct 2003 13:11:00 -0600 (MDT) (envelope-from lyndon@orthanc.ca) Date: Fri, 17 Oct 2003 13:10:51 -0600 From: Lyndon Nerenberg To: Madan Ganesh Velayudham cc: "'IMAP Extensions WG'" Subject: RE: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt Message-ID: <700090757.1066396251@[192.168.42.6]> In-Reply-To: <000301c394a6$afa405b0$3ce62a0f@nt23060> References: <000301c394a6$afa405b0$3ce62a0f@nt23060> X-Mailer: Mulberry/3.1.0b8 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========10C64BD7E4C20F34569B==========" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --==========10C64BD7E4C20F34569B========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > I understand them clearly. My belif is that my solution > would have some performance benefits compared having them > externally. Then do the math and prove it. > I will try to find some loop holes in sieve for arugments :-) Please stop wasting our time. We do engineering here. Marketing is down=20 the hall. --lyndon --==========10C64BD7E4C20F34569B========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: Mulberry PGP Plugin v3.0 Comment: processed by Mulberry PGP Plugin iQA/AwUBP5A+w+LnPQjwN7SAEQJklQCdHaNdBQzV8/G7ohcbdE4Qcj8k3osAoL1/ vyEWrXKiz6vz0nT+vnLZhq3M =CUFM -----END PGP SIGNATURE----- --==========10C64BD7E4C20F34569B==========-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9HDJ6I7009929 for ; Fri, 17 Oct 2003 06:19:06 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9HDJ6ST009928 for ietf-imapext-bks; Fri, 17 Oct 2003 06:19:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9HDJ4I7009923 for ; Fri, 17 Oct 2003 06:19:05 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9HDJ2k4004101; Fri, 17 Oct 2003 09:19:02 -0400 Date: Fri, 17 Oct 2003 09:19:02 -0400 (EDT) From: Rob Siemborski To: Madan Ganesh Velayudham cc: "'Mark Crispin'" , "'IMAP Extensions WG'" Subject: RE: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt In-Reply-To: <000301c394a6$afa405b0$3ce62a0f@nt23060> Message-ID: References: <000301c394a6$afa405b0$3ce62a0f@nt23060> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 17 Oct 2003, Madan Ganesh Velayudham wrote: > Thanks for your recommendations. Could you please get > me the wg that analyzes sieve. There is currently no working group, however there are a bunch of people who read the ietf-mta-filters@imc.org list. http://www.imc.org/ietf-mta-filters/index.html -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9HCmTI7008827 for ; Fri, 17 Oct 2003 05:48:29 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9HCmT5O008826 for ietf-imapext-bks; Fri, 17 Oct 2003 05:48:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9HCmOI7008818 for ; Fri, 17 Oct 2003 05:48:28 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Message-Id: From: Arnt Gulbrandsen To: Cyrus Daboo Subject: Re: SASL Initial Response? Cc: Ken Murchison , Rob Siemborski , Mark Crispin , IMAP Extensions WG References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> <3F8305BF.2050706@oceana.com> <2147483647.1066304385@socrates.cyrusoft.com> <2147483647.1066311186@socrates.cyrusoft.com> In-Reply-To: <2147483647.1066311186@socrates.cyrusoft.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Fri, 17 Oct 2003 14:51:16 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus Daboo writes: > A summary of the profiles and mechanisms - not a full detailed > description of each. This could be as simple as a table listing which > options a particular protocol's profile provides. e.g.: That table belongs on www.iana.org, doesn't it? Like the (hopelessly outdated) IMAP extensions page. > | b) a document that points out common errors in SASL implementations > > Yes.. Like 2683? Good idea, but I can't even comment on it, far less suggest appropriate content. --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9HC3aI7007805 for ; Fri, 17 Oct 2003 05:03:36 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9HC3asI007804 for ietf-imapext-bks; Fri, 17 Oct 2003 05:03:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9HC3ZI7007799 for ; Fri, 17 Oct 2003 05:03:35 -0700 (PDT) (envelope-from mganesh@india.hp.com) Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel12.hp.com (Postfix) with ESMTP id 3873C1C02155; Fri, 17 Oct 2003 05:03:34 -0700 (PDT) Received: from nt23060 (nt23060.india.hp.com [15.42.230.60]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id RAA25058; Fri, 17 Oct 2003 17:32:18 +0530 (IST) From: "Madan Ganesh Velayudham" To: "'Mark Crispin'" Cc: "'IMAP Extensions WG'" Subject: RE: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt Date: Fri, 17 Oct 2003 17:33:26 +0530 Organization: Hewlett-Packard STSD Message-ID: <000301c394a6$afa405b0$3ce62a0f@nt23060> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > Capabilities are defined in RFC 3501 as atoms. You can not > have multi-atom capabilities. This is an ongoing design > issue which other capabilities have had to face (and has had > considerable discussion) but as yet there is no clear solution. > Thanks for the explanation. > I need to reiterate that sieve already has this > functionality, and quite a bit more. You should be looking > into sieve rather than trying to shoehorn an orthogonal (and > much less functional) capability into IMAP. Hmm.. That was an effort to embedd the logic in IMAP. I will analyze further on this. > > In most environments, filters are done in the MTA and/or MDA, > especially when a filter is a defined set of rules which are > executed for all incoming mail. Filters are generally not > done in the MUA (such as an IMAP > server) because of the problem of executing a filter > repetitively on the same data; when it is done the MUA often > has to undertake heroic (and sometimes unsuccessful) efforts > to avoid this problem. > > In most environments, IMAP servers are completely separate > from the MTA and MDA. There would be a substantial > implementation burden to create an intercommunication of > filtering information between the IMAP server and a separate > MTA/MDA (perhaps from a different vendor). > > It is not likely that you will have much success convincing > either IMAP or MTA/MDA server implementors to implement your > extension, especially since sieve already addresses these > needs and quite a bit more. > > In general, IETF protocols avoid having multiple solutions > for the same problem. When multiple solutions exist, there > is strong pressure to have one solution win and the others I understand them clearly. My belif is that my solution would have some performance benefits compared having them externally. I will try to find some loop holes in sieve for arugments :-) > pass into oblivion. For many years, there was such pressure > between IMAP and POP since these two protocols seemingly did > the same thing. And, to be honest, it is likely that IMAP > would not have happened had I known about POP. I like this point very much :-) > > I strongly urge you to look into sieve, and become involved > in that development effort. You will find many helpful > people working on sieve, and you'll achieve your goals much > faster. Otherwise, you are likely to end up having wasted > your time (and other people's time) with no results to show for it. Thanks for your recommendations. Could you please get me the wg that analyzes sieve. +MG > -----Original Message----- > From: Mark Crispin [mailto:mrc@CAC.Washington.EDU] > Sent: Friday, October 17, 2003 12:35 AM > To: Madan Ganesh Velayudham > Cc: 'IMAP Extensions WG'; madan-ganesh.v@hp.com > Subject: RE: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt > > > On Fri, 17 Oct 2003, Madan Ganesh Velayudham wrote: > > * CAPABILITY IMAP4rev1 AUTH=DIGEST-MD5ORGANIZE=ADD,UPDATE > > [APPEND,DELETE,STORE],REMOVE,ENABLE,DISABLE,LIST > > > > I understand [APPEND, ... ] is the one which you are > > mentioning. Pls correct me if I'm wrong. I shall correct it > > while refining the draft. > > Capabilities are defined in RFC 3501 as atoms. You can not > have multi-atom capabilities. This is an ongoing design > issue which other capabilities have had to face (and has had > considerable discussion) but as yet there is no clear solution. > > > > As such, this functionality does not seem to be within > the scope of > > > IMAP; and instead belongs with Sieve. > > + Client need nt do extra operations. > > > > + I'm trying to leverage already available IMAP commands > > ( APPEND, STORE, Search Criterias, etc., ) to implement > > this organization of message for user. I feel there wont be > > much implementation strain : code reusability. > > > > + Many customers would be interested in single entity which > > will do the required tasks instead of having two independent > > entities. > > I need to reiterate that sieve already has this > functionality, and quite a bit more. You should be looking > into sieve rather than trying to shoehorn an orthogonal (and > much less functional) capability into IMAP. > > In most environments, filters are done in the MTA and/or MDA, > especially when a filter is a defined set of rules which are > executed for all incoming mail. Filters are generally not > done in the MUA (such as an IMAP > server) because of the problem of executing a filter > repetitively on the same data; when it is done the MUA often > has to undertake heroic (and sometimes unsuccessful) efforts > to avoid this problem. > > In most environments, IMAP servers are completely separate > from the MTA and MDA. There would be a substantial > implementation burden to create an intercommunication of > filtering information between the IMAP server and a separate > MTA/MDA (perhaps from a different vendor). > > It is not likely that you will have much success convincing > either IMAP or MTA/MDA server implementors to implement your > extension, especially since sieve already addresses these > needs and quite a bit more. > > In general, IETF protocols avoid having multiple solutions > for the same problem. When multiple solutions exist, there > is strong pressure to have one solution win and the others > pass into oblivion. For many years, there was such pressure > between IMAP and POP since these two protocols seemingly did > the same thing. And, to be honest, it is likely that IMAP > would not have happened had I known about POP. > > I strongly urge you to look into sieve, and become involved > in that development effort. You will find many helpful > people working on sieve, and you'll achieve your goals much > faster. Otherwise, you are likely to end up having wasted > your time (and other people's time) with no results to show for it. > > -- Mark -- > http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GLOvI7010783 for ; Thu, 16 Oct 2003 14:24:57 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GLOu2Z010782 for ietf-imapext-bks; Thu, 16 Oct 2003 14:24:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GLOtI7010769 for ; Thu, 16 Oct 2003 14:24:55 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Received: from [192.168.42.6] (peregrin.orthanc.ca [192.168.42.6]) by orthanc.ca (8.12.9p1/8.12.9) with ESMTP id h9GLOnP5054037; Thu, 16 Oct 2003 15:24:49 -0600 (MDT) (envelope-from lyndon@orthanc.ca) Date: Thu, 16 Oct 2003 15:24:43 -0600 From: Lyndon Nerenberg To: madan-ganesh.v@hp.com cc: ietf-imapext@imc.org Subject: IMAP Organize Extension Message-ID: <2147483647.1066317883@[192.168.42.6]> X-Mailer: Mulberry/3.1.0b8 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========C47C3D6041106DB99DBE==========" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --==========C47C3D6041106DB99DBE========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline The functionality of Organize already exists in SIEVE. Pushing the configuration of MDA filters into multiple unrelated=20 protocols is just bad engineering. Also, this document falsely claims to be a product of the WG, which it is = not. It's not even within the scope of the WG charter. This draft should be withdrawn immediately. We should instead focus on=20 getting ManageSieve onto the standards track. --lyndon --==========C47C3D6041106DB99DBE========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: Mulberry PGP Plugin v3.0 Comment: processed by Mulberry PGP Plugin iQA/AwUBP48MoeLnPQjwN7SAEQIM2gCeJ04vc4ig4m8k2z1nQKvJBiwx6/MAn1gn 6CeOFyF947RFvzm0u2/DbDPq =5qsS -----END PGP SIGNATURE----- --==========C47C3D6041106DB99DBE==========-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GKPAI7006556 for ; Thu, 16 Oct 2003 13:25:12 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GKPAHk006555 for ietf-imapext-bks; Thu, 16 Oct 2003 13:25:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GKP8I7006547 for ; Thu, 16 Oct 2003 13:25:08 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9GKNsk4002841; Thu, 16 Oct 2003 16:23:54 -0400 Date: Thu, 16 Oct 2003 16:23:55 -0400 (EDT) From: Rob Siemborski To: Madan Ganesh Velayudham cc: "'Mark Crispin'" , "'IMAP Extensions WG'" , madan-ganesh.v@hp.com Subject: RE: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt In-Reply-To: <000e01c39418$4731fc50$3ce62a0f@nt23060> Message-ID: References: <000e01c39418$4731fc50$3ce62a0f@nt23060> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 17 Oct 2003, Madan Ganesh Velayudham wrote: > > In fact, it seems to me that sieve is more flexible than this > > extension ever could be, since it is embeddable without > > protocol changes in any mail handling program (IMAP server, > > LMTP/SMTP server, POP client, etc). > > > + Many customers would be interested in single entity which > will do the required tasks instead of having two independent > entities. What users may perceive as a single entity does not need to be a single protocol on the wire. In fact, a single server product can support multiple protocols and provide this functionality and the administrators can still see it as a single product. For example, Cyrus implements mail filtering with Sieve scripts that can be manage remotely without touching the IMAP protocol at all. Users can have a mail client that supports both IMAP and MANAGESIEVE and have it maintain their filters *and* read their mail. The client can even support Sieve itself and provide a GUI to manipulate the filters. This doesn't require an extension to IMAP, and Sieve is already more flexible than the much more limited set of IMAP operations (In addition to simple file/reject/discard type actions, there are currently extensions for vacation messages, spam/virus scoring, regular expressions, relational comparisons and so on). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GJd4I7002226 for ; Thu, 16 Oct 2003 12:39:04 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GJd4fc002224 for ietf-imapext-bks; Thu, 16 Oct 2003 12:39:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GJd2I7002210 for ; Thu, 16 Oct 2003 12:39:03 -0700 (PDT) (envelope-from tony@att.com) Received: from maillennium.att.com ([135.25.114.99]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h9GJcxOa014201 for ; Thu, 16 Oct 2003 14:38:59 -0500 Received: from att.com (unknown[135.210.73.148](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20031016193615gw100lr88ne> (Authid: tony); Thu, 16 Oct 2003 19:36:16 +0000 Message-ID: <3F8EF3CF.7030101@att.com> Date: Thu, 16 Oct 2003 15:38:55 -0400 From: Tony Hansen User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: IMAP Extensions WG Subject: Re: SASL Initial Response? References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> <3F8305BF.2050706@oceana.com> <2147483647.1066304385@socrates.cyrusoft.com> <3F8EDE30.8070501@isode.com> In-Reply-To: <3F8EDE30.8070501@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > As I am the guilty party I should probably comment on this. It is quite > common for base64 encoding/decoding to be implemented by utility > functions that you steal from your friend or just implemented in a > library written by somebody-who-no-longer-works-for-the-company ten > years ago. These functions may have assumptions quite different from > those of IMAP AUTHENTICATE, because they could have been written for a > different environment. For example they were originally used to handle > MIME base64, which allows for spaces and CRLFs. Ditto. I was using a base64 library and it worked great, until I had a string that caused the base64 output to be >76 characters and it inserted a crlf. Sigh. Tony Hansen tony@att.com Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GJ5iI7000981 for ; Thu, 16 Oct 2003 12:05:44 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GJ5i4P000980 for ietf-imapext-bks; Thu, 16 Oct 2003 12:05:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GJ5hI7000975 for ; Thu, 16 Oct 2003 12:05:43 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout2.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9GJ4phu021171; Thu, 16 Oct 2003 12:04:52 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9GJ4p1T003590; Thu, 16 Oct 2003 12:04:51 -0700 Date: Thu, 16 Oct 2003 12:04:51 -0700 (PDT) From: Mark Crispin To: Madan Ganesh Velayudham cc: "'IMAP Extensions WG'" , madan-ganesh.v@hp.com Subject: RE: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt In-Reply-To: <000201c39414$7b9c8d60$3ce62a0f@nt23060> Message-ID: References: <000201c39414$7b9c8d60$3ce62a0f@nt23060> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 17 Oct 2003, Madan Ganesh Velayudham wrote: > * CAPABILITY IMAP4rev1 AUTH=DIGEST-MD5ORGANIZE=ADD,UPDATE > [APPEND,DELETE,STORE],REMOVE,ENABLE,DISABLE,LIST > > I understand [APPEND, ... ] is the one which you are > mentioning. Pls correct me if I'm wrong. I shall correct it > while refining the draft. Capabilities are defined in RFC 3501 as atoms. You can not have multi-atom capabilities. This is an ongoing design issue which other capabilities have had to face (and has had considerable discussion) but as yet there is no clear solution. > > As such, this functionality does not seem to be within the > > scope of IMAP; and instead belongs with Sieve. > + Client need nt do extra operations. > > + I'm trying to leverage already available IMAP commands > ( APPEND, STORE, Search Criterias, etc., ) to implement > this organization of message for user. I feel there wont be > much implementation strain : code reusability. > > + Many customers would be interested in single entity which > will do the required tasks instead of having two independent > entities. I need to reiterate that sieve already has this functionality, and quite a bit more. You should be looking into sieve rather than trying to shoehorn an orthogonal (and much less functional) capability into IMAP. In most environments, filters are done in the MTA and/or MDA, especially when a filter is a defined set of rules which are executed for all incoming mail. Filters are generally not done in the MUA (such as an IMAP server) because of the problem of executing a filter repetitively on the same data; when it is done the MUA often has to undertake heroic (and sometimes unsuccessful) efforts to avoid this problem. In most environments, IMAP servers are completely separate from the MTA and MDA. There would be a substantial implementation burden to create an intercommunication of filtering information between the IMAP server and a separate MTA/MDA (perhaps from a different vendor). It is not likely that you will have much success convincing either IMAP or MTA/MDA server implementors to implement your extension, especially since sieve already addresses these needs and quite a bit more. In general, IETF protocols avoid having multiple solutions for the same problem. When multiple solutions exist, there is strong pressure to have one solution win and the others pass into oblivion. For many years, there was such pressure between IMAP and POP since these two protocols seemingly did the same thing. And, to be honest, it is likely that IMAP would not have happened had I known about POP. I strongly urge you to look into sieve, and become involved in that development effort. You will find many helpful people working on sieve, and you'll achieve your goals much faster. Otherwise, you are likely to end up having wasted your time (and other people's time) with no results to show for it. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GJ4DI7000925 for ; Thu, 16 Oct 2003 12:04:13 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GJ4DEZ000924 for ietf-imapext-bks; Thu, 16 Oct 2003 12:04:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GJ4BI7000919 for ; Thu, 16 Oct 2003 12:04:11 -0700 (PDT) (envelope-from mganesh@india.hp.com) Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel13.hp.com (Postfix) with ESMTP id DC8971C00C36; Thu, 16 Oct 2003 12:04:10 -0700 (PDT) Received: from nt23060 (nt23060.india.hp.com [15.42.230.60]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id AAA09665; Fri, 17 Oct 2003 00:32:59 +0530 (IST) From: "Madan Ganesh Velayudham" To: "'Rob Siemborski'" , "'Mark Crispin'" Cc: "'IMAP Extensions WG'" , Subject: RE: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt Date: Fri, 17 Oct 2003 00:34:07 +0530 Organization: Hewlett-Packard STSD Message-ID: <000e01c39418$4731fc50$3ce62a0f@nt23060> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Rob, Thanks for your comments. > -----Original Message----- > From: owner-ietf-imapext@mail.imc.org > [mailto:owner-ietf-imapext@mail.imc.org] On Behalf Of Rob Siemborski > Sent: Thursday, October 16, 2003 2:21 AM > To: Mark Crispin > Cc: IMAP Extensions WG; madan-ganesh.v@hp.com > Subject: Re: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt > > > > On Wed, 15 Oct 2003, Mark Crispin wrote: > > > As such, this functionality does not seem to be within the scope of > > IMAP; and instead belongs with Sieve. Not withstanding the > attractive > > nuisance of rendering IMAP into Exchange ("shove everything > remotely > > related to email into one protocol"), I don't see how ORGANIZE > > provides any added value over Sieve. > > I agree with Mark's comments. I don't see any win here over > sieve, except that the client can avoid making the additional > MANAGESIEVE connection to update its filtering rules, which > is not compelling enough to try to reimplement all of Sieve's > functionality inside of the IMAP protocol. As I mentioned in Mark's reply, I'm trying to leverage existing IMAP commands feature to orgainze user mails. > > (Which reminds me -- MANAGESIEVE has yet to be published as > an RFC, I should probably bother Tim again). I've just went through the abstract of it and understand that managing sieve script remotely. > > In fact, it seems to me that sieve is more flexible than this > extension ever could be, since it is embeddable without > protocol changes in any mail handling program (IMAP server, > LMTP/SMTP server, POP client, etc). > + Many customers would be interested in single entity which will do the required tasks instead of having two independent entities. Please let me know your comments. Thanks again, MG > -Rob > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Rob Siemborski | Andrew Systems Group * Research Systems > Programmer PGP:0x5CE32FCC | Cyert Hall 207 * > rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- > Version: 3.12 > GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ > N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ > DI+++ G e h r- y? ------END GEEK CODE BLOCK----- > > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GIb3I7099488 for ; Thu, 16 Oct 2003 11:37:03 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GIb3Bk099487 for ietf-imapext-bks; Thu, 16 Oct 2003 11:37:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GIb2I7099478 for ; Thu, 16 Oct 2003 11:37:02 -0700 (PDT) (envelope-from mganesh@india.hp.com) Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by atlrel6.hp.com (Postfix) with ESMTP id 512BF1C02475; Thu, 16 Oct 2003 14:37:01 -0400 (EDT) Received: from nt23060 (nt23060.india.hp.com [15.42.230.60]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id AAA08091; Fri, 17 Oct 2003 00:05:45 +0530 (IST) From: "Madan Ganesh Velayudham" To: "'Mark Crispin'" , "'IMAP Extensions WG'" Cc: Subject: RE: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt Date: Fri, 17 Oct 2003 00:06:53 +0530 Organization: Hewlett-Packard STSD Message-ID: <000201c39414$7b9c8d60$3ce62a0f@nt23060> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Mark, Thanks for your comments. > -----Original Message----- > From: owner-ietf-imapext@mail.imc.org > [mailto:owner-ietf-imapext@mail.imc.org] On Behalf Of Mark Crispin > Sent: Thursday, October 16, 2003 1:41 AM > To: IMAP Extensions WG > Cc: madan-ganesh.v@hp.com > Subject: Re: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt > > > > Leaving aside the bugs in this specification (for example, > the added capabilities violate RFC 3501, security > considerations are glossed over), it seems that the purpose > of this proposed extension is not to "organize", but rather > to define MDA filtering rules. * CAPABILITY IMAP4rev1 AUTH=DIGEST-MD5ORGANIZE=ADD,UPDATE [APPEND,DELETE,STORE],REMOVE,ENABLE,DISABLE,LIST I understand [APPEND, ... ] is the one which you are mentioning. Pls correct me if I'm wrong. I shall correct it while refining the draft. Since the ORGANIZE command is in autenticated state, only users with proper credentials can have access to PUOT. I will definitely elaborate 3.2 Section ... [ When the IMAP server receives... It performs the specified action.. ] to include more implementation issues. How IMAP could behave for append, delete, store operations. In future, I would like expand these operations to include forwarding messages, automatic response for messages, etc. I could understand that the much emphasis is on define organizing (filtering) rules. I understand I should elaborate it. > > As such, this functionality does not seem to be within the > scope of IMAP; and instead belongs with Sieve. Not > withstanding the attractive nuisance of rendering IMAP into > Exchange ("shove everything remotely related to email into > one protocol"), I don't see how ORGANIZE provides any added > value over Sieve. + Client need nt do extra operations. + I'm trying to leverage already available IMAP commands ( APPEND, STORE, Search Criterias, etc., ) to implement this organization of message for user. I feel there wont be much implementation strain : code reusability. + Many customers would be interested in single entity which will do the required tasks instead of having two independent entities. > > The proposed SMTP extension for ORGANIZE is bizarre. The > purpose seems to be to shoehorn manipulation of MDA filtering > rules into yet another orthogonal protocol (plus note the > syntax errors in the example). The SMTP extensions people > can shoot that down. > I understand it and will definitely correct any errors. Actually, the idea that I came to me, just thought capture them in the draft merely I don't want to extent this part. This is just an idea. Thanks again, MG > -- Mark -- > http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GI6sI7098610 for ; Thu, 16 Oct 2003 11:06:54 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GI6slB098608 for ietf-imapext-bks; Thu, 16 Oct 2003 11:06:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GI6mI7098601 for ; Thu, 16 Oct 2003 11:06:53 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Thu, 16 Oct 2003 19:06:53 +0100 Message-ID: <3F8EDE30.8070501@isode.com> Date: Thu, 16 Oct 2003 19:06:40 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Crispin CC: Rob Siemborski , Cyrus Daboo , Ken Murchison , IMAP Extensions WG Subject: Re: SASL Initial Response? References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> <3F8305BF.2050706@oceana.com> <2147483647.1066304385@socrates.cyrusoft.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: >Another damning point. Just recently, it was claimed that RFC 3501 does >not enforce BASE64 syntax in the AUTHENTICATE command. The Formal Syntax >says otherwise; but that was countered with "nobody reads the formal >syntax." Or, as in the case with Courier server, the formal syntax is >openly defied if it does not match how the implementor chooses to >interpret the main text. > As I am the guilty party I should probably comment on this. It is quite common for base64 encoding/decoding to be implemented by utility functions that you steal from your friend or just implemented in a library written by somebody-who-no-longer-works-for-the-company ten years ago. These functions may have assumptions quite different from those of IMAP AUTHENTICATE, because they could have been written for a different environment. For example they were originally used to handle MIME base64, which allows for spaces and CRLFs. (And I am actually talking from my own experience and I've ended up discovering certain side effects of a base64 decoder I has borrowed). So, explicitly emphasizing some problems with existing base64 decoders will not hurt. >Perhaps if we lived in a world in which it was a criminal offense to >distribute non-compliant protocol implementations, we might see greater >attention to specifications. I don't see that happening; if anything I >see an increasingly lackadasical approach to specifications. > >Thus, we need more pedagogical texts, separate from the specifications, if >we hope to retain any interoperability at all. > Exactly. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GHbtI7097380 for ; Thu, 16 Oct 2003 10:37:55 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GHbtQr097379 for ietf-imapext-bks; Thu, 16 Oct 2003 10:37:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GHbsI7097372 for ; Thu, 16 Oct 2003 10:37:54 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout2.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9GHbhhu004895; Thu, 16 Oct 2003 10:37:48 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9GHbhjJ027922; Thu, 16 Oct 2003 10:37:43 -0700 Date: Thu, 16 Oct 2003 10:37:43 -0700 (PDT) From: Mark Crispin To: Rob Siemborski cc: Cyrus Daboo , Ken Murchison , IMAP Extensions WG Subject: Re: SASL Initial Response? In-Reply-To: Message-ID: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> <3F8305BF.2050706@oceana.com> <2147483647.1066304385@socrates.cyrusoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 16 Oct 2003, Rob Siemborski wrote: > Do you mean: > a) a document that includes SASL profiles for all of these protocols > b) a document that points out common errors in SASL implementations > c) a document akin to STD 1 that just points at the documents > that define various SASL profiles. What I would think would be a "SASL for Dummies"; that is, a document which gives a "how to" overview of SASL along with real-life examples. We live in a world full of implementors who do not read specifications. This isn't just with hacker-wannabees in the open source community; vendors are hiring such individuals. There's also a matter of blunder; simply not understanding how seemingly unrelated statements interact (or, for that matter, the significance of a seemingly unimportant statement). As I pointed out before, many POP and SMTP server SASL implementations fail to handle properly the case when the client does not provide an initial response for the PLAIN mechanism. Rob's new set of I-Ds should help a lot. But it should also tell us that we can not depend upon specifications, especially syntax of the specification, to get people to do the right thing. Another damning point. Just recently, it was claimed that RFC 3501 does not enforce BASE64 syntax in the AUTHENTICATE command. The Formal Syntax says otherwise; but that was countered with "nobody reads the formal syntax." Or, as in the case with Courier server, the formal syntax is openly defied if it does not match how the implementor chooses to interpret the main text. Perhaps if we lived in a world in which it was a criminal offense to distribute non-compliant protocol implementations, we might see greater attention to specifications. I don't see that happening; if anything I see an increasingly lackadasical approach to specifications. Thus, we need more pedagogical texts, separate from the specifications, if we hope to retain any interoperability at all. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GHZWI7097330 for ; Thu, 16 Oct 2003 10:35:32 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GHZWwP097329 for ietf-imapext-bks; Thu, 16 Oct 2003 10:35:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GHZUI7097322 for ; Thu, 16 Oct 2003 10:35:31 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [63.163.82.24]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id h9GHTjEG027245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Oct 2003 13:29:47 -0400 Date: Thu, 16 Oct 2003 13:36:17 -0400 From: Cyrus Daboo To: Rob Siemborski , Alexey Melnikov cc: Mark Crispin , Ken Murchison , IMAP Extensions WG Subject: Re: SASL Initial Response? Message-ID: <2147483647.1066311377@socrates.cyrusoft.com> In-Reply-To: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> <3F8305BF.2050706@oceana.com> <2147483647.1066304385@socrates.cyrusoft.com> <3F8ED428.30502@isode.com> X-Mailer: Mulberry/3.1.0b8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Rob, --On Thursday, October 16, 2003 13:30 -0400 Rob Siemborski wrote: | (c) seems likely to fall out of date. It would have to be updated on a regular basis to account for new protocols and mechanisms, but the document will point to the definitive place to get the most up to date information (e.g. IANA for mechanisms). -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GHWLI7097254 for ; Thu, 16 Oct 2003 10:32:21 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GHWL7Y097253 for ietf-imapext-bks; Thu, 16 Oct 2003 10:32:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GHWKI7097246 for ; Thu, 16 Oct 2003 10:32:20 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [63.163.82.24]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id h9GHQXEG027182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Oct 2003 13:26:35 -0400 Date: Thu, 16 Oct 2003 13:33:06 -0400 From: Cyrus Daboo To: Rob Siemborski cc: Mark Crispin , Ken Murchison , IMAP Extensions WG Subject: Re: SASL Initial Response? Message-ID: <2147483647.1066311186@socrates.cyrusoft.com> In-Reply-To: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> <3F8305BF.2050706@oceana.com> <2147483647.1066304385@socrates.cyrusoft.com> X-Mailer: Mulberry/3.1.0b8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Rob, --On Thursday, October 16, 2003 12:55 -0400 Rob Siemborski wrote: | I'm somewhat confused by what you're proposing here Cyrus... | | Do you mean: | | a) a document that includes SASL profiles for all of these protocols A summary of the profiles and mechanisms - not a full detailed description of each. This could be as simple as a table listing which options a particular protocol's profile provides. e.g.: Protocol Initial Response Base64 Encoding Relevant RFCs Supported IMAP No Yes 3501 ACAP Yes Yes 2244 SMTP Yes Yes 2821, 2554 etc Mechanism Initial Response Supports Security RFCs Allowed Layer CRAM-MD5 No No 2195 DIGEST-MD5 Sometimes (see rfc) Yes 2831 GSSAPI Yes Yes 2222 etc | b) a document that points out common errors in SASL implementations Yes.. | c) a document akin to STD 1 that just points at the documents | that define various SASL profiles. The table should list the references. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GHUjI7097208 for ; Thu, 16 Oct 2003 10:30:45 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GHUjtb097207 for ietf-imapext-bks; Thu, 16 Oct 2003 10:30:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GHUhI7097201 for ; Thu, 16 Oct 2003 10:30:44 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9GHUek4002582; Thu, 16 Oct 2003 13:30:40 -0400 Date: Thu, 16 Oct 2003 13:30:40 -0400 (EDT) From: Rob Siemborski To: Alexey Melnikov cc: Cyrus Daboo , Mark Crispin , Ken Murchison , IMAP Extensions WG Subject: Re: SASL Initial Response? In-Reply-To: <3F8ED428.30502@isode.com> Message-ID: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> <3F8305BF.2050706@oceana.com> <2147483647.1066304385@socrates.cyrusoft.com> <3F8ED428.30502@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 16 Oct 2003, Alexey Melnikov wrote: > >I'm somewhat confused by what you're proposing here Cyrus... > > > >Do you mean: > > > >a) a document that includes SASL profiles for all of these protocols > >b) a document that points out common errors in SASL implementations > >c) a document akin to STD 1 that just points at the documents > >that define various SASL profiles. > > > I think Cyrus was talking about b) with some pieces of c). > > After writing HTTP SASL spec and reviewing XMPP/BEEP/SMTP/etc. I am > willing to invest effort in this. Ok. (b) seems worthwhile but I wonder if there is enough there to justify a document separate from RFC2222bis. (c) seems likely to fall out of date. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GHO7I7097028 for ; Thu, 16 Oct 2003 10:24:07 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GHO7bN097027 for ietf-imapext-bks; Thu, 16 Oct 2003 10:24:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GHO6I7097021 for ; Thu, 16 Oct 2003 10:24:06 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Thu, 16 Oct 2003 18:24:05 +0100 Message-ID: <3F8ED428.30502@isode.com> Date: Thu, 16 Oct 2003 18:23:52 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rob Siemborski CC: Cyrus Daboo , Mark Crispin , Ken Murchison , IMAP Extensions WG Subject: Re: SASL Initial Response? References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> <3F8305BF.2050706@oceana.com> <2147483647.1066304385@socrates.cyrusoft.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski wrote: >On Thu, 16 Oct 2003, Cyrus Daboo wrote: > > >>I think what would be handy is to have a single informational RFC, that >>could be continually updated, that summarizes all the SASL profiles for >>standard protocols that use it. i.e. the document would describe how IMAP, >>ACAP, SMTP, POP3, LDAP, BEEP etc all use SASL paying particular attention >>to implementation differences (the initial response has been shown to be >>one problem). This document could list the relevant RFCs to read to get the >>specifics for implementing each profile. i.e. it would be the something >>akin t the IMAP implementer's guide but for SASL. >> >> > >I'm somewhat confused by what you're proposing here Cyrus... > >Do you mean: > >a) a document that includes SASL profiles for all of these protocols >b) a document that points out common errors in SASL implementations >c) a document akin to STD 1 that just points at the documents >that define various SASL profiles. > I think Cyrus was talking about b) with some pieces of c). After writing HTTP SASL spec and reviewing XMPP/BEEP/SMTP/etc. I am willing to invest effort in this. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GGtjI7095655 for ; Thu, 16 Oct 2003 09:55:45 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GGtjs8095654 for ietf-imapext-bks; Thu, 16 Oct 2003 09:55:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GGthI7095646 for ; Thu, 16 Oct 2003 09:55:43 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SMTP5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9GGtek4002521; Thu, 16 Oct 2003 12:55:40 -0400 Date: Thu, 16 Oct 2003 12:55:40 -0400 (EDT) From: Rob Siemborski To: Cyrus Daboo cc: Mark Crispin , Ken Murchison , IMAP Extensions WG Subject: Re: SASL Initial Response? In-Reply-To: <2147483647.1066304385@socrates.cyrusoft.com> Message-ID: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> <3F8305BF.2050706@oceana.com> <2147483647.1066304385@socrates.cyrusoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 16 Oct 2003, Cyrus Daboo wrote: > I think what would be handy is to have a single informational RFC, that > could be continually updated, that summarizes all the SASL profiles for > standard protocols that use it. i.e. the document would describe how IMAP, > ACAP, SMTP, POP3, LDAP, BEEP etc all use SASL paying particular attention > to implementation differences (the initial response has been shown to be > one problem). This document could list the relevant RFCs to read to get the > specifics for implementing each profile. i.e. it would be the something > akin t the IMAP implementer's guide but for SASL. I'm somewhat confused by what you're proposing here Cyrus... Do you mean: a) a document that includes SASL profiles for all of these protocols b) a document that points out common errors in SASL implementations c) a document akin to STD 1 that just points at the documents that define various SASL profiles. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GFhGI7093504 for ; Thu, 16 Oct 2003 08:43:16 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GFhGfD093503 for ietf-imapext-bks; Thu, 16 Oct 2003 08:43:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GFhFI7093498 for ; Thu, 16 Oct 2003 08:43:15 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout5.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9GFhCMk005131; Thu, 16 Oct 2003 08:43:13 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9GFhCdq016889; Thu, 16 Oct 2003 08:43:12 -0700 Date: Thu, 16 Oct 2003 08:43:12 -0700 (PDT) From: Mark Crispin To: Cyrus Daboo cc: Ken Murchison , IMAP Extensions WG Subject: Re: SASL Initial Response? In-Reply-To: <2147483647.1066304385@socrates.cyrusoft.com> Message-ID: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> <3F8305BF.2050706@oceana.com> <2147483647.1066304385@socrates.cyrusoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 16 Oct 2003, Cyrus Daboo wrote: > I think what would be handy is to have a single informational RFC, that > could be continually updated, that summarizes all the SASL profiles for > standard protocols that use it. i.e. the document would describe how IMAP, > ACAP, SMTP, POP3, LDAP, BEEP etc all use SASL paying particular attention > to implementation differences (the initial response has been shown to be > one problem). This document could list the relevant RFCs to read to get the > specifics for implementing each profile. i.e. it would be the something > akin t the IMAP implementer's guide but for SASL. This is an excellent idea. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GFcvI7093336 for ; Thu, 16 Oct 2003 08:38:57 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GFcvcY093335 for ietf-imapext-bks; Thu, 16 Oct 2003 08:38:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GFcuI7093327 for ; Thu, 16 Oct 2003 08:38:56 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [63.163.82.24]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id h9GFXCEG025485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Oct 2003 11:33:13 -0400 Date: Thu, 16 Oct 2003 11:39:45 -0400 From: Cyrus Daboo To: Mark Crispin , Ken Murchison cc: IMAP Extensions WG Subject: Re: SASL Initial Response? Message-ID: <2147483647.1066304385@socrates.cyrusoft.com> In-Reply-To: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> <3F8305BF.2050706@oceana.com> X-Mailer: Mulberry/3.1.0b8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Mark, {Coming into this debate late since I've been on vacation...] --On Tuesday, October 7, 2003 18:33 -0700 Mark Crispin wrote: |> At the very least, shouldn't the IMAP initial response doc and revised |> SMTP AUTH and POP3 AUTH docs be able to proceed in parallel, especially |> if they all use similar language for the initial client response issue? | | The question is if the SMTP and POP3 documents are going to advance or | not. This also depends upon the SASL document. I'd like to hear IESG | feedback on this. Clearly implementing SASL across multiple protocols is problematic because you have to read multiple documents to fully understand what optional features are supported etc. I think what would be handy is to have a single informational RFC, that could be continually updated, that summarizes all the SASL profiles for standard protocols that use it. i.e. the document would describe how IMAP, ACAP, SMTP, POP3, LDAP, BEEP etc all use SASL paying particular attention to implementation differences (the initial response has been shown to be one problem). This document could list the relevant RFCs to read to get the specifics for implementing each profile. i.e. it would be the something akin t the IMAP implementer's guide but for SASL. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FKoiI7091360 for ; Wed, 15 Oct 2003 13:50:44 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9FKoir1091359 for ietf-imapext-bks; Wed, 15 Oct 2003 13:50:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FKogI7091353 for ; Wed, 15 Oct 2003 13:50:42 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9FKoak4000934; Wed, 15 Oct 2003 16:50:36 -0400 Date: Wed, 15 Oct 2003 16:50:35 -0400 (EDT) From: Rob Siemborski To: Mark Crispin cc: IMAP Extensions WG , madan-ganesh.v@hp.com Subject: Re: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt In-Reply-To: Message-ID: References: <200310151932.PAA18348@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 15 Oct 2003, Mark Crispin wrote: > As such, this functionality does not seem to be within the scope of IMAP; > and instead belongs with Sieve. Not withstanding the attractive nuisance > of rendering IMAP into Exchange ("shove everything remotely related to > email into one protocol"), I don't see how ORGANIZE provides any added > value over Sieve. I agree with Mark's comments. I don't see any win here over sieve, except that the client can avoid making the additional MANAGESIEVE connection to update its filtering rules, which is not compelling enough to try to reimplement all of Sieve's functionality inside of the IMAP protocol. (Which reminds me -- MANAGESIEVE has yet to be published as an RFC, I should probably bother Tim again). In fact, it seems to me that sieve is more flexible than this extension ever could be, since it is embeddable without protocol changes in any mail handling program (IMAP server, LMTP/SMTP server, POP client, etc). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FKCGI7090436 for ; Wed, 15 Oct 2003 13:12:16 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9FKCGYv090435 for ietf-imapext-bks; Wed, 15 Oct 2003 13:12:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout6.cac.washington.edu (mxout6.cac.washington.edu [140.142.33.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FKCFI7090430 for ; Wed, 15 Oct 2003 13:12:15 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout6.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9FKBL0Y014853; Wed, 15 Oct 2003 13:11:21 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9FKBLT0003668; Wed, 15 Oct 2003 13:11:21 -0700 Date: Wed, 15 Oct 2003 13:11:21 -0700 (PDT) From: Mark Crispin To: IMAP Extensions WG cc: madan-ganesh.v@hp.com Subject: Re: I-D ACTION:draft-madanganeshv-imapext-organize-00.txt In-Reply-To: <200310151932.PAA18348@ietf.org> Message-ID: References: <200310151932.PAA18348@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Leaving aside the bugs in this specification (for example, the added capabilities violate RFC 3501, security considerations are glossed over), it seems that the purpose of this proposed extension is not to "organize", but rather to define MDA filtering rules. As such, this functionality does not seem to be within the scope of IMAP; and instead belongs with Sieve. Not withstanding the attractive nuisance of rendering IMAP into Exchange ("shove everything remotely related to email into one protocol"), I don't see how ORGANIZE provides any added value over Sieve. The proposed SMTP extension for ORGANIZE is bizarre. The purpose seems to be to shoehorn manipulation of MDA filtering rules into yet another orthogonal protocol (plus note the syntax errors in the example). The SMTP extensions people can shoot that down. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9F8fJI7057123 for ; Wed, 15 Oct 2003 01:41:19 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9F8fJ4D057121 for ietf-imapext-bks; Wed, 15 Oct 2003 01:41:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from melkebalanse.gulbrandsen.priv.no (melkebalanse.gulbrandsen.priv.no [217.19.171.131]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9F8f7I7057024 for ; Wed, 15 Oct 2003 01:41:14 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Message-Id: From: Arnt Gulbrandsen To: Mark Crispin Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt Cc: Alexey Melnikov , Rob Siemborski , IMAP extensions Mailing List References: <200310131515.LAA10872@ietf.org> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Wed, 15 Oct 2003 10:43:55 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: > On Tue, 14 Oct 2003, Rob Siemborski wrote: >> I have replaced that paragraph with: >> >> When decoding the [BASE64] data in the initial client response, >> decoding errors MUST be treated as [IMAP4] would handle them in any >> normal SASL client response. In particular, the server should check >> for any characters not explicitly allowed by the BASE64 alphabet, >> as well as any sequence of BASE64 characters that contains the pad >> character ('=') anywhere other than the end of the string (e.g. >> "=AAA" and "AAA=BBB" are not allowed). > > Excellent. Thanks! I like it. --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EIX4I7059360 for ; Tue, 14 Oct 2003 11:33:04 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EIX4xZ059359 for ietf-imapext-bks; Tue, 14 Oct 2003 11:33:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout6.cac.washington.edu (mxout6.cac.washington.edu [140.142.33.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EIWxI7059354 for ; Tue, 14 Oct 2003 11:32:59 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout6.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9EIWo0Y028747; Tue, 14 Oct 2003 11:32:50 -0700 Received: from Shimo-Tomobiki.Panda.COM (D-140-142-21-77.dhcp4.washington.edu [140.142.21.77]) (authenticated bits=0) by smtp.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9EIWmx0004715 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 14 Oct 2003 11:32:50 -0700 Date: Tue, 14 Oct 2003 11:32:54 -0700 (Pacific Daylight Time) From: Mark Crispin To: Rob Siemborski cc: Arnt Gulbrandsen , IMAP extensions Mailing List , alexey.melnikov@isode.com Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt In-Reply-To: Message-ID: References: <200310131515.LAA10872@ietf.org> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 14 Oct 2003, Rob Siemborski wrote: > I have replaced that paragraph with: > > When decoding the [BASE64] data in the initial client response, decoding > errors MUST be treated as [IMAP4] would handle them in any normal SASL > client response. In particular, the server should check for > any characters not explicitly allowed by the BASE64 alphabet, as well as > any sequence of BASE64 characters that contains the pad character ('=') > anywhere other than the end of the string (e.g. "=AAA" and "AAA=BBB" are > not allowed). Excellent. Thanks! -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EIQ3I7059086 for ; Tue, 14 Oct 2003 11:26:03 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EIQ3Od059085 for ietf-imapext-bks; Tue, 14 Oct 2003 11:26:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EIQ2I7059080 for ; Tue, 14 Oct 2003 11:26:02 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9EIPxWn000878; Tue, 14 Oct 2003 14:26:00 -0400 Date: Tue, 14 Oct 2003 14:25:59 -0400 (EDT) From: Rob Siemborski To: Mark Crispin cc: Arnt Gulbrandsen , IMAP extensions Mailing List , alexey.melnikov@isode.com Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt In-Reply-To: Message-ID: References: <200310131515.LAA10872@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 14 Oct 2003, Mark Crispin wrote: > > replacing it with something like "When base64 decoding the initial > > response argument, it MUST be treated as [IMAP4] would treat any > > other SASL client response.") > > It wouldn't hurt to add expository text with something like the original > wording, just for emphasis. I have replaced that paragraph with: When decoding the [BASE64] data in the initial client response, decoding errors MUST be treated as [IMAP4] would handle them in any normal SASL client response. In particular, the server should check for any characters not explicitly allowed by the BASE64 alphabet, as well as any sequence of BASE64 characters that contains the pad character ('=') anywhere other than the end of the string (e.g. "=AAA" and "AAA=BBB" are not allowed). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EIAII7058597 for ; Tue, 14 Oct 2003 11:10:18 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EIAI6l058596 for ietf-imapext-bks; Tue, 14 Oct 2003 11:10:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EIAHI7058587 for ; Tue, 14 Oct 2003 11:10:17 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9EIA6Mk020884; Tue, 14 Oct 2003 11:10:06 -0700 Received: from Shimo-Tomobiki.Panda.COM (D-140-142-21-77.dhcp4.washington.edu [140.142.21.77]) (authenticated bits=0) by smtp.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9EIA2x0002041 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 14 Oct 2003 11:10:06 -0700 Date: Tue, 14 Oct 2003 11:10:08 -0700 (Pacific Daylight Time) From: Mark Crispin To: Rob Siemborski cc: Arnt Gulbrandsen , IMAP extensions Mailing List , alexey.melnikov@isode.com Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt In-Reply-To: Message-ID: References: <200310131515.LAA10872@ietf.org> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 14 Oct 2003, Rob Siemborski wrote: > In that case, I am inclined to drop the paragraph from this draft (perhaps > replacing it with something like "When base64 decoding the initial > response argument, it MUST be treated as [IMAP4] would treat any > other SASL client response.") It wouldn't hurt to add expository text with something like the original wording, just for emphasis. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EHwQI7058214 for ; Tue, 14 Oct 2003 10:58:26 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EHwQ41058213 for ietf-imapext-bks; Tue, 14 Oct 2003 10:58:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EHwKI7058208 for ; Tue, 14 Oct 2003 10:58:21 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9EHwIWn000835; Tue, 14 Oct 2003 13:58:18 -0400 Date: Tue, 14 Oct 2003 13:58:17 -0400 (EDT) From: Rob Siemborski To: Mark Crispin cc: Arnt Gulbrandsen , IMAP extensions Mailing List , alexey.melnikov@isode.com Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt In-Reply-To: Message-ID: References: <200310131515.LAA10872@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 14 Oct 2003, Mark Crispin wrote: > > > This stuff is over and above the restrictions imposed by RFC 3501 > > > section 6.2.2. > > Since Alexey was the one who wanted me to add this, I'll ask him to > > comment here. > > I'm not Alexey, but I'll comment anyway. > > RFC 3501 fully supports the proposed restrictions in the Formal Syntax. > Characters that are not in the BASE64 alphabet and non-terminal = are > specifically prohibited in the formal syntax, violation of which leads to > a BAD. > > Just because something isn't explicitly mentioned in expository text (such > as 6.2.2) does not mean that it isn't there. In that case, I am inclined to drop the paragraph from this draft (perhaps replacing it with something like "When base64 decoding the initial response argument, it MUST be treated as [IMAP4] would treat any other SASL client response.") -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EHCOI7056855 for ; Tue, 14 Oct 2003 10:12:24 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EHCOhn056854 for ietf-imapext-bks; Tue, 14 Oct 2003 10:12:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EHCMI7056848 for ; Tue, 14 Oct 2003 10:12:23 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Tue, 14 Oct 2003 18:12:16 +0100 Message-ID: <3F8C2E6C.9080806@isode.com> Date: Tue, 14 Oct 2003 18:12:12 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Crispin CC: Arnt Gulbrandsen , Rob Siemborski , IMAP extensions Mailing List Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt References: <200310131515.LAA10872@ietf.org> <3F8C2764.3050208@isode.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: >On Tue, 14 Oct 2003, Alexey Melnikov wrote: > > >>>This stuff is over and above the restrictions imposed by RFC 3501 >>>section 6.2.2. >>> >>> >>Yes. The base IMAP spec should be updated as well. >> >> > >As noted in my previous message, this is unnecessary except as an >explanatory note. The Formal Syntax is already clear on this point. > Yes, but nobody reads ABNF anyway ;-). You are right, "this is not a bug", but I suggest you add some text, as this is a known issue that causes problems already. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EH1HI7056277 for ; Tue, 14 Oct 2003 10:01:17 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EH1HdE056276 for ietf-imapext-bks; Tue, 14 Oct 2003 10:01:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EH1CI7056271 for ; Tue, 14 Oct 2003 10:01:16 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout3.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9EH0rC2032706; Tue, 14 Oct 2003 10:00:58 -0700 Received: from Shimo-Tomobiki.Panda.COM (mes128085095.airdata.net [166.128.85.95]) (authenticated bits=0) by smtp.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9EH0gx0027011 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 14 Oct 2003 10:00:49 -0700 Date: Tue, 14 Oct 2003 10:00:43 -0700 (Pacific Daylight Time) From: Mark Crispin To: Alexey Melnikov cc: Arnt Gulbrandsen , Rob Siemborski , IMAP extensions Mailing List Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt In-Reply-To: <3F8C2764.3050208@isode.com> Message-ID: References: <200310131515.LAA10872@ietf.org> <3F8C2764.3050208@isode.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 14 Oct 2003, Alexey Melnikov wrote: > > This stuff is over and above the restrictions imposed by RFC 3501 > > section 6.2.2. > Yes. The base IMAP spec should be updated as well. As noted in my previous message, this is unnecessary except as an explanatory note. The Formal Syntax is already clear on this point. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EH0GI7056240 for ; Tue, 14 Oct 2003 10:00:16 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EH0GUC056239 for ietf-imapext-bks; Tue, 14 Oct 2003 10:00:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EH06I7056228 for ; Tue, 14 Oct 2003 10:00:06 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9EGxhMk007239; Tue, 14 Oct 2003 09:59:43 -0700 Received: from Shimo-Tomobiki.Panda.COM (mes128085095.airdata.net [166.128.85.95]) (authenticated bits=0) by smtp.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9EGxBx0026784 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 14 Oct 2003 09:59:35 -0700 Date: Tue, 14 Oct 2003 09:59:12 -0700 (Pacific Daylight Time) From: Mark Crispin To: Rob Siemborski cc: Arnt Gulbrandsen , IMAP extensions Mailing List , alexey.melnikov@isode.com Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt In-Reply-To: Message-ID: References: <200310131515.LAA10872@ietf.org> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 14 Oct 2003, Rob Siemborski wrote: > > If the server cannot decode the [BASE64] data > > transmitted by the client, the server MUST fail the authentication > > with a tagged BAD response. In particular, the server MUST reject > > (and not ignore) any characters not explicitly allowed by the BASE64 > > alphabet, and should reject any sequence of BASE64 characters that > > contains the pad character ('=') anywhere other than the end of the > > string (e.g. "=AAA" and "AAA=BBB" are not allowed). > > This stuff is over and above the restrictions imposed by RFC 3501 > > section 6.2.2. > Since Alexey was the one who wanted me to add this, I'll ask him to > comment here. I'm not Alexey, but I'll comment anyway. RFC 3501 fully supports the proposed restrictions in the Formal Syntax. Characters that are not in the BASE64 alphabet and non-terminal = are specifically prohibited in the formal syntax, violation of which leads to a BAD. Just because something isn't explicitly mentioned in expository text (such as 6.2.2) does not mean that it isn't there. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EGgLI7055646 for ; Tue, 14 Oct 2003 09:42:21 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EGgLGl055645 for ietf-imapext-bks; Tue, 14 Oct 2003 09:42:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EGgKI7055640 for ; Tue, 14 Oct 2003 09:42:20 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Tue, 14 Oct 2003 17:42:16 +0100 Message-ID: <3F8C2764.3050208@isode.com> Date: Tue, 14 Oct 2003 17:42:12 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Arnt Gulbrandsen CC: Rob Siemborski , IMAP extensions Mailing List Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt References: <200310131515.LAA10872@ietf.org> In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Arnt Gulbrandsen wrote: > If the server cannot decode the [BASE64] data > transmitted by the client, the server MUST fail the authentication > with a tagged BAD response. In particular, the server MUST reject > (and not ignore) any characters not explicitly allowed by the BASE64 > alphabet, and should reject any sequence of BASE64 characters that > contains the pad character ('=') anywhere other than the end of the > string (e.g. "=AAA" and "AAA=BBB" are not allowed). > > This stuff is over and above the restrictions imposed by RFC 3501 > section 6.2.2. Yes. The base IMAP spec should be updated as well. > I don't feel pedantic enough to look up the original base64 RFC and > see if there's equivalent text there. Unfortunately the base64 RFC was published before the issue was raised. There are problems in real world that different implementations treat invalid (as shown in the text above) base64 text in different ways. Some implementations just ignore invalid characters. Others truncate data at the first '='. And other reject the value (the right think). base64 is silent on this and this causes problems. > Either there is, and the text is superfluous, or there isn't, and the > quoted text is a syntax difference of the kind I don't want. Cheers, Alexey __________________________________________ Isode Limited, http://www.isode.com Cell: +44 7753759732 IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html Personal Home Page: http://orthanc.ab.ca/mel __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EGThI7055100 for ; Tue, 14 Oct 2003 09:29:43 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EGTh1E055099 for ietf-imapext-bks; Tue, 14 Oct 2003 09:29:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EGTgI7055088 for ; Tue, 14 Oct 2003 09:29:43 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Message-Id: From: Arnt Gulbrandsen To: Mark Crispin Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt Cc: Rob Siemborski , IMAP extensions Mailing List References: <200310131515.LAA10872@ietf.org> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Tue, 14 Oct 2003 18:32:25 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: > On Tue, 14 Oct 2003, Arnt Gulbrandsen wrote: >> With SMTP, the server can know that the client supports initial responses. > > Say WHAT????? > > Where did you get THAT??? Too tired. I mixed "mandatory for SMTP servers" up with "mandatory in SMTP". Sorry. --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EGSbI7055006 for ; Tue, 14 Oct 2003 09:28:37 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EGSbLp055005 for ietf-imapext-bks; Tue, 14 Oct 2003 09:28:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EGSaI7055000 for ; Tue, 14 Oct 2003 09:28:36 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from LIN1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9EGSV1v024566; Tue, 14 Oct 2003 12:28:31 -0400 Date: Tue, 14 Oct 2003 12:28:31 -0400 (EDT) From: Rob Siemborski To: Arnt Gulbrandsen cc: IMAP extensions Mailing List , alexey.melnikov@isode.com Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt In-Reply-To: Message-ID: References: <200310131515.LAA10872@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 14 Oct 2003, Arnt Gulbrandsen wrote: > Good. They aren't the same as the document stands now. There are 2-3 > extra restrictions, both/all small. > > If the client needs to transmit an > initial response which is a zero-length string, it MUST transmit a > single equals sign ("="). This indicates that the response is > present, but is a zero-length string. > > There's a MUST here, although I'm not sure whether it represents an > additional requirement over and above RFC 3501. > > Let me suggest a rewording. "To send a zero-length initial response, the > client can send a single pad character ("="). When decoded, this will > result in a zero-length string on the server." Or perhaps use "AUTH > EXTERNAL =" as an example. Either way, it's the same meaning, no > additional restrictions. I think this needs to be "the client MUST" for interoperability purposes. But I am willing to rework this and add the EXTERNAL example (which is good). Note that this only refers to the SASL initial response (as it is included with the AUTHENTICATE command), not to any part of the negotiation that proceeds later. Do you perhaps want text to that effect? > If the server cannot decode the [BASE64] data > transmitted by the client, the server MUST fail the authentication > with a tagged BAD response. In particular, the server MUST reject > (and not ignore) any characters not explicitly allowed by the BASE64 > alphabet, and should reject any sequence of BASE64 characters that > contains the pad character ('=') anywhere other than the end of the > string (e.g. "=AAA" and "AAA=BBB" are not allowed). > > This stuff is over and above the restrictions imposed by RFC 3501 > section 6.2.2. I don't feel pedantic enough to look up the original > base64 RFC and see if there's equivalent text there. Either there is, > and the text is superfluous, or there isn't, and the quoted text is a > syntax difference of the kind I don't want. Since Alexey was the one who wanted me to add this, I'll ask him to comment here. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EGP3I7054659 for ; Tue, 14 Oct 2003 09:25:03 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EGP37C054658 for ietf-imapext-bks; Tue, 14 Oct 2003 09:25:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EGOwI7054639 for ; Tue, 14 Oct 2003 09:25:02 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Message-Id: From: Arnt Gulbrandsen To: Rob Siemborski Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt Cc: IMAP extensions Mailing List References: <200310131515.LAA10872@ietf.org> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Tue, 14 Oct 2003 18:27:40 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski writes: > On Tue, 14 Oct 2003, Arnt Gulbrandsen wrote: >> I'm proposing that whether or not the server supports your extension, >> the rules that govern the client's first response should be the >> same. > > I agree. Good. They aren't the same as the document stands now. There are 2-3 extra restrictions, both/all small. If the client needs to transmit an initial response which is a zero-length string, it MUST transmit a single equals sign ("="). This indicates that the response is present, but is a zero-length string. There's a MUST here, although I'm not sure whether it represents an additional requirement over and above RFC 3501. Let me suggest a rewording. "To send a zero-length initial response, the client can send a single pad character ("="). When decoded, this will result in a zero-length string on the server." Or perhaps use "AUTH EXTERNAL =" as an example. Either way, it's the same meaning, no additional restrictions. If the server cannot decode the [BASE64] data transmitted by the client, the server MUST fail the authentication with a tagged BAD response. In particular, the server MUST reject (and not ignore) any characters not explicitly allowed by the BASE64 alphabet, and should reject any sequence of BASE64 characters that contains the pad character ('=') anywhere other than the end of the string (e.g. "=AAA" and "AAA=BBB" are not allowed). This stuff is over and above the restrictions imposed by RFC 3501 section 6.2.2. I don't feel pedantic enough to look up the original base64 RFC and see if there's equivalent text there. Either there is, and the text is superfluous, or there isn't, and the quoted text is a syntax difference of the kind I don't want. Thanks for taking the trouble to write the spec. --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EG83I7054032 for ; Tue, 14 Oct 2003 09:08:03 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EG833O054031 for ietf-imapext-bks; Tue, 14 Oct 2003 09:08:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EG81I7054024 for ; Tue, 14 Oct 2003 09:08:01 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from LIN1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9EG7w1v023174; Tue, 14 Oct 2003 12:07:59 -0400 Date: Tue, 14 Oct 2003 12:07:58 -0400 (EDT) From: Rob Siemborski To: Mark Crispin cc: Arnt Gulbrandsen , IMAP extensions Mailing List Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt In-Reply-To: Message-ID: References: <200310131515.LAA10872@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 14 Oct 2003, Mark Crispin wrote: > On Tue, 14 Oct 2003, Rob Siemborski wrote: > > > Mandatory to implement. With SMTP, the server can know that the client > > > supports initial responses. > > Sure, it knows that it supports it, but that doesn't change the fact that > > the server still must deal with the client leaving off the initial > > response. That's part of the sasl specification. > > Huh??? > > The server must implement initial responses in POP3 and SMTP, but there is > no requirement that the client do so since the client can always omit it. Yes, this is correct. I misspoke. FWIW, I hope that draft-siemborski-rfc2554bis-00.txt clarifies this situation. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EG6qI7053970 for ; Tue, 14 Oct 2003 09:06:52 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EG6qFC053969 for ietf-imapext-bks; Tue, 14 Oct 2003 09:06:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout6.cac.washington.edu (mxout6.cac.washington.edu [140.142.33.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EG6pI7053954 for ; Tue, 14 Oct 2003 09:06:51 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout6.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9EG6W0Y000581; Tue, 14 Oct 2003 09:06:37 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9EG6WeW000517; Tue, 14 Oct 2003 09:06:32 -0700 Date: Tue, 14 Oct 2003 09:06:32 -0700 (PDT) From: Mark Crispin To: Rob Siemborski cc: Arnt Gulbrandsen , IMAP extensions Mailing List Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt In-Reply-To: Message-ID: References: <200310131515.LAA10872@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 14 Oct 2003, Rob Siemborski wrote: > > Mandatory to implement. With SMTP, the server can know that the client > > supports initial responses. > Sure, it knows that it supports it, but that doesn't change the fact that > the server still must deal with the client leaving off the initial > response. That's part of the sasl specification. Huh??? The server must implement initial responses in POP3 and SMTP, but there is no requirement that the client do so since the client can always omit it. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EG5aI7053891 for ; Tue, 14 Oct 2003 09:05:36 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EG5aZo053890 for ietf-imapext-bks; Tue, 14 Oct 2003 09:05:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EG5ZI7053885 for ; Tue, 14 Oct 2003 09:05:35 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout4.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9EG5Fmw015379; Tue, 14 Oct 2003 09:05:20 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9EG5FS7000452; Tue, 14 Oct 2003 09:05:15 -0700 Date: Tue, 14 Oct 2003 09:05:15 -0700 (PDT) From: Mark Crispin To: Arnt Gulbrandsen cc: Rob Siemborski , IMAP extensions Mailing List Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt In-Reply-To: Message-ID: References: <200310131515.LAA10872@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 14 Oct 2003, Arnt Gulbrandsen wrote: > With SMTP, the server can know that the client > supports initial responses. Say WHAT????? Where did you get THAT??? -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EG33I7053785 for ; Tue, 14 Oct 2003 09:03:03 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EG33jJ053784 for ietf-imapext-bks; Tue, 14 Oct 2003 09:03:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EG32I7053779 for ; Tue, 14 Oct 2003 09:03:02 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from LIN1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9EG311v022845; Tue, 14 Oct 2003 12:03:01 -0400 Date: Tue, 14 Oct 2003 12:03:01 -0400 (EDT) From: Rob Siemborski To: Arnt Gulbrandsen cc: IMAP extensions Mailing List Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt In-Reply-To: Message-ID: References: <200310131515.LAA10872@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 14 Oct 2003, Arnt Gulbrandsen wrote: > Rob Siemborski writes: > > So you're proposing a situation where an extension that has an empty > > string as an initial response is penalized a round trip: > > Not at all. > > I'm proposing that whether or not the server supports your extension, > the rules that govern the client's first response should be the same. I agree. > >> SMTP is different - initial responses are m-t-i there. > > > > I'm sorry, What is m-t-i? > > Mandatory to implement. With SMTP, the server can know that the client > supports initial responses. Sure, it knows that it supports it, but that doesn't change the fact that the server still must deal with the client leaving off the initial response. That's part of the sasl specification. > With IMAP that's not the case. With IMAP, > the first response may be an initial response, or it may be a response > to an empty challenge. Either way, the syntax should be the same. Either way, the syntax is the same. The sever doesn't care if the client supports initial response or not. At the application level, it's not even allowed to care! If the client doesn't support an initial response, *or* the client doesn't choose to send an initial response, then the negotiation proceeds the same way: there was no initial response. For example, in the DIGEST-MD5 case, where there *is* a difference (fast reauth or not) in both of the above cases, you proceed without fast reauth. The server doesn't care about the reason. FWIW, EXTERNAL is likely to send an empty initial response. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EFvYI7053522 for ; Tue, 14 Oct 2003 08:57:34 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EFvYYL053521 for ietf-imapext-bks; Tue, 14 Oct 2003 08:57:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EFvXI7053516 for ; Tue, 14 Oct 2003 08:57:33 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Message-Id: From: Arnt Gulbrandsen To: Rob Siemborski Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt Cc: IMAP extensions Mailing List References: <200310131515.LAA10872@ietf.org> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Tue, 14 Oct 2003 18:00:14 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski writes: > So you're proposing a situation where an extension that has an empty > string as an initial response is penalized a round trip: Not at all. I'm proposing that whether or not the server supports your extension, the rules that govern the client's first response should be the same. >> SMTP is different - initial responses are m-t-i there. > > I'm sorry, What is m-t-i? Mandatory to implement. With SMTP, the server can know that the client supports initial responses. With IMAP that's not the case. With IMAP, the first response may be an initial response, or it may be a response to an empty challenge. Either way, the syntax should be the same. --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EFsKI7053349 for ; Tue, 14 Oct 2003 08:54:20 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EFsKBK053348 for ietf-imapext-bks; Tue, 14 Oct 2003 08:54:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EFsJI7053343 for ; Tue, 14 Oct 2003 08:54:19 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from LIN1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9EFsI1v022251; Tue, 14 Oct 2003 11:54:18 -0400 Date: Tue, 14 Oct 2003 11:54:18 -0400 (EDT) From: Rob Siemborski To: Arnt Gulbrandsen cc: IMAP extensions Mailing List Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt In-Reply-To: Message-ID: References: <200310131515.LAA10872@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 14 Oct 2003, Rob Siemborski wrote: > clearly says "there is an initial response here, but it is the empty > string" > > vs > > AUTHENTICATE MUMBLE > > which is required to mean "no initial response" > > Without the "=", you're required to fall back to the old behavior. I suppose you could also do "AUTHENTICATE MUMBLE " to indicate an empty response. Is that what you were proposing instead? -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EFkOI7053076 for ; Tue, 14 Oct 2003 08:46:24 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EFkOAX053075 for ietf-imapext-bks; Tue, 14 Oct 2003 08:46:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EFkMI7053069 for ; Tue, 14 Oct 2003 08:46:22 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from LIN1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9EFkL1v021716; Tue, 14 Oct 2003 11:46:21 -0400 Date: Tue, 14 Oct 2003 11:46:21 -0400 (EDT) From: Rob Siemborski To: Arnt Gulbrandsen cc: IMAP extensions Mailing List Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt In-Reply-To: Message-ID: References: <200310131515.LAA10872@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 14 Oct 2003, Arnt Gulbrandsen wrote: > I can see that empty responses may one day be meaningful. However, I > cannot see what's special about the combination of empty responses and > this extension. > > Suppose AUTH=MUMBLE has some feature whereby an empty response makes > sense. Shouldn't it work basically the same way whether this extension > is present or not? > > C: a AUTHENTICATE MUMBLE > S: + > C: = > ... No, in this case you'd use the normal SASL negotiation, you wouldn't have an =. > or > > C: a AUTHENTICATE MUMBLE = > ... > > IMO, the "=" should be governed by the same syntax in both cases, so the > extension should avoid specifying new rules. Now that I think about it, > I suppose that argument covers my base64 queasiness too - the argument > should use the same rules as the same response would follow in the > absence of the extension. So you're proposing a situation where an extension that has an empty string as an initial response is penalized a round trip: AUTHENTICATE MUMBLE = clearly says "there is an initial response here, but it is the empty string" vs AUTHENTICATE MUMBLE which is required to mean "no initial response" Without the "=", you're required to fall back to the old behavior. > > FWIW, SMTP does this. > > SMTP is different - initial responses are m-t-i there. I'm sorry, What is m-t-i? -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EFftI7052923 for ; Tue, 14 Oct 2003 08:41:55 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EFft1N052922 for ietf-imapext-bks; Tue, 14 Oct 2003 08:41:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EFfsI7052916 for ; Tue, 14 Oct 2003 08:41:55 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Message-Id: From: Arnt Gulbrandsen To: Rob Siemborski Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt Cc: IMAP extensions Mailing List References: <200310131515.LAA10872@ietf.org> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Tue, 14 Oct 2003 17:44:32 +0200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9EFftI7052918 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski writes: > On Tue, 14 Oct 2003, Arnt Gulbrandsen wrote: >> 2. The extension's capability name sounds a little inappropriate. >> This extension isn't "the SASL extension". I suggest SASL-IR >> instead. > > I was originally using SASLINITIAL, but it was suggested that I use > "SASL" instead because IMAP now "fully supports SASL" (well, as much > as it can without a client-side-capability extension, which would be > needed for server-last-sends). "PRACTICALLYSASL"? Please not ;) > Frankly, I don't really care what capability name is used, but I'd > like this to not be a continual point of argument. I'd rather see your initial name than the current, but either way I've had my say about it. > Whaile it is true that no current mechanisms have a situation where > they can send an empty initial response, a mechanism might be > developed where there may be something distinguising about the client > sending an empty initial send and the client omiting the initial send > (think of behavior like DIGEST-MD5 fast reauth). We need to handle > the two cases separately. I can see that empty responses may one day be meaningful. However, I cannot see what's special about the combination of empty responses and this extension. Suppose AUTH=MUMBLE has some feature whereby an empty response makes sense. Shouldn't it work basically the same way whether this extension is present or not? C: a AUTHENTICATE MUMBLE S: + C: = ... or C: a AUTHENTICATE MUMBLE = ... IMO, the "=" should be governed by the same syntax in both cases, so the extension should avoid specifying new rules. Now that I think about it, I suppose that argument covers my base64 queasiness too - the argument should use the same rules as the same response would follow in the absence of the extension. > FWIW, SMTP does this. SMTP is different - initial responses are m-t-i there. --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EFCfI7051731 for ; Tue, 14 Oct 2003 08:12:41 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EFCf7H051730 for ietf-imapext-bks; Tue, 14 Oct 2003 08:12:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EFCZI7051724 for ; Tue, 14 Oct 2003 08:12:36 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9EFCV1v019416; Tue, 14 Oct 2003 11:12:31 -0400 Date: Tue, 14 Oct 2003 11:12:30 -0400 (EDT) From: Rob Siemborski To: Arnt Gulbrandsen cc: IMAP extensions Mailing List Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt In-Reply-To: Message-ID: References: <200310131515.LAA10872@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 14 Oct 2003, Arnt Gulbrandsen wrote: > 1. The server must reject, not ignore, any characters outside the base64 > alphabet. Ditto = before the end. > > Why that? I can see it makes sense, but I'm tired of minor differences. > Won't stock base64 do? This was Alexey's suggestion due to bugs in base64 parsers. > 2. The extension's capability name sounds a little inappropriate. This > extension isn't "the SASL extension". I suggest SASL-IR instead. I was originally using SASLINITIAL, but it was suggested that I use "SASL" instead because IMAP now "fully supports SASL" (well, as much as it can without a client-side-capability extension, which would be needed for server-last-sends). Frankly, I don't really care what capability name is used, but I'd like this to not be a continual point of argument. > 3. The draft makes mandates specific syntax for empty initial responses. > I don't lik that. For one thing, under what circumstances would a > client _need_ to send an empty initial response? That is, as opposed to > sending no initial response at all? For another, why shouldn't the same > rules as for other empty responses apply? (I confess I didn't look > those up.) There is a difference between "" and NULL, as there is a difference between omiting the initial response and encoding an empty string. Whaile it is true that no current mechanisms have a situation where they can send an empty initial response, a mechanism might be developed where there may be something distinguising about the client sending an empty initial send and the client omiting the initial send (think of behavior like DIGEST-MD5 fast reauth). We need to handle the two cases separately. FWIW, SMTP does this. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EC6DI7042532 for ; Tue, 14 Oct 2003 05:06:13 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EC6D48042531 for ietf-imapext-bks; Tue, 14 Oct 2003 05:06:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from melkebalanse.gulbrandsen.priv.no (melkebalanse.gulbrandsen.priv.no [217.19.171.131]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EC68I7042512 for ; Tue, 14 Oct 2003 05:06:12 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Message-Id: From: Arnt Gulbrandsen To: IMAP extensions Mailing List Subject: Re: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt References: <200310131515.LAA10872@ietf.org> In-Reply-To: <200310131515.LAA10872@ietf.org> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Tue, 14 Oct 2003 14:08:54 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Internet-Drafts@ietf.org writes: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : IMAP Extension for SASL Initial Client Response > Author(s) : R. Siemborski > Filename : draft-siemborski-imap-sasl-initial-response-00.txt I'll skip the big issue and comment on some small ones. 1. The server must reject, not ignore, any characters outside the base64 alphabet. Ditto = before the end. Why that? I can see it makes sense, but I'm tired of minor differences. Won't stock base64 do? 2. The extension's capability name sounds a little inappropriate. This extension isn't "the SASL extension". I suggest SASL-IR instead. 3. The draft makes mandates specific syntax for empty initial responses. I don't lik that. For one thing, under what circumstances would a client _need_ to send an empty initial response? That is, as opposed to sending no initial response at all? For another, why shouldn't the same rules as for other empty responses apply? (I confess I didn't look those up.) --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DFFZI7036207 for ; Mon, 13 Oct 2003 08:15:35 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9DFFZqS036206 for ietf-imapext-bks; Mon, 13 Oct 2003 08:15:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DFFYI7036200 for ; Mon, 13 Oct 2003 08:15:34 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10872; Mon, 13 Oct 2003 11:15:25 -0400 (EDT) Message-Id: <200310131515.LAA10872@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-siemborski-imap-sasl-initial-response-00.txt Date: Mon, 13 Oct 2003 11:15:25 -0400 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IMAP Extension for SASL Initial Client Response Author(s) : R. Siemborski Filename : draft-siemborski-imap-sasl-initial-response-00.txt Pages : 7 Date : 2003-10-10 To date, the Internet Message Access Protocol (IMAP) has used a Simple Authentication and Security Layer (SASL) profile which always required at least one complete round trip for an authentication, as it did not support an initial client response argument. This additional round trip at the beginning of the session is undesirable, especially when round trip costs are high. This document defines an extension to IMAP which allows clients and servers to avoid this round trip by allowing an initial client response argument to the IMAP AUTHENTICATE command. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-siemborski-imap-sasl-initial-response-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-siemborski-imap-sasl-initial-response-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-siemborski-imap-sasl-initial-response-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-10143126.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-siemborski-imap-sasl-initial-response-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-siemborski-imap-sasl-initial-response-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-10143126.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h981XrKP055935 for ; Tue, 7 Oct 2003 18:33:53 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h981XriM055934 for ietf-imapext-bks; Tue, 7 Oct 2003 18:33:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout6.cac.washington.edu (mxout6.cac.washington.edu [140.142.33.20]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h981XqKP055926 for ; Tue, 7 Oct 2003 18:33:52 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout6.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h981Xp0Y027924; Tue, 7 Oct 2003 18:33:51 -0700 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h981Xp93021628; Tue, 7 Oct 2003 18:33:51 -0700 Date: Tue, 7 Oct 2003 18:33:51 -0700 (PDT) From: Mark Crispin To: Ken Murchison cc: IMAP Extensions WG Subject: Re: SASL Initial Response? In-Reply-To: <3F8305BF.2050706@oceana.com> Message-ID: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> <3F8305BF.2050706@oceana.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 7 Oct 2003, Ken Murchison wrote: > I don't see why implementations which are clearly broken and in > violation of the specs (regardless of how poorly written those specs may > or may not be), should prevent the IMAP initial client response > extension from proceeding as long as it avoids/corrects the problems > with the SMTP AUTH and POP3 AUTH specs. Ken, I believe that you are are thinking about a specification whereas I am thinking more about human nature. We have to allow for Murphy's Law. The IMAP spec will be much more complicated than the SMTP or POP3 specs, because IMAP is server-optional on initial response. That is four support states, whereas SMTP and POP3 only have two > At the very least, shouldn't the IMAP initial response doc and revised > SMTP AUTH and POP3 AUTH docs be able to proceed in parallel, especially > if they all use similar language for the initial client response issue? The question is if the SMTP and POP3 documents are going to advance or not. This also depends upon the SASL document. I'd like to hear IESG feedback on this. Without some surety that the SMTP/POP3 situation is fixed, I feel like I am being asked to leap from a tall building, based upon unproven claims that the building is on fire and with equally unproven assurances that by the time I reach the ground, you will have contrived to have erected a net. I don't see any urgency for initial response in IMAP; it is cosmetic or a minor RTT savings at best. We can afford to take the time to do it right. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97KddKP044769 for ; Tue, 7 Oct 2003 13:39:39 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h97KddFc044768 for ietf-imapext-bks; Tue, 7 Oct 2003 13:39:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97KdbKP044761 for ; Tue, 7 Oct 2003 13:39:37 -0700 (PDT) (envelope-from steve.hole@messagingdirect.com) Received: from kepler.esys.ca (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h97KhRw09272; Tue, 7 Oct 2003 14:43:27 -0600 From: Steve Hole Date: Tue, 7 Oct 2003 14:43:35 -0600 To: Mark Crispin Subject: Re: SASL Initial Response? Cc: IMAP Extensions WG In-Reply-To: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> Message-ID: X-Mailer: Execmail for Linux 6.0.0 alpha Build (1) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h97KdbKP044762 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 7 Oct 2003 10:52:59 -0700 (Pacific Daylight Time) Mark Crispin wrote: > Hi Steve - > > I'm afraid that you misunderstood the issue. The problem is not broken > server interoperability with clients that send initial responses to SMTP > and POP3 servers; rather, it is broken server interoperability with > clients that do NOT send the initial responses. Ah! Sorry about that. --- Steve Hole Chief Technology Officer - Billing and Payment Systems ACI Worldwide Phone: 780-424-4922 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97IPjKP039783 for ; Tue, 7 Oct 2003 11:25:45 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h97IPjn4039782 for ietf-imapext-bks; Tue, 7 Oct 2003 11:25:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97IPhKP039770 for ; Tue, 7 Oct 2003 11:25:44 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id h97IPao5001170; Tue, 7 Oct 2003 14:25:36 -0400 (EDT) Message-ID: <3F8305BF.2050706@oceana.com> Date: Tue, 07 Oct 2003 14:28:15 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030916 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Mark Crispin CC: IMAP Extensions WG Subject: Re: SASL Initial Response? References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > It is for this reason that I think that the proponents of an initial > response on the command line should back off until the specifications are > clarified such that these broken SMTP and POP3 servers stop happening. I don't see why implementations which are clearly broken and in violation of the specs (regardless of how poorly written those specs may or may not be), should prevent the IMAP initial client response extension from proceeding as long as it avoids/corrects the problems with the SMTP AUTH and POP3 AUTH specs. At the very least, shouldn't the IMAP initial response doc and revised SMTP AUTH and POP3 AUTH docs be able to proceed in parallel, especially if they all use similar language for the initial client response issue? -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97I0NKP038166 for ; Tue, 7 Oct 2003 11:00:23 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h97I0Np0038165 for ietf-imapext-bks; Tue, 7 Oct 2003 11:00:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97I0LKP038160 for ; Tue, 7 Oct 2003 11:00:21 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h97I0K5t011313; Tue, 7 Oct 2003 14:00:20 -0400 Date: Tue, 7 Oct 2003 14:00:20 -0400 (EDT) From: Rob Siemborski To: Steve Hole cc: Mark Crispin , IMAP Extensions WG Subject: Re: SASL Initial Response? In-Reply-To: Message-ID: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 7 Oct 2003, Steve Hole wrote: > Perhaps the larger surprise is why people suddenly feel this important. > Cutting a round trip is nice if you're connecting/reconnecting a lot, but > I'm not sure why you would want to do that. In general, the cost of > select/examine is pretty high and part of the channel setup. It more or > less mandates efficient use of connection pooling and maintenance. Over > highly latent connections, anything that reduces roundtrips is useful > though. Personally, I don't think its "suddenly important." I just think that the lack of initial response here is unfortunate given that it violates a SASL SHOULD. Of course, the reason for this is because IMAP AUTHENTICATE came before SASL, but that doesn't preclude it being fixed by an extension. > Personally I'd be thinking about synchronization optimizations > first. Let's see ... which set of message had flags that have changed > since this time?? Doesn't CONDSTORE (which is in IETF Last Call) handle this? e.g. C: s100 UID FETCH 1:* (FLAGS) (CHANGEDSINCE 12345) S: * 1 FETCH (UID 4 MODSEQ (65402) FLAGS (\Seen)) S: * 2 FETCH (UID 6 MODSEQ (75403) FLAGS (\Deleted)) S: * 4 FETCH (UID 8 MODSEQ (29738) FLAGS ($NoJunk $AutoJunk $MDNSent)) S: s100 OK FETCH completed -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97HrDKP037911 for ; Tue, 7 Oct 2003 10:53:13 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h97HrD2w037910 for ietf-imapext-bks; Tue, 7 Oct 2003 10:53:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97Hr8KP037904 for ; Tue, 7 Oct 2003 10:53:08 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h97HqwaZ004351; Tue, 7 Oct 2003 10:53:03 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h97Hqvx0024395 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 7 Oct 2003 10:52:58 -0700 Date: Tue, 7 Oct 2003 10:52:59 -0700 (Pacific Daylight Time) From: Mark Crispin To: Steve Hole cc: IMAP Extensions WG Subject: Re: SASL Initial Response? In-Reply-To: Message-ID: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Steve - I'm afraid that you misunderstood the issue. The problem is not broken server interoperability with clients that send initial responses to SMTP and POP3 servers; rather, it is broken server interoperability with clients that do NOT send the initial responses. There are multiple SMTP and POP3 servers, some running at large ISPs, which do NOT respond correctly when a client does not provide an initial response to the PLAIN authenticator. The most common offenses are 334 ok, go on from an SMTP server and + ok, go on from a POP3 server. Another common offense is to respond with something like: 334 VXNlciBOYW1lAA== (that is, treating AUTH PLAIN with no initial response as if it was AUTH LOGIN). Yet another variation does this, but has an extra CRLF. These problems occur both with open source and vendor servers. Once again, we hear the old tired story of "our server works with Netscape [or Outlook], so your client must be broken." As for "why is this important" for IMAP; I agree with you in thinking that AUTHENTICATE command line initial response is not all that important for IMAP, since IMAP sessions generally are much longer-lived than POP3 or SMTP sessions. It is for this reason that I think that the proponents of an initial response on the command line should back off until the specifications are clarified such that these broken SMTP and POP3 servers stop happening. *AFTER* the specifications are fixed, I promise in return that I will not only stop opposing initial response on the AUTHENTICATE command line, but will also promptly implement support for it in UW imapd. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97HLsKP036582 for ; Tue, 7 Oct 2003 10:21:54 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h97HLs4e036581 for ietf-imapext-bks; Tue, 7 Oct 2003 10:21:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97HLrKP036575 for ; Tue, 7 Oct 2003 10:21:53 -0700 (PDT) (envelope-from steve.hole@messagingdirect.com) Received: from kepler.esys.ca (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h97HPfw06770; Tue, 7 Oct 2003 11:25:41 -0600 From: Steve Hole Date: Tue, 7 Oct 2003 11:25:49 -0600 To: Mark Crispin Subject: Re: SASL Initial Response? Cc: IMAP Extensions WG In-Reply-To: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> Message-ID: X-Mailer: Execmail for Linux 6.0.0 alpha Build (1) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h97HLrKP036577 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 6 Oct 2003 15:55:30 -0700 (Pacific Daylight Time) Mark Crispin wrote: > > > The second most common offense is "334 ok, go on" or "+ ok, go on". > > > Somtimes you also find extra CRLFs in the responses. > > This might be an ambiguous/incomplete specification for SMTP AUTH. I'll > > take a look. > > It's not ambiguous, but you have to read three separate documents (RFCs > 2222, 2554, and 2595) to work out how to handle an AUTH PLAIN command in > SMTP. For POP3, you just need to read 2222 and 2595. > > There is no single document, and *NO* examples, that explains this. RFC > 2554 is a bit better in talking about empty challenges than 2595 (see > first paragraph of page 3, RFC 2554) but without the context of RFC 2222 > it makes no sense. Yes, you do have to look at more than one document, and I think that this did cause some problems in the beginning. I have to admit to being a bit surprised though Mark. We have been sending out initial responses to SMTP and POP3 servers for a number of years without too much in the way of interoperability problems. There were some in the beginning, but most of those sorted out during the first IMC interop testing. Many implementations use the Cyrus SASL library which provides good examples for usage and clearly supports initial response for those mechanisms that support it. Perhaps the larger surprise is why people suddenly feel this important. Cutting a round trip is nice if you're connecting/reconnecting a lot, but I'm not sure why you would want to do that. In general, the cost of select/examine is pretty high and part of the channel setup. It more or less mandates efficient use of connection pooling and maintenance. Over highly latent connections, anything that reduces roundtrips is useful though. Personally I'd be thinking about synchronization optimizations first. Let's see ... which set of message had flags that have changed since this time?? Cheers. --- Steve Hole Chief Technology Officer - Billing and Payment Systems ACI Worldwide Phone: 780-424-4922 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96ND4KP077752 for ; Mon, 6 Oct 2003 16:13:04 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96ND4Gv077750 for ietf-imapext-bks; Mon, 6 Oct 2003 16:13:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96ND2KP077741 for ; Mon, 6 Oct 2003 16:13:02 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout5.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h96NCvMk031402; Mon, 6 Oct 2003 16:12:57 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h96NCvSS002563 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 6 Oct 2003 16:12:57 -0700 Date: Mon, 6 Oct 2003 16:12:58 -0700 (Pacific Daylight Time) From: Mark Crispin To: Rob Siemborski cc: "RL 'Bob' Morgan" , IMAP Extensions WG Subject: Re: SASL Initial Response? In-Reply-To: Message-ID: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 6 Oct 2003, Rob Siemborski wrote: > I agree. I also suspect an example or two could help the appropriate > sections of 2222bis. But further discussion of this should probably move > to the ietf-sasl list. I'm not on the ietf-sasl list, so would appreciate this being passed on. I guess that I should be at the SASL session in Minneapolis (assuming I go there which seems likely). Examples are always helpful. Section 6.1 of 2222bis should give examples of AUTH PLAIN in SMTP both with and without initial client data. Similar examples should appear in the specification for the PLAIN mechanism (which currently is hidden in the IMAP/POP3/ACAP TLS spec!) *and* in the specifications for POP3 SASL and SMTP SASL. > Obviously. But currently it seems that the primary reason that we don't > have an initial SASL response in IMAP is concerns over clarity of the > SASL specification. Actually, the primary reason was compatibility with the past; IMAP SASL is older than SASL. I'm willing to go along with it as a server-optional extension *IF* the problems with the current client-optional server-mandatory initial client data POP3/SMTP SASL are fixed. Since implementation of initial client data will be server-optional in IMAP, it will be more complex than in POP3/SMTP. This is because it's mandatory to implement in POP3/SMTP servers. > If fixing *that* specification still isn't good enough, I'm totally > willing to supply text in the draft for the IMAP extention to the effect > of "pay careful attention to the fact that initial responses are > *optional*," even to the point of making it a Security Consideration. We will need that text, and much more. > And indeed, any IMAP server that didn't get this right would immediately > have a large number of old-style clients fail to work against it anyway, > since it is an extention and not part of the base protocol. It's not just IMAP servers we have to worry about. It's also IMAP clients. We already have clients which fail to interoperate with a server that does not have a particular extension and/or declare such servers to be "broken." The offenders know who they are. We have to concern ourselves about the possibility of clients that think that initial data is mandatory to implement in the server (since it is mandatory in POP3 and SMTP). Thus, the situation is *worse* with IMAP than with POP3 or SMTP. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96MtZKP077022 for ; Mon, 6 Oct 2003 15:55:35 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96MtZVb077021 for ietf-imapext-bks; Mon, 6 Oct 2003 15:55:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout6.cac.washington.edu (mxout6.cac.washington.edu [140.142.33.20]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96MtYKP077014 for ; Mon, 6 Oct 2003 15:55:34 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout6.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h96MtT0Y001280; Mon, 6 Oct 2003 15:55:29 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h96MtTx0011345 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 6 Oct 2003 15:55:29 -0700 Date: Mon, 6 Oct 2003 15:55:30 -0700 (Pacific Daylight Time) From: Mark Crispin To: Ken Murchison cc: Rob Siemborski , IMAP Extensions WG Subject: Re: SASL Initial Response? In-Reply-To: <3F81B45E.6050909@oceana.com> Message-ID: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 6 Oct 2003, Ken Murchison wrote: > Was there a broken Sendmail patch? For all mechs, or just one in > particular? I don't know. I know that sendmail at UW works correctly for GSSAPI and PLAIN. > > The most common offense is to implement PLAIN and LOGIN as the same thing, > > thus giving LOGIN challenges to PLAIN with no initial response. > That's inexcusable, since they are clearly NOT the same thing, and PLAIN > has always had a standardized SPEC. Obviously we can't make people read > the specs correctly, all we can do is make them clear and unambiguous. Agreed completely. However, multiple commercial implementations have done this blunder. > > The second most common offense is "334 ok, go on" or "+ ok, go on". > > Somtimes you also find extra CRLFs in the responses. > This might be an ambiguous/incomplete specification for SMTP AUTH. I'll > take a look. It's not ambiguous, but you have to read three separate documents (RFCs 2222, 2554, and 2595) to work out how to handle an AUTH PLAIN command in SMTP. For POP3, you just need to read 2222 and 2595. There is no single document, and *NO* examples, that explains this. RFC 2554 is a bit better in talking about empty challenges than 2595 (see first paragraph of page 3, RFC 2554) but without the context of RFC 2222 it makes no sense. > > Over and over again, I get told "just make Pine send the initial > > challenge"; in other words, that the initial challenge is mandatory. But > > the SASL specification does not say that; and the idea of inflicting the > > non-interoperable brokenness of POP/SMTP on IMAP repels me. > So, you would like to see section 6.1 of RFC 2222bis use a MUST instead > of SHOULD? For some mechs (e.g. DIGEST-MD5) this could become > problematic because the initial response truely is optional. Actually, I would like the SHOULD to become a MAY, and it be emphasized that servers MUST implement the correct empty challenge behavior. However, a MUST is preferable to the status quo, which is a de jure SHOULD but (at least according to certain individuals) a de facto MUST. > I will do this. Just to be clear, we are only talking about > client-first mechanisms in which the client chooses to not send an > initial response, correct? Correct. SMTP is the worst case, since you have to read three RFCs to work out how to implement PLAIN in SMTP. Note that there are no examples. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96IQFKP064945 for ; Mon, 6 Oct 2003 11:26:15 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96IQFho064944 for ietf-imapext-bks; Mon, 6 Oct 2003 11:26:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96IQEKP064934 for ; Mon, 6 Oct 2003 11:26:14 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id h96IQ8o5000645; Mon, 6 Oct 2003 14:26:08 -0400 (EDT) Message-ID: <3F81B45E.6050909@oceana.com> Date: Mon, 06 Oct 2003 14:28:46 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030916 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Mark Crispin CC: Rob Siemborski , IMAP Extensions WG Subject: Re: SASL Initial Response? References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > On Mon, 6 Oct 2003, Ken Murchison wrote: > >>Can you list the broken implementations? Are there any current versions >>of servers which are broken, or just old/deprecated/unsupported code? > > > It's easier to list the non-broken implementations: UW, Cyrus, and one of > the SASL patches to sendmail. Was there a broken Sendmail patch? For all mechs, or just one in particular? > The most common offense is to implement PLAIN and LOGIN as the same thing, > thus giving LOGIN challenges to PLAIN with no initial response. That's inexcusable, since they are clearly NOT the same thing, and PLAIN has always had a standardized SPEC. Obviously we can't make people read the specs correctly, all we can do is make them clear and unambiguous. > The second most common offense is "334 ok, go on" or "+ ok, go on". > Somtimes you also find extra CRLFs in the responses. This might be an ambiguous/incomplete specification for SMTP AUTH. I'll take a look. > Over and over again, I get told "just make Pine send the initial > challenge"; in other words, that the initial challenge is mandatory. But > the SASL specification does not say that; and the idea of inflicting the > non-interoperable brokenness of POP/SMTP on IMAP repels me. So, you would like to see section 6.1 of RFC 2222bis use a MUST instead of SHOULD? For some mechs (e.g. DIGEST-MD5) this could become problematic because the initial response truely is optional. > The text is NOT clear as to how a non-specified client response is to be > handled. You have to go through multiple documents to work it out. > > The best way to understand the problem is to go through the exercise > yourself. Pretend that you don't know how SASL works. The client gives > an "AUTH PLAIN" command to an SMTP server without the initial response. > Now, go through the steps of going through the RFCs to interpret that > command, and determine the proper response. I will do this. Just to be clear, we are only talking about client-first mechanisms in which the client chooses to not send an initial response, correct? -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96I0DKP063756 for ; Mon, 6 Oct 2003 11:00:13 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96I0D68063755 for ietf-imapext-bks; Mon, 6 Oct 2003 11:00:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96I0BKP063749 for ; Mon, 6 Oct 2003 11:00:11 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOLARIS8.WASH.andrew.cmu.edu (SOLARIS8.WASH.andrew.cmu.edu [128.2.11.123]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h96I0A5t009390; Mon, 6 Oct 2003 14:00:10 -0400 Date: Mon, 6 Oct 2003 14:00:10 -0400 (EDT) From: Rob Siemborski X-X-Sender: rjs3@solaris8.wash.andrew.cmu.edu To: "RL 'Bob' Morgan" cc: Mark Crispin , IMAP Extensions WG Subject: Re: SASL Initial Response? In-Reply-To: Message-ID: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 6 Oct 2003, RL 'Bob' Morgan wrote: > On Mon, 6 Oct 2003, Mark Crispin wrote: > > > > If there is a problem, it should > > > probably be raised in the SASL WG. (Of course, that document's WG last > > > call allegedly finished on Sep 30, but it looks like comments are still > > > being made). > > > > Well, there's a problem right there; it's probably too late to raise it > > in the SASL WG. I agree that that is where it should have been raised. > > WG Last Call is only the first of many hurdles, including IETF-wide Last > Call. There is still lots of time to comment on > draft-ietf-sasl-rfc2222bis-02.txt. I agree. I also suspect an example or two could help the appropriate sections of 2222bis. But further discussion of this should probably move to the ietf-sasl list. > > So it becomes an IMAP question again. > > Any change to the IMAP protocol is of course an IMAP(ext) WG question, > even if the SASL text is perfect. Obviously. But currently it seems that the primary reason that we don't have an initial SASL response in IMAP is concerns over clarity of the SASL specification. If fixing *that* specification still isn't good enough, I'm totally willing to supply text in the draft for the IMAP extention to the effect of "pay careful attention to the fact that initial responses are *optional*," even to the point of making it a Security Consideration. And indeed, any IMAP server that didn't get this right would immediately have a large number of old-style clients fail to work against it anyway, since it is an extention and not part of the base protocol. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96HVEKP062458 for ; Mon, 6 Oct 2003 10:31:14 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96HVE2m062457 for ietf-imapext-bks; Mon, 6 Oct 2003 10:31:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96HVDKP062449 for ; Mon, 6 Oct 2003 10:31:13 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout5.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h96HV7Mk032550; Mon, 6 Oct 2003 10:31:08 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h96HV7Os002133; Mon, 6 Oct 2003 10:31:07 -0700 Date: Mon, 6 Oct 2003 10:31:07 -0700 (PDT) From: Mark Crispin To: Ken Murchison cc: Rob Siemborski , IMAP Extensions WG Subject: Re: SASL Initial Response? In-Reply-To: <3F8198A2.3070105@oceana.com> Message-ID: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 6 Oct 2003, Ken Murchison wrote: > Can you list the broken implementations? Are there any current versions > of servers which are broken, or just old/deprecated/unsupported code? It's easier to list the non-broken implementations: UW, Cyrus, and one of the SASL patches to sendmail. I'm encountering broken server implementations all the time, and big providers run them. I've seen little progress in getting it fixed. It's pretty high on my FAQ list, second only to the PC Pine crashes caused by Microsoft's persistant failure to fix the bug in SSPI that they've known about for years (they fixed it in Win2K but not WinXP). The most common offense is to implement PLAIN and LOGIN as the same thing, thus giving LOGIN challenges to PLAIN with no initial response. The second most common offense is "334 ok, go on" or "+ ok, go on". Somtimes you also find extra CRLFs in the responses. Over and over again, I get told "just make Pine send the initial challenge"; in other words, that the initial challenge is mandatory. But the SASL specification does not say that; and the idea of inflicting the non-interoperable brokenness of POP/SMTP on IMAP repels me. IMAP currently forces a correct implementation of null server challenges. Before this protection is removed, something must be done to fix the broken situation in those protocols which lack this protection. > Based on RFC 2222(bis), RFC 1734/2449 and RFC 2554, do you have any > insight? I think the text is pretty clear, but maybe others don't. The text is NOT clear as to how a non-specified client response is to be handled. You have to go through multiple documents to work it out. The best way to understand the problem is to go through the exercise yourself. Pretend that you don't know how SASL works. The client gives an "AUTH PLAIN" command to an SMTP server without the initial response. Now, go through the steps of going through the RFCs to interpret that command, and determine the proper response. I've done this tedious exercise multiple times with server implementors who simply refuse to believe that I know what I am talking about. It would be helpful if you (Ken and Rob) went through it yourselves. I agree that the specification is complete and precise. The problem is that too many implementors fail to understand it. Incidentally, it would be an acceptable answer to me to declare "on January 1, 2004, the initial challenge becomes mandatory in all protocols." I would not *like* it, but it would be better than the status quo with POP3/SMTP. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96HT7KP062381 for ; Mon, 6 Oct 2003 10:29:07 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96HT6QH062380 for ietf-imapext-bks; Mon, 6 Oct 2003 10:29:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96HT5KP062375 for ; Mon, 6 Oct 2003 10:29:05 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Mon, 6 Oct 2003 18:28:55 +0100 Message-ID: <3F81A654.5070408@isode.com> Date: Mon, 06 Oct 2003 18:28:52 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Crispin CC: Rob Siemborski , Ken Murchison , IMAP Extensions WG Subject: Re: SASL Initial Response? References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus mentioned this extension during a private talk at least 6 month ago. Unless there is a compeling reason not to add this, I am in full support for this extension. Mark Crispin wrote: >On Mon, 6 Oct 2003, Rob Siemborski wrote: > > >>I agree -- this sounds like an issue with initial responses in general, >>not with a specific use of them in IMAP. >> >> >I agree. However, the question at hand is whether to reverse an earlier >decision NOT to add this facility to IMAP. > Mark, coould you remind me when this has taken place? > Thus, it is an IMAP question. > > >>If there is a problem, it should >>probably be raised in the SASL WG. (Of course, that document's WG last >>call allegedly finished on Sep 30, but it looks like comments are still >>being made). >> >> > >Well, there's a problem right there; it's probably too late to raise it in >the SASL WG. I agree that that is where it should have been raised. > As the editor of RFC2222bis, I can say that it is not too late. >So it becomes an IMAP question again. > Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96HCqKP061400 for ; Mon, 6 Oct 2003 10:12:52 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96HCqdr061399 for ietf-imapext-bks; Mon, 6 Oct 2003 10:12:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout6.cac.washington.edu (mxout6.cac.washington.edu [140.142.33.20]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96HCpKP061391 for ; Mon, 6 Oct 2003 10:12:51 -0700 (PDT) (envelope-from rlmorgan@washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout6.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h96HCf0Y002700; Mon, 6 Oct 2003 10:12:46 -0700 Received: from D-140-142-21-78.dhcp4.washington.edu (D-140-142-21-78.dhcp4.washington.edu [140.142.21.78]) (authenticated bits=0) by smtp.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h96HCex0010547 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 6 Oct 2003 10:12:40 -0700 Date: Mon, 6 Oct 2003 10:12:32 -0700 (PDT) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@perp.cac.washington.edu To: Mark Crispin cc: IMAP Extensions WG Subject: Re: SASL Initial Response? In-Reply-To: Message-ID: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 6 Oct 2003, Mark Crispin wrote: > > If there is a problem, it should > > probably be raised in the SASL WG. (Of course, that document's WG last > > call allegedly finished on Sep 30, but it looks like comments are still > > being made). > > Well, there's a problem right there; it's probably too late to raise it > in the SASL WG. I agree that that is where it should have been raised. WG Last Call is only the first of many hurdles, including IETF-wide Last Call. There is still lots of time to comment on draft-ietf-sasl-rfc2222bis-02.txt. > So it becomes an IMAP question again. Any change to the IMAP protocol is of course an IMAP(ext) WG question, even if the SASL text is perfect. - RL "Bob" Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96H3XKP060945 for ; Mon, 6 Oct 2003 10:03:33 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96H3XfJ060944 for ietf-imapext-bks; Mon, 6 Oct 2003 10:03:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96H3WKP060938 for ; Mon, 6 Oct 2003 10:03:32 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout3.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h96H3QC2018267; Mon, 6 Oct 2003 10:03:26 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h96H3PWF000441; Mon, 6 Oct 2003 10:03:25 -0700 Date: Mon, 6 Oct 2003 10:03:25 -0700 (PDT) From: Mark Crispin To: Rob Siemborski cc: Ken Murchison , IMAP Extensions WG Subject: Re: SASL Initial Response? In-Reply-To: Message-ID: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 6 Oct 2003, Rob Siemborski wrote: > I agree -- this sounds like an issue with initial responses in general, > not with a specific use of them in IMAP. I agree. However, the question at hand is whether to reverse an earlier decision NOT to add this facility to IMAP. Thus, it is an IMAP question. > If there is a problem, it should > probably be raised in the SASL WG. (Of course, that document's WG last > call allegedly finished on Sep 30, but it looks like comments are still > being made). Well, there's a problem right there; it's probably too late to raise it in the SASL WG. I agree that that is where it should have been raised. So it becomes an IMAP question again. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96GUKKP058666 for ; Mon, 6 Oct 2003 09:30:20 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96GUKoA058665 for ietf-imapext-bks; Mon, 6 Oct 2003 09:30:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96GUIKP058660 for ; Mon, 6 Oct 2003 09:30:19 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOLARIS8.WASH.andrew.cmu.edu (SOLARIS8.WASH.andrew.cmu.edu [128.2.11.123]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h96GUH5t009250; Mon, 6 Oct 2003 12:30:17 -0400 Date: Mon, 6 Oct 2003 12:30:17 -0400 (EDT) From: Rob Siemborski X-X-Sender: rjs3@solaris8.wash.andrew.cmu.edu To: Ken Murchison cc: Mark Crispin , IMAP Extensions WG Subject: Re: SASL Initial Response? In-Reply-To: <3F8198A2.3070105@oceana.com> Message-ID: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 6 Oct 2003, Ken Murchison wrote: > > 4) Would a change of wording in the specification help? > > Based on RFC 2222(bis), RFC 1734/2449 and RFC 2554, do you have any > insight? I think the text is pretty clear, but maybe others don't. I agree -- this sounds like an issue with initial responses in general, not with a specific use of them in IMAP. If there is a problem, it should probably be raised in the SASL WG. (Of course, that document's WG last call allegedly finished on Sep 30, but it looks like comments are still being made). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96GRuKP058525 for ; Mon, 6 Oct 2003 09:27:56 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96GRujM058524 for ietf-imapext-bks; Mon, 6 Oct 2003 09:27:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96GRsKP058513 for ; Mon, 6 Oct 2003 09:27:55 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id h96GRlo5025878; Mon, 6 Oct 2003 12:27:48 -0400 (EDT) Message-ID: <3F8198A2.3070105@oceana.com> Date: Mon, 06 Oct 2003 12:30:26 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030916 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Mark Crispin CC: Rob Siemborski , IMAP Extensions WG Subject: Re: SASL Initial Response? References: <3F81908D.5000101@oceana.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > On Mon, 6 Oct 2003, Ken Murchison wrote: > >>This might be true, but it doesn't seem like a compelling technical >>argument against allowing this in IMAP. Existing or future poor >>implementations should not stand in the way of progress, unless the >>specification is so complex that it is part of the implementation problem. > > > Well, I think that the example of POP and SMTP suggests that it may well > be too complex. Before proceeding, I think that the POP/SMTP experience > needs to be carefully reviewed. > > >>Are you saying that you would oppose such an extension, or just saying >>that based on past experience it might cause some heartburn? > > > It will cause some heartburn. The proof is out there. Can you list the broken implementations? Are there any current versions of servers which are broken, or just old/deprecated/unsupported code? > > As for support or opposition, I haven't taken a position; but if it is > proposed without any attempt to study or learn from the POP/SMTP > experience I probably will oppose it. > > Suggested topics for study: > > 1) Why is it difficult to understand that the initial response is > optional? > > 2) Why do server implementors have trouble in generating appropriate > initial challenges ("ok, go ahead" in plaintext is not appropriate)? > > 3) Why are incorrect implementations so widespread in the POP/SMTP world? > > 4) Would a change of wording in the specification help? Based on RFC 2222(bis), RFC 1734/2449 and RFC 2554, do you have any insight? I think the text is pretty clear, but maybe others don't. > If these questions are answered in a reasonable way, I will either support > or be neutral on the proposal. Glad to hear it. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96GIJKP058083 for ; Mon, 6 Oct 2003 09:18:19 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96GIJv0058082 for ietf-imapext-bks; Mon, 6 Oct 2003 09:18:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96GIIKP058072 for ; Mon, 6 Oct 2003 09:18:18 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout5.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h96GI7Mk017758; Mon, 6 Oct 2003 09:18:12 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h96GI7B3030349; Mon, 6 Oct 2003 09:18:07 -0700 Date: Mon, 6 Oct 2003 09:18:07 -0700 (PDT) From: Mark Crispin To: Ken Murchison cc: Rob Siemborski , IMAP Extensions WG Subject: Re: SASL Initial Response? In-Reply-To: <3F81908D.5000101@oceana.com> Message-ID: References: <3F81908D.5000101@oceana.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 6 Oct 2003, Ken Murchison wrote: > This might be true, but it doesn't seem like a compelling technical > argument against allowing this in IMAP. Existing or future poor > implementations should not stand in the way of progress, unless the > specification is so complex that it is part of the implementation problem. Well, I think that the example of POP and SMTP suggests that it may well be too complex. Before proceeding, I think that the POP/SMTP experience needs to be carefully reviewed. > Are you saying that you would oppose such an extension, or just saying > that based on past experience it might cause some heartburn? It will cause some heartburn. The proof is out there. As for support or opposition, I haven't taken a position; but if it is proposed without any attempt to study or learn from the POP/SMTP experience I probably will oppose it. Suggested topics for study: 1) Why is it difficult to understand that the initial response is optional? 2) Why do server implementors have trouble in generating appropriate initial challenges ("ok, go ahead" in plaintext is not appropriate)? 3) Why are incorrect implementations so widespread in the POP/SMTP world? 4) Would a change of wording in the specification help? If these questions are answered in a reasonable way, I will either support or be neutral on the proposal. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96FrXKP056715 for ; Mon, 6 Oct 2003 08:53:33 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96FrXpB056714 for ietf-imapext-bks; Mon, 6 Oct 2003 08:53:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96FrWKP056708 for ; Mon, 6 Oct 2003 08:53:32 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id h96FrJo5017536; Mon, 6 Oct 2003 11:53:19 -0400 (EDT) Message-ID: <3F81908D.5000101@oceana.com> Date: Mon, 06 Oct 2003 11:55:57 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030916 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Mark Crispin CC: Rob Siemborski , ietf-imapext@imc.org Subject: Re: SASL Initial Response? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > On Mon, 6 Oct 2003, Rob Siemborski wrote: > >>Is there any reason no one has ever proposed an IMAP extention to support >>SASL initial client responses? > > > Experience with POP and SMTP suggests that if the protcol supports initial > client responses, server implementors will never correctly implement the > case when the client does not supply one. > > This has been an ongoing problem which, to date, IMAP has had blissful > immunity. This might be true, but it doesn't seem like a compelling technical argument against allowing this in IMAP. Existing or future poor implementations should not stand in the way of progress, unless the specification is so complex that it is part of the implementation problem. Are you saying that you would oppose such an extension, or just saying that based on past experience it might cause some heartburn? -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96FRrKP055595 for ; Mon, 6 Oct 2003 08:27:53 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96FRrwm055594 for ietf-imapext-bks; Mon, 6 Oct 2003 08:27:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96FRqKP055586 for ; Mon, 6 Oct 2003 08:27:52 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout4.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h96FRkmw027328; Mon, 6 Oct 2003 08:27:51 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h96FRkLn027836; Mon, 6 Oct 2003 08:27:46 -0700 Date: Mon, 6 Oct 2003 08:27:46 -0700 (PDT) From: Mark Crispin To: Rob Siemborski cc: ietf-imapext@imc.org Subject: Re: SASL Initial Response? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 6 Oct 2003, Rob Siemborski wrote: > Is there any reason no one has ever proposed an IMAP extention to support > SASL initial client responses? Experience with POP and SMTP suggests that if the protcol supports initial client responses, server implementors will never correctly implement the case when the client does not supply one. This has been an ongoing problem which, to date, IMAP has had blissful immunity. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96EocKP053754 for ; Mon, 6 Oct 2003 07:50:38 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96Eoc1B053753 for ietf-imapext-bks; Mon, 6 Oct 2003 07:50:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96EoaKP053745 for ; Mon, 6 Oct 2003 07:50:37 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from MAIL5.andrew.cmu.edu (MAIL5.andrew.cmu.edu [128.2.10.135]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h96Eob5t009084 for ; Mon, 6 Oct 2003 10:50:37 -0400 Date: Mon, 6 Oct 2003 10:50:37 -0400 (EDT) From: Rob Siemborski To: ietf-imapext@imc.org Subject: SASL Initial Response? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Is there any reason no one has ever proposed an IMAP extention to support SASL initial client responses? My basic idea would be that the server would advertise another (sigh) capability, and would then accept a second argument to the AUTHENTICATE command which would contain the initial SASL blob (if applicable). Can anyone offhand see why this would be an outright bad idea? Certainly, I can understand not being able to do this for server-last-sends currently (since that seems to require a client-side capability mechanism of some sort), but it seems like initial client responses would be both easy to add, and beneficial (in terms of the number of round trips required at startup). If there aren't significant initial objections, I'm willing to put together an individual ID for this. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h94JtTKP044138 for ; Sat, 4 Oct 2003 12:55:31 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h94JtT9M044137 for ietf-imapext-bks; Sat, 4 Oct 2003 12:55:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from melkebalanse.gulbrandsen.priv.no (melkebalanse.gulbrandsen.priv.no [217.19.171.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h94JtSKP044131 for ; Sat, 4 Oct 2003 12:55:29 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Message-Id: From: Arnt Gulbrandsen To: Mark Crispin Subject: Re: two ACL2 points Cc: IMAP extensions Mailing List References: In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Sat, 4 Oct 2003 21:57:58 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: > On Sat, 4 Oct 2003, Arnt Gulbrandsen wrote: >> What I'd like is a requirement that the server MAY send unsolicited >> LIST (ACL) responses for any mailbox for which the client has issued >> an ACL command, and that the client MUST handle such responses. > > That is already a requirement of IMAP, and always has been. Yes, I've seen the half-sentence in 2.2.2. But I don't see much about "client MUST handle", except specific requirements such as that in 7.2.6. A nudge and a wink doesn't seem out of place in the ACL2 document. Perhaps in the form of a stated "client MUST handle", or perhaps in the form of an example that draws attention to rules that are in the base RFC. (I ran into this while fooling with an ACL dialog and thinking, what if this is run by two IMAP clients at the same time, e.g. two people responding to the same e-mailed request?) --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h94J6rKP042772 for ; Sat, 4 Oct 2003 12:06:53 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h94J6r32042771 for ietf-imapext-bks; Sat, 4 Oct 2003 12:06:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h94J6kKP042764 for ; Sat, 4 Oct 2003 12:06:47 -0700 (PDT) (envelope-from tss@iki.fi) Received: by danu.procontrol.fi (Postfix, from userid 106) id 082A9238C6; Sat, 4 Oct 2003 22:06:39 +0300 (EEST) Received: from iki.fi (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id 1A068238B6; Sat, 4 Oct 2003 22:06:26 +0300 (EEST) Date: Sat, 4 Oct 2003 22:06:36 +0300 Subject: Re: two ACL2 points Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: IMAP extensions Mailing List To: Arnt Gulbrandsen From: Timo Sirainen In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-5.8 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES, USER_AGENT_APPLEMAIL version=2.54 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Saturday, Oct 4, 2003, at 20:41 Europe/Helsinki, Arnt Gulbrandsen wrote: > 1. The SELECT command looks at ACL, says the draft, but as soon as a > client has selected a mailbox that's it. The security considerations > should probably note that if an ACL is restricted, any client that > already has selected the mailbox keeps its access indefinitely. > > Perhaps the server should be explicitly allowed to kick the client out > in this case. This is mail store dependent. If you drop access to maildir in filesystem level, you can't open mails anymore. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h94IgkKP042132 for ; Sat, 4 Oct 2003 11:42:46 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h94IgklB042131 for ietf-imapext-bks; Sat, 4 Oct 2003 11:42:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h94IgjKP042123 for ; Sat, 4 Oct 2003 11:42:45 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout3.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h94IgRC2028566; Sat, 4 Oct 2003 11:42:32 -0700 Received: from Shimo-Tomobiki.Panda.COM (panda.com [206.124.149.114]) (authenticated bits=0) by smtp.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h94IgKx0008663 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 4 Oct 2003 11:42:26 -0700 Date: Sat, 4 Oct 2003 11:42:20 -0700 (Pacific Daylight Time) From: Mark Crispin To: Arnt Gulbrandsen cc: IMAP extensions Mailing List Subject: Re: two ACL2 points In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sat, 4 Oct 2003, Arnt Gulbrandsen wrote: > 1. The SELECT command looks at ACL, says the draft, but as soon as a > client has selected a mailbox that's it. The security considerations > should probably note that if an ACL is restricted, any client that > already has selected the mailbox keeps its access indefinitely. I agree. > 2. A client that has run LIST ACL isn't told about later changes. Similarly, a client that does a LIST isn't told when mailboxes are created or deleted. > What I'd like is a requirement that the server MAY send unsolicited LIST > (ACL) responses for any mailbox for which the client has issued an ACL > command, and that the client MUST handle such responses. That is already a requirement of IMAP, and always has been. For example, a server can send an untagged SEARCH even if the client never issued a SEARCH command. However, there is no reason to believe that any client will do anything with such responses. The unsolicited data model only requires that clients keep track of state changes in the selected mailbox, and is silent about other data. It neither mandates nor forbids it. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h94Hd4KP040824 for ; Sat, 4 Oct 2003 10:39:04 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h94Hd4BD040823 for ietf-imapext-bks; Sat, 4 Oct 2003 10:39:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from melkebalanse.gulbrandsen.priv.no (melkebalanse.gulbrandsen.priv.no [217.19.171.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h94HcvKP040818 for ; Sat, 4 Oct 2003 10:39:04 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Message-Id: From: Arnt Gulbrandsen To: IMAP extensions Mailing List Subject: two ACL2 points Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Sat, 4 Oct 2003 19:41:21 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [ As I write this mail I have a deja vu feeling. Have I already noted these things? I don't see anything in my mail archive. ] Both points relate to changes in ACLs done by one client that affect another. 1. The SELECT command looks at ACL, says the draft, but as soon as a client has selected a mailbox that's it. The security considerations should probably note that if an ACL is restricted, any client that already has selected the mailbox keeps its access indefinitely. Perhaps the server should be explicitly allowed to kick the client out in this case. 2. A client that has run LIST ACL isn't told about later changes. IMO, the server has the right to send any and all unsolicited responses during IDLE mode, and also as side effects for most commands. But I suspect many clients don't handle that very well... What I'd like is a requirement that the server MAY send unsolicited LIST (ACL) responses for any mailbox for which the client has issued an ACL command, and that the client MUST handle such responses. --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93EGxKP022544 for ; Fri, 3 Oct 2003 07:16:59 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h93EGwnj022543 for ietf-imapext-bks; Fri, 3 Oct 2003 07:16:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93EGvKP022538 for ; Fri, 3 Oct 2003 07:16:58 -0700 (PDT) (envelope-from apache@asgard.ietf.org) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1A5Qjn-0001EU-CT; Fri, 03 Oct 2003 10:16:55 -0400 X-test-idtracker: no To: IETF-Announce :; Cc: ietf-imapext@imc.org From: The IESG Subject: Last Call: 'IMAP Extension for Conditional STORE operation' to Proposed Standard Reply-to: iesg@ietf.org Message-Id: Date: Fri, 03 Oct 2003 10:16:55 -0400 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has received a request from the Internet Message Access Protocol Extension WG to consider the following document: - 'IMAP Extension for Conditional STORE operation ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-10-17. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-imapext-condstore-04.txt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92GvCKP003955 for ; Thu, 2 Oct 2003 09:57:12 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h92GvCts003954 for ietf-imapext-bks; Thu, 2 Oct 2003 09:57:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92Gv6KP003945 for ; Thu, 2 Oct 2003 09:57:06 -0700 (PDT) (envelope-from ned+imapext@innosoft.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01L1CHPORFMO002O3W@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf-imapext@imc.org; Thu, 02 Oct 2003 09:56:44 -0700 (PDT) Date: Thu, 02 Oct 2003 09:55:35 -0700 (PDT) From: ned+imapext@INNOSOFT.COM Subject: Re: AD review comments on draft-ietf-imapext-condstore In-reply-to: "Your message dated Thu, 02 Oct 2003 10:01:45 +0100" <3F7BE979.3040401@isode.com> To: Alexey Melnikov Cc: ned+imapext@INNOSOFT.COM, Pete Resnick , ietf-imapext@imc.org, Ned Freed , hardie@qualcomm.com Message-id: <01L1CKZ0MGMY002O3W@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <01L1BYWZM9P200UICS@mauve.mrochek.com> <3F7BE979.3040401@isode.com> Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > The production: > > > > fetch = "FETCH" SP sequence-set SP ("ALL" / "FULL" / > > "FAST" / fetch-att / > > "(" fetch-att *(SP fetch-att) ")") > > [SPfetch-modifiers] > > > > should read: > > > > fetch = "FETCH" SP sequence-set SP ("ALL" / "FULL" / > > "FAST" / fetch-att / > > "(" fetch-att *(SP fetch-att) ")") [SP > > fetch-modifiers] > Actually, this production is correct (there is a space between SP and > fetch-modifiers. Some sort of wierd cut and paste error on my part then. Sorry about that. > I've updated the document. Yes, thanks, and now that the revision has hit the repository I'll ask for a last call. Ned Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92EobKP098892 for ; Thu, 2 Oct 2003 07:50:37 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h92Eob2N098890 for ietf-imapext-bks; Thu, 2 Oct 2003 07:50:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92EoZKP098884 for ; Thu, 2 Oct 2003 07:50:36 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23139; Thu, 2 Oct 2003 10:50:27 -0400 (EDT) Message-Id: <200310021450.KAA23139@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-condstore-04.txt Date: Thu, 02 Oct 2003 10:50:27 -0400 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF. Title : IMAP Extension for Conditional STORE operation Author(s) : A. Melnikov, S. Hole Filename : draft-ietf-imapext-condstore-04.txt Pages : 16 Date : 2003-10-2 Often, multiple IMAP clients need to coordinate changes to a common IMAP mailbox. Examples include different clients for the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to synchronize state changes for messages within the mailbox. They must be able to guarantee that only one client can change message state (e.g., message flags or annotations) at any time. An example of such an application is use of an IMAP mailbox as a message queue with multiple dequeueing clients. The Conditional Store facility provides a protected update mechanism for message state information that can detect and resolve conflicts between multiple writing mail clients. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-condstore-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-imapext-condstore-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imapext-condstore-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-2105852.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-condstore-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-condstore-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-2105852.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92929KP084522 for ; Thu, 2 Oct 2003 02:02:09 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h92929mU084521 for ietf-imapext-bks; Thu, 2 Oct 2003 02:02:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92922KP084508 for ; Thu, 2 Oct 2003 02:02:07 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Thu, 2 Oct 2003 10:01:47 +0100 Message-ID: <3F7BE979.3040401@isode.com> Date: Thu, 02 Oct 2003 10:01:45 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ned+imapext@INNOSOFT.COM CC: Pete Resnick , ietf-imapext@imc.org, Ned Freed , hardie@qualcomm.com Subject: Re: AD review comments on draft-ietf-imapext-condstore References: <01L1BYWZM9P200UICS@mauve.mrochek.com> In-Reply-To: <01L1BYWZM9P200UICS@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ned+imapext@INNOSOFT.COM wrote: > > Pete asked me to last call this document. However, my AD review turned up > a number of errors, mostly editorial in nature. There are enough of these > that I think they need to be corrected in a revised I-D before > proceeding. > > - - - - - - > > Section 2, fifth paragraph: A reference to [ANNOTATE] should be added. > > Section 2, seventh paragraph: extention -> extension > > Section 4, second paragraph: "[IMAP4]" -> "[IMAP4] or [ANNOTATE]" > > There are lots of ABNF errors. The production: > > entry-name = entry-name-flag / entry-annotate-name > should be: > > entry-name = entry-flag-name / entry-annotate-name > (There is no entry-name-flag production.) The production: > > entry-flag-name = '"' "/flags/" attr-flag '"' > > isn't syntactically valid and needs to be changed to: > > entry-flag-name = DQUOTE "/flags/" attr-flag DQUOTE > > (The DQUOTE production is used in RFC 3501, whose ABNF is available to > this document.) The production: > > entry-type-resp = "priv" | "shared" > > should be: > > entry-type-resp = "priv" / "shared" > > The production: > > entry-type-req = entry-type-resp | "all" > > should be: > > entry-type-req = entry-type-resp / "all" > > The production: > > store = "STORE" SP set store-modifiers SP > store-att-flags > > should read: > > store = "STORE" SP sequence-set store-modifiers > SP store-att-flags > The production: > > fetch = "FETCH" SP sequence-set SP ("ALL" / "FULL" / > "FAST" / fetch-att / > "(" fetch-att *(SP fetch-att) ")") > [SPfetch-modifiers] > > should read: > > fetch = "FETCH" SP sequence-set SP ("ALL" / "FULL" / > "FAST" / fetch-att / > "(" fetch-att *(SP fetch-att) ")") [SP > fetch-modifiers] Actually, this production is correct (there is a space between SP and fetch-modifiers. > The production: > > mod-sequence-valzer = "0" | mod-sequence-value > > should be: > > mod-sequence-valzer = "0" / mod-sequence-value > > The production name "search_sort_mod_seq" needs to be changed to > "search-sort-mod-seq" everywhere. (Underscors aren't allowed in > production > names.) > > Security considerations: > > The statement "It is believed that the Conditional STORE extension > doesn't raise any new security concerns that are not already discussed > in [IMAP4]" is correct as far as it goes. However, this extension > provides a means by which an IMAP store can be used for potentially > criticial applications involving multiple clients that could not be > supported before. This may have the effect of making correct IMAP > server behavior more important. Accordingly, I suggest amending the > section to read: > > It is believed that the Conditional STORE extension doesn't raise > any new security concerns that are not already discussed in [IMAP4]. > However, the availability of this extension may make it possible > for IMAP4 to be used in critical applications it could not be used > for previously, making correct IMAP server implementation and > operation in even more important. > > Section 7: The wording here is awkward. I suggest changing it to read: > "This document defines the CONDSTORE and SORT=MODSEQ IMAP capabilities. > IANA should add them to the registry accordingly." > > Acknowledgements, third paragraph: "Authors" -> "The authors" > > That's it! > > Ned Thank you Ned. I've updated the document. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h926PQKP049702 for ; Wed, 1 Oct 2003 23:25:26 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h926PQPj049701 for ietf-imapext-bks; Wed, 1 Oct 2003 23:25:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h926PMKP049680 for ; Wed, 1 Oct 2003 23:25:25 -0700 (PDT) (envelope-from ned+imapext@innosoft.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01L1BYJ8S38000UICS@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf-imapext@imc.org; Wed, 01 Oct 2003 23:25:09 -0700 (PDT) Date: Wed, 01 Oct 2003 23:15:36 -0700 (PDT) From: ned+imapext@INNOSOFT.COM Subject: AD review comments on draft-ietf-imapext-condstore In-reply-to: "Your message dated Wed, 01 Oct 2003 15:34:52 -0500" To: Pete Resnick , ietf-imapext@imc.org Cc: Ned Freed , hardie@qualcomm.com Message-id: <01L1BYWZM9P200UICS@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Pete asked me to last call this document. However, my AD review turned up a number of errors, mostly editorial in nature. There are enough of these that I think they need to be corrected in a revised I-D before proceeding. - - - - - - Section 2, fifth paragraph: A reference to [ANNOTATE] should be added. Section 2, seventh paragraph: extention -> extension Section 4, second paragraph: "[IMAP4]" -> "[IMAP4] or [ANNOTATE]" There are lots of ABNF errors. The production: entry-name = entry-name-flag / entry-annotate-name should be: entry-name = entry-flag-name / entry-annotate-name (There is no entry-name-flag production.) The production: entry-flag-name = '"' "/flags/" attr-flag '"' isn't syntactically valid and needs to be changed to: entry-flag-name = DQUOTE "/flags/" attr-flag DQUOTE (The DQUOTE production is used in RFC 3501, whose ABNF is available to this document.) The production: entry-type-resp = "priv" | "shared" should be: entry-type-resp = "priv" / "shared" The production: entry-type-req = entry-type-resp | "all" should be: entry-type-req = entry-type-resp / "all" The production: store = "STORE" SP set store-modifiers SP store-att-flags should read: store = "STORE" SP sequence-set store-modifiers SP store-att-flags The production: fetch = "FETCH" SP sequence-set SP ("ALL" / "FULL" / "FAST" / fetch-att / "(" fetch-att *(SP fetch-att) ")") [SPfetch-modifiers] should read: fetch = "FETCH" SP sequence-set SP ("ALL" / "FULL" / "FAST" / fetch-att / "(" fetch-att *(SP fetch-att) ")") [SP fetch-modifiers] The production: mod-sequence-valzer = "0" | mod-sequence-value should be: mod-sequence-valzer = "0" / mod-sequence-value The production name "search_sort_mod_seq" needs to be changed to "search-sort-mod-seq" everywhere. (Underscors aren't allowed in production names.) Security considerations: The statement "It is believed that the Conditional STORE extension doesn't raise any new security concerns that are not already discussed in [IMAP4]" is correct as far as it goes. However, this extension provides a means by which an IMAP store can be used for potentially criticial applications involving multiple clients that could not be supported before. This may have the effect of making correct IMAP server behavior more important. Accordingly, I suggest amending the section to read: It is believed that the Conditional STORE extension doesn't raise any new security concerns that are not already discussed in [IMAP4]. However, the availability of this extension may make it possible for IMAP4 to be used in critical applications it could not be used for previously, making correct IMAP server implementation and operation in even more important. Section 7: The wording here is awkward. I suggest changing it to read: "This document defines the CONDSTORE and SORT=MODSEQ IMAP capabilities. IANA should add them to the registry accordingly." Acknowledgements, third paragraph: "Authors" -> "The authors" That's it! Ned