Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4UICfAF042952 for ; Fri, 30 May 2003 11:12:41 -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 h4UICf8Z042951 for ietf-imapext-bks; Fri, 30 May 2003 11:12:41 -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 ([208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4UICdAF042942 for ; Fri, 30 May 2003 11:12:39 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.9/8.12.9) with ESMTP id h4UIC3bl013425; Fri, 30 May 2003 14:12:03 -0400 (EDT) Message-ID: <3ED79F1F.6070703@oceana.com> Date: Fri, 30 May 2003 14:12:47 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Cyrus Daboo CC: IMAP Extensions WG Subject: Re: New ANNOTATEMORE draft References: <2147483647.1053517397@[10.0.1.10]> 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 Daboo wrote: > > 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-03.txt > Pages : 17 > Date : 2003-5-20 From section 7: "If a client attempts to store or retrieve a shared annotation on a READ-ONLY mailbox, the server MUST respond with a NO response." Is there a reason why I shouldn't be able to fetch a shared annotation on a READ-ONLY mailbox? -- 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 h4LFh5AF037114 for ; Wed, 21 May 2003 08:43:05 -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 h4LFh5uH037113 for ietf-imapext-bks; Wed, 21 May 2003 08:43:05 -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.9/8.12.8) with ESMTP id h4LFh3AF037108 for ; Wed, 21 May 2003 08:43:04 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id LAA06958 for ; Wed, 21 May 2003 11:39:26 -0400 (EDT) Date: Wed, 21 May 2003 11:43:17 -0400 From: Cyrus Daboo To: IMAP Extensions WG Subject: New ANNOTATEMORE draft Message-ID: <2147483647.1053517397@[10.0.1.10]> X-Mailer: Mulberry/3.1.0b1 (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: 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-03.txt Pages : 17 Date : 2003-5-20 The ANNOTATEMORE extension to the Internet Message Access Protocol [IMAP4] permits clients and servers to maintain 'metadata' on IMAP4 servers. This document describes two 'profiles' for mailbox and server metadata. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-daboo-imap-annotatemore-03.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-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-daboo-imap-annotatemore-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4LCYsAF024314 for ; Wed, 21 May 2003 05:34: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 h4LCYslY024313 for ietf-imapext-bks; Wed, 21 May 2003 05:34:54 -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.9/8.12.8) with ESMTP id h4LCYqAF024308 for ; Wed, 21 May 2003 05:34:53 -0700 (PDT) (envelope-from tss@iki.fi) Received: by oma.irssi.org (Postfix, from userid 1000) id 1561D5C896C6; Wed, 21 May 2003 15:34:53 +0300 (EEST) Subject: Re: I-D ACTION:draft-ietf-imapext-annotate-07.txt From: Timo Sirainen To: ietf-imapext@imc.org In-Reply-To: <200305211210.IAA16043@ietf.org> References: <200305211210.IAA16043@ietf.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1053520492.28384.5.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 21 May 2003 15:34:52 +0300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > In some cases, servers may be able to offer annotations on some > mailboxes and not others. For mailboxes that cannot have > annotations associated with them, the server MUST return an > "ANNOTATESIZE" response with a value of "0" (zero) during the SELECT > or EXAMINE command for that mailbox. Clients MUST NOT attempt to > fetch or store annotations on any messages in a mailbox for which > the "ANNOTATESIZE" response was zero. What if I want read-only annotation support? I think ANNOTATESIZE 0 should mean that client must not attept to store annotations, but it may try fetching shared annotations. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4LCAgAF022946 for ; Wed, 21 May 2003 05:10:42 -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 h4LCAgR7022945 for ietf-imapext-bks; Wed, 21 May 2003 05:10:42 -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 h4LCAfAF022940 for ; Wed, 21 May 2003 05:10:41 -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 IAA16043; Wed, 21 May 2003 08:10:41 -0400 (EDT) Message-Id: <200305211210.IAA16043@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-07.txt Date: Wed, 21 May 2003 08:10:40 -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-07.txt Pages : 22 Date : 2003-5-20 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-07.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-07.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-07.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-5-20123707.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-annotate-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-annotate-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-20123707.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 h4L2BxAF068420 for ; Tue, 20 May 2003 19:11: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 h4L2BxkM068419 for ietf-imapext-bks; Tue, 20 May 2003 19:11:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4L2BvAF068414 for ; Tue, 20 May 2003 19:11:57 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id 3D301813E6D; Tue, 20 May 2003 19:12:00 -0700 (PDT) Received: from dev2.promeetium.com (adsl-67-123-208-210.dsl.lsan03.pacbell.net [67.123.208.210]) by DrPepper (Postfix) with ESMTP id F0FCC80D166; Tue, 20 May 2003 19:11:57 -0700 (PDT) From: Michael Fair Organization: DaClubhouse To: Timo Sirainen , ietf-imapext@imc.org Subject: Re: Foreknowledge versus pipelines Date: Tue, 20 May 2003 19:07:58 -0700 User-Agent: KMail/1.5.1 References: <014901c31d95$3a415a80$d1d07b43@cocacola> <015401c31f05$28c061e0$d1d07b43@cocacola> <1053463140.1214.322.camel@hurina> In-Reply-To: <1053463140.1214.322.camel@hurina> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200305201907.59220.michael@daclubhouse.net> X-Spam-Status: No, hits=-32.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_KMAIL version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tuesday 20 May 2003 01:39 pm, Timo Sirainen wrote: > On Tue, 2003-05-20 at 22:22, Michael Fair wrote: > > Could we achieve the same result by having the server dump the > > queue and then /dev/null the rest of the incoming queue data > > and then once that's finished return a "NO" to the client > > citing the error? > > Currently my server just disconnects the client if it tries to use too > large literal+ size. I don't think it's a good idea to allow clients to > say "hey, I'll send you 2 gigabytes of data, start reading" especially > before logging in. What's to stop a client from doing that now? S: * Hello Welcome to IMAP C: 1 a C: 2 a C: 3 a ..... Repeat 2G worth ..... The result is the same - it's just less explicit about its intentions. > How about specifying a limit for which you can use literal+? So that if > you send less data than eg. 8192 bytes, you can safely send it, but for > anything more you'd have to use regular literals which server can > reject. I'll have to read up on literal+ to understand what it does and how it behaves before I can really comment. If we are going to refuse a client for too much data before they start sending it, then I think we should explicitly tell them that it's clear to send somehow. I'm thinking a client must wait till it receives a response from the server which can be "+", "NO" or "BAD". If "+" the client can send the data. Once the number of octects specified by the client for the CQUEUE is reached, the buffer closes and if the buffer does not end in a \r\n it is a syntax error and is responded with "BAD" immediately. No further data is read by the server until the CQUEUE is finished or until a command in the queue that needs more input is reached. > > If we fix the octet counts so that server announces a max octet > > buffer which cannot be exceeded, and the client announces how > > much data it is submitting, the last two octets of which must > > be \r\n (the end of a command), would that satisfy the concerns > > that you have over this causing problems for generic usage? > > No, I'm thinking there could be some more subtle problems when some of > the commands in the group changes state in some way. My server currently > trashes all buffered input after logging in since the client's socket is > transferred to another process, but maybe I should fix that since it's > not fully IMAP compliant.. The full intent of this is to allow the client to optimistically "guess" a valid command path to go from HELLO to AUTHENTICATED. I expect clients might want to cache the command chain that worked and replay it whenever they log in for that account. Each command either succeeds, or the whole process stops. Each command is executed in order. This way the client progresses through the various states without stopping to check the environment (unless the chain fails of course). So this leads me to: S: * Hello welcome to IMAP C: 1 CAPABILITY S: 1 OK CAPABILITY CQUEUE (8192) C: 2 CQUEUE (111) S: + C: 3 VHOST (fqdn.example.com) C: 4 LANGUAGE (new_lang) C: 5 STARTTLS C: 6 AUTHENTICATE PLAIN C: 7 SELECT INBOX ... Rest as before but selecting the INBOX at the very end of the chain ... And for failures: S: * Hello welcome to IMAP C: 1 CAPABILITY S: 1 OK CAPABILITY CQUEUE (8192) C: 2 CQUEUE (9999) S: 2 NO Too much data S: * Hello welcome to IMAP C: 1 CAPABILITY S: 1 OK CAPABILITY CQUEUE (8192) C: 2 CQUEUE (11) S: + C: 3 VHOST (fqdn.example.com) S: 2 BAD Buffer does not end on a newline ... Server then should discard everything up to the next \r\n lest it choke on bad input ... > > > > As with the GROUP proposal, as bonus points, there would > > > > be an optional "TRANSACTION" parameter which would have > - etc. Until the rest of the command has been settled on I'm removing this from the list unless someone else would like to take a stab at clearly defining the semantics. If someone does want to take it on, for the most part, it should be sufficient to follow SQL database semantics for this in regards to simoultaneous access - CQUEUE with TRANSACTION could lock all writes to the mail store until it completed (most likely responding with "NO Transaction in progress" for any write operations until the QUEUE completed. If a command should fail, then the mail store should be message data and state identical to what it was before, and the session should be in whatever state it was in prior to the CQUEUE command. A more advanced server could parse through the command structure and build a list of object locks it would need prior to starting, would then lock those objects (or fail if it couldn't obtain such locks), and execute the commands. Any other client wanting to operate on other non-locked objects could be allowed to do so, attempting to write to a locked object should fail instantly to notify the client that the data is potentially about to change and it should fetch an update. Reading locked objects might be a blocking operation until the transaction completes, or might be refused pending transaction completion. I don't know exactly what all the details for the most useful operation behaviors would be - or even why it might be useful, so until there is a clearer use case and understanding of the mail store and session states as transactional creatures I'll withdraw it from the table. -- Michael -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4KKd3AF058043 for ; Tue, 20 May 2003 13:39:03 -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 h4KKd3l4058042 for ietf-imapext-bks; Tue, 20 May 2003 13:39:03 -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.9/8.12.8) with ESMTP id h4KKcxAF058035 for ; Tue, 20 May 2003 13:39:01 -0700 (PDT) (envelope-from tss@iki.fi) Received: by oma.irssi.org (Postfix, from userid 1000) id 893A25C896C6; Tue, 20 May 2003 23:39:00 +0300 (EEST) Subject: Re: Foreknowledge versus pipelines From: Timo Sirainen To: ietf-imapext@imc.org In-Reply-To: <015401c31f05$28c061e0$d1d07b43@cocacola> References: <014901c31d95$3a415a80$d1d07b43@cocacola> <1053450844.1218.249.camel@hurina> <015401c31f05$28c061e0$d1d07b43@cocacola> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1053463140.1214.322.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 20 May 2003 23:39:00 +0300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 2003-05-20 at 22:22, Michael Fair wrote: > Could we achieve the same result by having the server dump the > queue and then /dev/null the rest of the incoming queue data > and then once that's finished return a "NO" to the client > citing the error? Currently my server just disconnects the client if it tries to use too large literal+ size. I don't think it's a good idea to allow clients to say "hey, I'll send you 2 gigabytes of data, start reading" especially before logging in. How about specifying a limit for which you can use literal+? So that if you send less data than eg. 8192 bytes, you can safely send it, but for anything more you'd have to use regular literals which server can reject. So: 1 cgroup {40+} 2 capability 3 starttls 4 authenticate plain .. 10 cgroup {1000000} 10 NO Too much data > If we fix the octet counts so that server announces a max octet > buffer which cannot be exceeded, and the client announces how > much data it is submitting, the last two octets of which must > be \r\n (the end of a command), would that satisfy the concerns > that you have over this causing problems for generic usage? No, I'm thinking there could be some more subtle problems when some of the commands in the group changes state in some way. My server currently trashes all buffered input after logging in since the client's socket is transferred to another process, but maybe I should fix that since it's not fully IMAP compliant.. > > > As with the GROUP proposal, as bonus points, there would > > > be an optional "TRANSACTION" parameter which would have > > > a server revert to the same state prior to executing > > > the CQUEUE chain. > > > > No, even if server used a database capable of transactions for storing > > messages this would get complex. > > I should have been clearer: TRANSACTION is an optional server > implementation choice. It is an addon to CQUEUE not part of it. > It was never intended that any servers had to implement it. > The only other option would be to omit the possibility entirely > which I felt would be somewhat of an oversight. If you specify it, you'll have to specify exactly what it does. "revert to original state" isn't very exact. For example: - Does any other session see the changes before transaction is complete? (No, or it breaks really badly) - Client must be able to revert it's own understanding of the server state as well. - What happens if there's external updates while processing the transaction? Should server just not announce those (could be difficult), or how would client know what the original state looked like? For example you do EXPUNGE and the next command fails, server reverts the EXPUNGE but not the few pending EXPUNGEs that weren't yet announced to client. Does client now have any idea what sequence number is what? - etc. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4KJM5AF053712 for ; Tue, 20 May 2003 12:22:05 -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 h4KJM5PU053711 for ietf-imapext-bks; Tue, 20 May 2003 12:22:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4KJM3AF053706 for ; Tue, 20 May 2003 12:22:03 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id 1192C8113E5; Tue, 20 May 2003 12:22:04 -0700 (PDT) Received: from cocacola (adsl-67-123-208-209.dsl.lsan03.pacbell.net [67.123.208.209]) by DrPepper (Postfix) with ESMTP id 8DAC480D166; Tue, 20 May 2003 12:22:02 -0700 (PDT) Message-ID: <015401c31f05$28c061e0$d1d07b43@cocacola> From: "Michael Fair" To: "Timo Sirainen" , References: <014901c31d95$3a415a80$d1d07b43@cocacola> <1053450844.1218.249.camel@hurina> Subject: Re: Foreknowledge versus pipelines Date: Tue, 20 May 2003 12:22:30 -0700 Organization: DaClubhouse MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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 X-Spam-Status: No, hits=-10.4 required=5.0 tests=QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,REFERENCES version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > On Mon, 2003-05-19 at 02:28, Michael Fair wrote: > > S: * Hello Welcome to the IMAP server > > S: * CAPABILITY CQUEUE STARTTLS VHOST ....... > > C: tag1 CQUEUE (4) > > C: tag2 VHOST (fqdn.example.com) > > C: tag3 LANGUAGE (new_lang) > > C: tag4 STARTTLS > > C: tag5 AUTHENTICATE PLAIN > > This isn't too easy to implement. At the very least server should be > able to abort the whole queue if it doesn't like it for some reason, for > example because it thinks it has too much data in it. I think that would be a fine idea. Part of the reason I put (4) in the CQUEUE command was to give the server the opportunity to allocate an array of strings. I then figured it would fill the array and then execute the commands. Perhaps this wasn't the right approach. What if the server CAPABILITY response provided a CQUEUE maxoctets parameter which will gave the maximum number of octets including the tags and \r\n that the server can store. So the CAPABILITY response might read: CQUEUE (8192) If that's the case, then perhaps the initial parameter to CQUEUE the client submits should be the number of octets the client will be submitting (including \r\n and tags). So instead of CQUEUE (4) which was 4 commands it would be "tag1 CQUEUE (97)" Which would be everything from "tag2" to the "\r\n" of AUTHENTICATE (assuming I counted that right). If any characters are multibyte characters then those characters count as multiple octets. If the server should find that there is too much data, the server should dump the queue, /dev/null the rest of the incoming queue data (which is now countable by the number of octets) and then respond with "NO" giving an appropriate reason. > Still .. it would require that server reads the data into buffer before > processing any of it. And could there be literals in queue? That would > mean that server has to actually parse all the commands before executing > them. That could get tricky. > > Maybe a bit easier version would be to send the commands inside a > literal so server can just read it into buffer, and it can immediately > tell the client if there's just too much data in it (literal+ shouldn't > be allowed with it). I'm afraid I'm not too familiar with many IMAP commands. The intent was that only single line commands could be queued. And the newlines would be used as command separators. The tags were needed to identify the individual commands in the queue and would be treated as if they were executed without the CQUEUE command so should be globally unique within the session. Commands that required more than one line would be processed in turn and would fetch any extra lines at the time of execution. The server would delay parsing the command until it was time to execute it. If literal+ is an extra long one-liner, then I think if we used the octet count strategy from above there'd be no reason to keep it excluded from the list of valid commands. I don't know that the server "immediately" telling the client there's too much data is necessary. It's also very probable given how I was thinking this command would be used, that the client isn't paying attention to server responses at the time they are filling the queue. Could we achieve the same result by having the server dump the queue and then /dev/null the rest of the incoming queue data and then once that's finished return a "NO" to the client citing the error? I'm picturing that the client is going to be in two modes when it uses this command. Mode 1, is to stuff a bunch of commands in the queue, and then mode 2 is to get the results of each command and interact with any conversations it has to have to process them. If we use the byte counters I suggested above then CQUEUE could treat that many following bytes as literal data stuffing it in a single buffer and then reading from it. > Still, I'm not sure if this is a good idea. As limited in above example > it would work, but as a more generic feature it would just cause > problems. The primary motivation for this was to reduce round trips with the server during the log in process when the overall consensus is that many smaller commands is better than a generic big one. The discussion saw parallels to the MULTIAPPEND discussion (which I wasn't around for) and it seemed that an alternative that might have worked there could also work here. I had already worked on several commands that were very similar in nature to this proposal and figured that there was probably no escaping it. So the only question was is this new command only valid in the non-AUTHENTICATED state, or is it something that could be genericly useful? I'd tend towards the more generic mostly because I'm just bent that way, but if this only ended up to server the log in process it will have met the original design goals I had in mind. If we fix the octet counts so that server announces a max octet buffer which cannot be exceeded, and the client announces how much data it is submitting, the last two octets of which must be \r\n (the end of a command), would that satisfy the concerns that you have over this causing problems for generic usage? > > As with the GROUP proposal, as bonus points, there would > > be an optional "TRANSACTION" parameter which would have > > a server revert to the same state prior to executing > > the CQUEUE chain. > > No, even if server used a database capable of transactions for storing > messages this would get complex. I should have been clearer: TRANSACTION is an optional server implementation choice. It is an addon to CQUEUE not part of it. It was never intended that any servers had to implement it. The only other option would be to omit the possibility entirely which I felt would be somewhat of an oversight. I also wasn't clear enough on this when I originally submitted it, not only would the server need to support "TRANSACTION" but the client would also need to request that it wanted transaction semantics. I only saw this becoming popular in the event there developed an important use for it and the server challenges of implementing it were overcome (which they would be if there was an important enough use for it). Thanks for responding! -- Michael -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4KHEDAF048528 for ; Tue, 20 May 2003 10:14: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 h4KHEDR9048526 for ietf-imapext-bks; Tue, 20 May 2003 10:14:13 -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.9/8.12.8) with ESMTP id h4KHEAAF048498 for ; Tue, 20 May 2003 10:14:11 -0700 (PDT) (envelope-from tss@iki.fi) Received: by oma.irssi.org (Postfix, from userid 1000) id 7F9BD5C896C6; Tue, 20 May 2003 20:14:04 +0300 (EEST) Subject: Re: Foreknowledge versus pipelines From: Timo Sirainen To: ietf-imapext@imc.org In-Reply-To: <014901c31d95$3a415a80$d1d07b43@cocacola> References: <014901c31d95$3a415a80$d1d07b43@cocacola> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1053450844.1218.249.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 20 May 2003 20:14:04 +0300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 2003-05-19 at 02:28, Michael Fair wrote: > S: * Hello Welcome to the IMAP server > S: * CAPABILITY CQUEUE STARTTLS VHOST ....... > C: tag1 CQUEUE (4) > C: tag2 VHOST (fqdn.example.com) > C: tag3 LANGUAGE (new_lang) > C: tag4 STARTTLS > C: tag5 AUTHENTICATE PLAIN This isn't too easy to implement. At the very least server should be able to abort the whole queue if it doesn't like it for some reason, for example because it thinks it has too much data in it. Still .. it would require that server reads the data into buffer before processing any of it. And could there be literals in queue? That would mean that server has to actually parse all the commands before executing them. That could get tricky. Maybe a bit easier version would be to send the commands inside a literal so server can just read it into buffer, and it can immediately tell the client if there's just too much data in it (literal+ shouldn't be allowed with it). Still, I'm not sure if this is a good idea. As limited in above example it would work, but as a more generic feature it would just cause problems. > As with the GROUP proposal, as bonus points, there would > be an optional "TRANSACTION" parameter which would have > a server revert to the same state prior to executing > the CQUEUE chain. No, even if server used a database capable of transactions for storing messages this would get complex. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4INSNAF077963 for ; Sun, 18 May 2003 16:28:24 -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 h4INSNUL077962 for ietf-imapext-bks; Sun, 18 May 2003 16:28:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4INSMAF077957 for ; Sun, 18 May 2003 16:28:22 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id 55C188113E5; Sun, 18 May 2003 16:28:24 -0700 (PDT) Received: from cocacola (adsl-67-123-208-209.dsl.lsan03.pacbell.net [67.123.208.209]) by DrPepper (Postfix) with ESMTP id 9014780D166 for ; Sun, 18 May 2003 16:28:22 -0700 (PDT) Message-ID: <014901c31d95$3a415a80$d1d07b43@cocacola> From: "Michael Fair" To: Subject: Foreknowledge versus pipelines Date: Sun, 18 May 2003 16:28:45 -0700 Organization: DaClubhouse 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 X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Greetings all, So the latest developments on trying to harmonize on a design for reducing client side round trips while allowing for new pre-AUTH commands like LANGUAGE and VHOST has come down to making a decision between client foreknowledge that a particular command is actually going to be valid when it is executed and allowing a client to chain a series of commands together that the server will execute in sequence. After looking at it my self and talking it over with a couple others it has become more and more clear that the preferred approach is pipelining or command chaining. The LANGUAGE is already in implementation that expects it to be its own command, and the VHOST draft is also written with the expectation that it be its own command. The obvious downside to this is that a client has to issue these each as separate commands and for commands that can change the CAPABILITY response is forced to wait until that command is complete before moving on. This proliferation of commands demands an efficient way for clients to execute the series of them and to ensure they get executed in the proper order. Chris Newman shared with me that while discussing the MULTIAPPEND command he suggested a GROUP command that would allow a client to specify a series of commands in order. In keeping with that theme I propose a command called "CQUEUE" which would allow the client to create a "Command Queue" which would execute the commands in the queue in sequence and terminate at the first failure (defined as a "NO" or "BAD" response). Commands would be held up for execution until each prior command had finished executing. As a result the command issued need not be valid in the current CAPBILITY context. The dialog would look something like this: S: * Hello Welcome to the IMAP server S: * CAPABILITY CQUEUE STARTTLS VHOST ....... C: tag1 CQUEUE (4) C: tag2 VHOST (fqdn.example.com) C: tag3 LANGUAGE (new_lang) C: tag4 STARTTLS C: tag5 AUTHENTICATE PLAIN C: S: tag2 OK VHOST (fqdn.example.com) S: * CAPABILITY ... new capability after VHOST ... S: tag3 OK LANGUAGE (new_lang) S: tag4 OK BEGIN TLS S: tag4 OK STARTTLS successful S: * CAPABILITY ... new capability after STARTTLS ... S: + S: tag5 OK AUTHENTICATE successful S: * CAPABILITY ... new capability after AUTHENTICATE ... S: tag1 OK CQUEUE successful I've proposed changing the name to CQUEUE from GROUP because I felt a "Command Queue" was a bit more descriptive than a "Group of commands". The primary security risk preTLS is that any command issued goes in the clear. As a result it is forbidden for a client to execute a LOGIN in this manner if the client is going to attempt to establish a TLS session. As for the AUTHENTICATE command, that is different that the only revealed information is what method the client was going to request be attempted first. Knowing which authentication method a client was going to request post TLS does not reveal any information that compromises the security of the TLS session or the client's data. The client can and SHOULD monitor the execution of the command queue as the server announces its progress. If the command queue fails then the tag assigned to the failed command MUST be in the "NO" response to CQUEUE command in addition to the "NO" or "BAD" response. As with the GROUP proposal, as bonus points, there would be an optional "TRANSACTION" parameter which would have a server revert to the same state prior to executing the CQUEUE chain. -- Michael -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4HHHAAF089217 for ; Sat, 17 May 2003 10:17:10 -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 h4HHHAi5089216 for ietf-imapext-bks; Sat, 17 May 2003 10:17:10 -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 h4HHH8AF089209 for ; Sat, 17 May 2003 10:17:09 -0700 (PDT) (envelope-from mel@messagingdirect.com) Received: from messagingdirect.com (1Cust53.tnt110.lnd4.gbr.da.uu.net [62.188.174.53]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h4HHKKV32538; Sat, 17 May 2003 11:20:21 -0600 Message-ID: <3EC666F1.9BD543AC@messagingdirect.com> Date: Sat, 17 May 2003 17:44:34 +0100 From: Alexey Melnikov X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Pete Resnick CC: ietf-imapext@imc.org Subject: Re: Vienna References: 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 Resnick wrote: > I've been reminded to start early on figuring out what's going on for > the next IETF meeting, so let's do that. > > Document editors: Please provide to the list the status of your > documents. Are there open issues that will need to be discussed in > Vienna? > > Others: Are there items that you think need to be discussed in > Vienna? Do remember that LEMONADE-related items should be discussed > over there. > > I will be in Vienna either way. Let's figure out now whether we need a meeting. I will be in Vienna anyway. I should send an update revision of CONDSTORE in a week or so. Than I have some SASL documents I have to work, but I am planning to send ACL2 update before Vienna. Cheers, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html I speak for myself only, not for my employer. __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4HHErAF088927 for ; Sat, 17 May 2003 10:14: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 h4HHErO1088926 for ietf-imapext-bks; Sat, 17 May 2003 10:14:53 -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 h4HHEnAF088913 for ; Sat, 17 May 2003 10:14:52 -0700 (PDT) (envelope-from mel@messagingdirect.com) Received: from messagingdirect.com (1Cust53.tnt110.lnd4.gbr.da.uu.net [62.188.174.53]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h4HHHgV32513; Sat, 17 May 2003 11:17:48 -0600 Message-ID: <3EC61977.24CD85D1@messagingdirect.com> Date: Sat, 17 May 2003 12:13:59 +0100 From: Alexey Melnikov X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Crispin CC: Chris Newman , IMAP Extensions WG Subject: Re: SORT, THREAD and VIEW/WINDOW References: <2147483647.1052838555@nifty-jr.west.sun.com> 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: Mark Crispin wrote: > ... > My understanding of our status is: > > I) CHARTER EXTENSIONS > > SORT/THREAD is done, but will need to be blocked on I18N since it makes a > normative reference to it. > > I believe that the remaining documents that we need to complete to fufill > the charter are: > > ACL, ANNOTATE, ANNOTATEMORE, CONDSTORE, I18N > > II) NON-CHARTER EXTENSIONS. > > We also are considering: > > LISTEXT > > and may want to consider SEARCH-MULTIPLE, VHOST, and the following expired > drafts: > > QUOTA, UNSELECT > > I decided not to oppose UNSELECT any more; indeed, I recently implemented > it in my server. Cyrus server has it too. So let's do a quick last call > and get it published. I will try to publish the UNSELECT document shortly. > I vote to proceed on LISTEXT and punt on the other non-charter proposals. I agree. QUOTA will most likely be taken by LEMONADE people anyway. Cheers, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html I speak for myself only, not for my employer. __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4GBdFAF085745 for ; Fri, 16 May 2003 04:39:16 -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 h4GBdFwx085744 for ietf-imapext-bks; Fri, 16 May 2003 04:39:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from Ikkoku-Kan.Panda.COM (alex@panda.com [206.124.149.114]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4GBdEAF085738 for ; Fri, 16 May 2003 04:39:14 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from localhost (mrc@localhost) by Ikkoku-Kan.Panda.COM id EAA01598; Fri, 16 May 2003 04:39:12 -0700 (PDT) Date: Fri, 16 May 2003 04:39:12 -0700 (PDT) From: Mark Crispin To: IMAP Extensions WG Subject: LAST CALL: SORT AND THREAD EXTENSION Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As we agreed in Atlanta, now that the IMAP i18n document is an I-D this is a last call for draft-ietf-imapext-sort-13.txt prior to it being submitted to the IESG. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4GBPUAF085398 for ; Fri, 16 May 2003 04:25:30 -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 h4GBPUcK085397 for ietf-imapext-bks; Fri, 16 May 2003 04:25:30 -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 h4GBPSAF085391 for ; Fri, 16 May 2003 04:25:29 -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 HAA19464; Fri, 16 May 2003 07:22:23 -0400 (EDT) Message-Id: <200305161122.HAA19464@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-sort-13.txt Date: Fri, 16 May 2003 07:22:23 -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 : INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSION Author(s) : M. Crispin, K. Murchison Filename : draft-ietf-imapext-sort-13.txt Pages : 19 Date : 2003-5-15 This document describes the base-level server-based sorting and threading extensions to the [IMAP] protocol. These extensions provide substantial performance improvements for IMAP clients which offer sorted and threaded views. A server which supports the base-level SORT extension indicates this with a capability name which starts with 'SORT'. Future, upwards-compatible extensions to the SORT extension will all start with 'SORT', indicating support for this base level. A server which supports the THREAD extension indicates this with one or more capability names consisting of 'THREAD=' followed by a supported threading algorithm name as described in this document. This provides for future upwards-compatible extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-13.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-sort-13.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-sort-13.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-5-15150157.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-sort-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-sort-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-15150157.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 h4EMkDAF038112 for ; Wed, 14 May 2003 15:46: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 h4EMkDIF038111 for ietf-imapext-bks; Wed, 14 May 2003 15:46:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4EMkCAF038106 for ; Wed, 14 May 2003 15:46:12 -0700 (PDT) (envelope-from Chris.Newman@Sun.COM) Received: from esunmail ([129.147.58.198]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4EMkEY9016169 for ; Wed, 14 May 2003 16:46:14 -0600 (MDT) Received: from xpa-fe1 ([129.147.58.198]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HEW00IYAF594M@edgemail1.Central.Sun.COM> for ietf-imapext@imc.org; Wed, 14 May 2003 16:43:58 -0600 (MDT) Received: from nifty-jr.west.sun.com ([129.153.12.95]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HEW0004RF58FU@mail.sun.net> for ietf-imapext@imc.org; Wed, 14 May 2003 16:43:57 -0600 (MDT) Date: Wed, 14 May 2003 15:41:29 -0700 From: Chris Newman Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-00.txt In-reply-to: <1052925231.6863.106.camel@hurina> To: Timo Sirainen , ietf-imapext@imc.org Message-id: <2147483647.1052926889@nifty-jr.west.sun.com> MIME-version: 1.0 X-Mailer: Mulberry/3.0.3 (Mac OS X) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-message-flag: Outlook: the best virus distribution system around References: <200305131200.IAA05283@ietf.org> <020d01c3197f$dd7cf200$d1d07b43@cocacola> <2147483647.1052834224@nifty-jr.west.sun.com> <1052925231.6863.106.camel@hurina> Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: begin quotation by Timo Sirainen on 2003/5/14 18:13 +0300: > Well, this is somewhat aesthetic, but I think untagged LANGUAGE reply is > a bit badly designed. "If there's one language, that's what got > selected. if there's multiple ones, nothing was selected but you should > select one of them". Kind of messy. I agree that the design of the LANGUAGE reply is messy. But it is also unambiguous as defined in the spec, so I don't see a reason to change it. > Why not have work like COMPARATOR reply? Because they were designed by different people. > Or maybe give the selected language as resp-text-code in tagged > OK reply? That would be inconsistent with other IMAP commands that adjust server state. So I don't see it as better from an aesthetic point of view. > I think he means something like: > > 1 SETANNOTATION "/mailbox/{ietf-imapext}/alias" ("value.priv" "IMAP > Extensions") 1 OK > 2 LIST (ANNOTATION ("alias")) "" % > * LIST (("ANNOTATION" ("alias" ("value.shared" "Incoming Messages")))) "/" > "INBOX" * LIST (("ANNOTATION" ("alias" ("value.priv" "IMAP Extensions")))) > "/" "ietf-imapext" 2 OK > > INBOX and maybe some other site global mailbox names could be predefined > for multiple languages which would be used after client has selected > language. So maybe the ANNOTATEMORE extension should define a namespace for localized mailbox names? Sounds reasonable to me. > Looks like LISTEXT and ANNOTATEMORE don't play together currently. > Should they? I'd like the possibility to do above. I concur. > Other issues in the draft: > > "Clients MUST re-issue the LANGUAGE command once a security layer is > active" is mentioned only in "security considerations. I think it should > be mentioned in section 3.2 also. > > You mention only THREAD=ORDEREDSUBJECT, but THREAD=REFERENCES also does > sorting by subject. OK. Will fix these two in the next version. - Chris Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4EK0lAF033106 for ; Wed, 14 May 2003 13:00:47 -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 h4EK0kKD033105 for ietf-imapext-bks; Wed, 14 May 2003 13:00:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4EK0jAF033076 for ; Wed, 14 May 2003 13:00:45 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id 28391812C58; Wed, 14 May 2003 13:00:47 -0700 (PDT) Received: from cocacola (adsl-67-123-208-209.dsl.lsan03.pacbell.net [67.123.208.209]) by DrPepper (Postfix) with ESMTP id 9D0F48113E5; Wed, 14 May 2003 13:00:45 -0700 (PDT) Message-ID: <043a01c31a52$2cdfa2c0$d1d07b43@cocacola> From: "Michael Fair" To: "Mark Crispin" Cc: "Chris Newman" , References: <200305131200.IAA05283@ietf.org> <020d01c3197f$dd7cf200$d1d07b43@cocacola> <2147483647.1052834224@nifty-jr.west.sun.com> <040101c31a45$f8d54d60$d1d07b43@cocacola> Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-00.txt Date: Wed, 14 May 2003 12:51:13 -0700 Organization: DaClubhouse 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 X-Spam-Status: No, hits=-9.8 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > On Wed, 14 May 2003, Michael Fair wrote: > > LANGUAGE, VHOST (fqdn.example.com), STARTTLS, AUTHENTICATE (AUTH=plain) > > This is a contrived example. > > It's impossible to pipeline anything after STARTTLS. In fact, it's > impossible to even think about transmitting anything after STARTTLS, since > you need to do the key exchange negotiation before you have the physical > capability of transmitting the AUTHENTICATE. Sorry I was confusing the existing mechansims with the work I was doing on ECAPABILITY which was attempting to reduce round trips by asking the client for information as it needed it (thus STARTTLS would negotiate and once completed the server would immediately begin the AUTH conversation (lest the method requested wasn't supported and would therefore stop, requiring the client to issue a CAPABILTIY to find out what methods were supported). Even barring that ability, just drop the AUTH command off the end and the example still holds. The point is that pipelining and foreknowledge are mutually exclusive for most commands prior to AUTH because most of the important pre-auth commands change the CAPABILITY response. As a result, a client must issue a command, wait for the response, get the new capability list, issue the next command, wait, issue the next command, wait. A more detailed state progress of the above example as currently implemented by the proposed solutions: 1) Client shows up at server gets hello and requests CAPABILITY server sends LANGUAGE VHOST (but not STARTTLS, AUTH, or LOGIN) 2) Client issues the LANGUAGE command 3) Client issues the VHOST command ***** Client waits ***** 4) Client gets new CAPABILTIY and the server now issues LANGUAGE VHOST STARTTLS LOGIN and AUTH (but not AUTH plain) 5) Client issues STARTTLS and does the negotation ***** Client waits ***** 6) Client gets the new CAPABILTIY and the server now issues LANGUAGE VHOST STARTTLS LOGIN and AUTH including AUTH plain 7) Client issues AUTH using the plain mechanism ***** Client waits ***** 8) Client gets the new CAPABILTIY and is now ready to begin the real IMAP session work Same example with the method I was envisioning: 1) Client shows up at server gets hello 2) Client issues a new version of PIPELINE (with ordering and negotiation support) with the following chain: LANGUAGE, VHOST (fqdn.example.com), STARTTLS, AUTHENTICATE (AUTH=plain) ***** Client watches responses as the server executes each ***** ***** Client waits for BAD, NO, or STARTTLS ***** 3) Client does STARTTLS negotiation ***** Client waits for BAD, NO, or AUTH negotiation ***** If the client receives BAD or NO it knows what state it is in because the server issued and OK for every command that succeeded. Once an error occurs in the command chain processing of the chain stops. -- Michael -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4EJSgAF030629 for ; Wed, 14 May 2003 12:28:42 -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 h4EJSgcc030628 for ietf-imapext-bks; Wed, 14 May 2003 12:28:42 -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.9/8.12.8) with ESMTP id h4EJSfAF030620 for ; Wed, 14 May 2003 12:28:41 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout2.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h4EJSZg9031781; Wed, 14 May 2003 12:28:40 -0700 Received: from Shimo-Tomobiki.Panda.COM (D-128-95-18-95.dhcp4.washington.edu [128.95.18.95]) (authenticated bits=0) by smtp.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h4EJSYcx028909 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 14 May 2003 12:28:35 -0700 Date: Wed, 14 May 2003 12:28:39 -0700 (Pacific Daylight Time) From: Mark Crispin To: Michael Fair cc: Chris Newman , ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-00.txt In-Reply-To: <040101c31a45$f8d54d60$d1d07b43@cocacola> Message-ID: References: <200305131200.IAA05283@ietf.org> <020d01c3197f$dd7cf200$d1d07b43@cocacola> <2147483647.1052834224@nifty-jr.west.sun.com> <040101c31a45$f8d54d60$d1d07b43@cocacola> 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 Wed, 14 May 2003, Michael Fair wrote: > LANGUAGE, VHOST (fqdn.example.com), STARTTLS, AUTHENTICATE (AUTH=plain) This is a contrived example. It's impossible to pipeline anything after STARTTLS. In fact, it's impossible to even think about transmitting anything after STARTTLS, since you need to do the key exchange negotiation before you have the physical capability of transmitting the AUTHENTICATE. I'm finding it very difficult to read your messages. Could you please get to the point in a more consise fashion? -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4EJSHAF030552 for ; Wed, 14 May 2003 12:28:17 -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 h4EJSHii030550 for ietf-imapext-bks; Wed, 14 May 2003 12:28: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.9/8.12.8) with ESMTP id h4EJSGAF030543 for ; Wed, 14 May 2003 12:28:16 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout3.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h4EJSFSL004194; Wed, 14 May 2003 12:28:15 -0700 Received: from Shimo-Tomobiki.Panda.COM (D-128-95-18-95.dhcp4.washington.edu [128.95.18.95]) (authenticated bits=0) by smtp.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h4EJSEcx028884 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 14 May 2003 12:28:15 -0700 Date: Wed, 14 May 2003 12:28:19 -0700 (Pacific Daylight Time) From: Mark Crispin To: Michael Fair cc: IMAP Extensions WG Subject: Re: Vienna In-Reply-To: <039d01c319d7$0e6b9360$d1d07b43@cocacola> Message-ID: References: <039d01c319d7$0e6b9360$d1d07b43@cocacola> 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: I can't wade through your long message to answer it point-by-point, but here is a pedagogical explanation: LEMONADE has identified a need to send messages containing content from a mailbox in an IMAP server. It is costly, especially for embedded devices, to fetch the content from an IMAP server just to send it back out to an SMTP server. On the other hand, if the message submission server is not co-located with the IMAP server, then the submission server must have full IMAP access to the user's account on the IMAP server. This is perceived as a security risk. Consequently, it was proposed to use an IMAP server as a mesasge submission agent, by submitting the message with "include such-and-such text from such-and-such mailbox" pointers, which the IMAP server will acquire locally. As a counter proposal, I suggest a means by which an IMAP client can create a limited access token, which can access only the necessary data but not any other data. This limited access token can be used by the message submission server to obtain the data from the IMAP server without giving the message submission server access to any other user data. This also permits the message submission server to access data from multiple IMAP servers. Furthermore, it does not create a situation in which IMAP duplicates the functionality of other protocols. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4EIXJAF027717 for ; Wed, 14 May 2003 11:33: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 h4EIXJD4027716 for ietf-imapext-bks; Wed, 14 May 2003 11:33:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4EIXDAF027710 for ; Wed, 14 May 2003 11:33:18 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id 772C5812C58; Wed, 14 May 2003 11:33:14 -0700 (PDT) Received: from cocacola (adsl-67-123-208-209.dsl.lsan03.pacbell.net [67.123.208.209]) by DrPepper (Postfix) with ESMTP id 8C2B28113E5; Wed, 14 May 2003 11:33:11 -0700 (PDT) Message-ID: <040101c31a45$f8d54d60$d1d07b43@cocacola> From: "Michael Fair" To: "Chris Newman" , References: <200305131200.IAA05283@ietf.org> <020d01c3197f$dd7cf200$d1d07b43@cocacola> <2147483647.1052834224@nifty-jr.west.sun.com> Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-00.txt Date: Wed, 14 May 2003 11:23:51 -0700 Organization: DaClubhouse 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 X-Spam-Status: No, hits=-10.4 required=5.0 tests=QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,REFERENCES version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > begin quotation by Michael Fair on 2003/5/13 11:45 -0700: > > Is there anything else anyone else saw that seems to make > > this whole client side CAPABILITY approach to items like > > VHOST and LANGUAGE (and perhaps a CHARSET could be added > > to the list for UTF-8 support?) a bad idea? > > We discussed the issue of client capabilities at the informal > IMAPEXT BOF at > the last IETF and there was a rough consensus in the room (of about 20 > IMAP developers many of whom write code) which opposed the idea of a > combined client capability mechanism. The rough consensus of the > room appeared to favor separate commands which could be pipelined > rather than a combined command. Now the mailing list can override > that consensus, but I'd need to see stronger support than I've seen > to date. No one prior to you had ever mentioned that. Wish I would have known would have saved me some trouble. :) Creating a command pipeline works for me. I actually like that even more, but it seems to break with what a few ppl have said to me earlier in that they really don't like the idea of a client trying a command to find out if it will work or not. The general premise is that a client should always have foreknowledge that the command they want to use is valid. But there's a problem with this, since pretty much every commonly used command prior to authenticating has the potential to change the "environment" (read CAPABILITY response) then pipelining and foreknowledge are somewhat mutually exclusive in that using one denies the other. As an example, a client wants to execute: LANGUAGE, VHOST (fqdn.example.com), STARTTLS, AUTHENTICATE (AUTH=plain) Even though this might be a very valid sequence there's no way for a client to know whether or not this will work without stopping at each point and waiting for the response. STARTTLS might not be available till after VHOST and AUTH plain might further not be available until after STARTTLS. I also understood that servers can reorder commands so depending on the order executed the above means different things and it's success rate differs depending on the order executed. I personally prefer pipelining much more than foreknowledge on principal because the errors generated by usage of this nature uses a very minor number of resources in comparison to the possible efficiency gains and 9 times out of 10 the client is just checking to make sure the server does something that already has a more than reasonable chance at succeeding. The only con is that it demands proper failure behavior which should be, but is not always what's out there. However, protecting clients that don't check return codes and servers that don't generate them by not implementing a feature that could give trmendous efficiency gains for those that do the proper thing seems like it's asking for trouble. Since the commands will succeed the majority of the time, it seems wasteful to cause the login process to be longer just for a psuedo-gaurantee that it will succeed. This is further compounded by things admins can do to tain their environmnent. Clients might be able to be configured for, or discover and remember, success "paths" for the servers they access and not be forced to stop and wait at each step every login. If clients/servers all do some basic error checking then pipelining would simply trip over the error codes and the clients can issue the proper commands to get the info to determine how to proceed. Of course I believe that the client would need a way to specify the order in which the commands get executed (lest the command fail otherwise). I can see the merits of both approaches, but it seems that the consensus is that reducing round trips is important. The only way I see that happening is by giving up the notion that a client should always have foreknowledge that the commands they are issuing are valid when it comes to being able to pipeline commands. Instead, it shoud be that a client can try an optimistic pipeline expecting a chain to succeed and the pipeline should stop executing at the first failure. Assuming that people can live with that, I think the multiple commands with a pipeline provision is the best route as well. > In addition, there is deployed running code for the LANGUAGE extension > (implemented to the previous draft). As a result I am opposed to aesthetic > changes to the LANGUAGE extension as documented. Proposed changes need to have > a substantive technical justification. The only technical justification was discussed above. > > 2) In specific response to the LANGUAGE feature set as > > described, I noticed it is missing in-band administration > > for assigning the various LANGUAGE translations of folders. > > > > 3) Could this be extended to allow all folders to be > > represented in multiple languages by way of some kind > > of "ALIAS" command that could install a language alias > > for folders? This would probably require the equivalent > > of a RENAME ACL. This would anticipate a resolution > > to the lack of character set choice currently present. > > (For instance via a client capability mentioned above.) > > Please make a concrete proposal if you want to discuss these > issues. I'm not sure exactly what you're asking so it would > be easier to discuss if I could see something concrete. > > > 4) Since languages are somewhat tied to character sets, > > The selected character set is always UTF-8, so there is no issue. I was basing the character set issues off of section 5.2. Ok so 2,3 and 4 were all related, and I might be generalizing a feature that's not actually in the draft. Timo's SETANNOTATION example of creating aliases for INBOX and ietf-imapext folders were an example of how this might be used but I wasn't expecting it to be used to create aliases in the same language (though I think that would be useful). Further, the only folders that can currently be "localized" are the folders in NAMESPACE. There might be a technical reason for that. What I was envisioning was a way to name any mailbox in many languages by assigning several language specific aliases. This was primarily to facilitate "Shared Folders" in organizations where people who use multiple languages share the same folder. For instance, the folder "Technical Support" would be a general box for incoming issues in multiple languages. The support staff reading this mailbox speak different languages, and as a result would like the "Technical Support" folder to display its name in their native language. If they could attach a language specific alias for the foldername, they could do this. This would also satisfy the method by which namespace translations would be set. They would be treated just like any other folder for the purpose of setting the translation to begin with. Secondarily, if assigning aliases to arbitrary folders is not technically feasible for some reason, then there should still be a defined method to set the aliases for the folders returned by NAMESPACE. While the current draft describes how the server should format and respond to a client to provide the NAMESPACE response with translations, it doesn't specify any method to set those translations in the first place. This may just be a "server must be preconfigured" thing, but it seems to me that there should be an IMAP command for this. I do not feel the slightest bit qualified to recommend a method to set the translations. Timo's SETANNOTATION seemed like a decent enough approach however it would require the addition of a language parameter. Which brings up another question, are the language names going to support the localized variants like en_US and fr_CA? If so, does it need any special mentioning? For instance a phrase like "localized variants of a language if not explicity supported may match on either a non-localized version of the same language or if that's not available, then another variant of the same language. If there are no variants of the language supported by the server (localized or not) then the match SHOULD fail." I don't know if it really matters, but I expect it'll come up sooner or later. -- Michael -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4EFHdAF015844 for ; Wed, 14 May 2003 08:17: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 h4EFHdWP015843 for ietf-imapext-bks; Wed, 14 May 2003 08:17:39 -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.9/8.12.8) with ESMTP id h4EFHcAF015837 for ; Wed, 14 May 2003 08:17:38 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id LAA29125; Wed, 14 May 2003 11:12:32 -0400 (EDT) Date: Wed, 14 May 2003 11:16:38 -0400 From: Cyrus Daboo To: Chris Newman , IMAP Extensions WG Subject: Re: SORT, THREAD and VIEW/WINDOW Message-ID: <2147483647.1052910998@[63.163.82.24]> In-Reply-To: <2147483647.1052838555@nifty-jr.west.sun.com> References: <2147483647.1052838555@nifty-jr.west.sun.com> X-Mailer: Mulberry/3.1.0b1 (Mac OS/PPC) 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 Chris, --On Tuesday, May 13, 2003 3:09 PM -0700 Chris Newman wrote: | So I am now willing to see SORT and THREAD move forward without VIEW | despite my scalability concerns. Given how busy and resource limited the | IMAP community appears to be at the moment, I further propose we drop the | VIEW command from the list of WG deliverables we must complete prior to | WG closure (but let's not bother changing the charter until we've | finished the other deliverables). I fully agree with this position. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4EFDsAF015755 for ; Wed, 14 May 2003 08:13: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 h4EFDsPU015754 for ietf-imapext-bks; Wed, 14 May 2003 08:13:54 -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.9/8.12.8) with ESMTP id h4EFDpAF015749 for ; Wed, 14 May 2003 08:13:52 -0700 (PDT) (envelope-from tss@iki.fi) Received: by oma.irssi.org (Postfix, from userid 1000) id 3A7755C896C6; Wed, 14 May 2003 18:13:51 +0300 (EEST) Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-00.txt From: Timo Sirainen To: ietf-imapext@imc.org In-Reply-To: <2147483647.1052834224@nifty-jr.west.sun.com> References: <200305131200.IAA05283@ietf.org> <020d01c3197f$dd7cf200$d1d07b43@cocacola> <2147483647.1052834224@nifty-jr.west.sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1052925231.6863.106.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 14 May 2003 18:13:51 +0300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 2003-05-13 at 23:57, Chris Newman wrote: > In addition, there is deployed running code for the LANGUAGE extension > (implemented to the previous draft). As a result I am opposed to aesthetic > changes to the LANGUAGE extension as documented. Proposed changes need to have > a substantive technical justification. Well, this is somewhat aesthetic, but I think untagged LANGUAGE reply is a bit badly designed. "If there's one language, that's what got selected. if there's multiple ones, nothing was selected but you should select one of them". Kind of messy. Why not have work like COMPARATOR reply? Or maybe give the selected language as resp-text-code in tagged OK reply? > > 2) In specific response to the LANGUAGE feature set as > > described, I noticed it is missing in-band administration > > for assigning the various LANGUAGE translations of folders. > > > > 3) Could this be extended to allow all folders to be > > represented in multiple languages by way of some kind > > of "ALIAS" command that could install a language alias > > for folders? This would probably require the equivalent > > of a RENAME ACL. This would anticipate a resolution > > to the lack of character set choice currently present. > > (For instance via a client capability mentioned above.) > > Please make a concrete proposal if you want to discuss these issues. I'm not > sure exactly what you're asking so it would be easier to discuss if I could see > something concrete. I think he means something like: 1 SETANNOTATION "/mailbox/{ietf-imapext}/alias" ("value.priv" "IMAP Extensions") 1 OK 2 LIST (ANNOTATION ("alias")) "" % * LIST (("ANNOTATION" ("alias" ("value.shared" "Incoming Messages")))) "/" "INBOX" * LIST (("ANNOTATION" ("alias" ("value.priv" "IMAP Extensions")))) "/" "ietf-imapext" 2 OK INBOX and maybe some other site global mailbox names could be predefined for multiple languages which would be used after client has selected language. Looks like LISTEXT and ANNOTATEMORE don't play together currently. Should they? I'd like the possibility to do above. Other issues in the draft: "Clients MUST re-issue the LANGUAGE command once a security layer is active" is mentioned only in "security considerations. I think it should be mentioned in section 3.2 also. You mention only THREAD=ORDEREDSUBJECT, but THREAD=REFERENCES also does sorting by subject. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4E5HNAF059800 for ; Tue, 13 May 2003 22:17: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 h4E5HNVr059799 for ietf-imapext-bks; Tue, 13 May 2003 22:17:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4E5HLAF059793 for ; Tue, 13 May 2003 22:17:21 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id DABE5813F13; Tue, 13 May 2003 22:17:24 -0700 (PDT) Received: from cocacola (adsl-67-123-208-209.dsl.lsan03.pacbell.net [67.123.208.209]) by DrPepper (Postfix) with ESMTP id 1CF13813E6D; Tue, 13 May 2003 22:17:22 -0700 (PDT) Message-ID: <039d01c319d7$0e6b9360$d1d07b43@cocacola> From: "Michael Fair" To: "Mark Crispin" , "Pete Resnick" Cc: References: Subject: Re: Vienna Date: Tue, 13 May 2003 22:09:54 -0700 Organization: DaClubhouse 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 X-Spam-Status: No, hits=-9.8 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > 2) LEMONADE. > > LEMONADE clearly identified a need for message submission that does not > require downloading from IMAP server; however, doing submission in IMAP is > a mistake. I'd rather not argue the reasons why in email; it'll > just waste everybody's time. > > Instead, let's come up with an alternative so there is a choice that can > be made. Right now, there is no choice. > > I suggest a command, valid when not logged in, that will fetch a > particular message or portion of message. Thus, the argument to the > command has to carry authentication of some kind; the key is that this is > *not* the user's authentication but rather some special authentication > that is specific to that message or portion of a message. > > Desirable authentication forms: use-once, anonymous, use only by certain > entity, time-limited (e.g. "expires in 5 minutes"). > > Could be a SASL mechanism, since SASL has the framework; ultimately > returning a NO so it can be done multiple times in one IMAP connection. > > Must be expressable in an IMAP URL; the URL must carry the authentication > (possibly also with a client-supplied token). > > The idea here is that the MSA is given a message with various IMAP URLs > inserted. The MSA resolves the URL and fetches the data from the server > (or servers -- an advantage of doing it this way). > > We need a command for an IMAP client to create these things, e.g. "give me > a cookie, expiring in 10 minutes, that will fetch part [2.4.4] from UID > 12383 from my INBOX". Please correct me if I'm wrong, let me see if I can recap what you are proposing since I've gotten confused about what seems to be mixed or at least unclarified usage of the terms submission, client, and server. 1) It is inappropriate to make the IMAP server the middle man for transporting messages. The client should have a method of requesting data directly from foriegn servers (aka "message submission that does not require downloading from IMAP server")? You chose not to waste people's time with the details of an explanation. So you chose to propose a new IMAP command so we can compare and choose. 2) This new command is to provide a way for an end user client to tell an IMAP server to fetch arbirtrary message parts with authentication. And that relates to message submission because the server is to fetch the data from the remote server and store the retrieved data as part of the message in the local mail store? Or this command is intended to be issued by remote servers and/or clients who are trying to "pick up" the message parts from the current server? Or this has nothing to do with message submission and is about an end user client getting fast access to a separate IP connection (whether or its own use or some other agent's use) through which to transfer the data across with? It's not clear to me whether the ultimate intended recipient of this command is the IMAP server, the end user client, or some other remote service that was told to pick up the data. You then described the authentication requirements. 3) You then concluded with describing the general idea as the MSA gets handed a message with a bunch of URLs and goes off to do its thing. But I'm not clear on who the MSA is being an agent of. Given your example it seems that intended destination is an end user client who already as a session with the current server and that the definition of "submission" is actually a transfer from server space to end user space rather than the user space submitting to server space. (I use server space as loose term to refer to the collection of servers hosting the message data, and user space as the collection of clients being used to view it) I have not been following LEMONADE to really get what the current intended framework looks like. So it might be that I'm just missing some background info that I haven't read yet. Unfortunately, without clarity on exactly what the envisioned framework is I am having a hard time picturing the overall use and goal here. I might also be having a hard time because I have a general definition of submission as "moving away from the source", of "uploading" as moving away from the current active end user, and of "downloading" as moving to the active service. I just can't clearly tell what the various active objects in your description are and when they are being active. If the ultimate goal here to provide an end user client with a URL so that the end user client (or local agent) can open up another connection to the same server and quickly access the data, then I'd think simply providing a method for doing a "FASTAUTH" token which would at most need to renegotiate TLS to establish the same context as the initial session is all that would be required because then the new session can issue the same IMAP commands the other could. But that would leave the heavy lifting "in IMAP" which you don't think will work. (Because the connecting agent may not know any IMAP over and above submitting this command?) Further, if the purpose is really just to give other applications on the same client machine access to the data, then why not have the client act as a relay between the IMAP server and the final application. It could easily do this by opening a port bound to the 127.0.0.1 interface and then causing whatever Agent to connect to that loopback port while the IMAP client then transferred the data across via IMAP. This allows the IMAP client to cache the message part and provide the data to the external application at the same time. It further supplies a methodology for the same dat to be viewed by the end user multiple times without transferring from the server each time. This method doesn't work so well for real time protocols. Those will probably have to be handled differently unless the server and client learn to speak RTSP. If the purpose is to allow clients to request URLs that are to be issued to a server other than the one the client is talking to at the moment then I think I understand what you're trying to accomplish. The current server has a message whose parts are stored in many locations, the client wants to access these parts and therefore requests a token from the current server to fetch them. The questions I have then are, is it expected that all the remote servers are IMAP servers, or are they arbitrary protocols? Assuming IMAP its various IMAP servers involved then are they preaware of each other's existence? Can the servers share a secret between each other for generating the URLs (perhaps PKI based?)? If the purpose is actually to enable clients to upload data (aka submit new data to the server) then I'm having a hard time comprehending the client requesting a cookie to fetch the message part. Finally if I'm way off base on all of these, and you really just need a simple command to fetch data, then I suggest the command mimic the HTTP protocol (with recent extensions) as closely as possible to leverage as much existing work and mind share done in this area as possible (unless of course there is some technical reason that makes this impractical. Sorry for the long email but I just wanted to be clear about what the vaious confusions were. Thank you, -- Michael -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4E01uAF052133 for ; Tue, 13 May 2003 17:01: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 h4E01ua6052132 for ietf-imapext-bks; Tue, 13 May 2003 17:01:56 -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 h4E01tAF052127 for ; Tue, 13 May 2003 17:01:55 -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.1+UW03.04/8.12.1+UW02.12) with ESMTP id h4E01vSL031616; Tue, 13 May 2003 17:01: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.1+UW03.04/8.12.1+UW02.12) with ESMTP id h4E01uQ0009826 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 13 May 2003 17:01:57 -0700 Date: Tue, 13 May 2003 16:59:55 -0700 (Pacific Daylight Time) From: Mark Crispin To: Chris Newman cc: IMAP Extensions WG Subject: Re: SORT, THREAD and VIEW/WINDOW In-Reply-To: <2147483647.1052838555@nifty-jr.west.sun.com> Message-ID: References: <2147483647.1052838555@nifty-jr.west.sun.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, 13 May 2003, Chris Newman wrote: > So I am now willing to see SORT and THREAD move forward without VIEW > despite my scalability concerns. Given how busy and resource limited > the IMAP community appears to be at the moment, I further propose we > drop the VIEW command from the list of WG deliverables we must complete > prior to WG closure (but let's not bother changing the charter until > we've finished the other deliverables). Thank you. My understanding of our status is: I) CHARTER EXTENSIONS SORT/THREAD is done, but will need to be blocked on I18N since it makes a normative reference to it. I believe that the remaining documents that we need to complete to fufill the charter are: ACL, ANNOTATE, ANNOTATEMORE, CONDSTORE, I18N II) NON-CHARTER EXTENSIONS. We also are considering: LISTEXT and may want to consider SEARCH-MULTIPLE, VHOST, and the following expired drafts: QUOTA, UNSELECT I decided not to oppose UNSELECT any more; indeed, I recently implemented it in my server. Cyrus server has it too. So let's do a quick last call and get it published. I vote to proceed on LISTEXT and punt on the other non-charter proposals. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4DMBnHN047968 for ; Tue, 13 May 2003 15:11:49 -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 h4DMBnPU047966 for ietf-imapext-bks; Tue, 13 May 2003 15:11:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from brmea-mail-4.sun.com (kathmandu.sun.com [192.18.98.36]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4DMBmHN047957 for ; Tue, 13 May 2003 15:11:48 -0700 (PDT) (envelope-from Chris.Newman@Sun.COM) Received: from esunmail ([129.147.58.120]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h4DMBohm005479 for ; Tue, 13 May 2003 16:11:50 -0600 (MDT) Received: from xpa-fe1 ([129.147.58.198]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HEU00BAQIZQ8O@edgemail1.Central.Sun.COM> for ietf-imapext@imc.org; Tue, 13 May 2003 16:11:50 -0600 (MDT) Received: from nifty-jr.west.sun.com ([129.153.12.95]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HEU007WDIZHOV@mail.sun.net> for ietf-imapext@imc.org; Tue, 13 May 2003 16:11:50 -0600 (MDT) Date: Tue, 13 May 2003 15:09:15 -0700 From: Chris Newman Subject: SORT, THREAD and VIEW/WINDOW To: IMAP Extensions WG Message-id: <2147483647.1052838555@nifty-jr.west.sun.com> MIME-version: 1.0 X-Mailer: Mulberry/3.0.3 (Mac OS X) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-message-flag: Outlook: the best virus distribution system around Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: There is a scalability problem with the design of SORT and THREAD because their performance and bandwidth consumption depends on the number of messages in the mailbox. As a result of this problem, I held the position that we need to hold up SORT and THREAD until the VIEW command is ready to move forward on the standards track at the same time. After going through a number of revisions on VIEW and WINDOW proposals with Cyrus, my position has changed slightly. I now recognize that the VIEW command (or similar mechanism) would introduce significant complexity and that complexity may exceed the benefit it provides. In particular, the majority of users may be satisfied to keep the size of the mailboxes on which they apply SORT and THREAD to some reasonable limit (e.g., less than 10,000 messages) in order to get acceptable performance. Scalable servers might cache SORT and THREAD results so the computation cost is minimized and perhaps bandwidth is increasing fast enough that it isn't a concern. So I am now willing to see SORT and THREAD move forward without VIEW despite my scalability concerns. Given how busy and resource limited the IMAP community appears to be at the moment, I further propose we drop the VIEW command from the list of WG deliverables we must complete prior to WG closure (but let's not bother changing the charter until we've finished the other deliverables). - Chris Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4DKxZi2044963 for ; Tue, 13 May 2003 13:59:35 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h4DKxZKI044962 for ietf-imapext-bks; Tue, 13 May 2003 13:59:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from brmea-mail-3.sun.com (pheriche.sun.com [192.18.98.34]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4DKxYi2044957 for ; Tue, 13 May 2003 13:59:34 -0700 (PDT) (envelope-from Chris.Newman@Sun.COM) Received: from esunmail ([129.147.58.120]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4DKxaRh014252 for ; Tue, 13 May 2003 14:59:36 -0600 (MDT) Received: from xpa-fe1 ([129.147.58.198]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HEU00BK7FNB8Q@edgemail1.Central.Sun.COM> for ietf-imapext@imc.org; Tue, 13 May 2003 14:59:36 -0600 (MDT) Received: from nifty-jr.west.sun.com ([129.153.12.95]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HEU007EYFN6TO@mail.sun.net> for ietf-imapext@imc.org; Tue, 13 May 2003 14:59:34 -0600 (MDT) Date: Tue, 13 May 2003 13:57:04 -0700 From: Chris Newman Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-00.txt In-reply-to: <020d01c3197f$dd7cf200$d1d07b43@cocacola> To: Michael Fair , ietf-imapext@imc.org Message-id: <2147483647.1052834224@nifty-jr.west.sun.com> MIME-version: 1.0 X-Mailer: Mulberry/3.0.3 (Mac OS X) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-message-flag: Outlook: the best virus distribution system around References: <200305131200.IAA05283@ietf.org> <020d01c3197f$dd7cf200$d1d07b43@cocacola> Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: begin quotation by Michael Fair on 2003/5/13 11:45 -0700: > Four things: > > 1) Lately there's been talk of moving commands like these > into a client CAPABILITY announcement string. The command > has been proposed as a way for the client to: > > A) Announce capabilities it has that the server > might be able to do something special with, > and > B) Set options to server capabilities that impact the > behavior of the session > > The two major candidates in most examples so far have > been VHOST and LANGUAGE. I didn't see anything requested > here that would preclude LANGUAGE from being assigned > in that manner. The only "special case" I saw is that > any client issuing a CAPABILITY with a LANGUAGE option > MUST be prepared to receive an untagged NAMESPACE response > as one of the responses to CAPABILITY. > > Is there anything else anyone else saw that seems to make > this whole client side CAPABILITY approach to items like > VHOST and LANGUAGE (and perhaps a CHARSET could be added > to the list for UTF-8 support?) a bad idea? We discussed the issue of client capabilities at the informal IMAPEXT BOF at the last IETF and there was a rough consensus in the room (of about 20 IMAP developers many of whom write code) which opposed the idea of a combined client capability mechanism. The rough consensus of the room appeared to favor separate commands which could be pipelined rather than a combined command. Now the mailing list can override that consensus, but I'd need to see stronger support than I've seen to date. In addition, there is deployed running code for the LANGUAGE extension (implemented to the previous draft). As a result I am opposed to aesthetic changes to the LANGUAGE extension as documented. Proposed changes need to have a substantive technical justification. > 2) In specific response to the LANGUAGE feature set as > described, I noticed it is missing in-band administration > for assigning the various LANGUAGE translations of folders. > > 3) Could this be extended to allow all folders to be > represented in multiple languages by way of some kind > of "ALIAS" command that could install a language alias > for folders? This would probably require the equivalent > of a RENAME ACL. This would anticipate a resolution > to the lack of character set choice currently present. > (For instance via a client capability mentioned above.) Please make a concrete proposal if you want to discuss these issues. I'm not sure exactly what you're asking so it would be easier to discuss if I could see something concrete. > 4) Since languages are somewhat tied to character sets, > it seems logical that in response to the LANGUAGE command > aside from the language selected the character set used > by the server to display that language should also be > announced shouldn't it? I've done no internationalization > work so I'm not sure how you get two machines to align > on a character set implicity through just a language name. The selected character set is always UTF-8, so there is no issue. - Chris Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4DIpAi2038918 for ; Tue, 13 May 2003 11:51:10 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h4DIpAIl038917 for ietf-imapext-bks; Tue, 13 May 2003 11:51:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4DIp9i2038911 for ; Tue, 13 May 2003 11:51:09 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id 695AB812FF4; Tue, 13 May 2003 11:51:10 -0700 (PDT) Received: from cocacola (adsl-67-123-208-209.dsl.lsan03.pacbell.net [67.123.208.209]) by DrPepper (Postfix) with ESMTP id 636D381079A for ; Tue, 13 May 2003 11:51:08 -0700 (PDT) Message-ID: <020d01c3197f$dd7cf200$d1d07b43@cocacola> From: "Michael Fair" To: References: <200305131200.IAA05283@ietf.org> Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-00.txt Date: Tue, 13 May 2003 11:45:45 -0700 Organization: DaClubhouse MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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 X-Spam-Status: No, hits=-9.8 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Four things: 1) Lately there's been talk of moving commands like these into a client CAPABILITY announcement string. The command has been proposed as a way for the client to: A) Announce capabilities it has that the server might be able to do something special with, and B) Set options to server capabilities that impact the behavior of the session The two major candidates in most examples so far have been VHOST and LANGUAGE. I didn't see anything requested here that would preclude LANGUAGE from being assigned in that manner. The only "special case" I saw is that any client issuing a CAPABILITY with a LANGUAGE option MUST be prepared to receive an untagged NAMESPACE response as one of the responses to CAPABILITY. Is there anything else anyone else saw that seems to make this whole client side CAPABILITY approach to items like VHOST and LANGUAGE (and perhaps a CHARSET could be added to the list for UTF-8 support?) a bad idea? 2) In specific response to the LANGUAGE feature set as described, I noticed it is missing in-band administration for assigning the various LANGUAGE translations of folders. 3) Could this be extended to allow all folders to be represented in multiple languages by way of some kind of "ALIAS" command that could install a language alias for folders? This would probably require the equivalent of a RENAME ACL. This would anticipate a resolution to the lack of character set choice currently present. (For instance via a client capability mentioned above.) 4) Since languages are somewhat tied to character sets, it seems logical that in response to the LANGUAGE command aside from the language selected the character set used by the server to display that language should also be announced shouldn't it? I've done no internationalization work so I'm not sure how you get two machines to align on a character set implicity through just a language name. -- Michael -- ----- Original Message ----- From: To: Cc: Sent: Tuesday, May 13, 2003 5:00 AM Subject: I-D ACTION:draft-ietf-imapext-i18n-00.txt > 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 : Internet Message Access Protocol Internationalization > Author(s) : C. Newman > Filename : draft-ietf-imapext-i18n-00.txt > Pages : 18 > Date : 2003-5-12 > > Internet Message Access Protocol (IMAP) version 4rev1 has basic > support for non-ASCII characters in mailbox names and search > substrings. It also supports non-ASCII message headers and content > encoded as specified by Multipurpose Internet Mail Extensions (MIME). > This specification defines a collection of IMAP extensions which > improve international support including comparator negotiation for > search, sort and thread, language negotiation for international error > text, and translations for namespace prefixes. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-imapext-i18n-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-ietf-imapext-i18n-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-imapext-i18n-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. > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4DC3Ji2010151 for ; Tue, 13 May 2003 05:03:19 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h4DC3Jfc010150 for ietf-imapext-bks; Tue, 13 May 2003 05:03:19 -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.8p1/8.12.8) with ESMTP id h4DC3Ii2010145 for ; Tue, 13 May 2003 05:03:18 -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 IAA05283; Tue, 13 May 2003 08:00:16 -0400 (EDT) Message-Id: <200305131200.IAA05283@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-i18n-00.txt Date: Tue, 13 May 2003 08:00:15 -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 : Internet Message Access Protocol Internationalization Author(s) : C. Newman Filename : draft-ietf-imapext-i18n-00.txt Pages : 18 Date : 2003-5-12 Internet Message Access Protocol (IMAP) version 4rev1 has basic support for non-ASCII characters in mailbox names and search substrings. It also supports non-ASCII message headers and content encoded as specified by Multipurpose Internet Mail Extensions (MIME). This specification defines a collection of IMAP extensions which improve international support including comparator negotiation for search, sort and thread, language negotiation for international error text, and translations for namespace prefixes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-i18n-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-ietf-imapext-i18n-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imapext-i18n-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-5-12152624.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-i18n-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-i18n-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-12152624.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46Lv2i2004255 for ; Tue, 6 May 2003 14:57:02 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46Lv2Zt004254 for ietf-imapext-bks; Tue, 6 May 2003 14:57:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46Lv0i2004246 for ; Tue, 6 May 2003 14:57:01 -0700 (PDT) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h46LuhB4010410 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 6 May 2003 23:56:44 +0200 To: Mark Crispin Cc: Pete Resnick , ietf-imapext@imc.org Subject: Re: Vienna References: From: Simon Josefsson X-Payment: hashcash 1.2 0:030506:MRC@CAC.Washington.EDU:cfd99dea6f4c5d92 X-Hashcash: 0:030506:MRC@CAC.Washington.EDU:cfd99dea6f4c5d92 X-Payment: hashcash 1.2 0:030506:presnick@qualcomm.com:74e40c174dd4049c X-Hashcash: 0:030506:presnick@qualcomm.com:74e40c174dd4049c X-Payment: hashcash 1.2 0:030506:ietf-imapext@imc.org:c683ecff4b65dd0b X-Hashcash: 0:030506:ietf-imapext@imc.org:c683ecff4b65dd0b Date: Tue, 06 May 2003 23:56:43 +0200 In-Reply-To: (Mark Crispin's message of "Tue, 6 May 2003 14:20:04 -0700 (Pacific Daylight Time)") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-32.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: > I suggest a command, valid when not logged in, that will fetch a > particular message or portion of message. Thus, the argument to the > command has to carry authentication of some kind; the key is that this is > *not* the user's authentication but rather some special authentication > that is specific to that message or portion of a message. > > Desirable authentication forms: use-once, anonymous, use only by certain > entity, time-limited (e.g. "expires in 5 minutes"). > > Could be a SASL mechanism, since SASL has the framework; ultimately > returning a NO so it can be done multiple times in one IMAP connection. > > Must be expressable in an IMAP URL; the URL must carry the authentication > (possibly also with a client-supplied token). > > The idea here is that the MSA is given a message with various IMAP URLs > inserted. The MSA resolves the URL and fetches the data from the server > (or servers -- an advantage of doing it this way). > > We need a command for an IMAP client to create these things, e.g. "give me > a cookie, expiring in 10 minutes, that will fetch part [2.4.4] from UID > 12383 from my INBOX". SASL together with a short-lived Kerberos ticket is a somewhat heavy solution (even heavier if GSSAPI is involved), but possible. It could be done with a short-lived username/password combination too, although more difficult to embed useful information you can store in the ticket (like who created the ticket, useful for logging). The server could log on the user, using the short-lived authorization information, and present a restricted view of the mailboxes: only the appropriate message is available, from one mailbox (INBOX). SASL definitely has the framework for this, and using it wouldn't require changes to the IMAP URL either. My $.2. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46Ljpi2003987 for ; Tue, 6 May 2003 14:45:51 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46LjpWQ003986 for ietf-imapext-bks; Tue, 6 May 2003 14:45:51 -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.8p1/8.12.8) with ESMTP id h46Ljoi2003981 for ; Tue, 6 May 2003 14:45:50 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout4.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h46LjiTc027876; Tue, 6 May 2003 14:45:49 -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.1+UW03.04/8.12.1+UW02.12) with ESMTP id h46LjiQ0011028 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 6 May 2003 14:45:44 -0700 Date: Tue, 6 May 2003 14:45:45 -0700 (Pacific Daylight Time) From: Mark Crispin To: Cyrus Daboo cc: Pete Resnick , ietf-imapext@imc.org Subject: Re: Vienna In-Reply-To: <2147483647.1052242874@[63.163.82.24]> Message-ID: References: <2147483647.1052242874@[63.163.82.24]> 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, 6 May 2003, Cyrus Daboo wrote: > Surely its enough to simply require ACL and require that the MSA have an > associated user id on the IMAP server and that it be given read/write > access to each 'real' users' OUTBOX? No, part of the design is that the MSA does *NOT* have access to anything that it is not given specific access. Also, I'm thinking that this may be useful for other things; perhaps I might want to send someone an email with such a URL (as opposed to the actual data). -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46LiZi2003938 for ; Tue, 6 May 2003 14:44:35 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46LiZM6003937 for ietf-imapext-bks; Tue, 6 May 2003 14:44:35 -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.8p1/8.12.8) with ESMTP id h46LiYi2003932 for ; Tue, 6 May 2003 14:44:34 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id RAA17773; Tue, 6 May 2003 17:40:54 -0400 (EDT) Date: Tue, 06 May 2003 17:44:34 -0400 From: Cyrus Daboo To: Pete Resnick , ietf-imapext@imc.org Subject: Re: Vienna Message-ID: <2147483647.1052243074@[63.163.82.24]> In-Reply-To: References: X-Mailer: Mulberry/3.1.0b1 (Mac OS/PPC) 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 Pete, --On Tuesday, May 6, 2003 10:15 AM -0500 Pete Resnick wrote: | Document editors: Please provide to the list the status of your | documents. Are there open issues that will need to be discussed in Vienna? | I have to catch up on the changes to ANNOTATE/ANNOTATEMORE from the last meeting - sorry. I will try and get around to that by the end of this week. | I will be in Vienna either way. Let's figure out now whether we need a | meeting. I will not be waltzing over to Vienna :-( -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46LfWi2003836 for ; Tue, 6 May 2003 14:41:32 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46LfW0b003835 for ietf-imapext-bks; Tue, 6 May 2003 14:41: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.8p1/8.12.8) with ESMTP id h46LfVi2003826 for ; Tue, 6 May 2003 14:41:31 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id RAA17721; Tue, 6 May 2003 17:37:35 -0400 (EDT) Date: Tue, 06 May 2003 17:41:14 -0400 From: Cyrus Daboo To: Mark Crispin , Pete Resnick cc: ietf-imapext@imc.org Subject: Re: Vienna Message-ID: <2147483647.1052242874@[63.163.82.24]> In-Reply-To: References: X-Mailer: Mulberry/3.1.0b1 (Mac OS/PPC) 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, --On Tuesday, May 6, 2003 2:20 PM -0700 Mark Crispin wrote: | The idea here is that the MSA is given a message with various IMAP URLs | inserted. The MSA resolves the URL and fetches the data from the server | (or servers -- an advantage of doing it this way). | | We need a command for an IMAP client to create these things, e.g. "give me | a cookie, expiring in 10 minutes, that will fetch part [2.4.4] from UID | 12383 from my INBOX". Surely its enough to simply require ACL and require that the MSA have an associated user id on the IMAP server and that it be given read/write access to each 'real' users' OUTBOX? Its then a simple matter to write a dedicated IMAP client for the MSA that goes and gets messages from each OUTBOX on the IMAP server. If you combine this with async notifications for STATUS changes (i.e. when a message is added to an OUTBOX) there shouldn't be any need to pass a URL to the MSA. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46LK9i2003176 for ; Tue, 6 May 2003 14:20:09 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46LK9TA003175 for ietf-imapext-bks; Tue, 6 May 2003 14:20:09 -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.8p1/8.12.8) with ESMTP id h46LK7i2003170 for ; Tue, 6 May 2003 14:20:07 -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.1+UW03.04/8.12.1+UW02.12) with ESMTP id h46LK3RG015518; Tue, 6 May 2003 14:20:08 -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.1+UW03.04/8.12.1+UW02.12) with ESMTP id h46LK3Q0008083 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 6 May 2003 14:20:03 -0700 Date: Tue, 6 May 2003 14:20:04 -0700 (Pacific Daylight Time) From: Mark Crispin To: Pete Resnick cc: ietf-imapext@imc.org Subject: Re: Vienna 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 Tue, 6 May 2003, Pete Resnick wrote: > Document editors: Please provide to the list the status of your > documents. SORT/THREAD: awaiting Chris Newman's i18n document to come out as an I-D before making Last Call. > Are there open issues that will need to be discussed in > Vienna? Since both UW and Cyrus now implement Alexey's UNSELECT extension, let's Last Call it. The I-D is expired. > Others: Are there items that you think need to be discussed in > Vienna? Do remember that LEMONADE-related items should be discussed > over there. Two things come to mind: 1) Does Chris need help with the i18n I-D? If so, he should get it. 2) LEMONADE. LEMONADE clearly identified a need for message submission that does not require downloading from IMAP server; however, doing submission in IMAP is a mistake. I'd rather not argue the reasons why in email; it'll just waste everybody's time. Instead, let's come up with an alternative so there is a choice that can be made. Right now, there is no choice. I suggest a command, valid when not logged in, that will fetch a particular message or portion of message. Thus, the argument to the command has to carry authentication of some kind; the key is that this is *not* the user's authentication but rather some special authentication that is specific to that message or portion of a message. Desirable authentication forms: use-once, anonymous, use only by certain entity, time-limited (e.g. "expires in 5 minutes"). Could be a SASL mechanism, since SASL has the framework; ultimately returning a NO so it can be done multiple times in one IMAP connection. Must be expressable in an IMAP URL; the URL must carry the authentication (possibly also with a client-supplied token). The idea here is that the MSA is given a message with various IMAP URLs inserted. The MSA resolves the URL and fetches the data from the server (or servers -- an advantage of doing it this way). We need a command for an IMAP client to create these things, e.g. "give me a cookie, expiring in 10 minutes, that will fetch part [2.4.4] from UID 12383 from my INBOX". > I will be in Vienna either way. Let's figure out now whether we need a > meeting. I won't be in Vienna. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46FFgi2081993 for ; Tue, 6 May 2003 08:15:42 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46FFgZo081992 for ietf-imapext-bks; Tue, 6 May 2003 08:15:42 -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 (champdsl-25-66.mcleodusa.net [216.43.25.66]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46FFei2081987 for ; Tue, 6 May 2003 08:15:40 -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.1b1) for ; Tue, 6 May 2003 10:16:20 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: X-Mailer: Eudora [Macintosh version 6.0a15] Date: Tue, 6 May 2003 10:15:35 -0500 To: ietf-imapext@imc.org From: Pete Resnick Subject: Vienna Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've been reminded to start early on figuring out what's going on for the next IETF meeting, so let's do that. Document editors: Please provide to the list the status of your documents. Are there open issues that will need to be discussed in Vienna? Others: Are there items that you think need to be discussed in Vienna? Do remember that LEMONADE-related items should be discussed over there. I will be in Vienna either way. Let's figure out now whether we need a meeting. -- 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.8p1/8.12.8) with ESMTP id h45IMfi2004669 for ; Mon, 5 May 2003 11:22:41 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h45IMfTx004668 for ietf-imapext-bks; Mon, 5 May 2003 11:22:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h45IMdi2004662 for ; Mon, 5 May 2003 11:22:39 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id 038688831EB; Mon, 5 May 2003 11:22:40 -0700 (PDT) Received: from cocacola (adsl-67-123-208-209.dsl.lsan03.pacbell.net [67.123.208.209]) by DrPepper (Postfix) with ESMTP id 4227F8160F5; Mon, 5 May 2003 11:22:39 -0700 (PDT) Message-ID: <065101c3136e$023899e0$d1d07b43@cocacola> From: "Michael Fair" To: Cc: "Harrie Hazewinkel" References: <134EE589-7F01-11D7-B305-0003934A5A7E@lisanza.net> Subject: Re: Adding CAPABILITY to "Hello, Starttls, and Authenticate/Login" (saving round trips) Date: Mon, 5 May 2003 18:22:49 -0700 Organization: DaClubhouse 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 X-Spam-Status: No, hits=-5.6 required=5.0 tests=DATE_IN_FUTURE_06_12,REFERENCES version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'm looking forward to hearing what others also have to say about this. It seems to me that two or three drafts should be used to replace the current VHOST draft based on this discussion. While I may have the details wrong, in general, the three drafts seem to be something along the lines of the following: 1) ECAPABILITY draft (nobody seems to mind ECAPABILITY keyword). - This creates ECAPABILITY as a CAPABILITY keyword and means that the CAPABILITY command accepts parameters for the purposes of informing the server of client capabilities and for passing options to capabilities the server supports. 2) VHOST draft - Redefines VHOST in the context of ECAPABILITY as per the details of this discussion. 3) Notification of CAPABILITY as unsolicited responses draft - In order to save round trips, allows a server to post an unsolicitied CAPABILITY response after the client executes any command that changes the CAPABILITY set. Currently the identified responses are HELLO, STARTTLS, ECAPABILITY, LOGIN, and AUTHENTICATE. I'd imagine that in some servers other commands (like "SELECT") might also want/need this ability. It would also seem that other ideas and drafts might be recontextualized via ECAPABILITY as well. For instance, the LANGUAGE thread that went on a while ago might give servers the opportunity to store and manipulate folders in multiple languages and allow the client to define a preferred language priority list. Something would have to be done to allow clients to attach folder names in different languages to exisitng folders, but that's outside the scope of the ECAPABILITY draft. My $0.02, -- Michael -- ----- Original Message ----- From: "Harrie Hazewinkel" To: Cc: "Harrie Hazewinkel" ; "Michael Fair" Sent: Monday, May 05, 2003 6:54 AM Subject: Re: Adding CAPABILITY to "Hello, Starttls, and Authenticate/Login" (saving round trips) > HI all, > > > As being the author of that 'VHOST' command internet-draft > I was wondering if the group believes it is usefull > to recycle that draft based on the summary/idea/consensus > of this discussion?? > > > Harrie > > On Friday, May 2, 2003, at 05:16 AM, Michael Fair wrote: > > > > >> The really important thing is avoiding round-trips. The > >> amount of bandwidth > >> that is taken up by capabilities is really dwarfed by > >> any messages the client downloads. > >> > >> It would be nice, if you're redoing how capabilities > >> are announced, to do > >> away with the pointless roundtrips after STARTTLS and > >> after authentication. > > > > I've renamed the subject to reflect the topic. It's > > become pretty clear to me that this issue is important > > but is really separate from adding parameters to the > > CAPABILITY command. > > > > So far the suggestions are to automatically append > > a CAPABILITY response to any command that changes > > the current CAPABILITY set. So far those responses > > are HELLO, STARTTLS, AUTHENTICATE, LOGIN, and if > > accepted ECAPABILITY. > > > > This really sounds more like IMAP4rev2ish but I > > would suggest including something like: > > > > - A Client MUST be prepared to receive an unsolicited > > CAPABILITY response after the status response code > > of any command. > > > > If you wanted to restrict that to "state altering" > > commands that would probably work too. > > > > -- Michael -- > > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h423H3i2090274 for ; Thu, 1 May 2003 20:17:03 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h423H3W7090273 for ietf-imapext-bks; Thu, 1 May 2003 20:17:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h423H0i2090266 for ; Thu, 1 May 2003 20:17:01 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id 9FF9E883DD6; Thu, 1 May 2003 20:17:03 -0700 (PDT) Received: from cocacola (adsl-67-123-208-209.dsl.lsan03.pacbell.net [67.123.208.209]) by DrPepper (Postfix) with ESMTP id 571B7812FF5; Thu, 1 May 2003 20:17:02 -0700 (PDT) Message-ID: <018301c31059$4291efe0$d1d07b43@cocacola> From: "Michael Fair" To: "Lawrence Greenfield" , "Timo Sirainen" , "Cyrus Daboo" Cc: References: <1214403459.1051806924@PLATO.cyrusoft.com> <1051825642.26180.284.camel@hurina> <352505536.1051820546@majormajor.REM.CMU.EDU> Subject: Adding CAPABILITY to "Hello, Starttls, and Authenticate/Login" (saving round trips) Date: Thu, 1 May 2003 20:16:44 -0700 Organization: DaClubhouse 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 X-Spam-Status: No, hits=-6.6 required=5.0 tests=REFERENCES version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > The really important thing is avoiding round-trips. The > amount of bandwidth > that is taken up by capabilities is really dwarfed by > any messages the client downloads. > > It would be nice, if you're redoing how capabilities > are announced, to do > away with the pointless roundtrips after STARTTLS and > after authentication. I've renamed the subject to reflect the topic. It's become pretty clear to me that this issue is important but is really separate from adding parameters to the CAPABILITY command. So far the suggestions are to automatically append a CAPABILITY response to any command that changes the current CAPABILITY set. So far those responses are HELLO, STARTTLS, AUTHENTICATE, LOGIN, and if accepted ECAPABILITY. This really sounds more like IMAP4rev2ish but I would suggest including something like: - A Client MUST be prepared to receive an unsolicited CAPABILITY response after the status response code of any command. If you wanted to restrict that to "state altering" commands that would probably work too. -- Michael -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h420Mti2085796 for ; Thu, 1 May 2003 17:22:55 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h420MtVA085795 for ietf-imapext-bks; Thu, 1 May 2003 17:22:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp6.andrew.cmu.edu (SMTP6.andrew.cmu.edu [128.2.10.86]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h420Msi2085790 for ; Thu, 1 May 2003 17:22:54 -0700 (PDT) (envelope-from leg+@andrew.cmu.edu) Received: from majormajor.REM.CMU.EDU (DYN-4-218.CC.cmu.edu [128.2.4.218] (may be forged)) (user=leg mech=GSSAPI (0 bits)) by smtp6.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h420Modg027673 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 1 May 2003 20:22:50 -0400 Date: Thu, 01 May 2003 20:22:27 -0400 From: Lawrence Greenfield To: Timo Sirainen , Cyrus Daboo cc: Michael Fair , ietf-imapext@imc.org Subject: Re: Adding a parameter to CAPABILITY Message-ID: <352505536.1051820546@majormajor.REM.CMU.EDU> In-Reply-To: <1051825642.26180.284.camel@hurina> References: <1214403459.1051806924@PLATO.cyrusoft.com> <1051825642.26180.284.camel@hurina> X-Mailer: Mulberry/3.0.3 (Win32) 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: --On Friday, May 02, 2003 12:47 AM +0300 Timo Sirainen wrote: > > On Thu, 2003-05-01 at 23:35, Cyrus Daboo wrote: >> For better compatibility with clients that won't understand ECAPABILITY >> I think ECAPABILITY should be a capability value itself. This means >> that the greeting string can continue to display the CAPABILITY >> response code that some servers now return, but would include >> ECAPABILITY as one its items: >> >> * OK [CAPABILITY IMAP4REV1 ECAPABILITY STARTTLS AUTH=GSSAPI] Hello to >> you! > > I don't really like sending the capability to client automatically. That > also means that we would receive the capability twice, once at start and > next after issuing CAPABILITY VHOST (..). The really important thing is avoiding round-trips. The amount of bandwidth that is taken up by capabilities is really dwarfed by any messages the client downloads. It would be nice, if you're redoing how capabilities are announced, to do away with the pointless roundtrips after STARTTLS and after authentication. Larry Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41N1Ei2084060 for ; Thu, 1 May 2003 16:01:14 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h41N1EPu084059 for ietf-imapext-bks; Thu, 1 May 2003 16:01:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41N1Di2084054 for ; Thu, 1 May 2003 16:01:13 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id 323C187BDFB; Thu, 1 May 2003 16:01:15 -0700 (PDT) Received: from cocacola (adsl-67-123-208-209.dsl.lsan03.pacbell.net [67.123.208.209]) by DrPepper (Postfix) with ESMTP id 5ED26812FF5; Thu, 1 May 2003 16:01:13 -0700 (PDT) Message-ID: <011901c31035$87133580$d1d07b43@cocacola> From: "Michael Fair" To: "Timo Sirainen" , "Cyrus Daboo" Cc: References: <1214403459.1051806924@PLATO.cyrusoft.com> <1051825642.26180.284.camel@hurina> Subject: Re: Adding a parameter to CAPABILITY Date: Thu, 1 May 2003 16:00:57 -0700 Organization: DaClubhouse MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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 X-Spam-Status: No, hits=-10.4 required=5.0 tests=QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,REFERENCES version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > * OK [CAPABILITY IMAP4REV1 ECAPABILITY STARTTLS AUTH=GSSAPI] Hello to you! > > I don't really like sending the capability to client automatically. That > also means that we would receive the capability twice, once at start and > next after issuing CAPABILITY VHOST (..). You either need to convince people that it's ok for a client to just try it and then fallback on failure, or the client needs to get the information twice anyway. By pre-announcing we're just short circuiting one of the round trips. I initially proposed something that utilized the error codes of existing server to determine if it supported arguments to CAPABILITY. An example of that proposal when used against an existing server would now look like: * IMAP Server - Hello there! C: 1 CAPABILITY VHOST (fqdn.example.com) ... S: 1 BAD Unexpected extra arguments to Capability C: 2 CAPABILITY * CAPABILITY IMAP4rev1 ... S: 2 OK Completed I expected that over time servers would come to deal with the added arguments (first just by swallowing them and not returning BAD, but still responding to CAPABILITY) and so the only "wasted bandwidth" was during the initial introduction of the parameter, and only when new clients were used against old servers. Existing servers are prepared for such "malformed" requests so I was just taking advantage of "corerct behavior". I, like yourself, was trying to minimize the number of times a client had to parse a CAPABILITY response. But people didn't like that the client didn't at least have a method for having foreknowledge, so it forced a round trip. That example would now look like: * IMAP Server - Hello there! C: 1 CAPABILITY S: * CAPABILITY IMAP4rev1 ECAPABILITY ... S: 1 OK Completed C: 2 CAPABILITY VHOST (fqdn.example.com) ... S: * CAPABILITY IMAP4rev1 ECAPABILITY VHOST (fqdn.example.com) ... S: 2 OK Completed Which still makes the client make two round trips, but now it has to actually pay attention to the result of the first one just to find out if it can issue the second. Of course, there's nothing stopping a client from doing it the way I first proposed. I have no reason to believe the first proposal is "wrong" in anyway. But let's stick to the new method. So the client issues a CAPABILITY line to find out if it can issue a parameterized CAPABILITY line. Well that's two round trips and two CAPABILITY parses. That kinda sucks, why don't we "preannounce" the first CAPABILITY command that we know the client is going to have to issue anyway and save the client at least one round trip? If we don't pre-announce the capabilities we make the client fetch for it. Now these same semantics are not only related to ECAPABILITY also AUTHENTICATE and probably others. So the thought is that if we are going to bother with preannouncing something we might as well preannounce the whole capability response. This will save all clients at least one round trip regardless of what they are going to do. Of course we could/should break this out into two extensions - One is ECAPABILITY (for lack of a formal term) and the other is "CAPABILITY ON HELLO". If we did that, would you be satisfied that ECAPABILITY on its own and as its own CAPABILITY term is fine, and then talk about the merits of "CAPABILITY ON HELLO" in a different thread? -- Michael -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41LlXi2081389 for ; Thu, 1 May 2003 14:47:33 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h41LlXgL081388 for ietf-imapext-bks; Thu, 1 May 2003 14:47:33 -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.8p1/8.12.8) with ESMTP id h41LlVi2081382 for ; Thu, 1 May 2003 14:47:32 -0700 (PDT) (envelope-from tss@iki.fi) Received: by oma.irssi.org (Postfix, from userid 1000) id C0F265E107F8; Fri, 2 May 2003 00:47:22 +0300 (EEST) Subject: Re: Adding a parameter to CAPABILITY From: Timo Sirainen To: Cyrus Daboo Cc: Michael Fair , ietf-imapext@imc.org In-Reply-To: <1214403459.1051806924@PLATO.cyrusoft.com> References: <1214403459.1051806924@PLATO.cyrusoft.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1051825642.26180.284.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 02 May 2003 00:47:22 +0300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2003-05-01 at 23:35, Cyrus Daboo wrote: > For better compatibility with clients that won't understand ECAPABILITY I > think ECAPABILITY should be a capability value itself. This means that the > greeting string can continue to display the CAPABILITY response code that > some servers now return, but would include ECAPABILITY as one its items: > > * OK [CAPABILITY IMAP4REV1 ECAPABILITY STARTTLS AUTH=GSSAPI] Hello to you! I don't really like sending the capability to client automatically. That also means that we would receive the capability twice, once at start and next after issuing CAPABILITY VHOST (..). Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41LBUi2080321 for ; Thu, 1 May 2003 14:11:30 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h41LBUvc080320 for ietf-imapext-bks; Thu, 1 May 2003 14:11:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41LBSi2080315 for ; Thu, 1 May 2003 14:11:28 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id 5805D87BDFB; Thu, 1 May 2003 14:11:30 -0700 (PDT) Received: from cocacola (adsl-67-123-208-209.dsl.lsan03.pacbell.net [67.123.208.209]) by DrPepper (Postfix) with ESMTP id EC164812FF5; Thu, 1 May 2003 14:11:28 -0700 (PDT) Message-ID: <00e801c31026$327d9b00$d1d07b43@cocacola> From: "Michael Fair" To: "Cyrus Daboo" , References: <1214403459.1051806924@PLATO.cyrusoft.com> Subject: Re: Adding a parameter to CAPABILITY Date: Thu, 1 May 2003 14:11:13 -0700 Organization: DaClubhouse 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 X-Spam-Status: No, hits=-6.6 required=5.0 tests=REFERENCES version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Hi Michael, > > --On Thursday, May 01, 2003 1:05 PM -0700 Michael Fair > wrote: > > | Any and all feedback is welcome and encouraged. > | Especially in finding the string to put in the > | Hello response. > > For better compatibility with clients that won't > understand ECAPABILITY I think ECAPABILITY should > be a capability value itself. This means that the > greeting string can continue to display the > CAPABILITY response code that some servers now > return, but would include ECAPABILITY as one its items: > > * OK [CAPABILITY IMAP4REV1 ECAPABILITY STARTTLS AUTH=GSSAPI] Hello to you! I've got no problem with that at all. :) I'll keep an ear open for calling it something other than ECAPABILITY, "CLIENTCAPABILITY" has also been suggested, I missed mentioning it earlier. Anyone else have any other suggestions or should we move on to actually drawing up a draft? If we should move on to drawing up a draft, are there any other currently proposed extensions aside from VHOST that this new draft should supercede? I would love to hear some feedback from more server implementors and client writers that are on the list as to their opinion on how this should proceed. What changes, if any, would help make their lives easier and thus more likely to add this command into their code. -- Michael -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41KYEi2079002 for ; Thu, 1 May 2003 13:34:14 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h41KYEdn079001 for ietf-imapext-bks; Thu, 1 May 2003 13:34:14 -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.8p1/8.12.8) with ESMTP id h41KYCi2078995 for ; Thu, 1 May 2003 13:34:13 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from PLATO.cyrusoft.com (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id QAA03870; Thu, 1 May 2003 16:30:42 -0400 (EDT) Date: Thu, 01 May 2003 16:35:24 -0400 From: Cyrus Daboo To: Michael Fair , ietf-imapext@imc.org Subject: Re: Adding a parameter to CAPABILITY Message-ID: <1214403459.1051806924@PLATO.cyrusoft.com> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (Win32) 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 Michael, --On Thursday, May 01, 2003 1:05 PM -0700 Michael Fair wrote: | Any and all feedback is welcome and encouraged. | Especially in finding the string to put in the | Hello response. For better compatibility with clients that won't understand ECAPABILITY I think ECAPABILITY should be a capability value itself. This means that the greeting string can continue to display the CAPABILITY response code that some servers now return, but would include ECAPABILITY as one its items: * OK [CAPABILITY IMAP4REV1 ECAPABILITY STARTTLS AUTH=GSSAPI] Hello to you! -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41K6Ci2078011 for ; Thu, 1 May 2003 13:06:12 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h41K6CQc078007 for ietf-imapext-bks; Thu, 1 May 2003 13:06:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41K6Ai2077998 for ; Thu, 1 May 2003 13:06:11 -0700 (PDT) (envelope-from ietf-ietf-imapext@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19BKIX-0008LE-00 for ; Thu, 01 May 2003 22:04:53 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-imapext@imc.org Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19BKIV-0008Kl-00 for ; Thu, 01 May 2003 22:04:51 +0200 From: "Michael Fair" Subject: Adding a parameter to CAPABILITY Date: Thu, 1 May 2003 13:05:47 -0700 Lines: 89 Message-ID: X-Complaints-To: usenet@main.gmane.org X-MSMail-Priority: Normal X-Newsreader: 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: After much discussion about the VHOST feature for virtualizing domains and being able to reliably host multiple domains on a single IP. The general consensus is that being able to reliably host multiple domains on a single IP is useful, using a parameter to STARTTLS, while preferred and already supported with a STARTTLS draft extension, is unreliable, and that any of the other recommended solutions essentially equates adding a parameter to CAPABILITY, finally, that if we are going to bother adding a parameter to CAPABILITY we might as well make it so that future modifications of a similar type don't need another modification to the protocol and thus a client should be able to submit its own capability options to the server when it makes a capability request. This feature in general is being referred to as a "Client CAPABILITY" line. It's purpose is to inform the server of any capabilities the client has that the server may need to be informed of (no current need has been identified for this though there are potential ideas for its use) and to pass parameters to the server for any capabilities the server offers that may be modified (this is the feature that VHOST would use). As such, the current proposal on the table goes along the lines of: 1) A specific string is added to the HELLO response to notify the client that a client capability parameter is supported. The only string suggested as of yet is "[ECAPABILITY]" following with ESMTP. Other suggestions are requested. 2) A client MAY provide a CAPABILITY parameter if it saw the appropriate string in the HELLO response. The client capability should match syntax with the existing CAPABILITY response to prevent servers from having to invent new parsers. 3) The CAPABILITY response from the server MUST acknowledge each parameter response it understands to inform the client of the accepted parameters and their status. Absence of a parameter in the servers CAPABILITY response means the server does not support or does not understand that particular CAPABILITY. Syntax errors on parameters that the server does understand SHOULD respond with "BAD" and give the appropriate reason for failure. 4) While a client capability parameter may be supported the rules which govern the individual options are defined on a per instance basis. For instance, with VHOST, once a client has entered into a TLS session or the AUTHENTICATED state, if the client should issue another CAPABILITY line the VHOST parameter SHOULD NOT be changed, and if the client does try and change it, the server SHOULD respond with "No" indicating the VHOST parameter has been changed and is invalid (an exception might be made for server administrator users). It is considered a security risk to allow clients to jump between domains once they are in a TLS session or the AUTHENTICATED state. So an example conversation might be the following (note the server does not support LANGUAGE and so leaves it out of its response to CAPABILITY): S: * OK [ECAPABILITY] IMAP server ready. C: 1 CAPABILITY VHOST (fqdn.example.com) RLIST LANGUAGE (en_US en_GB) S: 1 OK [CAPABILITY IMAP4rev1 VHOST (fqdn.example.com) RLIST ...] C: 2 STARTTLS S: 2 OK ...etc... Any and all feedback is welcome and encouraged. Especially in finding the string to put in the Hello response. -- Michael -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4UICfAF042952 for ; Fri, 30 May 2003 11:12:41 -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 h4UICf8Z042951 for ietf-imapext-bks; Fri, 30 May 2003 11:12:41 -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 ([208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4UICdAF042942 for ; Fri, 30 May 2003 11:12:39 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.9/8.12.9) with ESMTP id h4UIC3bl013425; Fri, 30 May 2003 14:12:03 -0400 (EDT) Message-ID: <3ED79F1F.6070703@oceana.com> Date: Fri, 30 May 2003 14:12:47 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Cyrus Daboo CC: IMAP Extensions WG Subject: Re: New ANNOTATEMORE draft References: <2147483647.1053517397@[10.0.1.10]> 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 Daboo wrote: > > 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-03.txt > Pages : 17 > Date : 2003-5-20 From section 7: "If a client attempts to store or retrieve a shared annotation on a READ-ONLY mailbox, the server MUST respond with a NO response." Is there a reason why I shouldn't be able to fetch a shared annotation on a READ-ONLY mailbox? -- 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 h4LFh5AF037114 for ; Wed, 21 May 2003 08:43:05 -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 h4LFh5uH037113 for ietf-imapext-bks; Wed, 21 May 2003 08:43:05 -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.9/8.12.8) with ESMTP id h4LFh3AF037108 for ; Wed, 21 May 2003 08:43:04 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id LAA06958 for ; Wed, 21 May 2003 11:39:26 -0400 (EDT) Date: Wed, 21 May 2003 11:43:17 -0400 From: Cyrus Daboo To: IMAP Extensions WG Subject: New ANNOTATEMORE draft Message-ID: <2147483647.1053517397@[10.0.1.10]> X-Mailer: Mulberry/3.1.0b1 (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: 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-03.txt Pages : 17 Date : 2003-5-20 The ANNOTATEMORE extension to the Internet Message Access Protocol [IMAP4] permits clients and servers to maintain 'metadata' on IMAP4 servers. This document describes two 'profiles' for mailbox and server metadata. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-daboo-imap-annotatemore-03.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-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-daboo-imap-annotatemore-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4LCYsAF024314 for ; Wed, 21 May 2003 05:34: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 h4LCYslY024313 for ietf-imapext-bks; Wed, 21 May 2003 05:34:54 -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.9/8.12.8) with ESMTP id h4LCYqAF024308 for ; Wed, 21 May 2003 05:34:53 -0700 (PDT) (envelope-from tss@iki.fi) Received: by oma.irssi.org (Postfix, from userid 1000) id 1561D5C896C6; Wed, 21 May 2003 15:34:53 +0300 (EEST) Subject: Re: I-D ACTION:draft-ietf-imapext-annotate-07.txt From: Timo Sirainen To: ietf-imapext@imc.org In-Reply-To: <200305211210.IAA16043@ietf.org> References: <200305211210.IAA16043@ietf.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1053520492.28384.5.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 21 May 2003 15:34:52 +0300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > In some cases, servers may be able to offer annotations on some > mailboxes and not others. For mailboxes that cannot have > annotations associated with them, the server MUST return an > "ANNOTATESIZE" response with a value of "0" (zero) during the SELECT > or EXAMINE command for that mailbox. Clients MUST NOT attempt to > fetch or store annotations on any messages in a mailbox for which > the "ANNOTATESIZE" response was zero. What if I want read-only annotation support? I think ANNOTATESIZE 0 should mean that client must not attept to store annotations, but it may try fetching shared annotations. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4LCAgAF022946 for ; Wed, 21 May 2003 05:10:42 -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 h4LCAgR7022945 for ietf-imapext-bks; Wed, 21 May 2003 05:10:42 -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 h4LCAfAF022940 for ; Wed, 21 May 2003 05:10:41 -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 IAA16043; Wed, 21 May 2003 08:10:41 -0400 (EDT) Message-Id: <200305211210.IAA16043@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-07.txt Date: Wed, 21 May 2003 08:10:40 -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-07.txt Pages : 22 Date : 2003-5-20 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-07.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-07.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-07.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-5-20123707.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-annotate-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-annotate-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-20123707.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 h4L2BxAF068420 for ; Tue, 20 May 2003 19:11: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 h4L2BxkM068419 for ietf-imapext-bks; Tue, 20 May 2003 19:11:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4L2BvAF068414 for ; Tue, 20 May 2003 19:11:57 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id 3D301813E6D; Tue, 20 May 2003 19:12:00 -0700 (PDT) Received: from dev2.promeetium.com (adsl-67-123-208-210.dsl.lsan03.pacbell.net [67.123.208.210]) by DrPepper (Postfix) with ESMTP id F0FCC80D166; Tue, 20 May 2003 19:11:57 -0700 (PDT) From: Michael Fair Organization: DaClubhouse To: Timo Sirainen , ietf-imapext@imc.org Subject: Re: Foreknowledge versus pipelines Date: Tue, 20 May 2003 19:07:58 -0700 User-Agent: KMail/1.5.1 References: <014901c31d95$3a415a80$d1d07b43@cocacola> <015401c31f05$28c061e0$d1d07b43@cocacola> <1053463140.1214.322.camel@hurina> In-Reply-To: <1053463140.1214.322.camel@hurina> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200305201907.59220.michael@daclubhouse.net> X-Spam-Status: No, hits=-32.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_KMAIL version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tuesday 20 May 2003 01:39 pm, Timo Sirainen wrote: > On Tue, 2003-05-20 at 22:22, Michael Fair wrote: > > Could we achieve the same result by having the server dump the > > queue and then /dev/null the rest of the incoming queue data > > and then once that's finished return a "NO" to the client > > citing the error? > > Currently my server just disconnects the client if it tries to use too > large literal+ size. I don't think it's a good idea to allow clients to > say "hey, I'll send you 2 gigabytes of data, start reading" especially > before logging in. What's to stop a client from doing that now? S: * Hello Welcome to IMAP C: 1 a C: 2 a C: 3 a ..... Repeat 2G worth ..... The result is the same - it's just less explicit about its intentions. > How about specifying a limit for which you can use literal+? So that if > you send less data than eg. 8192 bytes, you can safely send it, but for > anything more you'd have to use regular literals which server can > reject. I'll have to read up on literal+ to understand what it does and how it behaves before I can really comment. If we are going to refuse a client for too much data before they start sending it, then I think we should explicitly tell them that it's clear to send somehow. I'm thinking a client must wait till it receives a response from the server which can be "+", "NO" or "BAD". If "+" the client can send the data. Once the number of octects specified by the client for the CQUEUE is reached, the buffer closes and if the buffer does not end in a \r\n it is a syntax error and is responded with "BAD" immediately. No further data is read by the server until the CQUEUE is finished or until a command in the queue that needs more input is reached. > > If we fix the octet counts so that server announces a max octet > > buffer which cannot be exceeded, and the client announces how > > much data it is submitting, the last two octets of which must > > be \r\n (the end of a command), would that satisfy the concerns > > that you have over this causing problems for generic usage? > > No, I'm thinking there could be some more subtle problems when some of > the commands in the group changes state in some way. My server currently > trashes all buffered input after logging in since the client's socket is > transferred to another process, but maybe I should fix that since it's > not fully IMAP compliant.. The full intent of this is to allow the client to optimistically "guess" a valid command path to go from HELLO to AUTHENTICATED. I expect clients might want to cache the command chain that worked and replay it whenever they log in for that account. Each command either succeeds, or the whole process stops. Each command is executed in order. This way the client progresses through the various states without stopping to check the environment (unless the chain fails of course). So this leads me to: S: * Hello welcome to IMAP C: 1 CAPABILITY S: 1 OK CAPABILITY CQUEUE (8192) C: 2 CQUEUE (111) S: + C: 3 VHOST (fqdn.example.com) C: 4 LANGUAGE (new_lang) C: 5 STARTTLS C: 6 AUTHENTICATE PLAIN C: 7 SELECT INBOX ... Rest as before but selecting the INBOX at the very end of the chain ... And for failures: S: * Hello welcome to IMAP C: 1 CAPABILITY S: 1 OK CAPABILITY CQUEUE (8192) C: 2 CQUEUE (9999) S: 2 NO Too much data S: * Hello welcome to IMAP C: 1 CAPABILITY S: 1 OK CAPABILITY CQUEUE (8192) C: 2 CQUEUE (11) S: + C: 3 VHOST (fqdn.example.com) S: 2 BAD Buffer does not end on a newline ... Server then should discard everything up to the next \r\n lest it choke on bad input ... > > > > As with the GROUP proposal, as bonus points, there would > > > > be an optional "TRANSACTION" parameter which would have > - etc. Until the rest of the command has been settled on I'm removing this from the list unless someone else would like to take a stab at clearly defining the semantics. If someone does want to take it on, for the most part, it should be sufficient to follow SQL database semantics for this in regards to simoultaneous access - CQUEUE with TRANSACTION could lock all writes to the mail store until it completed (most likely responding with "NO Transaction in progress" for any write operations until the QUEUE completed. If a command should fail, then the mail store should be message data and state identical to what it was before, and the session should be in whatever state it was in prior to the CQUEUE command. A more advanced server could parse through the command structure and build a list of object locks it would need prior to starting, would then lock those objects (or fail if it couldn't obtain such locks), and execute the commands. Any other client wanting to operate on other non-locked objects could be allowed to do so, attempting to write to a locked object should fail instantly to notify the client that the data is potentially about to change and it should fetch an update. Reading locked objects might be a blocking operation until the transaction completes, or might be refused pending transaction completion. I don't know exactly what all the details for the most useful operation behaviors would be - or even why it might be useful, so until there is a clearer use case and understanding of the mail store and session states as transactional creatures I'll withdraw it from the table. -- Michael -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4KKd3AF058043 for ; Tue, 20 May 2003 13:39:03 -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 h4KKd3l4058042 for ietf-imapext-bks; Tue, 20 May 2003 13:39:03 -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.9/8.12.8) with ESMTP id h4KKcxAF058035 for ; Tue, 20 May 2003 13:39:01 -0700 (PDT) (envelope-from tss@iki.fi) Received: by oma.irssi.org (Postfix, from userid 1000) id 893A25C896C6; Tue, 20 May 2003 23:39:00 +0300 (EEST) Subject: Re: Foreknowledge versus pipelines From: Timo Sirainen To: ietf-imapext@imc.org In-Reply-To: <015401c31f05$28c061e0$d1d07b43@cocacola> References: <014901c31d95$3a415a80$d1d07b43@cocacola> <1053450844.1218.249.camel@hurina> <015401c31f05$28c061e0$d1d07b43@cocacola> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1053463140.1214.322.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 20 May 2003 23:39:00 +0300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 2003-05-20 at 22:22, Michael Fair wrote: > Could we achieve the same result by having the server dump the > queue and then /dev/null the rest of the incoming queue data > and then once that's finished return a "NO" to the client > citing the error? Currently my server just disconnects the client if it tries to use too large literal+ size. I don't think it's a good idea to allow clients to say "hey, I'll send you 2 gigabytes of data, start reading" especially before logging in. How about specifying a limit for which you can use literal+? So that if you send less data than eg. 8192 bytes, you can safely send it, but for anything more you'd have to use regular literals which server can reject. So: 1 cgroup {40+} 2 capability 3 starttls 4 authenticate plain .. 10 cgroup {1000000} 10 NO Too much data > If we fix the octet counts so that server announces a max octet > buffer which cannot be exceeded, and the client announces how > much data it is submitting, the last two octets of which must > be \r\n (the end of a command), would that satisfy the concerns > that you have over this causing problems for generic usage? No, I'm thinking there could be some more subtle problems when some of the commands in the group changes state in some way. My server currently trashes all buffered input after logging in since the client's socket is transferred to another process, but maybe I should fix that since it's not fully IMAP compliant.. > > > As with the GROUP proposal, as bonus points, there would > > > be an optional "TRANSACTION" parameter which would have > > > a server revert to the same state prior to executing > > > the CQUEUE chain. > > > > No, even if server used a database capable of transactions for storing > > messages this would get complex. > > I should have been clearer: TRANSACTION is an optional server > implementation choice. It is an addon to CQUEUE not part of it. > It was never intended that any servers had to implement it. > The only other option would be to omit the possibility entirely > which I felt would be somewhat of an oversight. If you specify it, you'll have to specify exactly what it does. "revert to original state" isn't very exact. For example: - Does any other session see the changes before transaction is complete? (No, or it breaks really badly) - Client must be able to revert it's own understanding of the server state as well. - What happens if there's external updates while processing the transaction? Should server just not announce those (could be difficult), or how would client know what the original state looked like? For example you do EXPUNGE and the next command fails, server reverts the EXPUNGE but not the few pending EXPUNGEs that weren't yet announced to client. Does client now have any idea what sequence number is what? - etc. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4KJM5AF053712 for ; Tue, 20 May 2003 12:22:05 -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 h4KJM5PU053711 for ietf-imapext-bks; Tue, 20 May 2003 12:22:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4KJM3AF053706 for ; Tue, 20 May 2003 12:22:03 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id 1192C8113E5; Tue, 20 May 2003 12:22:04 -0700 (PDT) Received: from cocacola (adsl-67-123-208-209.dsl.lsan03.pacbell.net [67.123.208.209]) by DrPepper (Postfix) with ESMTP id 8DAC480D166; Tue, 20 May 2003 12:22:02 -0700 (PDT) Message-ID: <015401c31f05$28c061e0$d1d07b43@cocacola> From: "Michael Fair" To: "Timo Sirainen" , References: <014901c31d95$3a415a80$d1d07b43@cocacola> <1053450844.1218.249.camel@hurina> Subject: Re: Foreknowledge versus pipelines Date: Tue, 20 May 2003 12:22:30 -0700 Organization: DaClubhouse MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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 X-Spam-Status: No, hits=-10.4 required=5.0 tests=QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,REFERENCES version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > On Mon, 2003-05-19 at 02:28, Michael Fair wrote: > > S: * Hello Welcome to the IMAP server > > S: * CAPABILITY CQUEUE STARTTLS VHOST ....... > > C: tag1 CQUEUE (4) > > C: tag2 VHOST (fqdn.example.com) > > C: tag3 LANGUAGE (new_lang) > > C: tag4 STARTTLS > > C: tag5 AUTHENTICATE PLAIN > > This isn't too easy to implement. At the very least server should be > able to abort the whole queue if it doesn't like it for some reason, for > example because it thinks it has too much data in it. I think that would be a fine idea. Part of the reason I put (4) in the CQUEUE command was to give the server the opportunity to allocate an array of strings. I then figured it would fill the array and then execute the commands. Perhaps this wasn't the right approach. What if the server CAPABILITY response provided a CQUEUE maxoctets parameter which will gave the maximum number of octets including the tags and \r\n that the server can store. So the CAPABILITY response might read: CQUEUE (8192) If that's the case, then perhaps the initial parameter to CQUEUE the client submits should be the number of octets the client will be submitting (including \r\n and tags). So instead of CQUEUE (4) which was 4 commands it would be "tag1 CQUEUE (97)" Which would be everything from "tag2" to the "\r\n" of AUTHENTICATE (assuming I counted that right). If any characters are multibyte characters then those characters count as multiple octets. If the server should find that there is too much data, the server should dump the queue, /dev/null the rest of the incoming queue data (which is now countable by the number of octets) and then respond with "NO" giving an appropriate reason. > Still .. it would require that server reads the data into buffer before > processing any of it. And could there be literals in queue? That would > mean that server has to actually parse all the commands before executing > them. That could get tricky. > > Maybe a bit easier version would be to send the commands inside a > literal so server can just read it into buffer, and it can immediately > tell the client if there's just too much data in it (literal+ shouldn't > be allowed with it). I'm afraid I'm not too familiar with many IMAP commands. The intent was that only single line commands could be queued. And the newlines would be used as command separators. The tags were needed to identify the individual commands in the queue and would be treated as if they were executed without the CQUEUE command so should be globally unique within the session. Commands that required more than one line would be processed in turn and would fetch any extra lines at the time of execution. The server would delay parsing the command until it was time to execute it. If literal+ is an extra long one-liner, then I think if we used the octet count strategy from above there'd be no reason to keep it excluded from the list of valid commands. I don't know that the server "immediately" telling the client there's too much data is necessary. It's also very probable given how I was thinking this command would be used, that the client isn't paying attention to server responses at the time they are filling the queue. Could we achieve the same result by having the server dump the queue and then /dev/null the rest of the incoming queue data and then once that's finished return a "NO" to the client citing the error? I'm picturing that the client is going to be in two modes when it uses this command. Mode 1, is to stuff a bunch of commands in the queue, and then mode 2 is to get the results of each command and interact with any conversations it has to have to process them. If we use the byte counters I suggested above then CQUEUE could treat that many following bytes as literal data stuffing it in a single buffer and then reading from it. > Still, I'm not sure if this is a good idea. As limited in above example > it would work, but as a more generic feature it would just cause > problems. The primary motivation for this was to reduce round trips with the server during the log in process when the overall consensus is that many smaller commands is better than a generic big one. The discussion saw parallels to the MULTIAPPEND discussion (which I wasn't around for) and it seemed that an alternative that might have worked there could also work here. I had already worked on several commands that were very similar in nature to this proposal and figured that there was probably no escaping it. So the only question was is this new command only valid in the non-AUTHENTICATED state, or is it something that could be genericly useful? I'd tend towards the more generic mostly because I'm just bent that way, but if this only ended up to server the log in process it will have met the original design goals I had in mind. If we fix the octet counts so that server announces a max octet buffer which cannot be exceeded, and the client announces how much data it is submitting, the last two octets of which must be \r\n (the end of a command), would that satisfy the concerns that you have over this causing problems for generic usage? > > As with the GROUP proposal, as bonus points, there would > > be an optional "TRANSACTION" parameter which would have > > a server revert to the same state prior to executing > > the CQUEUE chain. > > No, even if server used a database capable of transactions for storing > messages this would get complex. I should have been clearer: TRANSACTION is an optional server implementation choice. It is an addon to CQUEUE not part of it. It was never intended that any servers had to implement it. The only other option would be to omit the possibility entirely which I felt would be somewhat of an oversight. I also wasn't clear enough on this when I originally submitted it, not only would the server need to support "TRANSACTION" but the client would also need to request that it wanted transaction semantics. I only saw this becoming popular in the event there developed an important use for it and the server challenges of implementing it were overcome (which they would be if there was an important enough use for it). Thanks for responding! -- Michael -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4KHEDAF048528 for ; Tue, 20 May 2003 10:14: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 h4KHEDR9048526 for ietf-imapext-bks; Tue, 20 May 2003 10:14:13 -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.9/8.12.8) with ESMTP id h4KHEAAF048498 for ; Tue, 20 May 2003 10:14:11 -0700 (PDT) (envelope-from tss@iki.fi) Received: by oma.irssi.org (Postfix, from userid 1000) id 7F9BD5C896C6; Tue, 20 May 2003 20:14:04 +0300 (EEST) Subject: Re: Foreknowledge versus pipelines From: Timo Sirainen To: ietf-imapext@imc.org In-Reply-To: <014901c31d95$3a415a80$d1d07b43@cocacola> References: <014901c31d95$3a415a80$d1d07b43@cocacola> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1053450844.1218.249.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 20 May 2003 20:14:04 +0300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 2003-05-19 at 02:28, Michael Fair wrote: > S: * Hello Welcome to the IMAP server > S: * CAPABILITY CQUEUE STARTTLS VHOST ....... > C: tag1 CQUEUE (4) > C: tag2 VHOST (fqdn.example.com) > C: tag3 LANGUAGE (new_lang) > C: tag4 STARTTLS > C: tag5 AUTHENTICATE PLAIN This isn't too easy to implement. At the very least server should be able to abort the whole queue if it doesn't like it for some reason, for example because it thinks it has too much data in it. Still .. it would require that server reads the data into buffer before processing any of it. And could there be literals in queue? That would mean that server has to actually parse all the commands before executing them. That could get tricky. Maybe a bit easier version would be to send the commands inside a literal so server can just read it into buffer, and it can immediately tell the client if there's just too much data in it (literal+ shouldn't be allowed with it). Still, I'm not sure if this is a good idea. As limited in above example it would work, but as a more generic feature it would just cause problems. > As with the GROUP proposal, as bonus points, there would > be an optional "TRANSACTION" parameter which would have > a server revert to the same state prior to executing > the CQUEUE chain. No, even if server used a database capable of transactions for storing messages this would get complex. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4INSNAF077963 for ; Sun, 18 May 2003 16:28:24 -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 h4INSNUL077962 for ietf-imapext-bks; Sun, 18 May 2003 16:28:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4INSMAF077957 for ; Sun, 18 May 2003 16:28:22 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id 55C188113E5; Sun, 18 May 2003 16:28:24 -0700 (PDT) Received: from cocacola (adsl-67-123-208-209.dsl.lsan03.pacbell.net [67.123.208.209]) by DrPepper (Postfix) with ESMTP id 9014780D166 for ; Sun, 18 May 2003 16:28:22 -0700 (PDT) Message-ID: <014901c31d95$3a415a80$d1d07b43@cocacola> From: "Michael Fair" To: Subject: Foreknowledge versus pipelines Date: Sun, 18 May 2003 16:28:45 -0700 Organization: DaClubhouse 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 X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Greetings all, So the latest developments on trying to harmonize on a design for reducing client side round trips while allowing for new pre-AUTH commands like LANGUAGE and VHOST has come down to making a decision between client foreknowledge that a particular command is actually going to be valid when it is executed and allowing a client to chain a series of commands together that the server will execute in sequence. After looking at it my self and talking it over with a couple others it has become more and more clear that the preferred approach is pipelining or command chaining. The LANGUAGE is already in implementation that expects it to be its own command, and the VHOST draft is also written with the expectation that it be its own command. The obvious downside to this is that a client has to issue these each as separate commands and for commands that can change the CAPABILITY response is forced to wait until that command is complete before moving on. This proliferation of commands demands an efficient way for clients to execute the series of them and to ensure they get executed in the proper order. Chris Newman shared with me that while discussing the MULTIAPPEND command he suggested a GROUP command that would allow a client to specify a series of commands in order. In keeping with that theme I propose a command called "CQUEUE" which would allow the client to create a "Command Queue" which would execute the commands in the queue in sequence and terminate at the first failure (defined as a "NO" or "BAD" response). Commands would be held up for execution until each prior command had finished executing. As a result the command issued need not be valid in the current CAPBILITY context. The dialog would look something like this: S: * Hello Welcome to the IMAP server S: * CAPABILITY CQUEUE STARTTLS VHOST ....... C: tag1 CQUEUE (4) C: tag2 VHOST (fqdn.example.com) C: tag3 LANGUAGE (new_lang) C: tag4 STARTTLS C: tag5 AUTHENTICATE PLAIN C: S: tag2 OK VHOST (fqdn.example.com) S: * CAPABILITY ... new capability after VHOST ... S: tag3 OK LANGUAGE (new_lang) S: tag4 OK BEGIN TLS S: tag4 OK STARTTLS successful S: * CAPABILITY ... new capability after STARTTLS ... S: + S: tag5 OK AUTHENTICATE successful S: * CAPABILITY ... new capability after AUTHENTICATE ... S: tag1 OK CQUEUE successful I've proposed changing the name to CQUEUE from GROUP because I felt a "Command Queue" was a bit more descriptive than a "Group of commands". The primary security risk preTLS is that any command issued goes in the clear. As a result it is forbidden for a client to execute a LOGIN in this manner if the client is going to attempt to establish a TLS session. As for the AUTHENTICATE command, that is different that the only revealed information is what method the client was going to request be attempted first. Knowing which authentication method a client was going to request post TLS does not reveal any information that compromises the security of the TLS session or the client's data. The client can and SHOULD monitor the execution of the command queue as the server announces its progress. If the command queue fails then the tag assigned to the failed command MUST be in the "NO" response to CQUEUE command in addition to the "NO" or "BAD" response. As with the GROUP proposal, as bonus points, there would be an optional "TRANSACTION" parameter which would have a server revert to the same state prior to executing the CQUEUE chain. -- Michael -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4HHHAAF089217 for ; Sat, 17 May 2003 10:17:10 -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 h4HHHAi5089216 for ietf-imapext-bks; Sat, 17 May 2003 10:17:10 -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 h4HHH8AF089209 for ; Sat, 17 May 2003 10:17:09 -0700 (PDT) (envelope-from mel@messagingdirect.com) Received: from messagingdirect.com (1Cust53.tnt110.lnd4.gbr.da.uu.net [62.188.174.53]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h4HHKKV32538; Sat, 17 May 2003 11:20:21 -0600 Message-ID: <3EC666F1.9BD543AC@messagingdirect.com> Date: Sat, 17 May 2003 17:44:34 +0100 From: Alexey Melnikov X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Pete Resnick CC: ietf-imapext@imc.org Subject: Re: Vienna References: 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 Resnick wrote: > I've been reminded to start early on figuring out what's going on for > the next IETF meeting, so let's do that. > > Document editors: Please provide to the list the status of your > documents. Are there open issues that will need to be discussed in > Vienna? > > Others: Are there items that you think need to be discussed in > Vienna? Do remember that LEMONADE-related items should be discussed > over there. > > I will be in Vienna either way. Let's figure out now whether we need a meeting. I will be in Vienna anyway. I should send an update revision of CONDSTORE in a week or so. Than I have some SASL documents I have to work, but I am planning to send ACL2 update before Vienna. Cheers, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html I speak for myself only, not for my employer. __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4HHErAF088927 for ; Sat, 17 May 2003 10:14: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 h4HHErO1088926 for ietf-imapext-bks; Sat, 17 May 2003 10:14:53 -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 h4HHEnAF088913 for ; Sat, 17 May 2003 10:14:52 -0700 (PDT) (envelope-from mel@messagingdirect.com) Received: from messagingdirect.com (1Cust53.tnt110.lnd4.gbr.da.uu.net [62.188.174.53]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h4HHHgV32513; Sat, 17 May 2003 11:17:48 -0600 Message-ID: <3EC61977.24CD85D1@messagingdirect.com> Date: Sat, 17 May 2003 12:13:59 +0100 From: Alexey Melnikov X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Crispin CC: Chris Newman , IMAP Extensions WG Subject: Re: SORT, THREAD and VIEW/WINDOW References: <2147483647.1052838555@nifty-jr.west.sun.com> 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: Mark Crispin wrote: > ... > My understanding of our status is: > > I) CHARTER EXTENSIONS > > SORT/THREAD is done, but will need to be blocked on I18N since it makes a > normative reference to it. > > I believe that the remaining documents that we need to complete to fufill > the charter are: > > ACL, ANNOTATE, ANNOTATEMORE, CONDSTORE, I18N > > II) NON-CHARTER EXTENSIONS. > > We also are considering: > > LISTEXT > > and may want to consider SEARCH-MULTIPLE, VHOST, and the following expired > drafts: > > QUOTA, UNSELECT > > I decided not to oppose UNSELECT any more; indeed, I recently implemented > it in my server. Cyrus server has it too. So let's do a quick last call > and get it published. I will try to publish the UNSELECT document shortly. > I vote to proceed on LISTEXT and punt on the other non-charter proposals. I agree. QUOTA will most likely be taken by LEMONADE people anyway. Cheers, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html I speak for myself only, not for my employer. __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4GBdFAF085745 for ; Fri, 16 May 2003 04:39:16 -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 h4GBdFwx085744 for ietf-imapext-bks; Fri, 16 May 2003 04:39:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from Ikkoku-Kan.Panda.COM (alex@panda.com [206.124.149.114]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4GBdEAF085738 for ; Fri, 16 May 2003 04:39:14 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from localhost (mrc@localhost) by Ikkoku-Kan.Panda.COM id EAA01598; Fri, 16 May 2003 04:39:12 -0700 (PDT) Date: Fri, 16 May 2003 04:39:12 -0700 (PDT) From: Mark Crispin To: IMAP Extensions WG Subject: LAST CALL: SORT AND THREAD EXTENSION Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As we agreed in Atlanta, now that the IMAP i18n document is an I-D this is a last call for draft-ietf-imapext-sort-13.txt prior to it being submitted to the IESG. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4GBPUAF085398 for ; Fri, 16 May 2003 04:25:30 -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 h4GBPUcK085397 for ietf-imapext-bks; Fri, 16 May 2003 04:25:30 -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 h4GBPSAF085391 for ; Fri, 16 May 2003 04:25:29 -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 HAA19464; Fri, 16 May 2003 07:22:23 -0400 (EDT) Message-Id: <200305161122.HAA19464@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-sort-13.txt Date: Fri, 16 May 2003 07:22:23 -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 : INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSION Author(s) : M. Crispin, K. Murchison Filename : draft-ietf-imapext-sort-13.txt Pages : 19 Date : 2003-5-15 This document describes the base-level server-based sorting and threading extensions to the [IMAP] protocol. These extensions provide substantial performance improvements for IMAP clients which offer sorted and threaded views. A server which supports the base-level SORT extension indicates this with a capability name which starts with 'SORT'. Future, upwards-compatible extensions to the SORT extension will all start with 'SORT', indicating support for this base level. A server which supports the THREAD extension indicates this with one or more capability names consisting of 'THREAD=' followed by a supported threading algorithm name as described in this document. This provides for future upwards-compatible extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-13.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-sort-13.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-sort-13.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-5-15150157.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-sort-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-sort-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-15150157.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 h4EMkDAF038112 for ; Wed, 14 May 2003 15:46: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 h4EMkDIF038111 for ietf-imapext-bks; Wed, 14 May 2003 15:46:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4EMkCAF038106 for ; Wed, 14 May 2003 15:46:12 -0700 (PDT) (envelope-from Chris.Newman@Sun.COM) Received: from esunmail ([129.147.58.198]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4EMkEY9016169 for ; Wed, 14 May 2003 16:46:14 -0600 (MDT) Received: from xpa-fe1 ([129.147.58.198]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HEW00IYAF594M@edgemail1.Central.Sun.COM> for ietf-imapext@imc.org; Wed, 14 May 2003 16:43:58 -0600 (MDT) Received: from nifty-jr.west.sun.com ([129.153.12.95]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HEW0004RF58FU@mail.sun.net> for ietf-imapext@imc.org; Wed, 14 May 2003 16:43:57 -0600 (MDT) Date: Wed, 14 May 2003 15:41:29 -0700 From: Chris Newman Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-00.txt In-reply-to: <1052925231.6863.106.camel@hurina> To: Timo Sirainen , ietf-imapext@imc.org Message-id: <2147483647.1052926889@nifty-jr.west.sun.com> MIME-version: 1.0 X-Mailer: Mulberry/3.0.3 (Mac OS X) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-message-flag: Outlook: the best virus distribution system around References: <200305131200.IAA05283@ietf.org> <020d01c3197f$dd7cf200$d1d07b43@cocacola> <2147483647.1052834224@nifty-jr.west.sun.com> <1052925231.6863.106.camel@hurina> Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: begin quotation by Timo Sirainen on 2003/5/14 18:13 +0300: > Well, this is somewhat aesthetic, but I think untagged LANGUAGE reply is > a bit badly designed. "If there's one language, that's what got > selected. if there's multiple ones, nothing was selected but you should > select one of them". Kind of messy. I agree that the design of the LANGUAGE reply is messy. But it is also unambiguous as defined in the spec, so I don't see a reason to change it. > Why not have work like COMPARATOR reply? Because they were designed by different people. > Or maybe give the selected language as resp-text-code in tagged > OK reply? That would be inconsistent with other IMAP commands that adjust server state. So I don't see it as better from an aesthetic point of view. > I think he means something like: > > 1 SETANNOTATION "/mailbox/{ietf-imapext}/alias" ("value.priv" "IMAP > Extensions") 1 OK > 2 LIST (ANNOTATION ("alias")) "" % > * LIST (("ANNOTATION" ("alias" ("value.shared" "Incoming Messages")))) "/" > "INBOX" * LIST (("ANNOTATION" ("alias" ("value.priv" "IMAP Extensions")))) > "/" "ietf-imapext" 2 OK > > INBOX and maybe some other site global mailbox names could be predefined > for multiple languages which would be used after client has selected > language. So maybe the ANNOTATEMORE extension should define a namespace for localized mailbox names? Sounds reasonable to me. > Looks like LISTEXT and ANNOTATEMORE don't play together currently. > Should they? I'd like the possibility to do above. I concur. > Other issues in the draft: > > "Clients MUST re-issue the LANGUAGE command once a security layer is > active" is mentioned only in "security considerations. I think it should > be mentioned in section 3.2 also. > > You mention only THREAD=ORDEREDSUBJECT, but THREAD=REFERENCES also does > sorting by subject. OK. Will fix these two in the next version. - Chris Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4EK0lAF033106 for ; Wed, 14 May 2003 13:00:47 -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 h4EK0kKD033105 for ietf-imapext-bks; Wed, 14 May 2003 13:00:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4EK0jAF033076 for ; Wed, 14 May 2003 13:00:45 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id 28391812C58; Wed, 14 May 2003 13:00:47 -0700 (PDT) Received: from cocacola (adsl-67-123-208-209.dsl.lsan03.pacbell.net [67.123.208.209]) by DrPepper (Postfix) with ESMTP id 9D0F48113E5; Wed, 14 May 2003 13:00:45 -0700 (PDT) Message-ID: <043a01c31a52$2cdfa2c0$d1d07b43@cocacola> From: "Michael Fair" To: "Mark Crispin" Cc: "Chris Newman" , References: <200305131200.IAA05283@ietf.org> <020d01c3197f$dd7cf200$d1d07b43@cocacola> <2147483647.1052834224@nifty-jr.west.sun.com> <040101c31a45$f8d54d60$d1d07b43@cocacola> Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-00.txt Date: Wed, 14 May 2003 12:51:13 -0700 Organization: DaClubhouse 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 X-Spam-Status: No, hits=-9.8 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > On Wed, 14 May 2003, Michael Fair wrote: > > LANGUAGE, VHOST (fqdn.example.com), STARTTLS, AUTHENTICATE (AUTH=plain) > > This is a contrived example. > > It's impossible to pipeline anything after STARTTLS. In fact, it's > impossible to even think about transmitting anything after STARTTLS, since > you need to do the key exchange negotiation before you have the physical > capability of transmitting the AUTHENTICATE. Sorry I was confusing the existing mechansims with the work I was doing on ECAPABILITY which was attempting to reduce round trips by asking the client for information as it needed it (thus STARTTLS would negotiate and once completed the server would immediately begin the AUTH conversation (lest the method requested wasn't supported and would therefore stop, requiring the client to issue a CAPABILTIY to find out what methods were supported). Even barring that ability, just drop the AUTH command off the end and the example still holds. The point is that pipelining and foreknowledge are mutually exclusive for most commands prior to AUTH because most of the important pre-auth commands change the CAPABILITY response. As a result, a client must issue a command, wait for the response, get the new capability list, issue the next command, wait, issue the next command, wait. A more detailed state progress of the above example as currently implemented by the proposed solutions: 1) Client shows up at server gets hello and requests CAPABILITY server sends LANGUAGE VHOST (but not STARTTLS, AUTH, or LOGIN) 2) Client issues the LANGUAGE command 3) Client issues the VHOST command ***** Client waits ***** 4) Client gets new CAPABILTIY and the server now issues LANGUAGE VHOST STARTTLS LOGIN and AUTH (but not AUTH plain) 5) Client issues STARTTLS and does the negotation ***** Client waits ***** 6) Client gets the new CAPABILTIY and the server now issues LANGUAGE VHOST STARTTLS LOGIN and AUTH including AUTH plain 7) Client issues AUTH using the plain mechanism ***** Client waits ***** 8) Client gets the new CAPABILTIY and is now ready to begin the real IMAP session work Same example with the method I was envisioning: 1) Client shows up at server gets hello 2) Client issues a new version of PIPELINE (with ordering and negotiation support) with the following chain: LANGUAGE, VHOST (fqdn.example.com), STARTTLS, AUTHENTICATE (AUTH=plain) ***** Client watches responses as the server executes each ***** ***** Client waits for BAD, NO, or STARTTLS ***** 3) Client does STARTTLS negotiation ***** Client waits for BAD, NO, or AUTH negotiation ***** If the client receives BAD or NO it knows what state it is in because the server issued and OK for every command that succeeded. Once an error occurs in the command chain processing of the chain stops. -- Michael -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4EJSgAF030629 for ; Wed, 14 May 2003 12:28:42 -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 h4EJSgcc030628 for ietf-imapext-bks; Wed, 14 May 2003 12:28:42 -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.9/8.12.8) with ESMTP id h4EJSfAF030620 for ; Wed, 14 May 2003 12:28:41 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout2.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h4EJSZg9031781; Wed, 14 May 2003 12:28:40 -0700 Received: from Shimo-Tomobiki.Panda.COM (D-128-95-18-95.dhcp4.washington.edu [128.95.18.95]) (authenticated bits=0) by smtp.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h4EJSYcx028909 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 14 May 2003 12:28:35 -0700 Date: Wed, 14 May 2003 12:28:39 -0700 (Pacific Daylight Time) From: Mark Crispin To: Michael Fair cc: Chris Newman , ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-00.txt In-Reply-To: <040101c31a45$f8d54d60$d1d07b43@cocacola> Message-ID: References: <200305131200.IAA05283@ietf.org> <020d01c3197f$dd7cf200$d1d07b43@cocacola> <2147483647.1052834224@nifty-jr.west.sun.com> <040101c31a45$f8d54d60$d1d07b43@cocacola> 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 Wed, 14 May 2003, Michael Fair wrote: > LANGUAGE, VHOST (fqdn.example.com), STARTTLS, AUTHENTICATE (AUTH=plain) This is a contrived example. It's impossible to pipeline anything after STARTTLS. In fact, it's impossible to even think about transmitting anything after STARTTLS, since you need to do the key exchange negotiation before you have the physical capability of transmitting the AUTHENTICATE. I'm finding it very difficult to read your messages. Could you please get to the point in a more consise fashion? -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4EJSHAF030552 for ; Wed, 14 May 2003 12:28:17 -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 h4EJSHii030550 for ietf-imapext-bks; Wed, 14 May 2003 12:28: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.9/8.12.8) with ESMTP id h4EJSGAF030543 for ; Wed, 14 May 2003 12:28:16 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout3.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h4EJSFSL004194; Wed, 14 May 2003 12:28:15 -0700 Received: from Shimo-Tomobiki.Panda.COM (D-128-95-18-95.dhcp4.washington.edu [128.95.18.95]) (authenticated bits=0) by smtp.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h4EJSEcx028884 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 14 May 2003 12:28:15 -0700 Date: Wed, 14 May 2003 12:28:19 -0700 (Pacific Daylight Time) From: Mark Crispin To: Michael Fair cc: IMAP Extensions WG Subject: Re: Vienna In-Reply-To: <039d01c319d7$0e6b9360$d1d07b43@cocacola> Message-ID: References: <039d01c319d7$0e6b9360$d1d07b43@cocacola> 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: I can't wade through your long message to answer it point-by-point, but here is a pedagogical explanation: LEMONADE has identified a need to send messages containing content from a mailbox in an IMAP server. It is costly, especially for embedded devices, to fetch the content from an IMAP server just to send it back out to an SMTP server. On the other hand, if the message submission server is not co-located with the IMAP server, then the submission server must have full IMAP access to the user's account on the IMAP server. This is perceived as a security risk. Consequently, it was proposed to use an IMAP server as a mesasge submission agent, by submitting the message with "include such-and-such text from such-and-such mailbox" pointers, which the IMAP server will acquire locally. As a counter proposal, I suggest a means by which an IMAP client can create a limited access token, which can access only the necessary data but not any other data. This limited access token can be used by the message submission server to obtain the data from the IMAP server without giving the message submission server access to any other user data. This also permits the message submission server to access data from multiple IMAP servers. Furthermore, it does not create a situation in which IMAP duplicates the functionality of other protocols. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4EIXJAF027717 for ; Wed, 14 May 2003 11:33: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 h4EIXJD4027716 for ietf-imapext-bks; Wed, 14 May 2003 11:33:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4EIXDAF027710 for ; Wed, 14 May 2003 11:33:18 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id 772C5812C58; Wed, 14 May 2003 11:33:14 -0700 (PDT) Received: from cocacola (adsl-67-123-208-209.dsl.lsan03.pacbell.net [67.123.208.209]) by DrPepper (Postfix) with ESMTP id 8C2B28113E5; Wed, 14 May 2003 11:33:11 -0700 (PDT) Message-ID: <040101c31a45$f8d54d60$d1d07b43@cocacola> From: "Michael Fair" To: "Chris Newman" , References: <200305131200.IAA05283@ietf.org> <020d01c3197f$dd7cf200$d1d07b43@cocacola> <2147483647.1052834224@nifty-jr.west.sun.com> Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-00.txt Date: Wed, 14 May 2003 11:23:51 -0700 Organization: DaClubhouse 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 X-Spam-Status: No, hits=-10.4 required=5.0 tests=QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,REFERENCES version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > begin quotation by Michael Fair on 2003/5/13 11:45 -0700: > > Is there anything else anyone else saw that seems to make > > this whole client side CAPABILITY approach to items like > > VHOST and LANGUAGE (and perhaps a CHARSET could be added > > to the list for UTF-8 support?) a bad idea? > > We discussed the issue of client capabilities at the informal > IMAPEXT BOF at > the last IETF and there was a rough consensus in the room (of about 20 > IMAP developers many of whom write code) which opposed the idea of a > combined client capability mechanism. The rough consensus of the > room appeared to favor separate commands which could be pipelined > rather than a combined command. Now the mailing list can override > that consensus, but I'd need to see stronger support than I've seen > to date. No one prior to you had ever mentioned that. Wish I would have known would have saved me some trouble. :) Creating a command pipeline works for me. I actually like that even more, but it seems to break with what a few ppl have said to me earlier in that they really don't like the idea of a client trying a command to find out if it will work or not. The general premise is that a client should always have foreknowledge that the command they want to use is valid. But there's a problem with this, since pretty much every commonly used command prior to authenticating has the potential to change the "environment" (read CAPABILITY response) then pipelining and foreknowledge are somewhat mutually exclusive in that using one denies the other. As an example, a client wants to execute: LANGUAGE, VHOST (fqdn.example.com), STARTTLS, AUTHENTICATE (AUTH=plain) Even though this might be a very valid sequence there's no way for a client to know whether or not this will work without stopping at each point and waiting for the response. STARTTLS might not be available till after VHOST and AUTH plain might further not be available until after STARTTLS. I also understood that servers can reorder commands so depending on the order executed the above means different things and it's success rate differs depending on the order executed. I personally prefer pipelining much more than foreknowledge on principal because the errors generated by usage of this nature uses a very minor number of resources in comparison to the possible efficiency gains and 9 times out of 10 the client is just checking to make sure the server does something that already has a more than reasonable chance at succeeding. The only con is that it demands proper failure behavior which should be, but is not always what's out there. However, protecting clients that don't check return codes and servers that don't generate them by not implementing a feature that could give trmendous efficiency gains for those that do the proper thing seems like it's asking for trouble. Since the commands will succeed the majority of the time, it seems wasteful to cause the login process to be longer just for a psuedo-gaurantee that it will succeed. This is further compounded by things admins can do to tain their environmnent. Clients might be able to be configured for, or discover and remember, success "paths" for the servers they access and not be forced to stop and wait at each step every login. If clients/servers all do some basic error checking then pipelining would simply trip over the error codes and the clients can issue the proper commands to get the info to determine how to proceed. Of course I believe that the client would need a way to specify the order in which the commands get executed (lest the command fail otherwise). I can see the merits of both approaches, but it seems that the consensus is that reducing round trips is important. The only way I see that happening is by giving up the notion that a client should always have foreknowledge that the commands they are issuing are valid when it comes to being able to pipeline commands. Instead, it shoud be that a client can try an optimistic pipeline expecting a chain to succeed and the pipeline should stop executing at the first failure. Assuming that people can live with that, I think the multiple commands with a pipeline provision is the best route as well. > In addition, there is deployed running code for the LANGUAGE extension > (implemented to the previous draft). As a result I am opposed to aesthetic > changes to the LANGUAGE extension as documented. Proposed changes need to have > a substantive technical justification. The only technical justification was discussed above. > > 2) In specific response to the LANGUAGE feature set as > > described, I noticed it is missing in-band administration > > for assigning the various LANGUAGE translations of folders. > > > > 3) Could this be extended to allow all folders to be > > represented in multiple languages by way of some kind > > of "ALIAS" command that could install a language alias > > for folders? This would probably require the equivalent > > of a RENAME ACL. This would anticipate a resolution > > to the lack of character set choice currently present. > > (For instance via a client capability mentioned above.) > > Please make a concrete proposal if you want to discuss these > issues. I'm not sure exactly what you're asking so it would > be easier to discuss if I could see something concrete. > > > 4) Since languages are somewhat tied to character sets, > > The selected character set is always UTF-8, so there is no issue. I was basing the character set issues off of section 5.2. Ok so 2,3 and 4 were all related, and I might be generalizing a feature that's not actually in the draft. Timo's SETANNOTATION example of creating aliases for INBOX and ietf-imapext folders were an example of how this might be used but I wasn't expecting it to be used to create aliases in the same language (though I think that would be useful). Further, the only folders that can currently be "localized" are the folders in NAMESPACE. There might be a technical reason for that. What I was envisioning was a way to name any mailbox in many languages by assigning several language specific aliases. This was primarily to facilitate "Shared Folders" in organizations where people who use multiple languages share the same folder. For instance, the folder "Technical Support" would be a general box for incoming issues in multiple languages. The support staff reading this mailbox speak different languages, and as a result would like the "Technical Support" folder to display its name in their native language. If they could attach a language specific alias for the foldername, they could do this. This would also satisfy the method by which namespace translations would be set. They would be treated just like any other folder for the purpose of setting the translation to begin with. Secondarily, if assigning aliases to arbitrary folders is not technically feasible for some reason, then there should still be a defined method to set the aliases for the folders returned by NAMESPACE. While the current draft describes how the server should format and respond to a client to provide the NAMESPACE response with translations, it doesn't specify any method to set those translations in the first place. This may just be a "server must be preconfigured" thing, but it seems to me that there should be an IMAP command for this. I do not feel the slightest bit qualified to recommend a method to set the translations. Timo's SETANNOTATION seemed like a decent enough approach however it would require the addition of a language parameter. Which brings up another question, are the language names going to support the localized variants like en_US and fr_CA? If so, does it need any special mentioning? For instance a phrase like "localized variants of a language if not explicity supported may match on either a non-localized version of the same language or if that's not available, then another variant of the same language. If there are no variants of the language supported by the server (localized or not) then the match SHOULD fail." I don't know if it really matters, but I expect it'll come up sooner or later. -- Michael -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4EFHdAF015844 for ; Wed, 14 May 2003 08:17: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 h4EFHdWP015843 for ietf-imapext-bks; Wed, 14 May 2003 08:17:39 -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.9/8.12.8) with ESMTP id h4EFHcAF015837 for ; Wed, 14 May 2003 08:17:38 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id LAA29125; Wed, 14 May 2003 11:12:32 -0400 (EDT) Date: Wed, 14 May 2003 11:16:38 -0400 From: Cyrus Daboo To: Chris Newman , IMAP Extensions WG Subject: Re: SORT, THREAD and VIEW/WINDOW Message-ID: <2147483647.1052910998@[63.163.82.24]> In-Reply-To: <2147483647.1052838555@nifty-jr.west.sun.com> References: <2147483647.1052838555@nifty-jr.west.sun.com> X-Mailer: Mulberry/3.1.0b1 (Mac OS/PPC) 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 Chris, --On Tuesday, May 13, 2003 3:09 PM -0700 Chris Newman wrote: | So I am now willing to see SORT and THREAD move forward without VIEW | despite my scalability concerns. Given how busy and resource limited the | IMAP community appears to be at the moment, I further propose we drop the | VIEW command from the list of WG deliverables we must complete prior to | WG closure (but let's not bother changing the charter until we've | finished the other deliverables). I fully agree with this position. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4EFDsAF015755 for ; Wed, 14 May 2003 08:13: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 h4EFDsPU015754 for ietf-imapext-bks; Wed, 14 May 2003 08:13:54 -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.9/8.12.8) with ESMTP id h4EFDpAF015749 for ; Wed, 14 May 2003 08:13:52 -0700 (PDT) (envelope-from tss@iki.fi) Received: by oma.irssi.org (Postfix, from userid 1000) id 3A7755C896C6; Wed, 14 May 2003 18:13:51 +0300 (EEST) Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-00.txt From: Timo Sirainen To: ietf-imapext@imc.org In-Reply-To: <2147483647.1052834224@nifty-jr.west.sun.com> References: <200305131200.IAA05283@ietf.org> <020d01c3197f$dd7cf200$d1d07b43@cocacola> <2147483647.1052834224@nifty-jr.west.sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1052925231.6863.106.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 14 May 2003 18:13:51 +0300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 2003-05-13 at 23:57, Chris Newman wrote: > In addition, there is deployed running code for the LANGUAGE extension > (implemented to the previous draft). As a result I am opposed to aesthetic > changes to the LANGUAGE extension as documented. Proposed changes need to have > a substantive technical justification. Well, this is somewhat aesthetic, but I think untagged LANGUAGE reply is a bit badly designed. "If there's one language, that's what got selected. if there's multiple ones, nothing was selected but you should select one of them". Kind of messy. Why not have work like COMPARATOR reply? Or maybe give the selected language as resp-text-code in tagged OK reply? > > 2) In specific response to the LANGUAGE feature set as > > described, I noticed it is missing in-band administration > > for assigning the various LANGUAGE translations of folders. > > > > 3) Could this be extended to allow all folders to be > > represented in multiple languages by way of some kind > > of "ALIAS" command that could install a language alias > > for folders? This would probably require the equivalent > > of a RENAME ACL. This would anticipate a resolution > > to the lack of character set choice currently present. > > (For instance via a client capability mentioned above.) > > Please make a concrete proposal if you want to discuss these issues. I'm not > sure exactly what you're asking so it would be easier to discuss if I could see > something concrete. I think he means something like: 1 SETANNOTATION "/mailbox/{ietf-imapext}/alias" ("value.priv" "IMAP Extensions") 1 OK 2 LIST (ANNOTATION ("alias")) "" % * LIST (("ANNOTATION" ("alias" ("value.shared" "Incoming Messages")))) "/" "INBOX" * LIST (("ANNOTATION" ("alias" ("value.priv" "IMAP Extensions")))) "/" "ietf-imapext" 2 OK INBOX and maybe some other site global mailbox names could be predefined for multiple languages which would be used after client has selected language. Looks like LISTEXT and ANNOTATEMORE don't play together currently. Should they? I'd like the possibility to do above. Other issues in the draft: "Clients MUST re-issue the LANGUAGE command once a security layer is active" is mentioned only in "security considerations. I think it should be mentioned in section 3.2 also. You mention only THREAD=ORDEREDSUBJECT, but THREAD=REFERENCES also does sorting by subject. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4E5HNAF059800 for ; Tue, 13 May 2003 22:17: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 h4E5HNVr059799 for ietf-imapext-bks; Tue, 13 May 2003 22:17:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4E5HLAF059793 for ; Tue, 13 May 2003 22:17:21 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id DABE5813F13; Tue, 13 May 2003 22:17:24 -0700 (PDT) Received: from cocacola (adsl-67-123-208-209.dsl.lsan03.pacbell.net [67.123.208.209]) by DrPepper (Postfix) with ESMTP id 1CF13813E6D; Tue, 13 May 2003 22:17:22 -0700 (PDT) Message-ID: <039d01c319d7$0e6b9360$d1d07b43@cocacola> From: "Michael Fair" To: "Mark Crispin" , "Pete Resnick" Cc: References: Subject: Re: Vienna Date: Tue, 13 May 2003 22:09:54 -0700 Organization: DaClubhouse 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 X-Spam-Status: No, hits=-9.8 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > 2) LEMONADE. > > LEMONADE clearly identified a need for message submission that does not > require downloading from IMAP server; however, doing submission in IMAP is > a mistake. I'd rather not argue the reasons why in email; it'll > just waste everybody's time. > > Instead, let's come up with an alternative so there is a choice that can > be made. Right now, there is no choice. > > I suggest a command, valid when not logged in, that will fetch a > particular message or portion of message. Thus, the argument to the > command has to carry authentication of some kind; the key is that this is > *not* the user's authentication but rather some special authentication > that is specific to that message or portion of a message. > > Desirable authentication forms: use-once, anonymous, use only by certain > entity, time-limited (e.g. "expires in 5 minutes"). > > Could be a SASL mechanism, since SASL has the framework; ultimately > returning a NO so it can be done multiple times in one IMAP connection. > > Must be expressable in an IMAP URL; the URL must carry the authentication > (possibly also with a client-supplied token). > > The idea here is that the MSA is given a message with various IMAP URLs > inserted. The MSA resolves the URL and fetches the data from the server > (or servers -- an advantage of doing it this way). > > We need a command for an IMAP client to create these things, e.g. "give me > a cookie, expiring in 10 minutes, that will fetch part [2.4.4] from UID > 12383 from my INBOX". Please correct me if I'm wrong, let me see if I can recap what you are proposing since I've gotten confused about what seems to be mixed or at least unclarified usage of the terms submission, client, and server. 1) It is inappropriate to make the IMAP server the middle man for transporting messages. The client should have a method of requesting data directly from foriegn servers (aka "message submission that does not require downloading from IMAP server")? You chose not to waste people's time with the details of an explanation. So you chose to propose a new IMAP command so we can compare and choose. 2) This new command is to provide a way for an end user client to tell an IMAP server to fetch arbirtrary message parts with authentication. And that relates to message submission because the server is to fetch the data from the remote server and store the retrieved data as part of the message in the local mail store? Or this command is intended to be issued by remote servers and/or clients who are trying to "pick up" the message parts from the current server? Or this has nothing to do with message submission and is about an end user client getting fast access to a separate IP connection (whether or its own use or some other agent's use) through which to transfer the data across with? It's not clear to me whether the ultimate intended recipient of this command is the IMAP server, the end user client, or some other remote service that was told to pick up the data. You then described the authentication requirements. 3) You then concluded with describing the general idea as the MSA gets handed a message with a bunch of URLs and goes off to do its thing. But I'm not clear on who the MSA is being an agent of. Given your example it seems that intended destination is an end user client who already as a session with the current server and that the definition of "submission" is actually a transfer from server space to end user space rather than the user space submitting to server space. (I use server space as loose term to refer to the collection of servers hosting the message data, and user space as the collection of clients being used to view it) I have not been following LEMONADE to really get what the current intended framework looks like. So it might be that I'm just missing some background info that I haven't read yet. Unfortunately, without clarity on exactly what the envisioned framework is I am having a hard time picturing the overall use and goal here. I might also be having a hard time because I have a general definition of submission as "moving away from the source", of "uploading" as moving away from the current active end user, and of "downloading" as moving to the active service. I just can't clearly tell what the various active objects in your description are and when they are being active. If the ultimate goal here to provide an end user client with a URL so that the end user client (or local agent) can open up another connection to the same server and quickly access the data, then I'd think simply providing a method for doing a "FASTAUTH" token which would at most need to renegotiate TLS to establish the same context as the initial session is all that would be required because then the new session can issue the same IMAP commands the other could. But that would leave the heavy lifting "in IMAP" which you don't think will work. (Because the connecting agent may not know any IMAP over and above submitting this command?) Further, if the purpose is really just to give other applications on the same client machine access to the data, then why not have the client act as a relay between the IMAP server and the final application. It could easily do this by opening a port bound to the 127.0.0.1 interface and then causing whatever Agent to connect to that loopback port while the IMAP client then transferred the data across via IMAP. This allows the IMAP client to cache the message part and provide the data to the external application at the same time. It further supplies a methodology for the same dat to be viewed by the end user multiple times without transferring from the server each time. This method doesn't work so well for real time protocols. Those will probably have to be handled differently unless the server and client learn to speak RTSP. If the purpose is to allow clients to request URLs that are to be issued to a server other than the one the client is talking to at the moment then I think I understand what you're trying to accomplish. The current server has a message whose parts are stored in many locations, the client wants to access these parts and therefore requests a token from the current server to fetch them. The questions I have then are, is it expected that all the remote servers are IMAP servers, or are they arbitrary protocols? Assuming IMAP its various IMAP servers involved then are they preaware of each other's existence? Can the servers share a secret between each other for generating the URLs (perhaps PKI based?)? If the purpose is actually to enable clients to upload data (aka submit new data to the server) then I'm having a hard time comprehending the client requesting a cookie to fetch the message part. Finally if I'm way off base on all of these, and you really just need a simple command to fetch data, then I suggest the command mimic the HTTP protocol (with recent extensions) as closely as possible to leverage as much existing work and mind share done in this area as possible (unless of course there is some technical reason that makes this impractical. Sorry for the long email but I just wanted to be clear about what the vaious confusions were. Thank you, -- Michael -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4E01uAF052133 for ; Tue, 13 May 2003 17:01: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 h4E01ua6052132 for ietf-imapext-bks; Tue, 13 May 2003 17:01:56 -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 h4E01tAF052127 for ; Tue, 13 May 2003 17:01:55 -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.1+UW03.04/8.12.1+UW02.12) with ESMTP id h4E01vSL031616; Tue, 13 May 2003 17:01: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.1+UW03.04/8.12.1+UW02.12) with ESMTP id h4E01uQ0009826 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 13 May 2003 17:01:57 -0700 Date: Tue, 13 May 2003 16:59:55 -0700 (Pacific Daylight Time) From: Mark Crispin To: Chris Newman cc: IMAP Extensions WG Subject: Re: SORT, THREAD and VIEW/WINDOW In-Reply-To: <2147483647.1052838555@nifty-jr.west.sun.com> Message-ID: References: <2147483647.1052838555@nifty-jr.west.sun.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, 13 May 2003, Chris Newman wrote: > So I am now willing to see SORT and THREAD move forward without VIEW > despite my scalability concerns. Given how busy and resource limited > the IMAP community appears to be at the moment, I further propose we > drop the VIEW command from the list of WG deliverables we must complete > prior to WG closure (but let's not bother changing the charter until > we've finished the other deliverables). Thank you. My understanding of our status is: I) CHARTER EXTENSIONS SORT/THREAD is done, but will need to be blocked on I18N since it makes a normative reference to it. I believe that the remaining documents that we need to complete to fufill the charter are: ACL, ANNOTATE, ANNOTATEMORE, CONDSTORE, I18N II) NON-CHARTER EXTENSIONS. We also are considering: LISTEXT and may want to consider SEARCH-MULTIPLE, VHOST, and the following expired drafts: QUOTA, UNSELECT I decided not to oppose UNSELECT any more; indeed, I recently implemented it in my server. Cyrus server has it too. So let's do a quick last call and get it published. I vote to proceed on LISTEXT and punt on the other non-charter proposals. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4DMBnHN047968 for ; Tue, 13 May 2003 15:11:49 -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 h4DMBnPU047966 for ietf-imapext-bks; Tue, 13 May 2003 15:11:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from brmea-mail-4.sun.com (kathmandu.sun.com [192.18.98.36]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4DMBmHN047957 for ; Tue, 13 May 2003 15:11:48 -0700 (PDT) (envelope-from Chris.Newman@Sun.COM) Received: from esunmail ([129.147.58.120]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h4DMBohm005479 for ; Tue, 13 May 2003 16:11:50 -0600 (MDT) Received: from xpa-fe1 ([129.147.58.198]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HEU00BAQIZQ8O@edgemail1.Central.Sun.COM> for ietf-imapext@imc.org; Tue, 13 May 2003 16:11:50 -0600 (MDT) Received: from nifty-jr.west.sun.com ([129.153.12.95]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HEU007WDIZHOV@mail.sun.net> for ietf-imapext@imc.org; Tue, 13 May 2003 16:11:50 -0600 (MDT) Date: Tue, 13 May 2003 15:09:15 -0700 From: Chris Newman Subject: SORT, THREAD and VIEW/WINDOW To: IMAP Extensions WG Message-id: <2147483647.1052838555@nifty-jr.west.sun.com> MIME-version: 1.0 X-Mailer: Mulberry/3.0.3 (Mac OS X) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-message-flag: Outlook: the best virus distribution system around Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: There is a scalability problem with the design of SORT and THREAD because their performance and bandwidth consumption depends on the number of messages in the mailbox. As a result of this problem, I held the position that we need to hold up SORT and THREAD until the VIEW command is ready to move forward on the standards track at the same time. After going through a number of revisions on VIEW and WINDOW proposals with Cyrus, my position has changed slightly. I now recognize that the VIEW command (or similar mechanism) would introduce significant complexity and that complexity may exceed the benefit it provides. In particular, the majority of users may be satisfied to keep the size of the mailboxes on which they apply SORT and THREAD to some reasonable limit (e.g., less than 10,000 messages) in order to get acceptable performance. Scalable servers might cache SORT and THREAD results so the computation cost is minimized and perhaps bandwidth is increasing fast enough that it isn't a concern. So I am now willing to see SORT and THREAD move forward without VIEW despite my scalability concerns. Given how busy and resource limited the IMAP community appears to be at the moment, I further propose we drop the VIEW command from the list of WG deliverables we must complete prior to WG closure (but let's not bother changing the charter until we've finished the other deliverables). - Chris Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4DKxZi2044963 for ; Tue, 13 May 2003 13:59:35 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h4DKxZKI044962 for ietf-imapext-bks; Tue, 13 May 2003 13:59:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from brmea-mail-3.sun.com (pheriche.sun.com [192.18.98.34]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4DKxYi2044957 for ; Tue, 13 May 2003 13:59:34 -0700 (PDT) (envelope-from Chris.Newman@Sun.COM) Received: from esunmail ([129.147.58.120]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4DKxaRh014252 for ; Tue, 13 May 2003 14:59:36 -0600 (MDT) Received: from xpa-fe1 ([129.147.58.198]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HEU00BK7FNB8Q@edgemail1.Central.Sun.COM> for ietf-imapext@imc.org; Tue, 13 May 2003 14:59:36 -0600 (MDT) Received: from nifty-jr.west.sun.com ([129.153.12.95]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HEU007EYFN6TO@mail.sun.net> for ietf-imapext@imc.org; Tue, 13 May 2003 14:59:34 -0600 (MDT) Date: Tue, 13 May 2003 13:57:04 -0700 From: Chris Newman Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-00.txt In-reply-to: <020d01c3197f$dd7cf200$d1d07b43@cocacola> To: Michael Fair , ietf-imapext@imc.org Message-id: <2147483647.1052834224@nifty-jr.west.sun.com> MIME-version: 1.0 X-Mailer: Mulberry/3.0.3 (Mac OS X) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-message-flag: Outlook: the best virus distribution system around References: <200305131200.IAA05283@ietf.org> <020d01c3197f$dd7cf200$d1d07b43@cocacola> Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: begin quotation by Michael Fair on 2003/5/13 11:45 -0700: > Four things: > > 1) Lately there's been talk of moving commands like these > into a client CAPABILITY announcement string. The command > has been proposed as a way for the client to: > > A) Announce capabilities it has that the server > might be able to do something special with, > and > B) Set options to server capabilities that impact the > behavior of the session > > The two major candidates in most examples so far have > been VHOST and LANGUAGE. I didn't see anything requested > here that would preclude LANGUAGE from being assigned > in that manner. The only "special case" I saw is that > any client issuing a CAPABILITY with a LANGUAGE option > MUST be prepared to receive an untagged NAMESPACE response > as one of the responses to CAPABILITY. > > Is there anything else anyone else saw that seems to make > this whole client side CAPABILITY approach to items like > VHOST and LANGUAGE (and perhaps a CHARSET could be added > to the list for UTF-8 support?) a bad idea? We discussed the issue of client capabilities at the informal IMAPEXT BOF at the last IETF and there was a rough consensus in the room (of about 20 IMAP developers many of whom write code) which opposed the idea of a combined client capability mechanism. The rough consensus of the room appeared to favor separate commands which could be pipelined rather than a combined command. Now the mailing list can override that consensus, but I'd need to see stronger support than I've seen to date. In addition, there is deployed running code for the LANGUAGE extension (implemented to the previous draft). As a result I am opposed to aesthetic changes to the LANGUAGE extension as documented. Proposed changes need to have a substantive technical justification. > 2) In specific response to the LANGUAGE feature set as > described, I noticed it is missing in-band administration > for assigning the various LANGUAGE translations of folders. > > 3) Could this be extended to allow all folders to be > represented in multiple languages by way of some kind > of "ALIAS" command that could install a language alias > for folders? This would probably require the equivalent > of a RENAME ACL. This would anticipate a resolution > to the lack of character set choice currently present. > (For instance via a client capability mentioned above.) Please make a concrete proposal if you want to discuss these issues. I'm not sure exactly what you're asking so it would be easier to discuss if I could see something concrete. > 4) Since languages are somewhat tied to character sets, > it seems logical that in response to the LANGUAGE command > aside from the language selected the character set used > by the server to display that language should also be > announced shouldn't it? I've done no internationalization > work so I'm not sure how you get two machines to align > on a character set implicity through just a language name. The selected character set is always UTF-8, so there is no issue. - Chris Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4DIpAi2038918 for ; Tue, 13 May 2003 11:51:10 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h4DIpAIl038917 for ietf-imapext-bks; Tue, 13 May 2003 11:51:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4DIp9i2038911 for ; Tue, 13 May 2003 11:51:09 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id 695AB812FF4; Tue, 13 May 2003 11:51:10 -0700 (PDT) Received: from cocacola (adsl-67-123-208-209.dsl.lsan03.pacbell.net [67.123.208.209]) by DrPepper (Postfix) with ESMTP id 636D381079A for ; Tue, 13 May 2003 11:51:08 -0700 (PDT) Message-ID: <020d01c3197f$dd7cf200$d1d07b43@cocacola> From: "Michael Fair" To: References: <200305131200.IAA05283@ietf.org> Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-00.txt Date: Tue, 13 May 2003 11:45:45 -0700 Organization: DaClubhouse MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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 X-Spam-Status: No, hits=-9.8 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Four things: 1) Lately there's been talk of moving commands like these into a client CAPABILITY announcement string. The command has been proposed as a way for the client to: A) Announce capabilities it has that the server might be able to do something special with, and B) Set options to server capabilities that impact the behavior of the session The two major candidates in most examples so far have been VHOST and LANGUAGE. I didn't see anything requested here that would preclude LANGUAGE from being assigned in that manner. The only "special case" I saw is that any client issuing a CAPABILITY with a LANGUAGE option MUST be prepared to receive an untagged NAMESPACE response as one of the responses to CAPABILITY. Is there anything else anyone else saw that seems to make this whole client side CAPABILITY approach to items like VHOST and LANGUAGE (and perhaps a CHARSET could be added to the list for UTF-8 support?) a bad idea? 2) In specific response to the LANGUAGE feature set as described, I noticed it is missing in-band administration for assigning the various LANGUAGE translations of folders. 3) Could this be extended to allow all folders to be represented in multiple languages by way of some kind of "ALIAS" command that could install a language alias for folders? This would probably require the equivalent of a RENAME ACL. This would anticipate a resolution to the lack of character set choice currently present. (For instance via a client capability mentioned above.) 4) Since languages are somewhat tied to character sets, it seems logical that in response to the LANGUAGE command aside from the language selected the character set used by the server to display that language should also be announced shouldn't it? I've done no internationalization work so I'm not sure how you get two machines to align on a character set implicity through just a language name. -- Michael -- ----- Original Message ----- From: To: Cc: Sent: Tuesday, May 13, 2003 5:00 AM Subject: I-D ACTION:draft-ietf-imapext-i18n-00.txt > 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 : Internet Message Access Protocol Internationalization > Author(s) : C. Newman > Filename : draft-ietf-imapext-i18n-00.txt > Pages : 18 > Date : 2003-5-12 > > Internet Message Access Protocol (IMAP) version 4rev1 has basic > support for non-ASCII characters in mailbox names and search > substrings. It also supports non-ASCII message headers and content > encoded as specified by Multipurpose Internet Mail Extensions (MIME). > This specification defines a collection of IMAP extensions which > improve international support including comparator negotiation for > search, sort and thread, language negotiation for international error > text, and translations for namespace prefixes. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-imapext-i18n-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-ietf-imapext-i18n-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-imapext-i18n-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. > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4DC3Ji2010151 for ; Tue, 13 May 2003 05:03:19 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h4DC3Jfc010150 for ietf-imapext-bks; Tue, 13 May 2003 05:03:19 -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.8p1/8.12.8) with ESMTP id h4DC3Ii2010145 for ; Tue, 13 May 2003 05:03:18 -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 IAA05283; Tue, 13 May 2003 08:00:16 -0400 (EDT) Message-Id: <200305131200.IAA05283@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-i18n-00.txt Date: Tue, 13 May 2003 08:00:15 -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 : Internet Message Access Protocol Internationalization Author(s) : C. Newman Filename : draft-ietf-imapext-i18n-00.txt Pages : 18 Date : 2003-5-12 Internet Message Access Protocol (IMAP) version 4rev1 has basic support for non-ASCII characters in mailbox names and search substrings. It also supports non-ASCII message headers and content encoded as specified by Multipurpose Internet Mail Extensions (MIME). This specification defines a collection of IMAP extensions which improve international support including comparator negotiation for search, sort and thread, language negotiation for international error text, and translations for namespace prefixes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-i18n-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-ietf-imapext-i18n-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imapext-i18n-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-5-12152624.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-i18n-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-i18n-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-12152624.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46Lv2i2004255 for ; Tue, 6 May 2003 14:57:02 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46Lv2Zt004254 for ietf-imapext-bks; Tue, 6 May 2003 14:57:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46Lv0i2004246 for ; Tue, 6 May 2003 14:57:01 -0700 (PDT) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h46LuhB4010410 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 6 May 2003 23:56:44 +0200 To: Mark Crispin Cc: Pete Resnick , ietf-imapext@imc.org Subject: Re: Vienna References: From: Simon Josefsson X-Payment: hashcash 1.2 0:030506:MRC@CAC.Washington.EDU:cfd99dea6f4c5d92 X-Hashcash: 0:030506:MRC@CAC.Washington.EDU:cfd99dea6f4c5d92 X-Payment: hashcash 1.2 0:030506:presnick@qualcomm.com:74e40c174dd4049c X-Hashcash: 0:030506:presnick@qualcomm.com:74e40c174dd4049c X-Payment: hashcash 1.2 0:030506:ietf-imapext@imc.org:c683ecff4b65dd0b X-Hashcash: 0:030506:ietf-imapext@imc.org:c683ecff4b65dd0b Date: Tue, 06 May 2003 23:56:43 +0200 In-Reply-To: (Mark Crispin's message of "Tue, 6 May 2003 14:20:04 -0700 (Pacific Daylight Time)") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-32.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: > I suggest a command, valid when not logged in, that will fetch a > particular message or portion of message. Thus, the argument to the > command has to carry authentication of some kind; the key is that this is > *not* the user's authentication but rather some special authentication > that is specific to that message or portion of a message. > > Desirable authentication forms: use-once, anonymous, use only by certain > entity, time-limited (e.g. "expires in 5 minutes"). > > Could be a SASL mechanism, since SASL has the framework; ultimately > returning a NO so it can be done multiple times in one IMAP connection. > > Must be expressable in an IMAP URL; the URL must carry the authentication > (possibly also with a client-supplied token). > > The idea here is that the MSA is given a message with various IMAP URLs > inserted. The MSA resolves the URL and fetches the data from the server > (or servers -- an advantage of doing it this way). > > We need a command for an IMAP client to create these things, e.g. "give me > a cookie, expiring in 10 minutes, that will fetch part [2.4.4] from UID > 12383 from my INBOX". SASL together with a short-lived Kerberos ticket is a somewhat heavy solution (even heavier if GSSAPI is involved), but possible. It could be done with a short-lived username/password combination too, although more difficult to embed useful information you can store in the ticket (like who created the ticket, useful for logging). The server could log on the user, using the short-lived authorization information, and present a restricted view of the mailboxes: only the appropriate message is available, from one mailbox (INBOX). SASL definitely has the framework for this, and using it wouldn't require changes to the IMAP URL either. My $.2. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46Ljpi2003987 for ; Tue, 6 May 2003 14:45:51 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46LjpWQ003986 for ietf-imapext-bks; Tue, 6 May 2003 14:45:51 -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.8p1/8.12.8) with ESMTP id h46Ljoi2003981 for ; Tue, 6 May 2003 14:45:50 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout4.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h46LjiTc027876; Tue, 6 May 2003 14:45:49 -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.1+UW03.04/8.12.1+UW02.12) with ESMTP id h46LjiQ0011028 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 6 May 2003 14:45:44 -0700 Date: Tue, 6 May 2003 14:45:45 -0700 (Pacific Daylight Time) From: Mark Crispin To: Cyrus Daboo cc: Pete Resnick , ietf-imapext@imc.org Subject: Re: Vienna In-Reply-To: <2147483647.1052242874@[63.163.82.24]> Message-ID: References: <2147483647.1052242874@[63.163.82.24]> 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, 6 May 2003, Cyrus Daboo wrote: > Surely its enough to simply require ACL and require that the MSA have an > associated user id on the IMAP server and that it be given read/write > access to each 'real' users' OUTBOX? No, part of the design is that the MSA does *NOT* have access to anything that it is not given specific access. Also, I'm thinking that this may be useful for other things; perhaps I might want to send someone an email with such a URL (as opposed to the actual data). -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46LiZi2003938 for ; Tue, 6 May 2003 14:44:35 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46LiZM6003937 for ietf-imapext-bks; Tue, 6 May 2003 14:44:35 -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.8p1/8.12.8) with ESMTP id h46LiYi2003932 for ; Tue, 6 May 2003 14:44:34 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id RAA17773; Tue, 6 May 2003 17:40:54 -0400 (EDT) Date: Tue, 06 May 2003 17:44:34 -0400 From: Cyrus Daboo To: Pete Resnick , ietf-imapext@imc.org Subject: Re: Vienna Message-ID: <2147483647.1052243074@[63.163.82.24]> In-Reply-To: References: X-Mailer: Mulberry/3.1.0b1 (Mac OS/PPC) 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 Pete, --On Tuesday, May 6, 2003 10:15 AM -0500 Pete Resnick wrote: | Document editors: Please provide to the list the status of your | documents. Are there open issues that will need to be discussed in Vienna? | I have to catch up on the changes to ANNOTATE/ANNOTATEMORE from the last meeting - sorry. I will try and get around to that by the end of this week. | I will be in Vienna either way. Let's figure out now whether we need a | meeting. I will not be waltzing over to Vienna :-( -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46LfWi2003836 for ; Tue, 6 May 2003 14:41:32 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46LfW0b003835 for ietf-imapext-bks; Tue, 6 May 2003 14:41: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.8p1/8.12.8) with ESMTP id h46LfVi2003826 for ; Tue, 6 May 2003 14:41:31 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id RAA17721; Tue, 6 May 2003 17:37:35 -0400 (EDT) Date: Tue, 06 May 2003 17:41:14 -0400 From: Cyrus Daboo To: Mark Crispin , Pete Resnick cc: ietf-imapext@imc.org Subject: Re: Vienna Message-ID: <2147483647.1052242874@[63.163.82.24]> In-Reply-To: References: X-Mailer: Mulberry/3.1.0b1 (Mac OS/PPC) 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, --On Tuesday, May 6, 2003 2:20 PM -0700 Mark Crispin wrote: | The idea here is that the MSA is given a message with various IMAP URLs | inserted. The MSA resolves the URL and fetches the data from the server | (or servers -- an advantage of doing it this way). | | We need a command for an IMAP client to create these things, e.g. "give me | a cookie, expiring in 10 minutes, that will fetch part [2.4.4] from UID | 12383 from my INBOX". Surely its enough to simply require ACL and require that the MSA have an associated user id on the IMAP server and that it be given read/write access to each 'real' users' OUTBOX? Its then a simple matter to write a dedicated IMAP client for the MSA that goes and gets messages from each OUTBOX on the IMAP server. If you combine this with async notifications for STATUS changes (i.e. when a message is added to an OUTBOX) there shouldn't be any need to pass a URL to the MSA. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46LK9i2003176 for ; Tue, 6 May 2003 14:20:09 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46LK9TA003175 for ietf-imapext-bks; Tue, 6 May 2003 14:20:09 -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.8p1/8.12.8) with ESMTP id h46LK7i2003170 for ; Tue, 6 May 2003 14:20:07 -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.1+UW03.04/8.12.1+UW02.12) with ESMTP id h46LK3RG015518; Tue, 6 May 2003 14:20:08 -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.1+UW03.04/8.12.1+UW02.12) with ESMTP id h46LK3Q0008083 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 6 May 2003 14:20:03 -0700 Date: Tue, 6 May 2003 14:20:04 -0700 (Pacific Daylight Time) From: Mark Crispin To: Pete Resnick cc: ietf-imapext@imc.org Subject: Re: Vienna 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 Tue, 6 May 2003, Pete Resnick wrote: > Document editors: Please provide to the list the status of your > documents. SORT/THREAD: awaiting Chris Newman's i18n document to come out as an I-D before making Last Call. > Are there open issues that will need to be discussed in > Vienna? Since both UW and Cyrus now implement Alexey's UNSELECT extension, let's Last Call it. The I-D is expired. > Others: Are there items that you think need to be discussed in > Vienna? Do remember that LEMONADE-related items should be discussed > over there. Two things come to mind: 1) Does Chris need help with the i18n I-D? If so, he should get it. 2) LEMONADE. LEMONADE clearly identified a need for message submission that does not require downloading from IMAP server; however, doing submission in IMAP is a mistake. I'd rather not argue the reasons why in email; it'll just waste everybody's time. Instead, let's come up with an alternative so there is a choice that can be made. Right now, there is no choice. I suggest a command, valid when not logged in, that will fetch a particular message or portion of message. Thus, the argument to the command has to carry authentication of some kind; the key is that this is *not* the user's authentication but rather some special authentication that is specific to that message or portion of a message. Desirable authentication forms: use-once, anonymous, use only by certain entity, time-limited (e.g. "expires in 5 minutes"). Could be a SASL mechanism, since SASL has the framework; ultimately returning a NO so it can be done multiple times in one IMAP connection. Must be expressable in an IMAP URL; the URL must carry the authentication (possibly also with a client-supplied token). The idea here is that the MSA is given a message with various IMAP URLs inserted. The MSA resolves the URL and fetches the data from the server (or servers -- an advantage of doing it this way). We need a command for an IMAP client to create these things, e.g. "give me a cookie, expiring in 10 minutes, that will fetch part [2.4.4] from UID 12383 from my INBOX". > I will be in Vienna either way. Let's figure out now whether we need a > meeting. I won't be in Vienna. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46FFgi2081993 for ; Tue, 6 May 2003 08:15:42 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46FFgZo081992 for ietf-imapext-bks; Tue, 6 May 2003 08:15:42 -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 (champdsl-25-66.mcleodusa.net [216.43.25.66]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46FFei2081987 for ; Tue, 6 May 2003 08:15:40 -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.1b1) for ; Tue, 6 May 2003 10:16:20 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: X-Mailer: Eudora [Macintosh version 6.0a15] Date: Tue, 6 May 2003 10:15:35 -0500 To: ietf-imapext@imc.org From: Pete Resnick Subject: Vienna Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've been reminded to start early on figuring out what's going on for the next IETF meeting, so let's do that. Document editors: Please provide to the list the status of your documents. Are there open issues that will need to be discussed in Vienna? Others: Are there items that you think need to be discussed in Vienna? Do remember that LEMONADE-related items should be discussed over there. I will be in Vienna either way. Let's figure out now whether we need a meeting. -- 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.8p1/8.12.8) with ESMTP id h45IMfi2004669 for ; Mon, 5 May 2003 11:22:41 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h45IMfTx004668 for ietf-imapext-bks; Mon, 5 May 2003 11:22:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h45IMdi2004662 for ; Mon, 5 May 2003 11:22:39 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id 038688831EB; Mon, 5 May 2003 11:22:40 -0700 (PDT) Received: from cocacola (adsl-67-123-208-209.dsl.lsan03.pacbell.net [67.123.208.209]) by DrPepper (Postfix) with ESMTP id 4227F8160F5; Mon, 5 May 2003 11:22:39 -0700 (PDT) Message-ID: <065101c3136e$023899e0$d1d07b43@cocacola> From: "Michael Fair" To: Cc: "Harrie Hazewinkel" References: <134EE589-7F01-11D7-B305-0003934A5A7E@lisanza.net> Subject: Re: Adding CAPABILITY to "Hello, Starttls, and Authenticate/Login" (saving round trips) Date: Mon, 5 May 2003 18:22:49 -0700 Organization: DaClubhouse 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 X-Spam-Status: No, hits=-5.6 required=5.0 tests=DATE_IN_FUTURE_06_12,REFERENCES version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'm looking forward to hearing what others also have to say about this. It seems to me that two or three drafts should be used to replace the current VHOST draft based on this discussion. While I may have the details wrong, in general, the three drafts seem to be something along the lines of the following: 1) ECAPABILITY draft (nobody seems to mind ECAPABILITY keyword). - This creates ECAPABILITY as a CAPABILITY keyword and means that the CAPABILITY command accepts parameters for the purposes of informing the server of client capabilities and for passing options to capabilities the server supports. 2) VHOST draft - Redefines VHOST in the context of ECAPABILITY as per the details of this discussion. 3) Notification of CAPABILITY as unsolicited responses draft - In order to save round trips, allows a server to post an unsolicitied CAPABILITY response after the client executes any command that changes the CAPABILITY set. Currently the identified responses are HELLO, STARTTLS, ECAPABILITY, LOGIN, and AUTHENTICATE. I'd imagine that in some servers other commands (like "SELECT") might also want/need this ability. It would also seem that other ideas and drafts might be recontextualized via ECAPABILITY as well. For instance, the LANGUAGE thread that went on a while ago might give servers the opportunity to store and manipulate folders in multiple languages and allow the client to define a preferred language priority list. Something would have to be done to allow clients to attach folder names in different languages to exisitng folders, but that's outside the scope of the ECAPABILITY draft. My $0.02, -- Michael -- ----- Original Message ----- From: "Harrie Hazewinkel" To: Cc: "Harrie Hazewinkel" ; "Michael Fair" Sent: Monday, May 05, 2003 6:54 AM Subject: Re: Adding CAPABILITY to "Hello, Starttls, and Authenticate/Login" (saving round trips) > HI all, > > > As being the author of that 'VHOST' command internet-draft > I was wondering if the group believes it is usefull > to recycle that draft based on the summary/idea/consensus > of this discussion?? > > > Harrie > > On Friday, May 2, 2003, at 05:16 AM, Michael Fair wrote: > > > > >> The really important thing is avoiding round-trips. The > >> amount of bandwidth > >> that is taken up by capabilities is really dwarfed by > >> any messages the client downloads. > >> > >> It would be nice, if you're redoing how capabilities > >> are announced, to do > >> away with the pointless roundtrips after STARTTLS and > >> after authentication. > > > > I've renamed the subject to reflect the topic. It's > > become pretty clear to me that this issue is important > > but is really separate from adding parameters to the > > CAPABILITY command. > > > > So far the suggestions are to automatically append > > a CAPABILITY response to any command that changes > > the current CAPABILITY set. So far those responses > > are HELLO, STARTTLS, AUTHENTICATE, LOGIN, and if > > accepted ECAPABILITY. > > > > This really sounds more like IMAP4rev2ish but I > > would suggest including something like: > > > > - A Client MUST be prepared to receive an unsolicited > > CAPABILITY response after the status response code > > of any command. > > > > If you wanted to restrict that to "state altering" > > commands that would probably work too. > > > > -- Michael -- > > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h423H3i2090274 for ; Thu, 1 May 2003 20:17:03 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h423H3W7090273 for ietf-imapext-bks; Thu, 1 May 2003 20:17:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h423H0i2090266 for ; Thu, 1 May 2003 20:17:01 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id 9FF9E883DD6; Thu, 1 May 2003 20:17:03 -0700 (PDT) Received: from cocacola (adsl-67-123-208-209.dsl.lsan03.pacbell.net [67.123.208.209]) by DrPepper (Postfix) with ESMTP id 571B7812FF5; Thu, 1 May 2003 20:17:02 -0700 (PDT) Message-ID: <018301c31059$4291efe0$d1d07b43@cocacola> From: "Michael Fair" To: "Lawrence Greenfield" , "Timo Sirainen" , "Cyrus Daboo" Cc: References: <1214403459.1051806924@PLATO.cyrusoft.com> <1051825642.26180.284.camel@hurina> <352505536.1051820546@majormajor.REM.CMU.EDU> Subject: Adding CAPABILITY to "Hello, Starttls, and Authenticate/Login" (saving round trips) Date: Thu, 1 May 2003 20:16:44 -0700 Organization: DaClubhouse 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 X-Spam-Status: No, hits=-6.6 required=5.0 tests=REFERENCES version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > The really important thing is avoiding round-trips. The > amount of bandwidth > that is taken up by capabilities is really dwarfed by > any messages the client downloads. > > It would be nice, if you're redoing how capabilities > are announced, to do > away with the pointless roundtrips after STARTTLS and > after authentication. I've renamed the subject to reflect the topic. It's become pretty clear to me that this issue is important but is really separate from adding parameters to the CAPABILITY command. So far the suggestions are to automatically append a CAPABILITY response to any command that changes the current CAPABILITY set. So far those responses are HELLO, STARTTLS, AUTHENTICATE, LOGIN, and if accepted ECAPABILITY. This really sounds more like IMAP4rev2ish but I would suggest including something like: - A Client MUST be prepared to receive an unsolicited CAPABILITY response after the status response code of any command. If you wanted to restrict that to "state altering" commands that would probably work too. -- Michael -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h420Mti2085796 for ; Thu, 1 May 2003 17:22:55 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h420MtVA085795 for ietf-imapext-bks; Thu, 1 May 2003 17:22:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp6.andrew.cmu.edu (SMTP6.andrew.cmu.edu [128.2.10.86]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h420Msi2085790 for ; Thu, 1 May 2003 17:22:54 -0700 (PDT) (envelope-from leg+@andrew.cmu.edu) Received: from majormajor.REM.CMU.EDU (DYN-4-218.CC.cmu.edu [128.2.4.218] (may be forged)) (user=leg mech=GSSAPI (0 bits)) by smtp6.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h420Modg027673 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 1 May 2003 20:22:50 -0400 Date: Thu, 01 May 2003 20:22:27 -0400 From: Lawrence Greenfield To: Timo Sirainen , Cyrus Daboo cc: Michael Fair , ietf-imapext@imc.org Subject: Re: Adding a parameter to CAPABILITY Message-ID: <352505536.1051820546@majormajor.REM.CMU.EDU> In-Reply-To: <1051825642.26180.284.camel@hurina> References: <1214403459.1051806924@PLATO.cyrusoft.com> <1051825642.26180.284.camel@hurina> X-Mailer: Mulberry/3.0.3 (Win32) 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: --On Friday, May 02, 2003 12:47 AM +0300 Timo Sirainen wrote: > > On Thu, 2003-05-01 at 23:35, Cyrus Daboo wrote: >> For better compatibility with clients that won't understand ECAPABILITY >> I think ECAPABILITY should be a capability value itself. This means >> that the greeting string can continue to display the CAPABILITY >> response code that some servers now return, but would include >> ECAPABILITY as one its items: >> >> * OK [CAPABILITY IMAP4REV1 ECAPABILITY STARTTLS AUTH=GSSAPI] Hello to >> you! > > I don't really like sending the capability to client automatically. That > also means that we would receive the capability twice, once at start and > next after issuing CAPABILITY VHOST (..). The really important thing is avoiding round-trips. The amount of bandwidth that is taken up by capabilities is really dwarfed by any messages the client downloads. It would be nice, if you're redoing how capabilities are announced, to do away with the pointless roundtrips after STARTTLS and after authentication. Larry Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41N1Ei2084060 for ; Thu, 1 May 2003 16:01:14 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h41N1EPu084059 for ietf-imapext-bks; Thu, 1 May 2003 16:01:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41N1Di2084054 for ; Thu, 1 May 2003 16:01:13 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id 323C187BDFB; Thu, 1 May 2003 16:01:15 -0700 (PDT) Received: from cocacola (adsl-67-123-208-209.dsl.lsan03.pacbell.net [67.123.208.209]) by DrPepper (Postfix) with ESMTP id 5ED26812FF5; Thu, 1 May 2003 16:01:13 -0700 (PDT) Message-ID: <011901c31035$87133580$d1d07b43@cocacola> From: "Michael Fair" To: "Timo Sirainen" , "Cyrus Daboo" Cc: References: <1214403459.1051806924@PLATO.cyrusoft.com> <1051825642.26180.284.camel@hurina> Subject: Re: Adding a parameter to CAPABILITY Date: Thu, 1 May 2003 16:00:57 -0700 Organization: DaClubhouse MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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 X-Spam-Status: No, hits=-10.4 required=5.0 tests=QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,REFERENCES version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > * OK [CAPABILITY IMAP4REV1 ECAPABILITY STARTTLS AUTH=GSSAPI] Hello to you! > > I don't really like sending the capability to client automatically. That > also means that we would receive the capability twice, once at start and > next after issuing CAPABILITY VHOST (..). You either need to convince people that it's ok for a client to just try it and then fallback on failure, or the client needs to get the information twice anyway. By pre-announcing we're just short circuiting one of the round trips. I initially proposed something that utilized the error codes of existing server to determine if it supported arguments to CAPABILITY. An example of that proposal when used against an existing server would now look like: * IMAP Server - Hello there! C: 1 CAPABILITY VHOST (fqdn.example.com) ... S: 1 BAD Unexpected extra arguments to Capability C: 2 CAPABILITY * CAPABILITY IMAP4rev1 ... S: 2 OK Completed I expected that over time servers would come to deal with the added arguments (first just by swallowing them and not returning BAD, but still responding to CAPABILITY) and so the only "wasted bandwidth" was during the initial introduction of the parameter, and only when new clients were used against old servers. Existing servers are prepared for such "malformed" requests so I was just taking advantage of "corerct behavior". I, like yourself, was trying to minimize the number of times a client had to parse a CAPABILITY response. But people didn't like that the client didn't at least have a method for having foreknowledge, so it forced a round trip. That example would now look like: * IMAP Server - Hello there! C: 1 CAPABILITY S: * CAPABILITY IMAP4rev1 ECAPABILITY ... S: 1 OK Completed C: 2 CAPABILITY VHOST (fqdn.example.com) ... S: * CAPABILITY IMAP4rev1 ECAPABILITY VHOST (fqdn.example.com) ... S: 2 OK Completed Which still makes the client make two round trips, but now it has to actually pay attention to the result of the first one just to find out if it can issue the second. Of course, there's nothing stopping a client from doing it the way I first proposed. I have no reason to believe the first proposal is "wrong" in anyway. But let's stick to the new method. So the client issues a CAPABILITY line to find out if it can issue a parameterized CAPABILITY line. Well that's two round trips and two CAPABILITY parses. That kinda sucks, why don't we "preannounce" the first CAPABILITY command that we know the client is going to have to issue anyway and save the client at least one round trip? If we don't pre-announce the capabilities we make the client fetch for it. Now these same semantics are not only related to ECAPABILITY also AUTHENTICATE and probably others. So the thought is that if we are going to bother with preannouncing something we might as well preannounce the whole capability response. This will save all clients at least one round trip regardless of what they are going to do. Of course we could/should break this out into two extensions - One is ECAPABILITY (for lack of a formal term) and the other is "CAPABILITY ON HELLO". If we did that, would you be satisfied that ECAPABILITY on its own and as its own CAPABILITY term is fine, and then talk about the merits of "CAPABILITY ON HELLO" in a different thread? -- Michael -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41LlXi2081389 for ; Thu, 1 May 2003 14:47:33 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h41LlXgL081388 for ietf-imapext-bks; Thu, 1 May 2003 14:47:33 -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.8p1/8.12.8) with ESMTP id h41LlVi2081382 for ; Thu, 1 May 2003 14:47:32 -0700 (PDT) (envelope-from tss@iki.fi) Received: by oma.irssi.org (Postfix, from userid 1000) id C0F265E107F8; Fri, 2 May 2003 00:47:22 +0300 (EEST) Subject: Re: Adding a parameter to CAPABILITY From: Timo Sirainen To: Cyrus Daboo Cc: Michael Fair , ietf-imapext@imc.org In-Reply-To: <1214403459.1051806924@PLATO.cyrusoft.com> References: <1214403459.1051806924@PLATO.cyrusoft.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1051825642.26180.284.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 02 May 2003 00:47:22 +0300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2003-05-01 at 23:35, Cyrus Daboo wrote: > For better compatibility with clients that won't understand ECAPABILITY I > think ECAPABILITY should be a capability value itself. This means that the > greeting string can continue to display the CAPABILITY response code that > some servers now return, but would include ECAPABILITY as one its items: > > * OK [CAPABILITY IMAP4REV1 ECAPABILITY STARTTLS AUTH=GSSAPI] Hello to you! I don't really like sending the capability to client automatically. That also means that we would receive the capability twice, once at start and next after issuing CAPABILITY VHOST (..). Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41LBUi2080321 for ; Thu, 1 May 2003 14:11:30 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h41LBUvc080320 for ietf-imapext-bks; Thu, 1 May 2003 14:11:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41LBSi2080315 for ; Thu, 1 May 2003 14:11:28 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id 5805D87BDFB; Thu, 1 May 2003 14:11:30 -0700 (PDT) Received: from cocacola (adsl-67-123-208-209.dsl.lsan03.pacbell.net [67.123.208.209]) by DrPepper (Postfix) with ESMTP id EC164812FF5; Thu, 1 May 2003 14:11:28 -0700 (PDT) Message-ID: <00e801c31026$327d9b00$d1d07b43@cocacola> From: "Michael Fair" To: "Cyrus Daboo" , References: <1214403459.1051806924@PLATO.cyrusoft.com> Subject: Re: Adding a parameter to CAPABILITY Date: Thu, 1 May 2003 14:11:13 -0700 Organization: DaClubhouse 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 X-Spam-Status: No, hits=-6.6 required=5.0 tests=REFERENCES version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Hi Michael, > > --On Thursday, May 01, 2003 1:05 PM -0700 Michael Fair > wrote: > > | Any and all feedback is welcome and encouraged. > | Especially in finding the string to put in the > | Hello response. > > For better compatibility with clients that won't > understand ECAPABILITY I think ECAPABILITY should > be a capability value itself. This means that the > greeting string can continue to display the > CAPABILITY response code that some servers now > return, but would include ECAPABILITY as one its items: > > * OK [CAPABILITY IMAP4REV1 ECAPABILITY STARTTLS AUTH=GSSAPI] Hello to you! I've got no problem with that at all. :) I'll keep an ear open for calling it something other than ECAPABILITY, "CLIENTCAPABILITY" has also been suggested, I missed mentioning it earlier. Anyone else have any other suggestions or should we move on to actually drawing up a draft? If we should move on to drawing up a draft, are there any other currently proposed extensions aside from VHOST that this new draft should supercede? I would love to hear some feedback from more server implementors and client writers that are on the list as to their opinion on how this should proceed. What changes, if any, would help make their lives easier and thus more likely to add this command into their code. -- Michael -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41KYEi2079002 for ; Thu, 1 May 2003 13:34:14 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h41KYEdn079001 for ietf-imapext-bks; Thu, 1 May 2003 13:34:14 -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.8p1/8.12.8) with ESMTP id h41KYCi2078995 for ; Thu, 1 May 2003 13:34:13 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from PLATO.cyrusoft.com (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id QAA03870; Thu, 1 May 2003 16:30:42 -0400 (EDT) Date: Thu, 01 May 2003 16:35:24 -0400 From: Cyrus Daboo To: Michael Fair , ietf-imapext@imc.org Subject: Re: Adding a parameter to CAPABILITY Message-ID: <1214403459.1051806924@PLATO.cyrusoft.com> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (Win32) 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 Michael, --On Thursday, May 01, 2003 1:05 PM -0700 Michael Fair wrote: | Any and all feedback is welcome and encouraged. | Especially in finding the string to put in the | Hello response. For better compatibility with clients that won't understand ECAPABILITY I think ECAPABILITY should be a capability value itself. This means that the greeting string can continue to display the CAPABILITY response code that some servers now return, but would include ECAPABILITY as one its items: * OK [CAPABILITY IMAP4REV1 ECAPABILITY STARTTLS AUTH=GSSAPI] Hello to you! -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41K6Ci2078011 for ; Thu, 1 May 2003 13:06:12 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h41K6CQc078007 for ietf-imapext-bks; Thu, 1 May 2003 13:06:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41K6Ai2077998 for ; Thu, 1 May 2003 13:06:11 -0700 (PDT) (envelope-from ietf-ietf-imapext@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19BKIX-0008LE-00 for ; Thu, 01 May 2003 22:04:53 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-imapext@imc.org Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19BKIV-0008Kl-00 for ; Thu, 01 May 2003 22:04:51 +0200 From: "Michael Fair" Subject: Adding a parameter to CAPABILITY Date: Thu, 1 May 2003 13:05:47 -0700 Lines: 89 Message-ID: X-Complaints-To: usenet@main.gmane.org X-MSMail-Priority: Normal X-Newsreader: 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: After much discussion about the VHOST feature for virtualizing domains and being able to reliably host multiple domains on a single IP. The general consensus is that being able to reliably host multiple domains on a single IP is useful, using a parameter to STARTTLS, while preferred and already supported with a STARTTLS draft extension, is unreliable, and that any of the other recommended solutions essentially equates adding a parameter to CAPABILITY, finally, that if we are going to bother adding a parameter to CAPABILITY we might as well make it so that future modifications of a similar type don't need another modification to the protocol and thus a client should be able to submit its own capability options to the server when it makes a capability request. This feature in general is being referred to as a "Client CAPABILITY" line. It's purpose is to inform the server of any capabilities the client has that the server may need to be informed of (no current need has been identified for this though there are potential ideas for its use) and to pass parameters to the server for any capabilities the server offers that may be modified (this is the feature that VHOST would use). As such, the current proposal on the table goes along the lines of: 1) A specific string is added to the HELLO response to notify the client that a client capability parameter is supported. The only string suggested as of yet is "[ECAPABILITY]" following with ESMTP. Other suggestions are requested. 2) A client MAY provide a CAPABILITY parameter if it saw the appropriate string in the HELLO response. The client capability should match syntax with the existing CAPABILITY response to prevent servers from having to invent new parsers. 3) The CAPABILITY response from the server MUST acknowledge each parameter response it understands to inform the client of the accepted parameters and their status. Absence of a parameter in the servers CAPABILITY response means the server does not support or does not understand that particular CAPABILITY. Syntax errors on parameters that the server does understand SHOULD respond with "BAD" and give the appropriate reason for failure. 4) While a client capability parameter may be supported the rules which govern the individual options are defined on a per instance basis. For instance, with VHOST, once a client has entered into a TLS session or the AUTHENTICATED state, if the client should issue another CAPABILITY line the VHOST parameter SHOULD NOT be changed, and if the client does try and change it, the server SHOULD respond with "No" indicating the VHOST parameter has been changed and is invalid (an exception might be made for server administrator users). It is considered a security risk to allow clients to jump between domains once they are in a TLS session or the AUTHENTICATED state. So an example conversation might be the following (note the server does not support LANGUAGE and so leaves it out of its response to CAPABILITY): S: * OK [ECAPABILITY] IMAP server ready. C: 1 CAPABILITY VHOST (fqdn.example.com) RLIST LANGUAGE (en_US en_GB) S: 1 OK [CAPABILITY IMAP4rev1 VHOST (fqdn.example.com) RLIST ...] C: 2 STARTTLS S: 2 OK ...etc... Any and all feedback is welcome and encouraged. Especially in finding the string to put in the Hello response. -- Michael --