From owner-ietf-imapext Thu Apr 9 10:50:12 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id KAA19613 for ietf-imapext-bks; Thu, 9 Apr 1998 10:50:12 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id KAA19604 for ; Thu, 9 Apr 1998 10:50:11 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id KAA09462 for ; Thu, 9 Apr 1998 10:49:31 -0700 (PDT) Received: from netscape.com ([205.217.229.78]) by dredd.mcom.com (Netscape Messaging Server 3.52) with ESMTP id AAA342E for ; Thu, 9 Apr 1998 10:49:30 -0700 Message-ID: <352D0A2A.98E166AE@netscape.com> Date: Thu, 09 Apr 1998 10:49:30 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.05 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-imapext@imc.org Subject: Proposed charter Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@imc.org Precedence: bulk I would like to start discussion with the following charter: Chair(s): TBD Mailing Lists: General discussion: ietf-imapext@imc.org To Subscribe: ietf-imap-request@imc.org Archive: http://www.imc.org/ietf-imapext/ Description of Working Group: The IETF IMAP extensions Working Group shall revise and publish standards-track extensions to IMAP4 for performing the following functions: 1) Access Control Lists 2) Sorting 3) Threading 4) Message-level annotations Goals and Milestones: August 98 Approve charter Dec 98 Submit revised ACL spec to IESG Mar 99 Submit revised Sorting/Threading spec(s) to IESG August 99 Submit annotation spec to IESG From owner-ietf-imapext Thu Apr 9 10:50:12 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id KAA19612 for ietf-imapext-bks; Thu, 9 Apr 1998 10:50:12 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id KAA19605 for ; Thu, 9 Apr 1998 10:50:11 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id KAA09339 for ; Thu, 9 Apr 1998 10:48:02 -0700 (PDT) Received: from netscape.com ([205.217.229.78]) by dredd.mcom.com (Netscape Messaging Server 3.52) with ESMTP id AAA329C for ; Thu, 9 Apr 1998 10:48:02 -0700 Message-ID: <352D09D2.F7DFE95B@netscape.com> Date: Thu, 09 Apr 1998 10:48:02 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.05 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-imapext@imc.org Subject: FROM THE CHAIR: Introduction to ietf-imapext Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@imc.org Precedence: bulk The ietf-imapext@imc.org mailing list is now accepting submissions. I will be the chair of the imapext BOF at the August 98 IETF. Since I will probably be a document editor for the imapext WG (should it form), the chair of the WG will likely be someone else. Messages I send to the list in the role of BOF chair will have the prefix "FROM THE CHAIR" in the Subject:. All other messages I send to the list are in my role as individual contributor. The first task of this mailing list is to discuss the need and scope of a possible imapext Working Group and to propose a charter for such a group. At this time, discussion of proposed IMAP extensions is only appropriate insofar as it is relevant to defining the need, scope, and charter of this proposed Working Group. Detailed debate about any contentious issues in proposed extensions is inappropriate at this time--it will become appropriate only after we have rough consensus on a charter. From owner-ietf-imapext Thu Apr 9 16:07:25 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id QAA22047 for ietf-imapext-bks; Thu, 9 Apr 1998 16:07:25 -0700 (PDT) Received: from rembrandt.esys.ca (502@rembrandt.esys.ca [198.161.92.18]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id QAA22043 for ; Thu, 9 Apr 1998 16:07:24 -0700 (PDT) Received: from gallileo.esys.ca (gallileo.esys.ca [198.161.92.85]) by rembrandt.esys.ca (2.0.2/8.8.8) with ESMTP id RAA08594; Thu, 9 Apr 1998 17:07:27 -0600 From: Steve Hole Date: Thu, 9 Apr 1998 17:07:26 -0600 To: John Myers Subject: Re: Proposed charter Cc: ietf-imapext@imc.org In-Reply-To: <352D0A2A.98E166AE@netscape.com> References: <352D0A2A.98E166AE@netscape.com> Message-ID: X-Mailer: Simeon for Win32 Version Mercury a7 Build (8) MIME-Version: 1.0 Content-Type: Text/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@imc.org Precedence: bulk On Thu, 09 Apr 1998 10:49:30 -0700 John Myers wrote: > Description of Working Group: > > The IETF IMAP extensions Working Group shall revise and publish > standards-track extensions to IMAP4 for performing the following > functions: > > 1) Access Control Lists > 2) Sorting > 3) Threading > 4) Message-level annotations I am not sure what context the namespace extension was discussed in -- as in we are happy enough with it just to continue or we don't believe it to be important enough to include in the list of extensions to work on in the working group. I think that it is important enough to include in the work unless we are completely happy with it so far. Cheers. --- Steve Hole The Esys Corporation Mailto:Steve.Hole@esys.ca Phone:403-424-4922 From owner-ietf-imapext Thu Apr 9 16:14:44 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id QAA22128 for ietf-imapext-bks; Thu, 9 Apr 1998 16:14:44 -0700 (PDT) Received: from doggate.exchange.microsoft.com (doggate.Exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.8.8/8.7.3) with SMTP id QAA22124 for ; Thu, 9 Apr 1998 16:14:43 -0700 (PDT) Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2194.0) id <2QHYM9RC>; Thu, 9 Apr 1998 16:14:32 -0700 Message-ID: <2FBF98FC7852CF11912A000000000001095E1517@DINO> From: "Larry Osterman (Exchange)" To: "'Steve Hole'" , John Myers Cc: ietf-imapext@imc.org Subject: RE: Proposed charter Date: Thu, 9 Apr 1998 16:14:26 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2194.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-imapext@imc.org Precedence: bulk My gut tells me that namespace is going to have to be merged as a part of the base spec, but others will probably differ. Larry Osterman Sent from larryo-laptop.dns.microsoft.com running NT5 and Outlook 98 and Exchange Server 5.5. Please notify the sender of any difficulties -----Original Message----- From: Steve Hole [mailto:steve@esys.ca] Sent: Thursday, April 09, 1998 4:07 PM To: John Myers Cc: ietf-imapext@imc.org Subject: Re: Proposed charter On Thu, 09 Apr 1998 10:49:30 -0700 John Myers wrote: > Description of Working Group: > > The IETF IMAP extensions Working Group shall revise and publish > standards-track extensions to IMAP4 for performing the following > functions: > > 1) Access Control Lists > 2) Sorting > 3) Threading > 4) Message-level annotations I am not sure what context the namespace extension was discussed in -- as in we are happy enough with it just to continue or we don't believe it to be important enough to include in the list of extensions to work on in the working group. I think that it is important enough to include in the work unless we are completely happy with it so far. Cheers. --- Steve Hole The Esys Corporation Mailto:Steve.Hole@esys.ca Phone:403-424-4922 From owner-ietf-imapext Thu Apr 9 16:37:09 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id QAA22468 for ietf-imapext-bks; Thu, 9 Apr 1998 16:37:09 -0700 (PDT) Received: from eemail.microsoft.com ([131.107.88.57]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id QAA22464 for ; Thu, 9 Apr 1998 16:37:08 -0700 (PDT) Received: from ims.microsoft.com ([131.107.88.57]) by eemail.microsoft.com with Microsoft SMTPSVC(5.5.1875.135.13); Thu, 9 Apr 1998 16:36:58 -0700 Received: from mikega8 ([157.59.253.87]) by ims.microsoft.com with Microsoft SMTPSVC(5.5.1875.135.13); Thu, 9 Apr 1998 16:36:57 -0700 Message-ID: <000501bd6410$2eecff20$57fd3b9d@mikega8.mikega> From: "Mike Gahrns" To: "Steve Hole" , "John Myers" Cc: Subject: Re: Proposed charter Date: Thu, 9 Apr 1998 16:35:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOle: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ietf-imapext@imc.org Precedence: bulk Steve Hole writes: >I am not sure what context the namespace extension was discussed in -- as in >we are happy enough with it just to continue or we don't believe it to be >important enough to include in the list of extensions to work on in the >working group. > >I think that it is important enough to include in the work unless we are >completely happy with it so far. *** Well consensus seemed to have been reached on the list on this, and it has gone through the Last Call process with no further comments. In speaking with Harald and Keith, the IESG has approved this as an RFC, although the number has not come out yet. Were you thinking of a particular problem with the draft? If so, then we definitely should discuss, but from what I could tell, thinks were pretty much wrapped up... From owner-ietf-imapext Fri Apr 10 10:18:23 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id KAA13053 for ietf-imapext-bks; Fri, 10 Apr 1998 10:18:23 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id KAA13049 for ; Fri, 10 Apr 1998 10:18:22 -0700 (PDT) Received: from ephesus.cyrusoft.com (ephesus.cyrusoft.com [206.31.218.204]) by darius.cyrusoft.com (8.8.5/8.8.5) with SMTP id NAA22175 for ; Fri, 10 Apr 1998 13:17:50 -0400 (EDT) Date: Fri, 10 Apr 1998 13:18:43 -0400 From: "Cyrus Daboo" To: ietf-imapext@imc.org Subject: RE: Proposed charter Message-ID: <3156093156.892214323@ephesus.cyrusoft.com> X-Mailer: Mulberry (Win32) [1.4.0a2, s/n S1-000001] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@imc.org Precedence: bulk --On Thursday, April 09, 1998, 4:14 PM -0700 "Larry Osterman (Exchange)" wrote: > My gut tells me that namespace is going to have to be merged as a part of > the base spec, but others will probably differ. I believe it should be made clear in the charter that the WG has absolutely no intention to do any changes to the base spec. I presume that that is the case and I think it needs to be emphasised. Also, I think it would be a good idea to have posted to this list a complete set of all extensions and their status so we at least have an overview of what is currently being worked on or is complete. I'm not proposing that any or all of these should be considered by the WG, just that it is useful to see if there may be some overlap. Perhaps someone should volunteer to collate extensions and post it to the list. I'd be happy to do this, so if those working on extensions could email me directly with brief details (title, authors, description, status) I'll put the list together. Here's what I have already: Name Author(s) Description Status ---- --------- ----------- ------ ACL Myers Access Control Lists RFC2086 QUOTA Myers Quota controls/feedback RFC2087 LITERAL+ Myers non-synchronising RFC2088 IDLE Leiba idle time polling RFC2177 MAILBOX-REFERRALS Gahrns distributed mailboxes RFC2193 LOGIN-REFERRALS Gahrns referrals to servers RFC2221 UIDPLUS Myers Better disconnected support Last Call? NAMESPACE Gahrns, Newman mailbox namespaces Draft SORT Crispin Message sorting posted to list SCAN Crispin Multi-mailbox search? ? THREAD Crispin Threaded sorts? ? HASCHILDREN? Leiba Extra LIST flag ? ID Showalter Identification information Draft (expired) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Cyrus Daboo Cyrusoft International, Inc. Voice: +1 412 605 0499 Fax: +1 412 605 0705 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Proud Purveyors of Mulberry: Internet Mail from the Ground Up ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-ietf-imapext Fri Apr 10 10:34:34 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id KAA13283 for ietf-imapext-bks; Fri, 10 Apr 1998 10:34:34 -0700 (PDT) Received: from doggate.exchange.microsoft.com (doggate.Exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.8.8/8.7.3) with SMTP id KAA13279 for ; Fri, 10 Apr 1998 10:34:34 -0700 (PDT) Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2197.1) id <24LGNRY9>; Fri, 10 Apr 1998 10:34:25 -0700 Message-ID: <0A684133865BCF118F0E08002BE7ADAC019E1D88@DABONE> From: "Mike Gahrns (Exchange)" To: "'Cyrus Daboo'" , ietf-imapext@imc.org Subject: RE: Proposed charter Date: Fri, 10 Apr 1998 10:34:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2197.1) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-imapext@imc.org Precedence: bulk Haschildren, should be Child Mailbox and authors are Gahrns and Cheng. It is draft-00, but I should have a version -01 out soon with the minor comments that came in on the list. Also Language Extension, authors Gahrns and McCown. It is also version -00 and I once again I aim to get an update out soon. you also missed rfc2088, non synchronizing literals, author Myers thx -----Original Message----- From: Cyrus Daboo [mailto:daboo@cyrusoft.com] Sent: Friday, April 10, 1998 10:19 AM To: ietf-imapext@imc.org Subject: RE: Proposed charter --On Thursday, April 09, 1998, 4:14 PM -0700 "Larry Osterman (Exchange)" wrote: > My gut tells me that namespace is going to have to be merged as a part of > the base spec, but others will probably differ. I believe it should be made clear in the charter that the WG has absolutely no intention to do any changes to the base spec. I presume that that is the case and I think it needs to be emphasised. Also, I think it would be a good idea to have posted to this list a complete set of all extensions and their status so we at least have an overview of what is currently being worked on or is complete. I'm not proposing that any or all of these should be considered by the WG, just that it is useful to see if there may be some overlap. Perhaps someone should volunteer to collate extensions and post it to the list. I'd be happy to do this, so if those working on extensions could email me directly with brief details (title, authors, description, status) I'll put the list together. Here's what I have already: Name Author(s) Description Status ---- --------- ----------- ------ ACL Myers Access Control Lists RFC2086 QUOTA Myers Quota controls/feedback RFC2087 LITERAL+ Myers non-synchronising RFC2088 IDLE Leiba idle time polling RFC2177 MAILBOX-REFERRALS Gahrns distributed mailboxes RFC2193 LOGIN-REFERRALS Gahrns referrals to servers RFC2221 UIDPLUS Myers Better disconnected support Last Call? NAMESPACE Gahrns, Newman mailbox namespaces Draft SORT Crispin Message sorting posted to list SCAN Crispin Multi-mailbox search? ? THREAD Crispin Threaded sorts? ? HASCHILDREN? Leiba Extra LIST flag ? ID Showalter Identification information Draft (expired) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Cyrus Daboo Cyrusoft International, Inc. Voice: +1 412 605 0499 Fax: +1 412 605 0705 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Proud Purveyors of Mulberry: Internet Mail from the Ground Up ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-ietf-imapext Fri Apr 10 11:08:51 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA13630 for ietf-imapext-bks; Fri, 10 Apr 1998 11:08:51 -0700 (PDT) Received: from om.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.7.3) with SMTP id LAA13626 for ; Fri, 10 Apr 1998 11:08:49 -0700 (PDT) Message-Id: <4.0.1.327.19980410102736.00de16a0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1.327 (Beta) Date: Fri, 10 Apr 1998 11:08:29 -0700 To: ietf-imapext@imc.org From: Paul Hoffman / IMC Subject: RE: Proposed charter In-Reply-To: <3156093156.892214323@ephesus.cyrusoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-imapext@imc.org Precedence: bulk Cyrus' point is a good one. I've now made a list on of all the extensions I've seen RFCs or drafts for. I fully admit there are probably others; please look over the table and let me know what needs to be added or changed. And, for those of you on Cyrus' list that don't have drafts for your proposals: please write up an I-D! They're not that hard to put together, and they let everyone have a chance to use your work. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-imapext Fri Apr 10 13:47:59 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id NAA14638 for ietf-imapext-bks; Fri, 10 Apr 1998 13:47:59 -0700 (PDT) Received: from starfish.netscape.com (h-205-217-237-33.netscape.com [205.217.237.33]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id NAA14634 for ; Fri, 10 Apr 1998 13:47:58 -0700 (PDT) Received: from continuity.mcom.com (continuity.mcom.com [205.217.237.112]) by starfish.netscape.com (8.7.5/8.7.3) with SMTP id NAA17618 for <@starfish.mcom.com:ietf-imapext@imc.org>; Fri, 10 Apr 1998 13:48:18 -0700 (PDT) Received: from continuity.mcom.com (localhost [127.0.0.1]) by continuity.mcom.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id NAA22141 for ; Fri, 10 Apr 1998 13:48:17 -0700 To: ietf-imapext@imc.org Path: not-for-mail From: John Gardiner Myers Newsgroups: mcom.list.ietf-imapext Subject: Re: Proposed charter Date: Fri, 10 Apr 1998 13:48:39 -0700 Organization: Netscape Communications Corporation Lines: 6 Message-ID: <352E85A5.1136F2D1@netscape.com> References: <3156093156.892214323@ephesus.cyrusoft.com> NNTP-Posting-Host: 198.93.95.149 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.04 (Macintosh; U; PPC) Sender: owner-ietf-imapext@imc.org Precedence: bulk Last I heard, UIDPLUS is in AD review prior to Last Call. I sent in the request during the last IETF. Hopefully, Last Call will be issued soon. I'll propose the following addition to the charter: Revising the base IMAP4rev1 spec is out of the scope of this WG. From owner-ietf-imapext Mon Apr 13 08:10:57 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id IAA09694 for ietf-imapext-bks; Mon, 13 Apr 1998 08:10:57 -0700 (PDT) Received: from rembrandt.esys.ca (502@rembrandt.esys.ca [198.161.92.18]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id IAA09690 for ; Mon, 13 Apr 1998 08:10:55 -0700 (PDT) Received: from gallileo.esys.ca (gallileo.esys.ca [198.161.92.85]) by rembrandt.esys.ca (2.0.2/8.8.8) with ESMTP id JAA24522 for ; Mon, 13 Apr 1998 09:11:28 -0600 From: Steve Hole Date: Mon, 13 Apr 1998 09:11:24 -0600 To: ietf-imapext@imc.org Subject: Re: Proposed charter In-Reply-To: <000501bd6410$2eecff20$57fd3b9d@mikega8.mikega> References: <000501bd6410$2eecff20$57fd3b9d@mikega8.mikega> Message-ID: X-Mailer: Simeon for Win32 Version Mercury a7 Build (8) MIME-Version: 1.0 Content-Type: Text/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@imc.org Precedence: bulk On Thu, 9 Apr 1998 16:35:30 -0700 Mike Gahrns wrote: > *** Well consensus seemed to have been reached on the list on this, and it > has gone through the Last Call process with no further comments. In > speaking with Harald and Keith, the IESG has approved this as an RFC, > although the number has not come out yet. > > Were you thinking of a particular problem with the draft? If so, then we > definitely should discuss, but from what I could tell, thinks were pretty > much wrapped up... I was happy with it. At least to the point where we need some operational experience to base changes on. I was probing to see if there were any last minute issues with it. Just about all the discussion on this extension was done on the list, and I'm not sure I always trust the results in such a case. Cheers. --- Steve Hole The Esys Corporation Mailto:Steve.Hole@esys.ca Phone:403-424-4922 From owner-ietf-imapext Fri May 22 07:47:04 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA21503 for ietf-imapext-bks; Fri, 22 May 1998 07:47:04 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA21499 for ; Fri, 22 May 1998 07:47:03 -0700 (PDT) Received: from ephesus.cyrusoft.com (ephesus.cyrusoft.com [206.31.218.204]) by darius.cyrusoft.com (8.8.5/8.8.5) with SMTP id KAA02427; Fri, 22 May 1998 10:49:57 -0400 (EDT) Date: Fri, 22 May 1998 10:50:34 -0400 From: "Cyrus Daboo" To: IMAP@cac.washington.edu cc: ietf-imapext@imc.org Subject: SEARCHing for empty fields and extendeing the SEARCH command? Message-ID: <2481037089.895834234@ephesus.cyrusoft.com> In-Reply-To: X-Mailer: Mulberry (Win32) [1.4.0a4, s/n S1-000001] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@imc.org Precedence: bulk Maybe I'm being stupid here, but is there not a way to do a search for messages that either contain an empty field or don't have a particular header present? All the search criteria seem to expect an 'astring', but what I would really like is an 'nstring' so that I could say 'SEARCH SUBJECT NIL' or 'SEARCH TO NIL' to find all messages with an empty subject line or To field - you might see why this could be useful! Along the same lines how much interest is there from vendors for having an enhanced SEARCH command be considered by IMAPEXT? I'm thinking there are many more useful things that could be done with SEARCH - even simple changes like allowing wildcards in string matches. Since search engines have been getting more and more sophisticated (having been driven by the Web) it makes sense to allow similar types of sophisticted searching in IMAP too. I'm sure those vendors with database backends on their servers would be keen on this. Comments? --Cyrus Daboo From owner-ietf-imapext Sat May 23 20:36:52 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA20529 for ietf-imapext-bks; Sat, 23 May 1998 20:36:52 -0700 (PDT) Received: from ferry.rbc.ru (ferry.rbc.ru [194.135.176.160]) by mail.proper.com (8.8.8/8.8.5) with SMTP id UAA20525 for ; Sat, 23 May 1998 20:36:51 -0700 (PDT) From: L4yvn3N0Q@trad7.no Received: (qmail 9121 invoked from network); 24 May 1998 03:34:06 -0000 Received: from rbc.rbc.ru (195.218.138.2) by ferry.rbc.ru with SMTP; 24 May 1998 03:34:06 -0000 Received: from RBC4_1/SpoolDir by RBC.rbc.ru (Mercury 1.21); 24 May 98 07:34:07 +0300 Received: from SpoolDir by RBC4_1 (Mercury 1.21); 24 May 98 07:32:51 +0300 Received: from NWPo0fWyu by RBC.rbc.ru (Mercury 1.21); 24 May 98 07:31:59 +0300 DATE: 23 May 98 11:36:30 PM Message-ID: TO: maybe@tene44r.de SUBJECT: Let Us Do It For You! Sender: owner-ietf-imapext@imc.org Precedence: bulk LET US DO YOUR BULK E-MAIL ADVERTISING!!! $600 PER MILLION (5 MILLION OR MORE $500 PER MILLION) $450 PER 1/2 MILLION These prices are non-targeted. THE WAY OF THE FUTURE FOR SUCCESS IN YOUR BUSINESS! Let our company do mailing for your product/service, newsletter/report or client list. Addresses are extracted 24 hours a day 7 days a week, scanning the net for new addresses. Estimated 150-200,000 addresses extracted daily. They are fresh! Over 55 million addresses on file. No more than 2 pages (50 lines), no porn, no sexual relative material and no foul language. Each ad must be no more than 50 characters wide by 50 lines deep. ***Targeted mailings: $200 per 50,000 addresses or less extracted. $125 per 25,000 addresses or less extracted. We can extract by city, country, occupation, organizations, associations, product, website, state, megatags (keywords), etc. If we can not search and extract what you need, then nobody can. No one can target your mailing for less. If interested in purchasing targeted addresses: $10 per 1,000 up to 100,000 (min. 10,000) $7.50 per 1,000 over 100,000 & up to 500,000 $5.00 per 1,000 over 500,000 ***SPECIAL*** Targeted US ADDRESSES ONLY $750 per 1/2 million. A savings of $1,250. We have over 10 million addresses, non AOL, and collecting more each day. There are no lower prices on the net. Your mailing can be done in a matter of hours, instead of days. For the fastest service, cheapest prices and cleanest mailings call our processing and new accounts department at 904-282-0945, Monday - Friday 9 - 5 EST. If the line is busy or no answer, please keep trying, as bulk mailing is growing fast. We do want to work with you to advertise your product. Check out our prices and compare with other bulk emailers, you will find we have the BESt prices anywhere. In fact, we do bulk mailings for many other bulk emailers. To have yourname@domain removed, call our processing department. Any negative responses will be dealt with accordingly. From owner-ietf-imapext Fri Jul 31 18:31:54 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA07231 for ietf-imapext-bks; Fri, 31 Jul 1998 18:31:54 -0700 (PDT) Received: from doggate.exchange.microsoft.com (doggate.Exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA07227 for ; Fri, 31 Jul 1998 18:31:51 -0700 (PDT) Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Fri, 31 Jul 1998 18:33:17 -0700 Message-ID: <2FBF98FC7852CF11912A0000000000010C992424@DINO> From: "Mike Gahrns (Exchange)" To: "'jgmyers@netscape.com'" , ietf-imapext@imc.org Cc: "'moore@cs.utk.edu'" , "'paf@swip.net'" , "Mark Pustilnik (Exchange)" Subject: Will there be an IMAP Extension WG at the Chicago IETF? Date: Fri, 31 Jul 1998 18:33:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-imapext@imc.org Precedence: bulk I could not find an imap extensions working listed on the chicago agenda. The IETF web site says that working group scheduling closes August 3 at 17:00 ET. Is an IMAP Extension WG still planned for chicago? thanks -----Original Message----- From: jgmyers@netscape.com [mailto:jgmyers@netscape.com] Sent: Thursday, April 09, 1998 10:48 AM To: ietf-imapext@imc.org Subject: FROM THE CHAIR: Introduction to ietf-imapext The ietf-imapext@imc.org mailing list is now accepting submissions. I will be the chair of the imapext BOF at the August 98 IETF. Since I will probably be a document editor for the imapext WG (should it form), the chair of the WG will likely be someone else. Messages I send to the list in the role of BOF chair will have the prefix "FROM THE CHAIR" in the Subject:. All other messages I send to the list are in my role as individual contributor. The first task of this mailing list is to discuss the need and scope of a possible imapext Working Group and to propose a charter for such a group. At this time, discussion of proposed IMAP extensions is only appropriate insofar as it is relevant to defining the need, scope, and charter of this proposed Working Group. Detailed debate about any contentious issues in proposed extensions is inappropriate at this time--it will become appropriate only after we have rough consensus on a charter. From owner-ietf-imapext Fri Jul 31 21:21:22 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA07732 for ietf-imapext-bks; Fri, 31 Jul 1998 21:21:22 -0700 (PDT) Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA07728 for ; Fri, 31 Jul 1998 21:21:21 -0700 (PDT) Received: from spot.cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id AAA01088; Sat, 1 Aug 1998 00:23:06 -0400 (EDT) Message-Id: <199808010423.AAA01088@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Mike Gahrns (Exchange)" cc: "'jgmyers@netscape.com'" , ietf-imapext@imc.org, "'moore@cs.utk.edu'" , "'paf@swip.net'" , "Mark Pustilnik (Exchange)" , moore@cs.utk.edu Subject: Re: Will there be an IMAP Extension WG at the Chicago IETF? In-reply-to: Your message of "Fri, 31 Jul 1998 18:33:20 PDT." <2FBF98FC7852CF11912A0000000000010C992424@DINO> Date: Sat, 01 Aug 1998 00:23:06 -0400 Sender: owner-ietf-imapext@imc.org Precedence: bulk > I could not find an imap extensions working listed on the chicago agenda. > > The IETF web site says that working group scheduling closes August 3 at > 17:00 ET. Is an IMAP Extension WG still planned for chicago? Yes, we do have a slot reserved. It's just that the secretariat won't list any BOFs in the schedule until they have 1. a chairperson 2. a description 3. a preliminary agenda So somebody needs to send these for imapext to agenda@ietf.org I didn't find this out until today, and my email has been down all day, which is why you're just now hearing about it. Keith From owner-ietf-imapext Thu Aug 6 15:15:58 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA06233 for ietf-imapext-bks; Thu, 6 Aug 1998 15:15:58 -0700 (PDT) Received: from starfish.netscape.com (h-205-217-237-33.netscape.com [205.217.237.33]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA06229 for ; Thu, 6 Aug 1998 15:15:57 -0700 (PDT) Received: from continuity.mcom.com (continuity.mcom.com [205.217.237.112]) by starfish.netscape.com (8.7.5/8.7.3) with SMTP id PAA27728 for <@starfish.mcom.com:ietf-imapext@imc.org>; Thu, 6 Aug 1998 15:17:56 -0700 (PDT) Received: from continuity.mcom.com (localhost [127.0.0.1]) by continuity.mcom.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id PAA03672 for ; Thu, 6 Aug 1998 15:17:55 -0700 To: ietf-imapext@imc.org Path: not-for-mail From: John Gardiner Myers Newsgroups: mcom.list.ietf-imapext Subject: Proposed charter Date: Thu, 06 Aug 1998 15:17:53 -0700 Organization: Netscape Communications Corporation Lines: 37 Message-ID: <35CA2B91.23E34D60@netscape.com> NNTP-Posting-Host: 208.12.60.63 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.5b1 [en] (WinNT; U) X-Accept-Language: en Sender: owner-ietf-imapext@imc.org Precedence: bulk To remind people, the proposed charter is as follows: Chair(s): TBD Mailing Lists: General discussion: ietf-imapext@imc.org To Subscribe: ietf-imap-request@imc.org Archive: http://www.imc.org/ietf-imapext/ Description of Working Group: The IETF IMAP extensions Working Group shall revise and publish standards-track extensions to IMAP4 for performing the following functions: 1) Access Control Lists 2) Sorting 3) Threading 4) Message-level annotations Revising the base IMAP4rev1 specification is out of the scope of this WG. Goals and Milestones: August 98 Approve charter Dec 98 Submit revised ACL spec to IESG Mar 99 Submit revised Sorting/Threading spec(s) to IESG August 99 Submit annotation spec to IESG From owner-ietf-imapext Fri Aug 7 17:14:35 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA04906 for ietf-imapext-bks; Fri, 7 Aug 1998 17:14:35 -0700 (PDT) Received: from tide03.microsoft.com (firewall-user@tide03.microsoft.com [131.107.3.13]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA04902 for ; Fri, 7 Aug 1998 17:14:34 -0700 (PDT) Received: by tide03.microsoft.com; id RAA19555; Fri, 7 Aug 1998 17:17:04 -0700 (PDT) Received: from unknown(157.54.17.74) by tide03.microsoft.com via smap (V3.1) id xma019549; Fri, 7 Aug 98 17:16:55 -0700 Received: from red-01-imc.dns.microsoft.com ([157.54.1.197]) by imail2.microsoft.com (8.7.3/8.7.1) with ESMTP id RAA22834; Fri, 7 Aug 1998 17:27:22 -0700 (PDT) Received: from popdog.exchange.microsoft.com (POPDOG [172.30.236.242]) by red-01-imc.dns.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id QMVCHA2G; Fri, 7 Aug 1998 17:16:56 -0700 Received: from MIKEGA9 ([157.59.255.141]) by popdog.exchange.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id QJBJPWXV; Fri, 7 Aug 1998 17:17:48 -0700 Message-ID: <000a01bdc262$3439d1f0$8dff3b9d@mikega9.dns.microsoft.com> From: "Mike Gahrns" To: , "John Gardiner Myers" Subject: Re: Proposed charter Date: Fri, 7 Aug 1998 17:19:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-imapext@imc.org Precedence: bulk Did we now get an official slot on the IETF agenda? Its still not showing up on the ietf web site.... For those unable to attend the entire IETF week, it would be helpful to know when this is scheduled for in regards to making our travel arrangements. thanks -----Original Message----- From: John Gardiner Myers Newsgroups: mcom.list.ietf-imapext To: ietf-imapext@imc.org Date: Thursday, August 06, 1998 3:21 PM Subject: Proposed charter >To remind people, the proposed charter is as follows: > >Chair(s): > >TBD > >Mailing Lists: > >General discussion: ietf-imapext@imc.org >To Subscribe: ietf-imap-request@imc.org >Archive: http://www.imc.org/ietf-imapext/ > > >Description of Working Group: > >The IETF IMAP extensions Working Group shall revise and publish >standards-track extensions to IMAP4 for performing the following >functions: > >1) Access Control Lists >2) Sorting >3) Threading >4) Message-level annotations > >Revising the base IMAP4rev1 specification is out of the scope of this >WG. > > >Goals and Milestones: > >August 98 Approve charter > >Dec 98 Submit revised ACL spec to IESG > >Mar 99 Submit revised Sorting/Threading spec(s) to IESG > >August 99 Submit annotation spec to IESG > From owner-ietf-imapext Fri Aug 7 21:03:15 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA06114 for ietf-imapext-bks; Fri, 7 Aug 1998 21:03:15 -0700 (PDT) Received: from vadar.mcom.com (h-207-1-141-5.netscape.com [207.1.141.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA06110 for ; Fri, 7 Aug 1998 21:03:14 -0700 (PDT) Received: from netscape.com ([198.93.95.141]) by vadar.mcom.com (Netscape Messaging Server 4.0b2 ) with ESMTP id 0EXCRBI0.03U for ; Fri, 7 Aug 1998 21:04:30 -0700 Message-ID: <35CBCE87.599BC832@netscape.com> Date: Fri, 07 Aug 1998 21:05:27 -0700 From: John Gardiner Myers X-Mailer: Mozilla 4.5b1 (Macintosh; U; PPC) X-Accept-Language: English [en] MIME-Version: 1.0 To: ietf-imapext@imc.org Subject: Re: Proposed charter References: <000a01bdc262$3439d1f0$8dff3b9d@mikega9.dns.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@imc.org Precedence: bulk Mike Gahrns wrote: > For those unable to attend the entire IETF week, it would be helpful to know > when this is scheduled for in regards to making our travel arrangements. It's scheduled Tuesday 10:15. I only recently got the agenda in, so it should show up soon. From owner-ietf-imapext Mon Dec 7 13:01:22 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA21858 for ietf-imapext-bks; Mon, 7 Dec 1998 13:01:22 -0800 (PST) Received: from smtprich (smtprich.nortel.com [192.135.215.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA21854 for ; Mon, 7 Dec 1998 13:01:21 -0800 (PST) Received: from zrtpd004.us.nortel.com (actually nrtpd004) by smtprich; Mon, 7 Dec 1998 15:03:39 -0600 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.0.1460.8) id ; Mon, 7 Dec 1998 15:31:37 -0500 Message-ID: From: "Glenn Parsons" To: ietf-imapext@imc.org, imap@u.washington.edu Cc: vpim-l@ema.org Subject: IMAP extensions for voice messaging Date: Mon, 7 Dec 1998 15:31:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-ietf-imapext@imc.org Precedence: bulk Folks, For those who are interested there will be a short discussion on requirements (and maybe some possible solutions) for IMAP extensions for voice messaging at the Orlando IETF. I think the feeling is that this would be outside the scope of the proposed IMAPEXT BOF that met in Chicago. Essentially, we are initially thinking of a short list of IMAP extensions that would assist voice mail (and likely 'unified messaging') systems: - binary attachment transfer - external reference (e.g., use phone for playback) - alternate codec request (i.e., server please transcode) - streaming audio attachments Actually the extensions may become a part of VPIM (RFC2421) and not require any extensions 'per se' in IMAP. If you are interested, please join us in Pelican B, Tuesday at 1pm. Cheers, Glenn. From owner-ietf-imapext Tue Dec 15 11:31:02 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA08246 for ietf-imapext-bks; Tue, 15 Dec 1998 11:31:02 -0800 (PST) Received: from smtpott1.nortel.ca (smtpott1.nortel.ca [192.58.194.78]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA08242 for ; Tue, 15 Dec 1998 11:31:01 -0800 (PST) Received: from zcard00m.ca.nortel.com by smtpott1; Tue, 15 Dec 1998 14:36:25 -0500 Received: by zcard00m.ca.nortel.com with Internet Mail Service (5.0.1460.8) id ; Tue, 15 Dec 1998 14:36:23 -0500 Message-ID: From: "Glenn Parsons" To: "'vpim-l@ema.org'" , "'ietf-imapext@imc.org'" , "'discuss@apps.ietf.org'" Subject: IMAP extensions for voice Date: Tue, 15 Dec 1998 14:36:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-ietf-imapext@imc.org Precedence: bulk Folks, Following on from the informal BOF in Orlando we have set up a mailing list to discuss extensions to IMAP4 in support of voice messaging system requirements. The goal is to standardize these extensions in the IETF. As discussed in Orlando, the current featrues of interest are: - Binary attachment transfer - External reference (e.g., use phone for playback) - Alternate codec request (i.e., server please transcode) - Streaming audio attachments - Message length indicator (seconds for voice, pages for fax) - Body part read indicator (separate for voice, fax and other) > To subscribe to the mailing list, send a message to > ietf-imap-voice-request@imc.or > with the single word > subscribe > in the body of the message. There is a description of the list and archive > at . > Cheers, Glenn From owner-ietf-imapext Fri Jan 15 10:24:05 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23721 for ietf-imapext-bks; Fri, 15 Jan 1999 08:44:12 -0800 (PST) Received: (from phoffman@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23661; Fri, 15 Jan 1999 08:43:40 -0800 (PST) Date: Fri, 15 Jan 1999 08:43:40 -0800 (PST) Message-Id: <199901151643.IAA23661@mail.proper.com> From: List Manager of ietf-imapext To: ietf-imapext@imc.org Subject: How to be removed from this list Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Greetings again. Occasionally, people will sign up for a mailing list and forget how to be removed. This message is a reminder for those folks. First off, when you subscribe to a mailing list, you almost always get a first message from the list owner telling you about the mailing list, and explaining how to unsubscribe. It is always a good idea to keep those messages, since you never know when you will need to unsubscribe. This is particularly useful when you change email addresses, because it is difficult to unsubscribe from a list after you have a different mailing address. In the case of this list, the method to unsubscribe is to send a message to: ietf-imapext-request@imc.org with the single word: unsubscribe in the body of the message. This is the same as it always has been. To make this easier for you, I have crafted this message so that you should be able to simply reply to this message, and the reply address should be ietf-imapext-request@imc.org (although some mail clients screw this up...). Remove everything from the body of the reply, and put in the single word: unsubscribe If you have tried this method, and the mailing list software won't let you unsubscribe, it is probably because your address has changed. In that case, please send a message to subs@imc.org stating which list (or lists) you want to unsubscribe from, and what you think your previous address was. There is a human (that's me!) who will then try to take care of your request, often within a few days. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-imapext Tue Mar 30 07:06:15 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA09727 for ietf-imapext-bks; Tue, 30 Mar 1999 07:06:15 -0800 (PST) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA09723 for ; Tue, 30 Mar 1999 07:06:14 -0800 (PST) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id KAA02658 for ; Tue, 30 Mar 1999 10:06:16 -0500 Received: from aspen.watson.ibm.com (aspen.watson.ibm.com [9.2.3.31]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id KAA03382 for ; Tue, 30 Mar 1999 10:06:15 -0500 Received: from mars.watson.ibm.com by aspen.watson.ibm.com (IBM OS/2 SENDMAIL VERSION 2.0/ISSC1.0) id KAA041.24; Tue, 30 Mar 1999 10:06:04 -0500 From: Barry Leiba Date: Tue, 30 Mar 1999 10:06:14 -0500 To: ietf-imapext@imc.org Subject: IMAPExt discussion at 44th IETF Message-ID: X-Mailer: Execmail for Win32 Version 5.0 Build (41) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii"; name="ipm.txt" Content-Disposition: inline; filename="ipm.txt" Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Those of us who were at the 44th IETF in Minneapolis got together on Wednesday afternoon to discuss some IMAP extensions issues and to get ready to get the IMAPEXT working group started for real. I took some notes at the gathering, and I'm posting them here to start some discussion. They aren't terribly detailed, so details will have to be filled in during the discussion. I can also post, if someone would like, the notes my Mark Pustilnik and Chris Newman, proposing (and counter-proposing) how the extended SELECT, referred to below, should work. Of course, people should feel free to correct errors and fill in gaps in my notes, as appropriate. Barry Leiba, Internet Messaging Technology (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba -------- IMAP Ext -------- Goal: start IMAPext activity in Oslo. Work items: Sort, Thread, ACL, Annotate (not I18n) Authors... Annotate: Chris -transfer to-> Cyrus & Steve Sort: Mark C Sorted view: ? ask Mark P Thread: Mark C has ideas ACL: ? Discussion of Mark P/Chris proposal. Server advertises capability. Optional sort & search parameters on select/examine. Sequence numbers now reflect sorted order -- client behaves as usual. New/changed server responses (MOVE, REMOVE, NEW, VIEW?). 1. Should client be told about messages outside view? 2. Should view change or be static (add only)? 3. How does this dovetail (or not) with Mark C's sort & view? Discussion of threads 1. How to represent the tree/graph 2. Multiple parents are difficult. 3. Does this interact with view? 4. Is it sufficient to give, for each message, the UID of the nearest parent that's in the view, and the number of missing levels (not in view)? Thread experimental? Limit thread to simple hierarchy (no multi-parent)? Can we do sort *before* thread, without worrying too much about interaction? Thread on view: "Show me the treeness of this set" (Pete R) Consensus: Select extension is good... go ahead with it. Continue working on thread -- orthogonal. Threading, using additional fetch attributes -- investigate. Pete prompts Mark P to draft something & post to mailing list. Alexei is second choice, maybe Cyrus. ----------------------------------------------------------------- From owner-ietf-imapext Tue Mar 30 12:28:51 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA13363 for ietf-imapext-bks; Tue, 30 Mar 1999 12:28:51 -0800 (PST) Received: from smtp1.cern.ch (smtp1.cern.ch [137.138.128.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA13359 for ; Tue, 30 Mar 1999 12:28:48 -0800 (PST) Received: from cern.ch (csacbp12.cern.ch [137.138.245.32]) by smtp1.cern.ch (8.9.3/8.9.3) with ESMTP id WAA15672; Tue, 30 Mar 1999 22:27:31 +0200 (MET DST) X-Authentication-Warning: smtp1.cern.ch: Host csacbp12.cern.ch [137.138.245.32] claimed to be cern.ch Message-ID: <370135B4.9AA56A4E@cern.ch> Date: Tue, 30 Mar 1999 22:36:04 +0200 From: Arnaud Taddei X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en,fr-FR MIME-Version: 1.0 To: Barry Leiba CC: ietf-imapext@imc.org, imap@u.washington.edu Subject: Re: IMAPExt discussion at 44th IETF References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: I don't know if this should be discussed here or if it is the right timing for that but some long time ago it was discussed the possibility to have a CLIENTINFO command. I believe that this command doesn't exist for IMAP. Although I can see some drawbacks, it would be extremely useful from a service point of view to capture a string which would declare what client from which platform is connecting to the IMAP server. There are rather clear needs for user support and statistics/service deployment point of view. Any chance to see this as an IMAP extension? Is it that terrible? Barry Leiba wrote: > > Those of us who were at the 44th IETF in Minneapolis got together on > Wednesday afternoon to discuss some IMAP extensions issues and to get ready > to get the IMAPEXT working group started for real. I took some notes at > the gathering, and I'm posting them here to start some discussion. They > aren't terribly detailed, so details will have to be filled in during the > discussion. I can also post, if someone would like, the notes my Mark > Pustilnik and Chris Newman, proposing (and counter-proposing) how the > extended SELECT, referred to below, should work. > > Of course, people should feel free to correct errors and fill in gaps in my > notes, as appropriate. > > Barry Leiba, Internet Messaging Technology (leiba@watson.ibm.com) > http://www.research.ibm.com/people/l/leiba > > -------- > IMAP Ext > -------- > Goal: start IMAPext activity in Oslo. > Work items: Sort, Thread, ACL, Annotate (not I18n) > > Authors... > Annotate: Chris -transfer to-> Cyrus & Steve > Sort: Mark C > Sorted view: ? ask Mark P > Thread: Mark C has ideas > ACL: ? > > Discussion of Mark P/Chris proposal. > Server advertises capability. > Optional sort & search parameters on select/examine. > Sequence numbers now reflect sorted order -- client behaves as usual. > New/changed server responses (MOVE, REMOVE, NEW, VIEW?). > 1. Should client be told about messages outside view? > 2. Should view change or be static (add only)? > 3. How does this dovetail (or not) with Mark C's sort & view? > > Discussion of threads > 1. How to represent the tree/graph > 2. Multiple parents are difficult. > 3. Does this interact with view? > 4. Is it sufficient to give, for each message, the UID of the nearest > parent that's in the view, and the number of missing levels (not in view)? > > Thread experimental? > Limit thread to simple hierarchy (no multi-parent)? > Can we do sort *before* thread, without worrying too much about interaction? > Thread on view: "Show me the treeness of this set" (Pete R) > > Consensus: > Select extension is good... go ahead with it. > Continue working on thread -- orthogonal. > Threading, using additional fetch attributes -- investigate. > > Pete prompts Mark P to draft something & post to mailing list. Alexei is > second choice, maybe Cyrus. > ----------------------------------------------------------------- -- ------------------------------------------------------------ Arnaud Taddei tel: +41 22 767 9349 IT Division 31 1-016 fax: +41 22 767 7155 CERN mail: Arnaud.Taddei@cern.ch CH-1211 Geneve 23 URL: http://wwwinfo.cern.ch/~taddei ------------------------------------------------------------ From owner-ietf-imapext Tue Mar 30 12:47:54 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA13555 for ietf-imapext-bks; Tue, 30 Mar 1999 12:47:54 -0800 (PST) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA13551 for ; Tue, 30 Mar 1999 12:47:53 -0800 (PST) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id PAA125804; Tue, 30 Mar 1999 15:47:55 -0500 Received: from mars (mars.watson.ibm.com [9.2.2.58]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id PAA26758; Tue, 30 Mar 1999 15:47:55 -0500 Message-ID: <00d501be7aee$95de94f0$3a020209@watson.ibm.com> From: "Barry Leiba" To: Cc: References: <370135B4.9AA56A4E@cern.ch> Subject: Re: IMAPExt discussion at 44th IETF Date: Tue, 30 Mar 1999 15:47:54 -0500 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 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Arnaud Taddei says... > I don't know if this should be discussed here or if it is the right First, let's please *not* start discussing things in two places. One thing is clear: the IMAPEXT working group does not have this issue on its charter, so let's keep any discussion of this on the IMAP mailing list. Please remove the cc for imapext from any replies to this. > timing for that but some long time ago it was discussed the possibility > to have a CLIENTINFO command. I believe that this command doesn't exist > for IMAP. Although I can see some drawbacks, it would be extremely > useful from a service point of view to capture a string which would > declare what client from which platform is connecting to the IMAP > server. There's an obsolete draft by Tim Showalter for the "ID" command, which allows a client to announce its name, vendor, version number, and such to the server and get the server's corresponding information in return. In fact, my server implements this, just because it was trivial to do, but I know of no other server or client that does. There simply wasn't enough interest in it to carry it further, and people were worried (rightly so) that some implementations would use this to tailor their behaviour to certain other implementations, at the expense of interoperability. Barry Leiba, Internet Messaging Technology (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba From owner-ietf-imapext Tue Mar 30 12:47:44 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA13545 for ietf-imapext-bks; Tue, 30 Mar 1999 12:47:44 -0800 (PST) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA13541 for ; Tue, 30 Mar 1999 12:47:43 -0800 (PST) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id PAA124514; Tue, 30 Mar 1999 15:47:46 -0500 Received: from mars (mars.watson.ibm.com [9.2.2.58]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id PAA22398; Tue, 30 Mar 1999 15:47:45 -0500 Message-ID: <00d401be7aee$90114a90$3a020209@watson.ibm.com> From: "Barry Leiba" To: Cc: References: <370135B4.9AA56A4E@cern.ch> Subject: Re: IMAPExt discussion at 44th IETF Date: Tue, 30 Mar 1999 15:47:44 -0500 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 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Arnaud Taddei says... > I don't know if this should be discussed here or if it is the right First, let's please *not* start discussing things in two places. One thing is clear: the IMAPEXT working group does not have this issue on its charter, so let's keep any discussion of this on the IMAP mailing list. Please remove the cc for imapext from any replies to this. > timing for that but some long time ago it was discussed the possibility > to have a CLIENTINFO command. I believe that this command doesn't exist > for IMAP. Although I can see some drawbacks, it would be extremely > useful from a service point of view to capture a string which would > declare what client from which platform is connecting to the IMAP > server. There's an obsolete draft by Tim Showalter for the "ID" command, which allows a client to announce its name, vendor, version number, and such to the server and get the server's corresponding information in return. In fact, my server implements this, just because it was trivial to do, but I know of no other server or client that does. There simply wasn't enough interest in it to carry it further, and people were worried (rightly so) that some implementations would use this to tailor their behaviour to certain other implementations, at the expense of interoperability. Barry Leiba, Internet Messaging Technology (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba From owner-ietf-imapext Tue Mar 30 12:47:57 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA13564 for ietf-imapext-bks; Tue, 30 Mar 1999 12:47:57 -0800 (PST) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA13560 for ; Tue, 30 Mar 1999 12:47:56 -0800 (PST) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id PAA04468; Tue, 30 Mar 1999 15:47:58 -0500 Received: from mars (mars.watson.ibm.com [9.2.2.58]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id PAA18318; Tue, 30 Mar 1999 15:47:58 -0500 Message-ID: <00d601be7aee$9792d4a0$3a020209@watson.ibm.com> From: "Barry Leiba" To: Cc: References: <370135B4.9AA56A4E@cern.ch> Subject: Re: IMAPExt discussion at 44th IETF Date: Tue, 30 Mar 1999 15:47:57 -0500 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 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Arnaud Taddei says... > I don't know if this should be discussed here or if it is the right First, let's please *not* start discussing things in two places. One thing is clear: the IMAPEXT working group does not have this issue on its charter, so let's keep any discussion of this on the IMAP mailing list. Please remove the cc for imapext from any replies to this. > timing for that but some long time ago it was discussed the possibility > to have a CLIENTINFO command. I believe that this command doesn't exist > for IMAP. Although I can see some drawbacks, it would be extremely > useful from a service point of view to capture a string which would > declare what client from which platform is connecting to the IMAP > server. There's an obsolete draft by Tim Showalter for the "ID" command, which allows a client to announce its name, vendor, version number, and such to the server and get the server's corresponding information in return. In fact, my server implements this, just because it was trivial to do, but I know of no other server or client that does. There simply wasn't enough interest in it to carry it further, and people were worried (rightly so) that some implementations would use this to tailor their behaviour to certain other implementations, at the expense of interoperability. Barry Leiba, Internet Messaging Technology (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba From owner-ietf-imapext Tue Mar 30 12:49:44 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA13619 for ietf-imapext-bks; Tue, 30 Mar 1999 12:49:44 -0800 (PST) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA13615 for ; Tue, 30 Mar 1999 12:49:43 -0800 (PST) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id PAA04500; Tue, 30 Mar 1999 15:49:45 -0500 Received: from aspen.watson.ibm.com (aspen.watson.ibm.com [9.2.3.31]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id PAA26730; Tue, 30 Mar 1999 15:49:45 -0500 Received: from mars.watson.ibm.com by aspen.watson.ibm.com (IBM OS/2 SENDMAIL VERSION 2.0/ISSC1.0) id PAA041.58; Tue, 30 Mar 1999 15:49:34 -0500 From: Barry Leiba Date: Tue, 30 Mar 1999 15:49:44 -0500 To: imap@u.washington.edu Subject: Re: IMAPExt discussion at 44th IETF Cc: ietf-imapext@imc.org In-Reply-To: <370135B4.9AA56A4E@cern.ch> References: <370135B4.9AA56A4E@cern.ch> Message-ID: X-Mailer: Execmail for Win32 Version 5.0 Build (41) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii"; name="ipm.txt" Content-Disposition: inline; filename="ipm.txt" Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Arnaud Taddei says... > I don't know if this should be discussed here or if it is the right First, let's please *not* start discussing things in two places. One thing is clear: the IMAPEXT working group does not have this issue on its charter, so let's keep any discussion of this on the IMAP mailing list. Please remove the cc for imapext from any replies to this. > timing for that but some long time ago it was discussed the possibility > to have a CLIENTINFO command. I believe that this command doesn't exist > for IMAP. Although I can see some drawbacks, it would be extremely > useful from a service point of view to capture a string which would > declare what client from which platform is connecting to the IMAP > server. There's an obsolete draft by Tim Showalter for the "ID" command, which allows a client to announce its name, vendor, version number, and such to the server and get the server's corresponding information in return. In fact, my server implements this, just because it was trivial to do, but I know of no other server or client that does. There simply wasn't enough interest in it to carry it further, and people were worried (rightly so) that some implementations would use this to tailor their behaviour to certain other implementations, at the expense of interoperability. Barry Leiba, Internet Messaging Technology (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba From owner-ietf-imapext Tue Mar 30 12:48:06 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA13573 for ietf-imapext-bks; Tue, 30 Mar 1999 12:48:06 -0800 (PST) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA13569 for ; Tue, 30 Mar 1999 12:48:05 -0800 (PST) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id PAA125572; Tue, 30 Mar 1999 15:48:07 -0500 Received: from mars (mars.watson.ibm.com [9.2.2.58]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id PAA14236; Tue, 30 Mar 1999 15:48:07 -0500 Message-ID: <00d701be7aee$9d18b5c0$3a020209@watson.ibm.com> From: "Barry Leiba" To: Cc: References: <370135B4.9AA56A4E@cern.ch> Subject: Re: IMAPExt discussion at 44th IETF Date: Tue, 30 Mar 1999 15:48:06 -0500 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 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Arnaud Taddei says... > I don't know if this should be discussed here or if it is the right First, let's please *not* start discussing things in two places. One thing is clear: the IMAPEXT working group does not have this issue on its charter, so let's keep any discussion of this on the IMAP mailing list. Please remove the cc for imapext from any replies to this. > timing for that but some long time ago it was discussed the possibility > to have a CLIENTINFO command. I believe that this command doesn't exist > for IMAP. Although I can see some drawbacks, it would be extremely > useful from a service point of view to capture a string which would > declare what client from which platform is connecting to the IMAP > server. There's an obsolete draft by Tim Showalter for the "ID" command, which allows a client to announce its name, vendor, version number, and such to the server and get the server's corresponding information in return. In fact, my server implements this, just because it was trivial to do, but I know of no other server or client that does. There simply wasn't enough interest in it to carry it further, and people were worried (rightly so) that some implementations would use this to tailor their behaviour to certain other implementations, at the expense of interoperability. Barry Leiba, Internet Messaging Technology (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba From owner-ietf-imapext Thu Apr 15 07:15:35 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA18838 for ietf-imapext-bks; Thu, 15 Apr 1999 07:15:35 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA18834 for ; Thu, 15 Apr 1999 07:15:19 -0700 (PDT) Received: from ephesus.cyrusoft.com (ephesus.cyrusoft.com [206.31.218.204]) by darius.cyrusoft.com (8.8.5/8.8.5) with ESMTP id KAA08538; Thu, 15 Apr 1999 10:15:24 -0400 (EDT) Date: Thu, 15 Apr 1999 10:15:09 -0400 From: Cyrus Daboo To: IMAP@u.washington.edu cc: ietf-imapext@imc.org Subject: I-D ACTION:draft-daboo-imap-commandplus-00.txt (fwd) Message-ID: <753340991.924171309@ephesus.cyrusoft.com> Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431 X-Mailer: Mulberry (Win32) [2.0.0d9, s/n S1-000001] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: ---------- Forwarded Message ---------- Date: Thursday, April 15, 1999, 8:24 AM -0400 From: Internet-Drafts@ietf.org To: IETF-Announce Subject: I-D ACTION:draft-daboo-imap-commandplus-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IMAP4 COMMAND+ Extension Author(s) : C. Daboo,B. Leiba Filename : draft-daboo-imap-commandplus-00.txt Pages : 6 Date : 14-Apr-99 The COMMAND+ extension to the Internet Message Access Protocol [IMAP4] defines a formal syntax for extending [IMAP4] commands. This includes adding requirements on future extensions to the [IMAP4] syntax that may add new commands, so that any command in an [IMAP4] session, be it part of the base-specification, or a current or future extension, can be extended in an arbitrary manner, without conflicts in syntax between current or future extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-daboo-imap-commandplus-00.txt 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-commandplus-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-daboo-imap-commandplus-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. ---------- End Forwarded Message ---------- -- Cyrus From owner-ietf-imapext Wed Jun 2 10:10:58 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA21452 for ietf-imapext-bks; Wed, 2 Jun 1999 10:10:58 -0700 (PDT) Received: from resnick1.qualcomm.com (resnick1.qualcomm.com [206.139.85.98]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA21448 for ; Wed, 2 Jun 1999 10:10:56 -0700 (PDT) Received: from dhcp990531114138.qualcomm.com (129.46.215.137) by resnick1.qualcomm.com with ESMTP (Eudora Internet Mail Server 2.2b7); Wed, 2 Jun 1999 12:12:03 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: X-Mailer: Eudora [Macintosh version 4.2b??] Date: Wed, 2 Jun 1999 10:11:57 -0700 To: ietf-imapext@imc.org From: Pete Resnick Subject: IMAPEXT at Oslo? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: There hasn't been a whole lot of action here to charter a WG or have discussions. Do we want to BOF at Oslo for the purpose of chartering a WG? What's the state of affairs? Deadlines are looming. pr -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (619)651-4478, Fax: (619)651-1102 From owner-ietf-imapext Wed Jun 2 10:22:38 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA21620 for ietf-imapext-bks; Wed, 2 Jun 1999 10:22:38 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA21616 for ; Wed, 2 Jun 1999 10:22:37 -0700 (PDT) Received: from ephesus.cyrusoft.com (ephesus.cyrusoft.com [206.31.218.204]) by darius.cyrusoft.com (8.8.5/8.8.5) with ESMTP id NAA08264; Wed, 2 Jun 1999 13:23:31 -0400 (EDT) Date: Wed, 02 Jun 1999 13:22:22 -0400 From: Cyrus Daboo To: Pete Resnick , ietf-imapext@imc.org Subject: Re: IMAPEXT at Oslo? Message-ID: <616806434.928329742@ephesus.cyrusoft.com> In-Reply-To: Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431 X-Mailer: Mulberry (Win32) [2.0.0a2, s/n S1-000001] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: --On Wednesday, June 02, 1999, 10:11 AM -0700 Pete Resnick wrote: > There hasn't been a whole lot of action here to charter a WG or have > discussions. Do we want to BOF at Oslo for the purpose of chartering > a WG? What's the state of affairs? Deadlines are looming. I think we should have a meeting. Ideally we should get the WG setup and running before then so we can do 'real work' in Oslo, though a BOF would be just as good. What's currently holding up chartering of this group? I thought we had a charter bashed out ready to go? Can we make sure a request goes in to the ADs for a meeting in Oslo (be it WG or BOF)? I have a sort draft that is being reviewed by co-authors right now, and hopefully we can get this out to the list soon. There will be some serious debate about this and a face-to-face in Oslo would proove extermely beneficial IMHO. -- Cyrus From owner-ietf-imapext Wed Jun 2 11:21:03 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA22027 for ietf-imapext-bks; Wed, 2 Jun 1999 11:21:03 -0700 (PDT) Received: from tide03.microsoft.com (firewall-user@tide03.microsoft.com [131.107.3.13]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA22023 for ; Wed, 2 Jun 1999 11:21:02 -0700 (PDT) Received: by tide03.microsoft.com; id LAA28038; Wed, 2 Jun 1999 11:22:11 -0700 (PDT) Received: from imail2.dns.microsoft.com(157.54.17.74) by tide03.microsoft.com via smap (V3.1) id xma028031; Wed, 2 Jun 99 11:21:58 -0700 Received: from red-imc-01.dns.microsoft.com ([157.54.4.91]) by imail2.microsoft.com (8.7.3/8.7.1) with ESMTP id LAA07727; Wed, 2 Jun 1999 11:37:38 -0700 (PDT) Received: from ptgate.dns.microsoft.com (PTGATE [172.30.236.86]) by red-imc-01.dns.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id MC9QTRDM; Wed, 2 Jun 1999 11:21:47 -0700 Received: from PTROUTE.dfpt.extest.microsoft.com (PTROUTE [172.30.236.83]) by ptgate.dns.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id LFBL0MYN; Wed, 2 Jun 1999 11:21:50 -0700 Received: from PTDOG.dfpt.extest.microsoft.com ([172.30.236.159]) by PTROUTE.dfpt.extest.microsoft.com with Microsoft SMTPSVC(5.0.2031.2031.2); Wed, 2 Jun 1999 11:22:22 -0700 From: "Mike Gahrns (Platinum)" To: "Cyrus Daboo" , "Pete Resnick" , Subject: RE: IMAPEXT at Oslo? Date: Wed, 2 Jun 1999 11:22:21 -0700 Message-ID: <04855D0BAA0ED311BA7800A0C9C74D0F022015@PTDOG.dfpt.extest.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_1EE12_01BEACEA.2F828440" content-class: urn:content-classes:message/mail X-MS-TNEF-Correlator: <04855D0BAA0ED311BA7800A0C9C74D0F022015@PTDOG.dfpt.extest.microsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 X-OriginalArrivalTime: 02 Jun 1999 18:22:22.0252 (UTC) FILETIME=[DB4B36C0:01BEAD24] Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_1EE12_01BEACEA.2F828440 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I agree whole heartily with Cyrus here. There have been several informal discussions off the list in regards to SORT. As Cyrus mentions, there are a couple of proposals that are close to being issued as drafts. A face to face meeting in Oslo will prove extremely beneficial, as in the early stages of many proposals, a lot more can be accomplished quicker through face to face discussions rather than lengthy email exchanges. At the last IMC interop event in San Jose a few months ago, I think the general consensus of the room was that there should be an IMAPEXT WG at the next meeting. Although not entirely related to the orginal proposed charter of the WG, there was a lot of discussion a few months back on the regular IMAP list regarding LIST Extensions/Childmailbox, etc.. If there is an IMAPEXT WG, a lot of the right people will likely be at OSLO to further discuss this. -----Original Message----- From: Cyrus Daboo [mailto:daboo@cyrusoft.com] Sent: Wednesday, June 02, 1999 10:22 AM To: Pete Resnick; ietf-imapext@imc.org Subject: Re: IMAPEXT at Oslo? --On Wednesday, June 02, 1999, 10:11 AM -0700 Pete Resnick wrote: > There hasn't been a whole lot of action here to charter a WG or have > discussions. Do we want to BOF at Oslo for the purpose of chartering > a WG? What's the state of affairs? Deadlines are looming. I think we should have a meeting. Ideally we should get the WG setup and running before then so we can do 'real work' in Oslo, though a BOF would be just as good. What's currently holding up chartering of this group? I thought we had a charter bashed out ready to go? Can we make sure a request goes in to the ADs for a meeting in Oslo (be it WG or BOF)? I have a sort draft that is being reviewed by co-authors right now, and hopefully we can get this out to the list soon. There will be some serious debate about this and a face-to-face in Oslo would proove extermely beneficial IMHO. -- Cyrus ------=_NextPart_000_1EE12_01BEACEA.2F828440 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IhgSAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAFQAAAFJFOiBJTUFQRVhUIGF0IE9z bG8/APoFAQWAAwAOAAAAzwcGAAIACwAWABUAAwAXAQEggAMADgAAAM8HBgACAAsAFgAXAAMAGQEB CYABACEAAAAxOEJCRTMzODE3MTlEMzExQkE3RTAwQTBDOUM3NEQwRgAvBwEDkAYAVA0AADwAAAAL AAIAAQAAAAMAJgAAAAAAAwAuAAAAAAADADYAAAAAAEAAOQCQbPDaJK2+AR4APQABAAAABQAAAFJF OiAAAAAAHgAxQAEAAAAHAAAATUlLRUdBAAAeAEFAAQAAAAUAAABTTVRQAAAAAB4AQkABAAAAFQAA AG1pa2VnYUBtaWNyb3NvZnQuY29tAAAAAAIBRwABAAAAKgAAAGM9dXM7YT0gO3A9ZGZwdDtsPVBU RE9HLTk5MDYwMjE4MjIyMVotMjY2AAAAHgBwAAEAAAARAAAASU1BUEVYVCBhdCBPc2xvPwAAAAAC AXEAAQAAABsAAAABvq0dt4ry4PMBGRAR07p+AKDJx00PAAFrr+AAHgAwQAEAAAAHAAAATUlLRUdB AAAeAD9AAQAAAAUAAABTTVRQAAAAAB4AQEABAAAAFQAAAG1pa2VnYUBtaWNyb3NvZnQuY29tAAAA AB4AHQ4BAAAAEQAAAElNQVBFWFQgYXQgT3Nsbz8AAAAAAgEJEAEAAAD/BQAA+wUAAGUJAABMWkZ1 e/Dy7AMACgByY3BnMTI14jIDQ3RleAVBAQMB9/8KgAKkA+QHEwKAD/MAUARWPwhVB7IRJQ5RAwEC AGNo4QrAc2V0MgYABsMRJfYzBEYTtzASLBEzCO8J97Y7GB8OMDURIgxgYwBQMwsJAWQzNhZQC6Yg ScQgYQnCIHdoBvAdUFRoZQrAdAMQeR1gacR0aBIgeXJ1BCAd0N0YIC4KogqECoBUHxIdwNRhdh1Q YgnhIBQQIKDacgdAIAuAAhByAMADIHpkBABjHuAAkAIgBCBv7QEgIB6AHVBsBAAFQAuAmiAYIGcL EQQgdG8GAOBPUlQuIBDABCAepfcHgAIwIqIsIyIgUQrAJpE6IAWgdQtQHVAi8CBw8QNgcG9zB0Ak URPgBUB9JrJjF7AUECRiINALgGe3IZAEEApQZB0ABCBkIWDlAYBzJOIgZgDQKSMrI88HgBQgKZMD oE9zF7AeUf5sAyAnsSChDsEYIAeAHjH9INBuARAN4AcxJjAqQSPB/yMyHeEeMSOQHRAHkSeBA4Hv HkAnty7hI2BvBUAEYCiy1wORINAdAGMFoG0LUAQA0x3QKiBxdQ3gaxKBHoD5A2B1Zx6QKysiOiFg JlL/KEIDoB2gKaAegB5ALeALcL8DIA7AE9EpoAeQH1tBBUDHIzMqQAVASU1DIZEOsD8nwS2QIKAC MCOyBhEgSrspAibwZgfRBGACMGgEIL0dEG8mMBzwHoALgGsjI/8wMC5gIWIFoACACfAp8DBT/yMy A2ADcB1gKkEoUyZUM0A9CGBsKiAykgOgOeBBUMBFWFQgV0cdADk0by5gDtEr9ThcbB6ANENu/zHR JcIYIB4xRQEocCoRJHH7IzIFsGcLgCFxJ7QqERPS/zpBPrZBwCY2P4IxpCeBIjj9O7xiANA9QEox PvMkAECgHwrBQUIjZCP0KZJMSVOdQaBFDtA+YSKiL0M9EDdAsDdyBuB4JjAUIGMu/SThSSMTIFEE AEEMMYY+xuZpNGAFQHBlJ9AdoSzzDyNwM9AuE0HiT1NMT38rYwhwNkMiNTzyOEwfZC3tV2JPUoFG c00HkCgAMDCrV2MfZEYDYToepUQBoJk/QCBbN3IkcDpkWjJMQGMewiLwdC4y4V1vH2QGYAIwWaBX CYAuYHMlWwB5JjBKdS5gIDAyMiYwMTleQF4gMDoyMhRAQU0fxVrgIFC7FCAdUFIHkAMAM8A7IZBp FCBmLQdwYVLgDtBAjwdwT7BGQVw1dWJqBZC/XMFf8FmgQUZUQiyxP1ZPfVdRTwOgXP9eBV4RXpAx gjFe0SAtMDcwFlDbX6ofZDwnsGAEQDOQB0B1MuFtW+I+HWADYA6wOu8fampwICZgECcFQCDTJvD/ HXRJRQDQJeIfAyRiR1Ym8L9BwQWxIINrViI5JOBELNHHSMI60SRxQk9GY2YrEPsFsSMycAhwRvIn ckdVKZLba1ZvUj9BsChhJygyQFF/AZBfwW2yASALcBQAdbBE/R3gZCNwZZEmoxewA3BC/v885nGh QHUggybwQrYc4AEA/wdAHjJAVzAwOTRBwRQRJzDvQQELMR+CHtBuAwApoSDQvyHBKSEd0CEBcYMy UmQkgJYnGCAhcXcFsGsnLGZ/JjI0QybwclKBEECkH2Rq/x7gKIEEIDygBHAk4HXVImD+chggAjAe MR2BTWN94XRJ3z7DUJEJwCchdbBJH2REFP8FQHGhE+AqIUdHSzAzQwhgv0zyd8AeQCRxPKB1sEMD kf9xoQDAM9AhEAhwJtIYIDOQfQeQdB9kPKAHkS8yReRB3kQEIHMSezcsZygykR5w+29lclEpY+sc 8HrlW6AAIN8qZChEUJEpdBggdgiQcaDnQMEeQAWgLWGKcB2AFAD7UnVEgHcu4X4mHYBS4FTw/3wl MlJ9BFCRimJF1SNzW6D/AiAk4CAkLPMykVugB4AhEfsFEAhgcx9kAQBLMF/BWjFfmGKHQn4RO7Ir MS0kcC3/KyMsd0CTJ7EtZQSQLfIfZPMuSDnRSE8fW1jmHrMfZAJ9o0AAHgA1EAEAAABJAAAAPDA0 ODU1RDBCQUEwRUQzMTFCQTc4MDBBMEM5Qzc0RDBGMDIyMDE1QFBURE9HLmRmcHQuZXh0ZXN0Lm1p Y3Jvc29mdC5jb20+AAAAAB4AQhABAAAAKwAAADw2MTY4MDY0MzQuOTI4MzI5NzQyQGVwaGVzdXMu Y3lydXNvZnQuY29tPgAAAwCAEP////8LAPIQAQAAAAsA9BAAAAAACwD1EAAAAAALAPYQAAAAAEAA BzASB8zbJK2+AUAACDDo8tfbJK2+AQMA3j+vbwAAAwDxPwkEAAAeADhAAQAAAAcAAABNSUtFR0EA AB4A+j8BAAAAFQAAAFN5c3RlbSBBZG1pbmlzdHJhdG9yAAAAAB4AOUABAAAAAgAAAC4AAAACAfs/ AQAAAB4AAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAALgAAAAMA/T/kBAAAAwAZQAAAAAAD ABpAAAAAAAMACVkBAAAAHgA3gIYDAgAAAAAAwAAAAAAAAEYBAAAAHAAAAGMAbwBuAHQAZQBuAHQA LQBjAGwAYQBzAHMAAAABAAAAIQAAAHVybjpjb250ZW50LWNsYXNzZXM6bWVzc2FnZS9tYWlsAAAA AB4AWYCGAwIAAAAAAMAAAAAAAABGAQAAABgAAAByAGUAdAB1AHIAbgAtAHAAYQB0AGgAAAABAAAA IwAAADxtaWtlZ2FAZGZwdC5leHRlc3QubWljcm9zb2Z0LmNvbT4AAAsAWIEIIAYAAAAAAMAAAAAA AABGAAAAAA6FAAAAAAAAAwBwgQggBgAAAAAAwAAAAAAAAEYAAAAAUoUAACdqAQAeAHGBCCAGAAAA AADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA5LjAAHgCmgQggBgAAAAAAwAAAAAAAAEYAAAAAOIUA AAEAAAABAAAAAAAAAB4Ap4EIIAYAAAAAAMAAAAAAAABGAAAAADeFAAABAAAAAQAAAAAAAAAeAKiB CCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAAwC4gQggBgAAAAAAwAAAAAAAAEYA AAAAAYUAAAAAAAALAL2BCCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMAwoEIIAYAAAAAAMAA AAAAAABGAAAAABGFAAAAAAAAAwDOgQggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAeANmBhgMC AAAAAADAAAAAAAAARgEAAAAUAAAAeAAtAG0AaQBtAGUAbwBsAGUAAAABAAAALQAAAFByb2R1Y2Vk IEJ5IE1pY3Jvc29mdCBNaW1lT0xFIFY1LjAwLjIwMTQuMjExAAAAAB4A2oGGAwIAAAAAAMAAAAAA AABGAQAAACwAAAB4AC0AbwByAGkAZwBpAG4AYQBsAGEAcgByAGkAdgBhAGwAdABpAG0AZQAAAAEA AAA9AAAAMDIgSnVuIDE5OTkgMTg6MjI6MjIuMDI1MiAoVVRDKSBGSUxFVElNRT1bREI0QjM2QzA6 MDFCRUFEMjRdAAAAAAsA24EIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAAAwDcgQggBgAAAAAA wAAAAAAAAEYAAAAAEIUAAAAAAAALACkAAAAAAAsAIwAAAAAAAwAGECeev3IDAAcQJAYAAAMAEBAA AAAAAwAREAAAAAAeAAgQAQAAAGUAAABJQUdSRUVXSE9MRUhFQVJUSUxZV0lUSENZUlVTSEVSRVRI RVJFSEFWRUJFRU5TRVZFUkFMSU5GT1JNQUxESVNDVVNTSU9OU09GRlRIRUxJU1RJTlJFR0FSRFNU T1NPUlRBU0NZAAAAAAIBfwABAAAASQAAADwwNDg1NUQwQkFBMEVEMzExQkE3ODAwQTBDOUM3NEQw RjAyMjAxNUBQVERPRy5kZnB0LmV4dGVzdC5taWNyb3NvZnQuY29tPgAAAADIRw== ------=_NextPart_000_1EE12_01BEACEA.2F828440-- From owner-ietf-imapext Wed Jun 2 14:26:13 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA23614 for ietf-imapext-bks; Wed, 2 Jun 1999 14:26:13 -0700 (PDT) Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA23610 for ; Wed, 2 Jun 1999 14:26:12 -0700 (PDT) Received: from MessagingDirect.COM (zappa.esys.ca [198.161.92.28]) by rembrandt.esys.ca (2.1.2/8.9.1/Execmail 2.1) with ESMTP id PAA05809 for ; Wed, 2 Jun 1999 15:27:24 -0600 Message-Id: <199906022127.PAA05809@rembrandt.esys.ca> Date: Wed, 2 Jun 1999 15:27:21 -0600 From: Lyndon.Nerenberg@messagingdirect.com Subject: Proposed WG worklist from March IMC To: ietf-imapext@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: I recall someone at the March IMAP interop putting together a list of candidate items for the WG. I thought it was Mike G., but he claims no knowledge of this. Would the guilty party please step forward with that list? From owner-ietf-imapext Wed Jun 2 14:36:31 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA23697 for ietf-imapext-bks; Wed, 2 Jun 1999 14:36:31 -0700 (PDT) Received: from tide03.microsoft.com (firewall-user@tide03.microsoft.com [131.107.3.13]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA23692 for ; Wed, 2 Jun 1999 14:36:30 -0700 (PDT) Received: by tide03.microsoft.com; id OAA02939; Wed, 2 Jun 1999 14:37:45 -0700 (PDT) Received: from imail2.dns.microsoft.com(157.54.17.74) by tide03.microsoft.com via smap (V3.1) id xma002937; Wed, 2 Jun 99 14:37:39 -0700 Received: from red-imc-01.dns.microsoft.com ([157.54.4.91]) by imail2.microsoft.com (8.7.3/8.7.1) with ESMTP id OAA10356; Wed, 2 Jun 1999 14:53:19 -0700 (PDT) Received: from ptgate.dns.microsoft.com (PTGATE [172.30.236.86]) by red-imc-01.dns.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id MC9Q4AQP; Wed, 2 Jun 1999 14:37:28 -0700 Received: from PTROUTE.dfpt.extest.microsoft.com (PTROUTE [172.30.236.83]) by ptgate.dns.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id LFBL0RPT; Wed, 2 Jun 1999 14:37:33 -0700 Received: from PTDOG.dfpt.extest.microsoft.com ([172.30.236.159]) by PTROUTE.dfpt.extest.microsoft.com with Microsoft SMTPSVC(5.0.2031.2031.2); Wed, 2 Jun 1999 14:38:04 -0700 From: "Mike Gahrns (Platinum)" To: , Subject: RE: Proposed WG worklist from March IMC Date: Wed, 2 Jun 1999 14:38:03 -0700 Message-ID: <04855D0BAA0ED311BA7800A0C9C74D0F0FB728@PTDOG.dfpt.extest.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_2009A_01BEAD05.8609BF20" content-class: urn:content-classes:message/mail X-MS-TNEF-Correlator: <04855D0BAA0ED311BA7800A0C9C74D0F0FB728@PTDOG.dfpt.extest.microsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 X-OriginalArrivalTime: 02 Jun 1999 21:38:04.0053 (UTC) FILETIME=[31F3DC50:01BEAD40] Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_2009A_01BEAD05.8609BF20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I believe the original proposed charter for the IMAPEXT WG was to cover SORT, Annotate and ACLs. I did not put together that list, but it sounds look a good list to me. -----Original Message----- From: Lyndon.Nerenberg@messagingdirect.com [mailto:Lyndon.Nerenberg@messagingdirect.com] Sent: Wednesday, June 02, 1999 2:27 PM To: ietf-imapext@imc.org Subject: Proposed WG worklist from March IMC I recall someone at the March IMAP interop putting together a list of candidate items for the WG. I thought it was Mike G., but he claims no knowledge of this. Would the guilty party please step forward with that list? ------=_NextPart_000_2009A_01BEAD05.8609BF20 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IgUVAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAKAAAAFJFOiBQcm9wb3NlZCBXRyB3 b3JrbGlzdCBmcm9tIE1hcmNoIElNQwByDQEFgAMADgAAAM8HBgACAA4AJgADAAMAGAEBIIADAA4A AADPBwYAAgAOACYABAADABkBAQmAAQAhAAAANUFGRDVGNkYzMzE5RDMxMUJBN0UwMEEwQzlDNzRE MEYAVAcBA5AGABQKAAA8AAAACwACAAEAAAADACYAAAAAAAMALgAAAAAAAwA2AAAAAABAADkA0Hy6 MUCtvgEeAD0AAQAAAAUAAABSRTogAAAAAB4AMUABAAAABwAAAE1JS0VHQQAAHgBBQAEAAAAFAAAA U01UUAAAAAAeAEJAAQAAABUAAABtaWtlZ2FAbWljcm9zb2Z0LmNvbQAAAAACAUcAAQAAACoAAABj PXVzO2E9IDtwPWRmcHQ7bD1QVERPRy05OTA2MDIyMTM4MDNaLTY2NwAAAB4AcAABAAAAJAAAAFBy b3Bvc2VkIFdHIHdvcmtsaXN0IGZyb20gTWFyY2ggSU1DAAIBcQABAAAAGwAAAAG+rT8VK1LV4RMZ MhHTun4AoMnHTQ8AAC4lQAAeADBAAQAAAAcAAABNSUtFR0EAAB4AP0ABAAAABQAAAFNNVFAAAAAA HgBAQAEAAAAVAAAAbWlrZWdhQG1pY3Jvc29mdC5jb20AAAAAHgAdDgEAAAAkAAAAUHJvcG9zZWQg V0cgd29ya2xpc3QgZnJvbSBNYXJjaCBJTUMAAgEJEAEAAACeAgAAmgIAALIDAABMWkZ1/RgixwMA CgByY3BnMTI14jIDQ3RleAVBAQMB9/8KgAKkA+QHEwKAD/MAUARWPwhVB7IRJQ5RAwECAGNo4QrA c2V0MgYABsMRJfYzBEYTtzASLBEzCO8J97Y7GB8OMDURIgxgYwBQMwsJAWQzNhZQC6YgSRAgYmVs CJB2ZSDMdGgdcAWwaWcLgAdAJCBwA2BwbxQQZCA/E9IOsAXAAhAFwB2SSU0AQVBFWFQgV0dIIHdh BCB0bx7gb4MdYAXAU09SVCwQwNhubm8BkA6wIABwHtBAQUNMcy4gHOFkbmke0CHxHlB1BUAg4Gcv FCAdoB+SIiAgHTBzdNUhsGIjwWkFQHMIYCJwkwQgF7BvayJQIGcmIP8e0CTSINIHgCLhCqIKhAqA Ki0oYk8d5k0HkHNhFyQQKGMnpEYDYTogTLZ5InACIC4HwBggbh0QuHJnQAeBKXELgGcjMFEYIGN0 LgWgbSekW3cAwAMQIOA6Ks8r3wNwXa8npAZgAjAqoFcJgG4HkGhkYXkhsEolwB1wMBIyIbAxOTJA IDI6oDI3IFBNJ6RULcCTJWAUIGYtB3BhcA7BUkAHcGMuBbBnMDV17GJqLJEqoFAediByBbB+aybT A1IF0ArAE9Af4UP/J6onpBzwLIEHQAMgJaAHgP8CICJBI9EdoTdmIBAlYAIw9wSQHoAjonQsMSPo JmAm0/xvZiekOVAicCNAIiIlcPxlbQQgH3YgcCLgHPAdkBkIYGdoJVMgok1pa+8dcD9QJRQdoWML YT6QJ6TJIfAgayHwd2wJgCQQrz0xHYEEACLgVwhgbB7Q6R2SZ3UtkXkeUB8RRKHvQsAgsB1wJPBl O6AfcSCgtwsgIJAlcGgnpCSHPyekAn1IEAAAHgA1EAEAAABJAAAAPDA0ODU1RDBCQUEwRUQzMTFC QTc4MDBBMEM5Qzc0RDBGMEZCNzI4QFBURE9HLmRmcHQuZXh0ZXN0Lm1pY3Jvc29mdC5jb20+AAAA AB4AQhABAAAAKgAAADwxOTk5MDYwMjIxMjcuUEFBMDU4MDlAcmVtYnJhbmR0LmVzeXMuY2E+AAAA AwCAEP////8LAPIQAQAAAAsA9BAAAAAACwD1EAAAAAALAPYQAAAAAEAABzCMnVUyQK2+AUAACDCm xFwyQK2+AQMA3j+vbwAAAwDxPwkEAAAeADhAAQAAAAcAAABNSUtFR0EAAB4A+j8BAAAAFQAAAFN5 c3RlbSBBZG1pbmlzdHJhdG9yAAAAAB4AOUABAAAAAgAAAC4AAAACAfs/AQAAAB4AAAAAAAAA3KdA yMBCEBq0uQgAKy/hggEAAAAAAAAALgAAAAMA/T/kBAAAAwAZQAAAAAADABpAAAAAAAMACVkBAAAA HgA3gIYDAgAAAAAAwAAAAAAAAEYBAAAAHAAAAGMAbwBuAHQAZQBuAHQALQBjAGwAYQBzAHMAAAAB AAAAIQAAAHVybjpjb250ZW50LWNsYXNzZXM6bWVzc2FnZS9tYWlsAAAAAB4AWYCGAwIAAAAAAMAA AAAAAABGAQAAABgAAAByAGUAdAB1AHIAbgAtAHAAYQB0AGgAAAABAAAAIwAAADxtaWtlZ2FAZGZw dC5leHRlc3QubWljcm9zb2Z0LmNvbT4AAAsAWIEIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAA AwBwgQggBgAAAAAAwAAAAAAAAEYAAAAAUoUAACdqAQAeAHGBCCAGAAAAAADAAAAAAAAARgAAAABU hQAAAQAAAAQAAAA5LjAAHgCmgQggBgAAAAAAwAAAAAAAAEYAAAAAOIUAAAEAAAABAAAAAAAAAB4A p4EIIAYAAAAAAMAAAAAAAABGAAAAADeFAAABAAAAAQAAAAAAAAAeAKiBCCAGAAAAAADAAAAAAAAA RgAAAAA2hQAAAQAAAAEAAAAAAAAAAwC4gQggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALAL2B CCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMAwoEIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAA AAAAAwDOgQggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAeANmBhgMCAAAAAADAAAAAAAAARgEA AAAUAAAAeAAtAG0AaQBtAGUAbwBsAGUAAAABAAAALQAAAFByb2R1Y2VkIEJ5IE1pY3Jvc29mdCBN aW1lT0xFIFY1LjAwLjIwMTQuMjExAAAAAB4A2oGGAwIAAAAAAMAAAAAAAABGAQAAACwAAAB4AC0A bwByAGkAZwBpAG4AYQBsAGEAcgByAGkAdgBhAGwAdABpAG0AZQAAAAEAAAA9AAAAMDIgSnVuIDE5 OTkgMjE6Mzg6MDQuMDA1MyAoVVRDKSBGSUxFVElNRT1bMzFGM0RDNTA6MDFCRUFENDBdAAAAAAsA 24EIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAAAwDcgQggBgAAAAAAwAAAAAAAAEYAAAAAEIUA AAAAAAALACkAAAAAAAsAIwAAAAAAAwAGEDHw8k8DAAcQ+gEAAAMAEBAAAAAAAwAREAAAAAAeAAgQ AQAAAGUAAABJQkVMSUVWRVRIRU9SSUdJTkFMUFJPUE9TRURDSEFSVEVSRk9SVEhFSU1BUEVYVFdH V0FTVE9DT1ZFUlNPUlQsQU5OT1RBVEVBTkRBQ0xTSURJRE5PVFBVVFRPR0VUSEVSVEhBAAAAAAIB fwABAAAASQAAADwwNDg1NUQwQkFBMEVEMzExQkE3ODAwQTBDOUM3NEQwRjBGQjcyOEBQVERPRy5k ZnB0LmV4dGVzdC5taWNyb3NvZnQuY29tPgAAAAC5Kg== ------=_NextPart_000_2009A_01BEAD05.8609BF20-- From owner-ietf-imapext Wed Jun 2 15:00:15 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA23857 for ietf-imapext-bks; Wed, 2 Jun 1999 15:00:15 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA23853 for ; Wed, 2 Jun 1999 15:00:14 -0700 (PDT) Received: from ephesus.cyrusoft.com (ephesus.cyrusoft.com [206.31.218.204]) by darius.cyrusoft.com (8.8.5/8.8.5) with ESMTP id SAA24781; Wed, 2 Jun 1999 18:01:18 -0400 (EDT) Date: Wed, 02 Jun 1999 18:00:09 -0400 From: Cyrus Daboo To: "Mike Gahrns (Platinum)" , Lyndon.Nerenberg@messagingdirect.com, ietf-imapext@imc.org Subject: RE: Proposed WG worklist from March IMC Message-ID: <633473871.928346409@ephesus.cyrusoft.com> In-Reply-To: <04855D0BAA0ED311BA7800A0C9C74D0F0FB728@PTDOG.dfpt.extest.microsoft.com> Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431 X-Mailer: Mulberry (Win32) [2.0.0a2, s/n S1-000001] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: --On Wednesday, June 02, 1999, 2:38 PM -0700 "Mike Gahrns (Platinum)" wrote: > I believe the original proposed charter for the IMAPEXT WG was to cover > SORT, Annotate and ACLs. I did not put together that list, but it > sounds look a good list to me. The last charter we had was the one posted to the list by John Myers (I've quoted it below - obviously the target dates are wrong). This needs to be taken over by the WG chair (Pete?) and processed through the usual IETF channels, after discussion/approval on this list. > From: John Gardiner Myers > To: ietf-imapext@imc.org > Subject: Proposed charter > Date-Sent: 08/06/98, 3:17 PM -0700 > > To remind people, the proposed charter is as follows: > > Chair(s): > > TBD > > Mailing Lists: > > General discussion: ietf-imapext@imc.org > To Subscribe: ietf-imap-request@imc.org > Archive: http://www.imc.org/ietf-imapext/ > > > Description of Working Group: > > The IETF IMAP extensions Working Group shall revise and publish > standards-track extensions to IMAP4 for performing the following > functions: > > 1) Access Control Lists > 2) Sorting > 3) Threading > 4) Message-level annotations > > Revising the base IMAP4rev1 specification is out of the scope of this > WG. > > > Goals and Milestones: > > August 98 Approve charter > > Dec 98 Submit revised ACL spec to IESG > > Mar 99 Submit revised Sorting/Threading spec(s) to IESG > > August 99 Submit annotation spec to IESG --On Friday, April 10, 1998, 1:48 PM -0700 John Gardiner Myers wrote: > I'll propose the following addition to the charter: > > Revising the base IMAP4rev1 spec is out of the scope of this WG. -- Cyrus From owner-ietf-imapext Tue Jun 22 09:47:38 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA07674 for ietf-imapext-bks; Tue, 22 Jun 1999 09:47:38 -0700 (PDT) Received: from smtprich.nortel.com ([192.135.215.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA07628; Tue, 22 Jun 1999 09:46:26 -0700 (PDT) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprich.nortel.com; Tue, 22 Jun 1999 11:48:05 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Tue, 22 Jun 1999 11:47:56 -0500 Message-ID: <456E6DB7180ED3118A670000F8BDCA290A959B@zcard00p.ca.nortel.com> From: "Glenn Parsons" To: "'Dmitry Rubinstein'" Cc: imap@u.washington.edu, "'ietf-imap-voice@imc.org'" , "'ietf-imapext@imc.org'" , "'vpim-l@ema.org'" Subject: RE: Oslo IETF meeting Date: Tue, 22 Jun 1999 11:47:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Dmitry, > I'd like to know what will be the agenda of the WG(s), that will > deal with IMAP issues. In particular I'd like to know whether > the following two drafts are going to be discussed: > > 2. draft-ema-vpim-imap-00 (VPIM over IMAP) > I hope to have a slightly updated version of this available soon based on the various comments to date. The goal of this draft is to list the possible options to solve various requirements we have noted for retrieving voice messages over IMAP. > I'd appreciate it if whoever is preparing the agenda (assuming > such preparations are being done) will tip us on the major > points that are to be discussed. The agendas are only due within > two weeks and will probably be written on the last night, but > still... > At previous meetings, the view was that this was sufficiently different that we should create another list (IMAP-Voice) and have it discussed in a different IETF session. I'd be happy to discuss it in IMAPEXT if folks wanted to talk about this and revisit if it should be in the charter. We will likely mention this draft in passing in the VPIM meeting -- though we won't have time to look at any details. Cheers, Glenn. From owner-ietf-imapext Wed Jun 23 15:42:45 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA21045 for ietf-imapext-bks; Wed, 23 Jun 1999 15:42:45 -0700 (PDT) Received: from resnick1.qualcomm.com (resnick1.qualcomm.com [206.139.85.98]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA21041 for ; Wed, 23 Jun 1999 15:42:44 -0700 (PDT) Received: from resnick2.qualcomm.com (206.139.85.99) by resnick1.qualcomm.com with ESMTP (Eudora Internet Mail Server 3.0a8); Wed, 23 Jun 1999 17:45:35 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: X-Mailer: Eudora [Macintosh version 4.2b??] Date: Wed, 23 Jun 1999 17:45:33 -0500 To: IMAP Extensions From: Pete Resnick Subject: Fwd: 45th IETF: IMAPEXT Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: --- begin forwarded text Return-Path: X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 23 Jun 1999 18:36:24 -0400 To: Pete Resnick From: Marcia Beaulieu Subject: 45th IETF: IMAPEXT Cc: Keith Moore , Pätrik Faltström Mime-Version: 1.0 IMAPEXT is scheduled as follows: Thursday, July 15 at 1300-1500 other groups scheduled at that time: roamops, issll, ldapext, saag, mobileip, iptel Please submit an agenda for this meeting as soon as possible to agenda@ietf.org The deadline for submitting an agenda is July 1 at 1200 ET. Thanks, Marcia --- end forwarded text -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (619)651-4478, Fax: (619)651-1102 From owner-ietf-imapext Mon Jun 28 10:12:47 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA28183 for ietf-imapext-bks; Mon, 28 Jun 1999 10:12:47 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA28179 for ; Mon, 28 Jun 1999 10:12:45 -0700 (PDT) Received: from ephesus.cyrusoft.com (ephesus.cyrusoft.com [206.31.218.204]) by darius.cyrusoft.com (8.8.5/8.8.5) with ESMTP id NAA10190; Mon, 28 Jun 1999 13:16:04 -0400 (EDT) Date: Mon, 28 Jun 1999 13:16:45 -0400 From: Cyrus Daboo To: ietf-imapext@imc.org cc: IMAP@u.washington.edu Subject: I-D ACTION:draft-daboo-imap-view-00.txt Message-ID: <2862869525.930575805@ephesus.cyrusoft.com> Originator-Info: login-id=daboo; server=imap.cyrusoft.com X-Mailer: Mulberry (Win32) [1.4.4b2, s/n S1-000001] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Hi folks, A new internet draft is available at: This is the first cut at moving towards a standardised sorting mechanism for IMAP. The extension proposed in this draft is actually a more general extension that is used to allow a client to operate on a sub-set of messages (as determined right now by an IMAP SEARCH command) as opposed to the entire set of messages in the mailbox. Basically this extension introduces a couple of new commands, together with some new responses, including a new FETCH item called 'VIEW' which is the message's position in the 'sub-set' or 'view'. Clients can then access messages by their view position using a new VIEW command that takes FETCH (and other commands) as arguments (inthe same way as the UID command already present in IMAP4). It is proposed that a future SORT extension will be used with the VIEW mechanism to allow sub-setting of sort results and to allow clients to access the messages in sorted order as opposed to sequence number order. Thus this draft represents the first step towards the goal of a sort command acceptable to all - hopefully! BTW that the VIEW mechanism can be used with other types of sub-setting we might want to think about in the future (e.g. message threading based on message-id/in-reply-to etc). Note that this document proposes a mechanism different from that discussed by various groups at recent IETF and IMC interop meetings. I can post a list of reasons why we feel this approach is better if there is interest. --Cyrus Daboo From owner-ietf-imapext Mon Jun 28 10:53:42 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA28504 for ietf-imapext-bks; Mon, 28 Jun 1999 10:53:42 -0700 (PDT) Received: from metal.mcom.com (h-208-12-60-75.netscape.com [208.12.60.75]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA28500 for ; Mon, 28 Jun 1999 10:53:41 -0700 (PDT) Received: from Netscape.COM ([208.12.60.75]) by metal.mcom.com (Netscape Messaging Server 3.6) with ESMTP id AAA1AA0; Mon, 28 Jun 1999 10:56:33 -0700 Message-ID: <3777B74A.CB6B0ABE@Netscape.COM> Date: Mon, 28 Jun 1999 10:56:26 -0700 From: Mike Macgirvin Organization: The Rebel Alliance X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Cyrus Daboo CC: ietf-imapext@imc.org, IMAP@u.washington.edu Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt References: <2862869525.930575805@ephesus.cyrusoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: This appears to have the side effect of limiting you to one view. Multiple active views would require extensive client polling, and the notification events would only be active on one of them. I'd like to propose a modest enhancement, where the client can provide a (client generated) view-id, and subsequent changes to that view are tagged with the view-id. This permits multiple active views. Granted, there is server overhead involved, but this is the price of moving it off the client in the first place. Having the client generate an ID is better than having to match an untagged response with a search string. C: A143 VIEW SET 0001 SEARCH FROM "Smith" S: * 172 EXISTS 0001 23 S: A143 OK VIEW SET completed C: A144 VIEW SET 0002 SEARCH FROM "Myboss" S: * 172 EXISTS 0001 23 0002 6 S: A144 OK VIEW SET completed It probably isn't necessary that the results be chained in the EXISTS response, i.e. S: 172 EXISTS 0001 23 S: 172 EXISTS 0002 6 would be just fine. This would alter other responses appropriately. This way mailbox events can trigger updates of any active views. Thinking one step further, something to shut down an active view would likely be desirable in this model. C: A145 VIEW REMOVE 0001 S: A145 OK VIEW 0001 FROM "Smith" removed If I'm missing something obvious and all this isn't necessary, please correct me. From owner-ietf-imapext Mon Jun 28 11:00:05 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA28590 for ietf-imapext-bks; Mon, 28 Jun 1999 11:00:05 -0700 (PDT) Received: from metal.mcom.com (h-208-12-60-75.netscape.com [208.12.60.75]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA28586 for ; Mon, 28 Jun 1999 11:00:02 -0700 (PDT) Received: from Netscape.COM ([208.12.60.75]) by metal.mcom.com (Netscape Messaging Server 3.6) with ESMTP id AAA1DAA; Mon, 28 Jun 1999 11:02:57 -0700 Message-ID: <3777B8D1.F8075111@Netscape.COM> Date: Mon, 28 Jun 1999 11:02:57 -0700 From: Mike Macgirvin Organization: The Rebel Alliance X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Cyrus Daboo , ietf-imapext@imc.org, IMAP@u.washington.edu Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt References: <2862869525.930575805@ephesus.cyrusoft.com> <3777B74A.CB6B0ABE@Netscape.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Before somebody corrects me - yes I do know that EXISTS are untagged and require *. > It probably isn't necessary that the results be chained in the EXISTS > response, i.e. > S: * 172 EXISTS 0001 23 > S: * 172 EXISTS 0002 6 ............^ > would be just fine. From owner-ietf-imapext Mon Jun 28 11:01:17 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA28614 for ietf-imapext-bks; Mon, 28 Jun 1999 11:01:17 -0700 (PDT) Received: from mailgw1.netvision.net.il (mailgw1.netvision.net.il [194.90.1.14]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA28609 for ; Mon, 28 Jun 1999 11:01:11 -0700 (PDT) Received: from goofy-ex.icomverse.com (goofy-ex.icomverse.com [199.203.140.35]) by mailgw1.netvision.net.il (8.9.3/8.9.3) with ESMTP id VAA13781 for ; Mon, 28 Jun 1999 21:04:32 +0300 Received: by GOOFY_EX.QUANTUM.icomverse.com with Internet Mail Service (5.5.2448.0) id ; Mon, 28 Jun 1999 21:03:30 +0300 Message-ID: <5C5BA40F28F1D211AAE200105A057CB0210FDB@GOOFY_EX.QUANTUM.icomverse.com> From: "Rubinstein, Dmitry" To: ietf-imapext@imc.org Subject: Client ID extension Date: Mon, 28 Jun 1999 21:03:28 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="koi8-r" Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Hi, everybody! There has been a long discussion regarding the need for on the imap@u.washington.edu mailing list (whose subscribers, if I'm not terribly misaken, are a superset of the current list's subscribers). The majority of speakers eventually supported the idea of adding Client ID extension and at least 3-4 developers expressed their willingness to add support to ClientID to their products. There is a draft that is about year old that describes the proposed extension. There was a talk of adding this extension to the charter of this WG. What does it take at this point to make it into a standard? TIA, -- Dmitry Rubinstein From owner-ietf-imapext Mon Jun 28 11:33:10 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA29008 for ietf-imapext-bks; Mon, 28 Jun 1999 11:33:10 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (koval@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA29004 for ; Mon, 28 Jun 1999 11:33:09 -0700 (PDT) Date: Mon, 28 Jun 1999 11:14:00 -0700 (PDT) From: Mark Crispin Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt To: Mike Macgirvin cc: Cyrus Daboo , ietf-imapext@imc.org, IMAP@u.washington.edu In-Reply-To: <3777B74A.CB6B0ABE@Netscape.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: My only comment about multiple simultaneous views is that this makes VIEW much more complicated to implement; and as such presents a barrier to prospective implementors. It may also contribute to the ongoing myth that IMAP is an expensive service to have on a machine. Nevertheless, this is just an observation and I don't oppose your proposal. Please bring it up at Oslo. From owner-ietf-imapext Mon Jun 28 11:34:08 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA29020 for ietf-imapext-bks; Mon, 28 Jun 1999 11:34:08 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA29015 for ; Mon, 28 Jun 1999 11:34:07 -0700 (PDT) Received: from ephesus.cyrusoft.com (ephesus.cyrusoft.com [206.31.218.204]) by darius.cyrusoft.com (8.8.5/8.8.5) with ESMTP id OAA10619; Mon, 28 Jun 1999 14:37:25 -0400 (EDT) Date: Mon, 28 Jun 1999 14:38:06 -0400 From: Cyrus Daboo To: Mike Macgirvin cc: ietf-imapext@imc.org, IMAP@u.washington.edu Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt Message-ID: <2867750433.930580686@ephesus.cyrusoft.com> In-Reply-To: <3777B74A.CB6B0ABE@Netscape.COM> Originator-Info: login-id=daboo; server=imap.cyrusoft.com X-Mailer: Mulberry (Win32) [1.4.4b2, s/n S1-000001] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Hi Mike, --On Monday, June 28, 1999, 10:56 AM -0700 Mike Macgirvin wrote: > This appears to have the side effect of limiting you to one view. Multiple > active views would require extensive client polling, and the notification > events would only be active on one of them. > > I'd like to propose a modest enhancement, where the client can provide a > (client generated) view-id, and subsequent changes to that view are tagged > with the view-id. This permits multiple active views. Granted, there is > server overhead involved, but this is the price of moving it off the > client in the first place. Having the client generate an ID is better > than having to match an untagged response with a search string. Multiple views would be nice. I thought of doing something similar too. However, I concluded that the added complexity of handling multiple views is too much for now. It requires a lot more than just modifying EXISTS. One major problem is that messages can be in more than one view. One way to handle this would be to redefine the 'position' syntax to be a list of 'view number'/'view position' pairs. For example, an EXPUNGE for a message in view #0001 and view #0003 would end up as: a EXPUNGE * 1 EXPUNGE 1234 ((0001 1)(0003 4)) a OK My personal feeling is to keep VIEW simple for now and see how implementation experience goes. There's no reason why later we can't define a new command to deal with multiple named views and redefine the existing VIEW syntax appropriately. e.g. 'VIEW SET' would be augmented by a 'VIEW NAMEDSET' command that could redfine the 'position' formal syntax item to be an S-Expression list (or whatever), and require a view name in addition to the sub-command in a VIEW command. --Cyrus From owner-ietf-imapext Mon Jun 28 11:49:05 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA29772 for ietf-imapext-bks; Mon, 28 Jun 1999 11:49:05 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA29768 for ; Mon, 28 Jun 1999 11:49:04 -0700 (PDT) Received: from ephesus.cyrusoft.com (ephesus.cyrusoft.com [206.31.218.204]) by darius.cyrusoft.com (8.8.5/8.8.5) with ESMTP id OAA10743; Mon, 28 Jun 1999 14:52:20 -0400 (EDT) Date: Mon, 28 Jun 1999 14:53:00 -0400 From: Cyrus Daboo To: "Rubinstein, Dmitry" , ietf-imapext@imc.org Subject: Re: Client ID extension Message-ID: <2868644759.930581580@ephesus.cyrusoft.com> In-Reply-To: <5C5BA40F28F1D211AAE200105A057CB0210FDB@GOOFY_EX.QUANTUM.icomverse.com> Originator-Info: login-id=daboo; server=imap.cyrusoft.com X-Mailer: Mulberry (Win32) [1.4.4b2, s/n S1-000001] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: --On Monday, June 28, 1999, 9:03 PM +0300 "Rubinstein, Dmitry" wrote: > Hi, everybody! > > There has been a long discussion regarding the need for on the > imap@u.washington.edu mailing list (whose subscribers, if I'm not terribly > misaken, are a superset of the current list's subscribers). The majority > of speakers eventually supported the idea of adding Client ID extension > and at least 3-4 developers expressed their willingness to add support to > ClientID to their products. There is a draft that is about year old that > describes the proposed extension. There was a talk of adding this > extension to the charter of this WG. What does it take at this point to > make it into a standard? > Well there is no formal charter for this group as yet. That ought to be the first item on the agenda for Oslo! I think the client ID extension should be straightforward enough that it can be moved forward via the mailing list rather than needing to be added to the future WG. All it really needs is for someone to update the document and to start the formal review process over again. Perhaps Tim (original author) could be persuaded to do this? --Cyrus From owner-ietf-imapext Mon Jun 28 12:42:36 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA00881 for ietf-imapext-bks; Mon, 28 Jun 1999 12:42:36 -0700 (PDT) Received: from metal.mcom.com (h-208-12-60-75.netscape.com [208.12.60.75]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA00877 for ; Mon, 28 Jun 1999 12:42:35 -0700 (PDT) Received: from Netscape.COM ([208.12.60.75]) by metal.mcom.com (Netscape Messaging Server 3.6) with ESMTP id AAA4E97; Mon, 28 Jun 1999 12:45:32 -0700 Message-ID: <3777D0DB.2105A918@Netscape.COM> Date: Mon, 28 Jun 1999 12:45:31 -0700 From: Mike Macgirvin Organization: The Rebel Alliance X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Mark Crispin CC: Cyrus Daboo , ietf-imapext@imc.org, IMAP@u.washington.edu Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Mark Crispin wrote: > > My only comment about multiple simultaneous views is that this makes VIEW much > more complicated to implement; and as such presents a barrier to prospective > implementors. It may also contribute to the ongoing myth that IMAP is an > expensive service to have on a machine. > > Nevertheless, this is just an observation and I don't oppose your proposal. > Please bring it up at Oslo. I agree totally that it makes server implementation of this feature non-trivial. Without it I think the client ends up having to work just as hard by issuing multiple SEARCH and/or VIEW commands everytime anything in the mailbox changes - or doing all the work client-side. We can do that today without requiring any extensions, but it's hardly efficient. So this draft presents a way to avoid a lot of client overhead as long as you only define or "activate" only one view. Having worked a lot with views in the past, one is not very typical. The bell curve fits around 5 and 20 at least on INBOX and it's reasonable for a human to want to have all their views active in the sense that message counts are propogated in as near to real time as possible. I'll see if somebody else from here will be at Oslo and ask that they present these arguments - unfortunately, I have other obligations. From owner-ietf-imapext Mon Jun 28 14:53:28 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA02316 for ietf-imapext-bks; Mon, 28 Jun 1999 14:53:28 -0700 (PDT) Received: from alms1.fw.att.com (alms1.att.com [192.128.167.146]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA02312 for ; Mon, 28 Jun 1999 14:53:26 -0700 (PDT) Received: from dns.maillennium.att.com ([135.25.114.99]) by alms1.fw.att.com (AT&T IPNS/MS-2.2) with ESMTP id RAA07272 for ; Mon, 28 Jun 1999 17:56:20 -0400 (EDT) Received: from att.com (hansenpc.bl-els.att.com[135.25.111.58](may be forged)) by maillennium.att.com (labmail) with SMTP id <19990628215414un129110fie>; Mon, 28 Jun 1999 21:54:14 +0000 Message-ID: <3777EEA4.A650B2F7@att.com> Date: Mon, 28 Jun 1999 17:52:36 -0400 From: Tony Hansen Reply-To: tony@att.com Organization: AT&T Laboratories X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Cyrus Daboo CC: ietf-imapext@imc.org, IMAP@u.washington.edu Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt References: <2862869525.930575805@ephesus.cyrusoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Cyrus Daboo wrote: > > A new internet draft is available at: > > > This is the first cut at moving towards a standardised sorting mechanism > for IMAP. The extension proposed in this draft is actually a more general > extension that is used to allow a client to operate on a sub-set of > messages (as determined right now by an IMAP SEARCH command) as opposed to > the entire set of messages in the mailbox. > > Basically this extension introduces a couple of new commands, together with > some new responses, including a new FETCH item called 'VIEW' which is the > message's position in the 'sub-set' or 'view'. Clients can then access > messages by their view position using a new VIEW command that takes FETCH > (and other commands) as arguments (inthe same way as the UID command > already present in IMAP4). > ... Our major problem with this proposal is not an issue with the extension itself. Instead, we have an issue with its impact on server performance when dealing with LARGE user populations (hundreds of thousands or millions). Each proposal such as this does increase the server load. Tony Hansen tony@att.com From owner-ietf-imapext Mon Jun 28 15:34:28 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA03186 for ietf-imapext-bks; Mon, 28 Jun 1999 15:34:28 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (harley@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA03182 for ; Mon, 28 Jun 1999 15:34:27 -0700 (PDT) Date: Mon, 28 Jun 1999 15:05:38 -0700 (PDT) From: Mark Crispin Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt To: tony@att.com cc: Cyrus Daboo , ietf-imapext@imc.org, IMAP@u.washington.edu In-Reply-To: <3777EEA4.A650B2F7@att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Mon, 28 Jun 1999 17:52:36 -0400, Tony Hansen wrote: > Our major problem with this proposal is not an issue with the extension > itself. Instead, we have an issue with its impact on server performance > when dealing with LARGE user populations (hundreds of thousands or > millions). Each proposal such as this does increase the server load. There's a tradeoff in all of these things. Some people consider the functionality of VIEW to be very important, and have blocked SORT and THREAD unless this functionality is provided. One of their concerns is that the SORT command uses communication bandwidth; for example, sorting a 2000 message mailbox results in a response that is 8900 octets long. SORT and THREAD are very important for UW since these extensions make a *HUGE* difference in Pine performance. So, it's important for us to get these concerns addressed, and preferably in an extensible mechanism. From owner-ietf-imapext Mon Jun 28 15:56:24 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA03378 for ietf-imapext-bks; Mon, 28 Jun 1999 15:56:24 -0700 (PDT) Received: from tide03.microsoft.com (firewall-user@tide03.microsoft.com [131.107.3.13]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA03374 for ; Mon, 28 Jun 1999 15:56:23 -0700 (PDT) Received: by tide03.microsoft.com; id PAA11702; Mon, 28 Jun 1999 15:59:51 -0700 (PDT) Received: from imail2.dns.microsoft.com(157.54.17.74) by tide03.microsoft.com via smap (V3.1) id xma011698; Mon, 28 Jun 99 15:59:40 -0700 Received: from red-imc-01.dns.microsoft.com ([157.54.4.91]) by imail2.microsoft.com (8.7.3/8.7.1) with ESMTP id QAA05586 for ; Mon, 28 Jun 1999 16:15:50 -0700 (PDT) Received: from red-imc-01.dns.microsoft.com (RED-IMC-01 [157.54.4.91]) by red-imc-01.dns.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id NPXNA4FB; Mon, 28 Jun 1999 15:58:28 -0700 Received: from 172.30.236.86 by red-imc-01.dns.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 28 Jun 1999 15:57:46 -0700 (Pacific Daylight Time) Received: from PTROUTE.dfpt.extest.microsoft.com (PTROUTE [172.30.236.83]) by ptgate.dns.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id NS1J2BVL; Mon, 28 Jun 1999 15:57:49 -0700 Received: from PTDOG.dfpt.extest.microsoft.com ([172.30.236.159]) by PTROUTE.dfpt.extest.microsoft.com with Microsoft SMTPSVC(5.0.2054.0054.0); Mon, 28 Jun 1999 15:58:39 -0700 Received: from mikega9 ([157.59.255.62]) by PTDOG.dfpt.extest.microsoft.com with Microsoft SMTPSVC(5.0.2054.0054.0); Mon, 28 Jun 1999 15:58:39 -0700 Message-ID: <000601bec1b9$b9925c80$3eff3b9d@dns.microsoft.com> From: "Mike Gahrns" To: References: <2868644759.930581580@ephesus.cyrusoft.com> Subject: Re: Client ID extension Date: Mon, 28 Jun 1999 15:58:23 -0700 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 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-OriginalArrivalTime: 28 Jun 1999 22:58:39.0054 (UTC) FILETIME=[C293F6E0:01BEC1B9] Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Cyrus Daboo writes: > I think the client ID extension should be straightforward enough that it > can be moved forward via the mailing list rather than needing to be added > to the future WG. All it really needs is for someone to update the document > and to start the formal review process over again. Perhaps Tim (original > author) could be persuaded to do this? This echos a previous comment I had regarding the charter of the WG. I'd prefer that the WG concentrate on the "larger" issues already proposed: SORT, ANNOTATE and ACL. Smaller extensions will probably be better served taking them outside of the WG. In regards to ID, I think the original proposal was pretty much there. The dissention seemed to resolve around whether the premise of allowing this functionality was good or bad. Given that there seems to be reasonable number of people who concur that this type of functionality would be useful, moving the extension forward should hopefully be rather straight foward with only minor changes needed. I am not sure what Tim's thoughts are on moving this forward, but I would be willing to help with this if he is unable to. From owner-ietf-imapext Mon Jun 28 17:23:50 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA04483 for ietf-imapext-bks; Mon, 28 Jun 1999 17:23:50 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA04479 for ; Mon, 28 Jun 1999 17:23:49 -0700 (PDT) Received: from creamofwheat-5.slip.andrew.cmu.edu (CREAMOFWHEAT-5.SLIP.ANDREW.CMU.EDU [128.2.120.5]) by darius.cyrusoft.com (8.8.5/8.8.5) with ESMTP id UAA11810; Mon, 28 Jun 1999 20:27:08 -0400 (EDT) Date: Mon, 28 Jun 1999 20:28:06 -0400 From: Cyrus Daboo To: tony@att.com cc: ietf-imapext@imc.org, IMAP@u.washington.edu Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt Message-ID: <155182.3139590486@creamofwheat-5.slip.andrew.cmu.edu> In-Reply-To: <3777EEA4.A650B2F7@att.com> Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431 X-Mailer: Mulberry (MacOS) [2.0.0a3, s/n S1-000001] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: --On Mon, Jun 28, 1999 5:52 PM -0400 Tony Hansen wrote: > Our major problem with this proposal is not an issue with the extension > itself. Instead, we have an issue with its impact on server performance > when dealing with LARGE user populations (hundreds of thousands or > millions). Each proposal such as this does increase the server load. Actually the hope for this proposal (wrt to sorting) is to REDUCE the overall server load by removing the need for a client to download the envelopes of all messages in order to sort them for the end-user. It should also reduce client load and indeed allow thin-clients to present sorted or sub-set views without having to do much work. -- Cyrus From owner-ietf-imapext Mon Jun 28 18:34:45 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA05484 for ietf-imapext-bks; Mon, 28 Jun 1999 18:34:45 -0700 (PDT) Received: from alms1.fw.att.com (alms1.att.com [192.128.167.146]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA05480 for ; Mon, 28 Jun 1999 18:34:43 -0700 (PDT) Received: from dns.maillennium.att.com ([135.25.114.99]) by alms1.fw.att.com (AT&T IPNS/MS-2.2) with ESMTP id VAA07781 for ; Mon, 28 Jun 1999 21:37:42 -0400 (EDT) Received: from maillennium.att.com ([135.197.86.177](may be forged)) by maillennium.att.com (labmail) with SMTP id <19990629013550un129110j2e>; Tue, 29 Jun 1999 01:35:51 +0000 Message-ID: <37781577.37D9BAF1@maillennium.att.com> Date: Tue, 29 Jun 1999 00:38:15 +0000 From: steve spear X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-imapext@imc.org CC: IMAP@u.washington.edu Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt References: <155182.3139590486@creamofwheat-5.slip.andrew.cmu.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Can someone explain how traffic is reduced by SORT over clients that are caching the headers and simply request messages headers they haven't seen before? As Tony Hansen pointed out - AT&T is trying to handle many millions of users. The thought of using more resources on the server instead of the clients that are largely idle is a concern of ours. We keep hearing about thin-client's, but the memory available in the thin clients still boggles the mind of those who had memory measured in Kilobytes ( not Megabytes ) 25+ years ago. If it makes sense we'll cheer for it, but we'd like to understand where the advantage is. Steve Spear AT&T Technology Consultant Cyrus Daboo wrote: > --On Mon, Jun 28, 1999 5:52 PM -0400 Tony Hansen wrote: > > > Our major problem with this proposal is not an issue with the extension > > itself. Instead, we have an issue with its impact on server performance > > when dealing with LARGE user populations (hundreds of thousands or > > millions). Each proposal such as this does increase the server load. > > Actually the hope for this proposal (wrt to sorting) is to REDUCE the > overall server load by removing the need for a client to download the > envelopes of all messages in order to sort them for the end-user. It should > also reduce client load and indeed allow thin-clients to present sorted or > sub-set views without having to do much work. > > -- > Cyrus From owner-ietf-imapext Mon Jun 28 18:39:17 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA05526 for ietf-imapext-bks; Mon, 28 Jun 1999 18:39:17 -0700 (PDT) Received: from mailhost2.u.washington.edu (mailhost2.u.washington.edu [140.142.33.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA05522 for ; Mon, 28 Jun 1999 18:39:16 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (rossi@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost2.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.01) with ESMTP id SAA10510; Mon, 28 Jun 1999 18:42:45 -0700 Date: Mon, 28 Jun 1999 18:40:54 -0700 (PDT) From: Mark Crispin Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt To: steve spear cc: ietf-imapext@imc.org, IMAP@u.washington.edu In-Reply-To: <37781577.37D9BAF1@maillennium.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Tue, 29 Jun 1999 00:38:15 +0000, steve spear wrote: > Can someone explain how traffic is reduced by SORT over clients that are > caching the headers and simply request messages headers they haven't seen > before? Most such clients are POP clients masquerading as IMAP clients. Consider true IMAP clients, which don't have a cache (and may well be a kiosk or other shared machine which shouldn't cache!), and don't want to load all those headers. From owner-ietf-imapext Tue Jun 29 02:39:14 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA14864 for ietf-imapext-bks; Tue, 29 Jun 1999 02:39:14 -0700 (PDT) Received: from mailgw1.netvision.net.il (mailgw1.netvision.net.il [194.90.1.14]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA14860 for ; Tue, 29 Jun 1999 02:39:09 -0700 (PDT) Received: from goofy-ex.icomverse.com (goofy-ex.icomverse.com [199.203.140.35]) by mailgw1.netvision.net.il (8.9.3/8.9.3) with ESMTP id MAA18936 for ; Tue, 29 Jun 1999 12:42:37 +0300 Received: by GOOFY_EX.QUANTUM.icomverse.com with Internet Mail Service (5.5.2448.0) id ; Tue, 29 Jun 1999 12:41:52 +0300 Message-ID: <5C5BA40F28F1D211AAE200105A057CB0210FE1@GOOFY_EX.QUANTUM.icomverse.com> From: "Rubinstein, Dmitry" To: ietf-imapext@imc.org Subject: RE: Client ID extension Date: Tue, 29 Jun 1999 12:41:52 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BEC213.9E2A9490" Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BEC213.9E2A9490 Content-Type: text/plain; charset="iso-8859-1" > From: Mike Gahrns [mailto:mikega@microsoft.com] > Given that there seems to be > reasonable > number of people who concur that this type of functionality > would be useful, > moving the extension forward should hopefully be rather > straight foward with > only minor changes needed. OK then, what are the needed changes? Below is the original draft for your reference. -- Dmitry Rubinstein ------_=_NextPart_000_01BEC213.9E2A9490 Content-Type: text/plain; name="draft-tjs-id-01.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-tjs-id-01.txt" Network Working Group T. = Showalter Not An Internet Draft Carnegie = Mellon Document: untitled February = 1997 Expire sometime after it's released IMAP4 ID extension Status of this Memo This document does not exist. 1. Abstract The purpose of the ID extension to the IMAP4rev1 protocol is to allow the server and client to exchange identification information on their implementation in order to make bug reports and usage statistics more complete. Although the IMAP4rev1 protocol described in [IMAP4rev1] provides a method for accessing remote mail stores, there is no facility to advertise what program a client or server uses to provide service. This makes it difficult for implementors to get complete bug = reports from users, as it is frequently difficult to know what client or server is in use. Additionally, some sites may wish to assemble usage statistics = based on what clients are used, but in an an environment where users are permitted to obtain and maintain their own clients this is = difficult to accomplish. The ID command provides a facility to advertise information on what programs are being used, along with contact information should bugs ever occur. 2. Conventions Used in this Document The conventions used in this document are the same as specified in [IMAP4rev1]. In examples, "C:" and "S:" indicate lines sent by the client and server respectively. Line breaks have been inserted for readability. 3. Specification The ID extension is provided in order for clients and servers to exchange information on their implementations. This information may be submitted to a server by any client wishing to provide information for statistical purposes, provided the = server advertises its willingness to take the information with the atom "ID" included in the list of capabilities returned by the = CAPABILITY command. Implementations MUST NOT make operational changes based on the data sent as part of the ID command or response. 3.1. ID Command Arguments: client parameter list or NIL Responses: OPTIONAL untagged response: ID Result: OK identification information accepted BAD command unknown or arguments invalid Identification information is sent by the client with the ID command. The information sent is in the form of a list of field/value pairs. Fields are permitted to be any IMAP4 string, = and values are permitted to be any IMAP4 string or NIL. A value of NIL indicates that the client can not or will not specify this information. The client may also send NIL instead of the list, indicating that it wants to send no information, but would still accept a server response. The avalible fields are defined in section 3.3. Example: C: a023 ID ("name" "sodr" "version" "19.34" "vendor" "Pink Floyd Music Limited") S: a023 OK ID completed 3.2. ID Response Contents: server parameter list In response to an ID command issued by the client, the server MAY reply with a tagged response containing information on its implementation. The format is the same as the client list. Example: C: a023 ID NIL S: * ID ("name" "Cyrus" "version" "1.5" "os" "sunos" "os-version" = "5.5" "email" "cyrus-bugs@andrew.cmu.edu") S: a023 OK ID command completed The server is not required to send an ID response to an ID command. 3.3. Defined Field Values Any string may be sent as a field, but the following are defined to describe certain values that might be sent. Implementations are free to send none, any, or all of these. Strings are not case-sensitive. name Name of the program version Version number of the program os Name of the operating system os-version Version of the operating system vendor Vendor of the client/server contact Contact person for the client/server email Email address of contact/vendor phone Phone number of contact/vendor address Postal address of contact/vendor date Date program was released; should be in a human-readable form command Command used to start the program arguments Arguments supplied on the command line (if any) environment Description of environment (i.e., UNIX environment variables or Windows = registry settings. Implementations MUST NOT use contact information to submit = automatic bug reports. Information supplied with the ID command is not necessarily complete or accurate. Implementations may include such information in a report submitted. It is preferrable to find the name and version of the underlying operating system at runtime in cases where this is possible. Some of this information (specifically, the command, arguments, and environment fields) is likely to violate users' privacy. See the section on security considerations below. Implementations may send the same tag more than once; for example, C: a001 ID ("client-name" NIL "client-name" "spooky" "client-name" NIL) S: a001 OK ID completed 4. Formal Syntax This syntax is intended to augment the grammar specified in = [IMAP4rev1] in order to provide for the ID command. This specification uses = the augmented Backus-Naur Form (BNF) notation as specified in [RFC-822] and modified by [IMAP4rev1]. command_any ::=3D "CAPABILITY / "LOGOUT" / "NOOP" / x_command / id ;; adds id command to command_any in [IMAP4rev1] id ::=3D "ID" SPACE id_params_list / nil id_response ::=3D "ID" SPACE id_params_list / nil id_params_list ::=3D "(" #(string SPACE nstring) ")" / nil ;; list of field value pairs response_data ::=3D "*" (resp_cond_state / resp_cond_bye / mailbox_data / message_data / capability_data / id_response) 5. References [IMAP4rev1] Crispin, M., "Internet Message Access Protocol - = Version 4rev1", RFC 2060, University of Washington, October, 1996. [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822. 6. Security Considerations A client or server supporting ID may violate the privacy of users = by sending information on the underlying implementation, or in some cases, information on how the mail client was invoked. For this reason, it is highly desirable that client implementations provide = a method of disabling ID support -- by either not sending ID at all, or by sending the command "ID NIL", or by controlling the level of detail of information sent. A server may reply similarly in its untagged response ("* ID NIL"), or it may send no untagged = response. 7. Author's Address Tim Showalter Carnegie Mellon University 5000 Forbes Avenue Pittsburgh, PA 15213 Email: tjs@andrew.cmu.edu ------_=_NextPart_000_01BEC213.9E2A9490-- From owner-ietf-imapext Tue Jun 29 12:18:26 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA00151 for ietf-imapext-bks; Tue, 29 Jun 1999 12:18:26 -0700 (PDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA00139 for ; Tue, 29 Jun 1999 12:18:23 -0700 (PDT) Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id PAA08494; Tue, 29 Jun 1999 15:21:53 -0400 Received: from watson.ibm.com (mars.watson.ibm.com [9.2.2.58]) by mailhub1.watson.ibm.com (8.8.7/Feb-20-98) with ESMTP id PAA11052; Tue, 29 Jun 1999 15:21:53 -0400 Message-ID: <37791CD0.99397D08@watson.ibm.com> Date: Tue, 29 Jun 1999 15:21:52 -0400 From: Barry Leiba Organization: Internet Messaging Technology; TR2_Xagent=WATSON X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Cyrus Daboo CC: ietf-imapext@imc.org, IMAP@u.washington.edu Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt References: <2862869525.930575805@ephesus.cyrusoft.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: First comment: Can we take the IMAP mailing list out of the list on this discussion, and just hold it on the IMAPext mailing list? It seems silly to post the same discussion to both lists -- why do we have the IMAPext list at all, if we're going to do that? Other comments: * Section 4.1 refers to an "optional" sub-command, and (a) says that the VIEW SET command selects messages that "match the results of the sub-command". It doesn't make it clear what happens if there's no sub-command (all messages are selected, I presume). It also doesn't say much about the sub-command; if "SEARCH" is the only command in the base spec that applies, it should probably say so, to prevent people from wondering what commands apply. It might also say (which is also said elsewhere) that it's intended that future SORT and THREAD commands may go here. * In 4.1 (b), "c.f." is properly abbreviated "cf.", and, anyway, is the wrong Latin abbreviation here. "cf." means "compare" (from the Latin "confer"), and I don't think you want anyone to compare what you say here to what's said in 4.2. If you mean "see section 4.2", just say it. (Sorry... pet peeve about misuse of Latin abbreviations.) * In the example in 4.1 (g), correct spelling of "SEARCH". * In 4.2 you should make it clear what, if anything, it means to use a VIEW command without a VIEW SET being in effect. It seems to me that it's nonsensical (so should "VIEW FETCH" respond "NO" or "BAD" in that case?). * In 4.2, you say command response. However, server implementations MUST implicitly include the VIEW fetch item as part of any FETCH response caused by a VIEW command, regardless of whether a VIEW was specified as a message data item to the FETCH. ...but you've already said that a VIEW fetch item must be included if a VIEW SET is in effect. If I'm right in my previous note, then you probably shouldn't *also* say this. * In 5.1.1: A VIEW untagged response MUST NOT be sent when no command is in progress; nor while responding to a FETCH, SEARCH or STORE command. Understandable. But that means that a client that receives an EXISTS in response to a FETCH must then go issue a NOOP to get the corresponding VIEW response. Can we think of a better way? Also, it might not hurt to point out that IDLE can count as a command in progress. But, then, maybe that's too obvious to have to mention. * In 5.1.2: When the old view position number in the VIEW untagged response is non-zero, the effect of VIEW is a message inserted into the view at the position given by . The view position numbers of all subsequent messages inthge current view are incremented. When the new view position number in the VIEW untagged response is non-zero, the effect of VIEW is a message removed from the view at the position given by . The view position numbers of all subsequent messages inthe current view are decremented. In both of these, I think you mean "zero" where you say "non-zero". Also, fix "inthge" and "inthe". Also also, since you explicitly talk about incrementing and decrementing view position numbers, perhaps you should include a paragraph about what happens if both the old and new positions are non-zero... which also require renumbering other messages. No, *I* don't think it needs to be said, but, then, I'm always surprised at the interpretations that sometimes happen when one fails to say something. :-) * In the grammar: position ::= number ["." number] ;; position number of messages in the view ;; may be hierarchical if sub-command defines ;; hierarchic ordering of messages This makes some of the statements about "incrementing" and "decrementing" view positions harder to understand. Maybe all we should say about what happens after a VIEW response is that "view positions of subsequent [or intervening] messages must be adjusted appropriately" or some such. * Finally, just to clarify things... we'd had an extended discussion about whether it was reasonable to remove a message from a view, once it was in the view. Problems of side-effects and such -- for instance, what happens in the following case (abbreviating a little): c: t0 VIEW SET SEARCH UNSEEN s: * 25 VIEW 1234 0 4 c: t1 VIEW FETCH 4 BODY[1] s: * 25 FETCH (FLAGS (\Seen) VIEW 4 BODY[1] ... s: t1 OK done c: t2 NOOP s: * 25 VIEW 1234 4 0 [\Seen flag caused view to change] s: t2 OK done Now, as a side-effect of the FETCH, the client can no longer use VIEW FETCH on this message. Other cases are easy to imagine. It makes VIEW FETCH of questionable use. Clearly, the decision made in writing this draft was to have messages disappear from the view (during earlier discussions, some thought they should not, though it came out that that makes reconnecting after connection failures difficult). I just wanted to point out, for the record, that there were two sides to that discussion, and to point out, for the record, which one was adopted. (And, for the record, I agree with the choice.) But I would like to see some of these potential problems mentioned in the spec. I would also like to see some encouragement to use UIDs instead of view positions. In fact, I'd go as far as to say that I don't think we should *have* a VIEW FETCH, VIEW STORE, or VIEW COPY command, and that we should clearly state that UIDs are the things to use when you're using views. Barry Leiba, Internet Messaging Technology (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba From owner-ietf-imapext Tue Jun 29 16:17:02 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA07897 for ietf-imapext-bks; Tue, 29 Jun 1999 16:17:02 -0700 (PDT) Received: from baikonur.demo.ru ([194.87.43.111]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA07893 for ; Tue, 29 Jun 1999 16:17:00 -0700 (PDT) Received: from taxxi.com ([195.218.251.244]) by baikonur.demo.ru (Netscape Messaging Server 3.62) with ESMTP id 337; Wed, 30 Jun 1999 03:19:28 +0400 Message-ID: <3779545C.18AD4F8C@taxxi.com> Date: Wed, 30 Jun 1999 03:18:52 +0400 From: Alexey Melnikov X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: ru,en-US MIME-Version: 1.0 To: Cyrus Daboo CC: ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt References: <2862869525.930575805@ephesus.cyrusoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Cyrus Daboo wrote: > Hi folks, > A new internet draft is available at: > > > > [skipped] > > Note that this document proposes a mechanism different from that discussed > by various groups at recent IETF and IMC interop meetings. I can post a > list of reasons why we feel this approach is better if there is interest. I understand most of them (I didn't like the idea to overload SELECT from the beginning), but I would like to know them all. Few comments in addition to what Barry wrote: 1). I am concerned about amount of responses sent when message moves into or outside of the view. I would rather add something like the following: Server MUST NOT send extended EXISTS response when message moves into or outside of the view, but there is no changes to the total number of messages in the mailbox. This is not clear from the current version of the draft. 2). According to the draft a server MUST send untagged VIEW for every new message that arrives in the mailbox. Again, there is no reason why server should send EXISTS ***after*** VIEW response, because untagged VIEW already contains all information about new message. (EXISTS still MUST be sent right after VIEW SET) -- Best Regards, Alexey Melnikov From owner-ietf-imapext Tue Jun 29 16:26:42 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA08211 for ietf-imapext-bks; Tue, 29 Jun 1999 16:26:42 -0700 (PDT) Received: from baikonur.demo.ru ([194.87.43.111]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA08207 for ; Tue, 29 Jun 1999 16:26:40 -0700 (PDT) Received: from taxxi.com ([195.218.251.244]) by baikonur.demo.ru (Netscape Messaging Server 3.62) with ESMTP id 334; Wed, 30 Jun 1999 03:29:09 +0400 Message-ID: <377956A0.F6D9B0F3@taxxi.com> Date: Wed, 30 Jun 1999 03:28:32 +0400 From: Alexey Melnikov X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: ru,en-US MIME-Version: 1.0 To: Barry Leiba CC: Cyrus Daboo , ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt References: <2862869525.930575805@ephesus.cyrusoft.com> <37791CD0.99397D08@watson.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Barry Leiba wrote: > First comment: Can we take the IMAP mailing list out of the list on > this discussion, and just hold it on the IMAPext mailing list? It seems > silly to post the same discussion to both lists -- why do we have the > IMAPext list at all, if we're going to do that? > > Other comments: > * Section 4.1 refers to an "optional" sub-command, and (a) says that > the VIEW SET command selects messages that "match the results of the > sub-command". It doesn't make it clear what happens if there's no > sub-command (all messages are selected, I presume). Draft says that VIEW SET with out optional argument cancels VIEW state (section 4.1 point g)). > * In 4.2 you should make it clear what, if anything, it means to use a > VIEW command without a VIEW SET being in effect. It seems to me that > it's nonsensical (so should "VIEW FETCH" respond "NO" or "BAD" in that > case?). Actually, I don't mind if VIEW returns OK, as if "VIEW SET SEARCH ALL" has been issued. > * In 4.2, you say > command response. However, server implementations MUST implicitly > include the VIEW fetch item as part of any FETCH response caused by > a VIEW command, regardless of whether a VIEW was specified as a > message data item to the FETCH. > > ...but you've already said that a VIEW fetch item must be included if > a VIEW SET is in effect. If I'm right in my previous note, then you > probably shouldn't *also* say this. IMHO, it is not a big trouble to say something twice, especially in this case. > * Finally, just to clarify things... we'd had an extended discussion about > whether it was reasonable to remove a message from a view, once it was > in the view. Problems of side-effects and such -- for instance, what > happens in the following case (abbreviating a little): > [skipped] > But I would like to see some of these potential problems mentioned in the > spec. I would also like to see some encouragement to use UIDs instead of > view positions. In fact, I'd go as far as to say that I don't think we > should *have* a VIEW FETCH, VIEW STORE, or VIEW COPY command, and that we > should clearly state that UIDs are the things to use when you're using views. I am tend to support the idea. -- Best Regards, Alexey Melnikov From owner-ietf-imapext Tue Jun 29 16:35:45 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA08539 for ietf-imapext-bks; Tue, 29 Jun 1999 16:35:45 -0700 (PDT) Received: from mailhost1.u.washington.edu (mailhost1.u.washington.edu [140.142.32.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA08535 for ; Tue, 29 Jun 1999 16:35:44 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (bwi@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost1.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.01) with ESMTP id QAA07056; Tue, 29 Jun 1999 16:39:15 -0700 Date: Tue, 29 Jun 1999 16:25:56 -0700 (PDT) From: Mark Crispin Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt To: Barry Leiba cc: Cyrus Daboo , ietf-imapext@imc.org, IMAP@u.washington.edu In-Reply-To: <37791CD0.99397D08@watson.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: First, an apology. My contribution to this document so far has been mostly architectural, so if I say something that doesn't fully mesh with what the document says, keep this in mind. > * Section 4.1 refers to an "optional" sub-command, and (a) says that > the VIEW SET command selects messages that "match the results of the > sub-command". It doesn't make it clear what happens if there's no > sub-command (all messages are selected, I presume). I thought that VIEW SET without a command was to cancel the view. If this isn't specified, it should be. > It also doesn't > say much about the sub-command; if "SEARCH" is the only command in > the base spec that applies, it should probably say so, to prevent > people from wondering what commands apply. It might also say (which > is also said elsewhere) that it's intended that future SORT and > THREAD commands may go here. Let's talk about the wordsmithing for this at Oslo. VIEW SET's command argument is a command that defines a set (and, potentially, ordering) of messages. I agree that this needs to be well-specified, but I don't want to tag/limit it to SEARCH/SORT/THREAD even if that's the actual situation today. > * In 4.2 you should make it clear what, if anything, it means to use a > VIEW command without a VIEW SET being in effect. It seems to me that > it's nonsensical (so should "VIEW FETCH" respond "NO" or "BAD" in that > case?). I think that it's a BAD. > I would also like to see some encouragement to use UIDs instead of > view positions. In fact, I'd go as far as to say that I don't think we > should *have* a VIEW FETCH, VIEW STORE, or VIEW COPY command, and that we > should clearly state that UIDs are the things to use when you're using > views. You need some way to express hierarchy in a VIEW (for threading), which is why neither sequence numbers nor UIDs are good enough. If you use either a sequence number or UID (I don't think that one should be preferred over the other, beyond what technical considerations indicate), then you have to maintain the map or some portion of it. The whole point for VIEW FETCH and friends is so you don't need to have the map at all. From owner-ietf-imapext Tue Jun 29 17:17:57 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA09510 for ietf-imapext-bks; Tue, 29 Jun 1999 17:17:57 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA09506 for ; Tue, 29 Jun 1999 17:17:56 -0700 (PDT) Received: from sardis.cyrusoft.com (sardis.cyrusoft.com [206.31.218.203]) by darius.cyrusoft.com (8.8.5/8.8.5) with ESMTP id UAA16133; Tue, 29 Jun 1999 20:21:14 -0400 (EDT) Date: Tue, 29 Jun 1999 20:22:42 -0400 From: Cyrus Daboo To: Barry Leiba cc: ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt Message-ID: <477154.3139676562@sardis.cyrusoft.com> In-Reply-To: <37791CD0.99397D08@watson.ibm.com> Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431 X-Mailer: Mulberry (MacOS) [2.0.0a3, s/n S1-000001] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: --On Tue, Jun 29, 1999 3:21 PM -0400 Barry Leiba wrote: > * Section 4.1 refers to an "optional" sub-command, and (a) says that > the VIEW SET command selects messages that "match the results of the > sub-command". It doesn't make it clear what happens if there's no > sub-command (all messages are selected, I presume). No - a VIEW SET without a sub-command cancels the view mode. The server then falls back to 'standard' IMAP4 behaviour and the VIEW ... commands are invalid. > It also doesn't > say much about the sub-command; if "SEARCH" is the only command in > the base spec that applies, it should probably say so, to prevent > people from wondering what commands apply. It might also say (which > is also said elsewhere) that it's intended that future SORT and > THREAD commands may go here. Agreed. This document should define what commands are currently valid with VIEW SET, with provisions for future extensions to define new sub-commands. > * In 4.1 (b), "c.f." is properly abbreviated "cf.", and, anyway, is the > wrong Latin abbreviation here. "cf." means "compare" (from the Latin > "confer"), and I don't think you want anyone to compare what you say > here to what's said in 4.2. If you mean "see section 4.2", just say it. > (Sorry... pet peeve about misuse of Latin abbreviations.) Your're right. I guess I failed to pay full attention in my Latin classes! > * In 4.2 you should make it clear what, if anything, it means to use a > VIEW command without a VIEW SET being in effect. It seems to me that > it's nonsensical (so should "VIEW FETCH" respond "NO" or "BAD" in that > case?). I think it must be a BAD. The document must say that clients MUST NOT issue the VIEW command when a VIEW SET is not operational, and servers MUST respond with BAD. This can be clarified in section 4.2. > * In 4.2, you say > command response. However, server implementations MUST implicitly > include the VIEW fetch item as part of any FETCH response caused by > a VIEW command, regardless of whether a VIEW was specified as a > message data item to the FETCH. > > ...but you've already said that a VIEW fetch item must be included if > a VIEW SET is in effect. If I'm right in my previous note, then you > probably shouldn't *also* say this. Actually 4.1(c) only refers to unsolicited FETCH responses. Perhaps this should be changed to 'all FETCH responses' in 4.1(c) and the section quoted above dropped. > * In 5.1.1: > A VIEW untagged response MUST NOT be sent when no command is in > progress; nor while responding to a FETCH, SEARCH or STORE command. > > Understandable. But that means that a client that receives an EXISTS > in response to a FETCH must then go issue a NOOP to get the > corresponding VIEW response. Can we think of a better way? Hmm, that's a difficult one. I'm sure we can come up with a wy to deal with this. > * In 5.1.2: > When the old view position number in the VIEW untagged response is > non-zero, the effect of VIEW is a message inserted into the view at > the position given by . The view position numbers of all > subsequent messages inthge current view are incremented. > > When the new view position number in the VIEW untagged response is > non-zero, the effect of VIEW is a message removed from the view at > the position given by . The view position numbers of all > subsequent messages inthe current view are decremented. > > In both of these, I think you mean "zero" where you say "non-zero". Yup, that's wrong in the document. > Also also, since you explicitly talk about incrementing and decrementing > view position numbers, perhaps you should include a paragraph about what > happens if both the old and new positions are non-zero... which also > require renumbering other messages. No, *I* don't think it needs to be > said, but, then, I'm always surprised at the interpretations that > sometimes happen when one fails to say something. :-) This can easily be added, and would be a good example to clarify things. > * In the grammar: > position ::= number ["." number] > ;; position number of messages in the view > ;; may be hierarchical if sub-command defines > ;; hierarchic ordering of messages > > This makes some of the statements about "incrementing" and > "decrementing" view positions harder to understand. Maybe all we > should say about what happens after a VIEW response is that "view > positions of subsequent [or intervening] messages must be adjusted > appropriately" or some such. That phrase could be used together with the existing examples. > * Finally, just to clarify things... we'd had an extended discussion about > whether it was reasonable to remove a message from a view, once it was > in the view. Problems of side-effects and such -- for instance, what > happens in the following case (abbreviating a little): > c: t0 VIEW SET SEARCH UNSEEN > s: * 25 VIEW 1234 0 4 > c: t1 VIEW FETCH 4 BODY[1] > s: * 25 FETCH (FLAGS (\Seen) VIEW 4 BODY[1] ... > s: t1 OK done > c: t2 NOOP > s: * 25 VIEW 1234 4 0 [\Seen flag caused view to change] > s: t2 OK done > > Now, as a side-effect of the FETCH, the client can no longer use VIEW > FETCH on this message. Other cases are easy to imagine. It makes VIEW > FETCH of questionable use. > > Clearly, the decision made in writing this draft was to have messages > disappear from the view (during earlier discussions, some thought they > should not, though it came out that that makes reconnecting after > connection failures difficult). > > I just wanted to point out, for the record, that there were two sides to > that discussion, and to point out, for the record, which one was > adopted. (And, for the record, I agree with the choice.) I think the issue of 'static' vs 'dynamic' views still needs more discussion. I've not ruled out one or the other or indeed both. For example to do VIEW in static mode, we just remove the unsolicted VIEW untagged response and add a 'VIEW UPDATE' command, which returns untagged VIEWs for all changes since the last VIEW SET or VIEW UPDATE. One could even envisage a situation where the client determines whether the view is static or dynamic based on the command it issues. > But I would like to see some of these potential problems mentioned in > the spec. I would also like to see some encouragement to use UIDs > instead of view positions. In fact, I'd go as far as to say that I > don't think we should *have* a VIEW FETCH, VIEW STORE, or VIEW COPY > command, and that we should clearly state that UIDs are the things to > use when you're using views. No, you have to have the VIEW commands because there is no way to know how the UIDs map into the view. Clients must be able to say 'fetch the first ten messages in my sorted view'. Without VIEW FETCH the client has no way of knowing the sequence numbers or UIDs of these messages without first doing a 'FETCH 1:* (UID VIEW)', which would defeat the whole purpose of VIEW itself. Having said that, with the 'dynamic' view approach it does need to be made clear that clients will need to maintain their own UID mappings, as they may need to access messages that move outside the view (as per your example). -- Cyrus From owner-ietf-imapext Wed Jun 30 05:05:19 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA05513 for ietf-imapext-bks; Wed, 30 Jun 1999 05:05:19 -0700 (PDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA05509 for ; Wed, 30 Jun 1999 05:05:18 -0700 (PDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id IAA105828 for ; Wed, 30 Jun 1999 08:08:53 -0400 Received: from mars.watson.ibm.com (mars.watson.ibm.com [9.2.2.58]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with ESMTP id IAA28768 for ; Wed, 30 Jun 1999 08:08:53 -0400 Date: Wed, 30 Jun 1999 08:08:52 -0400 From: Barry Leiba To: ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt Message-ID: <3017196325.930730132@mars.watson.ibm.com> In-Reply-To: <477154.3139676562@sardis.cyrusoft.com> Originator-Info: login-id=leiba; server=mars.watson.ibm.com X-Mailer: Mulberry (Win32) [2.0.0a1, s/n U-301245] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Cyrus says... > No - a VIEW SET without a sub-command cancels the view mode. As all three of you said; yes, I must have been distracted when I was reading that part. Sorry. > Agreed. This document should define what commands are currently valid with > VIEW SET, with provisions for future extensions to define new > sub-commands. I agree with Mark that we don't want to limit ourselves, but what Cyrus says above was my intent when I made my comment: make it clear what commands are appropriate now (and make it clear what the response will be ("BAD", I think) if you use an inappropriate command), and also make it clear that future extensions may add commands to the "appropriate" list. > Your're right. I guess I failed to pay full attention in my Latin classes! :-) > I think it must be a BAD. The document must say that clients MUST NOT > issue the VIEW command when a VIEW SET is not operational, and servers > MUST respond with BAD. This can be clarified in section 4.2. Agreed. Good. Me: >> ...but you've already said that a VIEW fetch item must be included if >> a VIEW SET is in effect. If I'm right in my previous note, then you >> probably shouldn't *also* say this. Alexey: > IMHO, it is not a big trouble to say something twice, especially in this > case. I'd generally agree, but the trouble here is that it's being said slightly different, and I worry that the difference will confuse someone who's reading the spec with only a marginal understanding of what's going on. Cyrus: > Actually 4.1(c) only refers to unsolicited FETCH responses. Perhaps this > should be changed to 'all FETCH responses' in 4.1(c) and the section > quoted above dropped. Yeah, I like that answer. >> Understandable. But that means that a client that receives an EXISTS >> in response to a FETCH must then go issue a NOOP to get the >> corresponding VIEW response. Can we think of a better way? > > Hmm, that's a difficult one. I'm sure we can come up with a wy to deal > with this. Since I won't be in Oslo, if you discuss this there I'd like to see a summary posted here. Well, I suppose that someone'll take minutes of the WG meeting and the whole thing'll be posted here anyway, so.... > No, you have to have the VIEW commands because there is no way to know how > the UIDs map into the view. Clients must be able to say 'fetch the first > ten messages in my sorted view'. Without VIEW FETCH the client has no way > of knowing the sequence numbers or UIDs of these messages without first > doing a 'FETCH 1:* (UID VIEW)', which would defeat the whole purpose of > VIEW itself. Well, duh. Of course; I didn't think it out enough before I said what I said. Mark's also right about the hierarchy. Of *course* we need the VIEW FETCH command and so on. > Having said that, with the 'dynamic' view approach it does need to be made > clear that clients will need to maintain their own UID mappings, as they > may need to access messages that move outside the view (as per your > example). Maybe a section on "implementation considerations" would be useful. It could highlight this, it could suggest when a client might want to use VIEW (and when not), and that sort of thing. Something brief, naturally, but it might be nice to have. (Again, I'm thinking of some of the questions we see people asking about IMAP sometimes, which indicate that they're trying to implement it without understanding it.) Barry Leiba, Internet Messaging Technology (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba From owner-ietf-imapext Wed Jun 30 10:44:05 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA14778 for ietf-imapext-bks; Wed, 30 Jun 1999 10:44:05 -0700 (PDT) Received: from email.Tristrata.com (adsl-207-104-6-194.dsl.snfc21.pacbell.net [207.104.6.194]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA14774 for ; Wed, 30 Jun 1999 10:44:02 -0700 (PDT) Received: from engineer17 (192.168.8.117 [192.168.8.117]) by email.Tristrata.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id N1SF9RB5; Wed, 30 Jun 1999 10:27:52 -0700 Reply-To: From: "CJ Lofstedt" To: "'Alexey Melnikov'" , , "'Cyrus Daboo'" Subject: RE: I-D ACTION:draft-daboo-imap-view-00.txt Date: Wed, 30 Jun 1999 10:31:39 -0700 Message-ID: <000a01bec31e$6ac1bef0$7508a8c0@engineer17.tristrata.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <3779545C.18AD4F8C@taxxi.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > -----Original Message----- > From: owner-ietf-imapext@imc.org [mailto:owner-ietf-imapext@imc.org]On > Behalf Of Alexey Melnikov > Sent: Tuesday, June 29, 1999 4:19 PM > To: Cyrus Daboo > Cc: ietf-imapext@imc.org > Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt > > > Cyrus Daboo wrote: > > > Hi folks, > > A new internet draft is available at: > > > > > > > > [skipped] > > > > Note that this document proposes a mechanism different from > that discussed > > by various groups at recent IETF and IMC interop meetings. > I can post a > > list of reasons why we feel this approach is better if > there is interest. > > I understand most of them (I didn't like the idea to overload > SELECT from the > beginning), but I would like to know them all. > I would also be interested in hearing why the "overloaded SELECT" (view as a folder) approach has been completely ruled out. /C-J Lofstedt From owner-ietf-imapext Wed Jun 30 17:21:18 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA19498 for ietf-imapext-bks; Wed, 30 Jun 1999 17:21:18 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (rossi@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA19494 for ; Wed, 30 Jun 1999 17:21:15 -0700 (PDT) Date: Wed, 30 Jun 1999 17:05:30 -0700 (PDT) From: Mark Crispin Subject: RE: I-D ACTION:draft-daboo-imap-view-00.txt To: clofstedt@tristrata.com cc: "'Alexey Melnikov'" , ietf-imapext@imc.org, "'Cyrus Daboo'" In-Reply-To: <000a01bec31e$6ac1bef0$7508a8c0@engineer17.tristrata.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Wed, 30 Jun 1999 10:31:39 -0700, CJ Lofstedt wrote: > I would also be interested in hearing why the "overloaded SELECT" (view as a > folder) approach has been completely ruled out. The short answer is "several people who work with IMAP don't like the idea of overloading SELECT. They think that they have a better way, and don't want to do any work on what they consider to be inferior." Basically, the problem with overloading SELECT is just that; it overloads an existing mechanism and thus requires a server modality that changes existing IMAP commands and responses, and too many incompatible changes need to be made to the existing mechanism. Another issue is that the client may want to change the view on the selected mailbox. With the VIEW architecture, this is simple; just do a new VIEW SET. But, with overloaded SELECT, you have to issue a new SELECT. Overloaded SELECT also limits the view mechanism to what is defined in the overload. VIEW, on the other hand, is designed to be extensible. There's a few other issues, but these are the big ones. These problems with overloaded SELECT aren't unsolvable. However, (at least in my opinion) the VIEW architecture is superior in all respects and there really isn't much point to wasting time on overloaded SELECT. It is superior to add to IMAP instead of changing what is already there. With all of the above in mind, I would not object to adding a means to do both a SELECT and a VIEW SET in the same command, e.g. something like tag VIEW SELECT INBOX SEARCH FROM "Fred" that is, a VIEW SELECT command whose first argument is the mailbox name to be selected and subsequent arguments are as in VIEW SET. It would have to be stipulated that you can change the view with VIEW SET and don't need to issue another VIEW SELECT -- so VIEW SELECT is just a way of reducing RTTs. From owner-ietf-imapext Thu Jul 1 13:09:38 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA06867 for ietf-imapext-bks; Thu, 1 Jul 1999 13:09:38 -0700 (PDT) Received: from tide03.microsoft.com (firewall-user@tide03.microsoft.com [131.107.3.13]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA06863 for ; Thu, 1 Jul 1999 13:09:37 -0700 (PDT) Received: by tide03.microsoft.com; id NAA05286; Thu, 1 Jul 1999 13:13:14 -0700 (PDT) Received: from imail2.dns.microsoft.com(157.54.17.74) by tide03.microsoft.com via smap (V3.1) id xma005222; Thu, 1 Jul 99 13:12:59 -0700 Received: from red-imc-01.dns.microsoft.com ([157.54.4.91]) by imail2.microsoft.com (8.7.3/8.7.1) with ESMTP id NAA14999; Thu, 1 Jul 1999 13:29:07 -0700 (PDT) Received: from red-imc-01.dns.microsoft.com (RED-IMC-01 [157.54.4.91]) by red-imc-01.dns.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id N8DYHNTX; Thu, 1 Jul 1999 13:11:46 -0700 Received: from 172.30.236.86 by red-imc-01.dns.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 01 Jul 1999 13:11:41 -0700 (Pacific Daylight Time) Received: from PTROUTE.dfpt.extest.microsoft.com (PTROUTE [172.30.236.83]) by ptgate.dns.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 3CZPLT8Q; Thu, 1 Jul 1999 13:11:23 -0700 Received: from PTDOG.dfpt.extest.microsoft.com ([172.30.236.159]) by PTROUTE.dfpt.extest.microsoft.com with Microsoft SMTPSVC(5.0.2067.0067.0); Thu, 1 Jul 1999 13:13:16 -0700 Received: from mikega9 ([157.59.255.62]) by PTDOG.dfpt.extest.microsoft.com with Microsoft SMTPSVC(5.0.2067.0067.0); Thu, 1 Jul 1999 09:46:11 -0700 Message-ID: <001001bec3e1$115e8e60$3eff3b9d@dns.microsoft.com> From: "Mike Gahrns" To: "Rubinstein, Dmitry" , References: <5C5BA40F28F1D211AAE200105A057CB0210FE1@GOOFY_EX.QUANTUM.icomverse.com> Subject: Re: Client ID extension Date: Thu, 1 Jul 1999 09:45:03 -0700 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 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-OriginalArrivalTime: 01 Jul 1999 16:46:11.0660 (UTC) FILETIME=[39BB80C0:01BEC3E1] Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Dmitry writes: > > From: Mike Gahrns [mailto:mikega@microsoft.com] > > Given that there seems to be > > reasonable > > number of people who concur that this type of functionality > > would be useful, > > moving the extension forward should hopefully be rather > > straight foward with > > only minor changes needed. > > > OK then, what are the needed changes? Below is the original draft for your > reference. Since there was a lot of concerns about the potential abuse of it and privacy concerns, we probably should have stronger language regarding the caveats around this to avoid potential abuse. e.g. in the client parameter list it states any value over and above the defined fields can be sent. I think you'd want a stronger privacy statement here, in case people start sending more than the defined fields and include things like Processor ID, MAC address etc. (I certainly don't want to start a discussion regarding the merits or non-merits of including this type of info, but I think it would be wise to have strong language here) In the security section, it should be noted that knowing the make/type of client/server could make it easier for hackers to exploit known vulnerabilities with particular software. If you cruise through the IMAP archives you'll probably find some other comments as well. If memory serves me correctly, I think the author, Tim Showalter, said that he had a list of changes he wanted to incorporate. In any event, I think any changes would be minor in nature, and would be more along the lines of "editorial" type changes. From owner-ietf-imapext Thu Jul 1 13:18:03 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA06991 for ietf-imapext-bks; Thu, 1 Jul 1999 13:18:03 -0700 (PDT) Received: from resnick1.qualcomm.com (resnick1.qualcomm.com [206.139.85.98]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA06987 for ; Thu, 1 Jul 1999 13:18:01 -0700 (PDT) Received: from resnick2.qualcomm.com (206.139.85.99) by resnick1.qualcomm.com with ESMTP (Eudora Internet Mail Server 3.0a9); Thu, 1 Jul 1999 15:21:32 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: X-Mailer: Eudora [Macintosh version 4.2b??] Date: Thu, 1 Jul 1999 15:21:27 -0500 To: ietf-imapext@imc.org From: Pete Resnick Subject: Agenda due today Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: In among my mayhem, I'd forgotten that I was supposed to get an agenda for the BOF in today. I'll get it in late today and hope I don't get yelled at. I assume we'll spend a little time on the charter, but then what's on the plate? I'm sending something in by 6PM CDT today (so that Marcia doesn't beat me up) with or without input, so please send input ASAP. Otherwise, I'll make something up. pr -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (619)651-4478, Fax: (619)651-1102 From owner-ietf-imapext Thu Jul 1 13:25:44 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA07085 for ietf-imapext-bks; Thu, 1 Jul 1999 13:25:44 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA07081 for ; Thu, 1 Jul 1999 13:25:43 -0700 (PDT) Received: from ephesus.cyrusoft.com (ephesus.cyrusoft.com [206.31.218.204]) by darius.cyrusoft.com (8.8.5/8.8.5) with ESMTP id QAA23058; Thu, 1 Jul 1999 16:29:13 -0400 (EDT) Date: Thu, 01 Jul 1999 16:29:51 -0400 From: Cyrus Daboo To: Pete Resnick , ietf-imapext@imc.org Subject: Re: Agenda due today Message-ID: <3133655238.930846591@ephesus.cyrusoft.com> In-Reply-To: Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431 X-Mailer: Mulberry (Win32) [2.0.0a3, s/n S1-000001] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: --On Thursday, July 01, 1999, 3:21 PM -0500 Pete Resnick wrote: > In among my mayhem, I'd forgotten that I was supposed to get an > agenda for the BOF in today. I'll get it in late today and hope I > don't get yelled at. I assume we'll spend a little time on the > charter, but then what's on the plate? > > I'm sending something in by 6PM CDT today (so that Marcia doesn't > beat me up) with or without input, so please send input ASAP. > Otherwise, I'll make something up. I guess we want something like: 1) Charter completion - approval of WG status 2) Discuss VIEW/SORT drafts (long) 3) Discuss ACL2 (should consult John Myers to see how much he's been able to do on this) 4) Discuss annotations (short as there's no real draft yet, but a general 'how should we do it' discussion would be good) 5) Discuss other extensions not on the 'official' charter (e.g. Client ID and anything else that folks want to bring up) -- Cyrus From owner-ietf-imapext Thu Jul 1 14:58:04 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA07730 for ietf-imapext-bks; Thu, 1 Jul 1999 14:58:04 -0700 (PDT) Received: from baikonur.demo.ru ([194.87.43.111]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA07725 for ; Thu, 1 Jul 1999 14:58:02 -0700 (PDT) Received: from taxxi.com ([195.218.251.249]) by baikonur.demo.ru (Netscape Messaging Server 3.62) with ESMTP id 393; Fri, 2 Jul 1999 02:00:37 +0400 Message-ID: <377BE4D7.9484EFDC@taxxi.com> Date: Fri, 02 Jul 1999 01:59:51 +0400 From: Alexey Melnikov X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: ru,en-US MIME-Version: 1.0 To: Cyrus Daboo CC: Pete Resnick , ietf-imapext@imc.org Subject: Re: Agenda due today References: <3133655238.930846591@ephesus.cyrusoft.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Cyrus Daboo wrote: > --On Thursday, July 01, 1999, 3:21 PM -0500 Pete Resnick > wrote: > > > In among my mayhem, I'd forgotten that I was supposed to get an > > agenda for the BOF in today. I'll get it in late today and hope I > > don't get yelled at. I assume we'll spend a little time on the > > charter, but then what's on the plate? > > > > I'm sending something in by 6PM CDT today (so that Marcia doesn't > > beat me up) with or without input, so please send input ASAP. > > Otherwise, I'll make something up. > > I guess we want something like: > > 1) Charter completion - approval of WG status > 2) Discuss VIEW/SORT drafts (long) > 3) Discuss ACL2 (should consult John Myers to see how much he's been able > to do on this) > 4) Discuss annotations (short as there's no real draft yet, but a general > 'how should we do it' discussion would be good) > 5) Discuss other extensions not on the 'official' charter (e.g. Client ID > and anything else that folks want to bring up) Probably we should discuss LANGUAGE extension. -- Best Regards, Alexey Melnikov From owner-ietf-imapext Thu Jul 1 15:18:39 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA07985 for ietf-imapext-bks; Thu, 1 Jul 1999 15:18:39 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (alex@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA07981 for ; Thu, 1 Jul 1999 15:18:38 -0700 (PDT) Date: Thu, 1 Jul 1999 15:22:03 -0700 (Pacific Daylight Time) From: Mark Crispin To: Alexey Melnikov cc: Cyrus Daboo , Pete Resnick , ietf-imapext@imc.org Subject: Re: Agenda due today In-Reply-To: <377BE4D7.9484EFDC@taxxi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Fri, 2 Jul 1999, Alexey Melnikov wrote: > Probably we should discuss LANGUAGE extension. I propose that we form a small e-mail working sub-group of people interested this issue, rather than spend the limited time in Oslo. The Oslo meeting should just mention the existance of the sub-group and the mailing list for it. This is too complex and too important of an issue to be tossed into the agenda and made to compete with the other issues already in the agenda. I will oppose any "quick and dirty" proposal for LANGUAGE. We have to do this right, and doing it right requires careful consideration from all of us. We need to consider localization, internationalization, and mulilingualization; and from these draw up a list of desired functionalties. Among other things, we need to establish a transition mechanism from ASCII and charsets to pure UTF-8. I have no problem with a separate face-to-face meeting of people interested in LANGUAGE at Oslo. From owner-ietf-imapext Thu Jul 1 16:07:06 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA08548 for ietf-imapext-bks; Thu, 1 Jul 1999 16:07:06 -0700 (PDT) Received: from baikonur.demo.ru ([194.87.43.111]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA08544 for ; Thu, 1 Jul 1999 16:07:01 -0700 (PDT) Received: from taxxi.com ([195.218.251.249]) by baikonur.demo.ru (Netscape Messaging Server 3.62) with ESMTP id 112; Fri, 2 Jul 1999 03:09:36 +0400 Message-ID: <377BF502.DD02CE7@taxxi.com> Date: Fri, 02 Jul 1999 03:08:51 +0400 From: Alexey Melnikov X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: ru,en-US MIME-Version: 1.0 To: Mark Crispin CC: ietf-imapext@imc.org Subject: Re: Agenda due today References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Mark Crispin wrote: > On Fri, 2 Jul 1999, Alexey Melnikov wrote: > > Probably we should discuss LANGUAGE extension. > > I propose that we form a small e-mail working sub-group of people > interested this issue, rather than spend the limited time in Oslo. The > Oslo meeting should just mention the existance of the sub-group and the > mailing list for it. > > This is too complex and too important of an issue to be tossed into the > agenda and made to compete with the other issues already in the agenda. > > I will oppose any "quick and dirty" proposal for LANGUAGE. We have to do > this right, and doing it right requires careful consideration from all of > us. > > We need to consider localization, internationalization, and > mulilingualization; and from these draw up a list of desired > functionalties. Among other things, we need to establish a transition > mechanism from ASCII and charsets to pure UTF-8. > > I have no problem with a separate face-to-face meeting of people > interested in LANGUAGE at Oslo. I don't mind. Let me know about date and time for LANGUAGE meeting. (BTW, I've recently submitted SMTP LANG draft, we may discuss it as well). I will be in Oslo all week. -- Best Regards, Alexey Melnikov +----------------------------------------------------+ |SMTP/POP3/IMAP4/ACAP | Epsylon Technologies, Russia| |servers creation team | http://www.taxxi.com | |----------------------------------------------------| |Imap Development Kit (my own product) | |http://194.87.43.111/homerus/mail/idk/index.htm | |----------------------------------------------------| |Fax (in San Diego, California): 1 (619) 8393837 | +----------------------------------------------------+ From owner-ietf-imapext Thu Jul 1 16:04:59 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA08509 for ietf-imapext-bks; Thu, 1 Jul 1999 16:04:59 -0700 (PDT) Received: from tide03.microsoft.com (firewall-user@tide03.microsoft.com [131.107.3.13]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA08504 for ; Thu, 1 Jul 1999 16:04:58 -0700 (PDT) Received: by tide03.microsoft.com; id QAA09467; Thu, 1 Jul 1999 16:08:37 -0700 (PDT) Received: from imail2.dns.microsoft.com(157.54.17.74) by tide03.microsoft.com via smap (V3.1) id xma009444; Thu, 1 Jul 99 16:08:28 -0700 Received: from red-imc-01.dns.microsoft.com ([157.54.4.91]) by imail2.microsoft.com (8.7.3/8.7.1) with ESMTP id QAA17886; Thu, 1 Jul 1999 16:24:38 -0700 (PDT) Received: from red-imc-01.dns.microsoft.com (RED-IMC-01 [157.54.4.91]) by red-imc-01.dns.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id N8DYH9H1; Thu, 1 Jul 1999 16:07:19 -0700 Received: from 172.30.236.242 by red-imc-01.dns.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 01 Jul 1999 16:07:19 -0700 (Pacific Daylight Time) Received: from PTROUTE.dfpt.extest.microsoft.com (PTROUTE [172.30.236.83]) by popdog.exchange.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 3C0A5SLP; Thu, 1 Jul 1999 16:07:22 -0700 Received: from PTDOG.dfpt.extest.microsoft.com ([172.30.236.159]) by PTROUTE.dfpt.extest.microsoft.com with Microsoft SMTPSVC(5.0.2067.0067.0); Thu, 1 Jul 1999 16:09:12 -0700 Received: from mikega9 ([157.59.255.62]) by PTDOG.dfpt.extest.microsoft.com with Microsoft SMTPSVC(5.0.2067.0067.0); Thu, 1 Jul 1999 14:06:15 -0700 Message-ID: <001b01bec405$64bbc360$3eff3b9d@dns.microsoft.com> From: "Mike Gahrns" To: "Cyrus Daboo" , "Barry Leiba" Cc: References: <477154.3139676562@sardis.cyrusoft.com> Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt Date: Thu, 1 Jul 1999 14:05:05 -0700 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 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-OriginalArrivalTime: 01 Jul 1999 21:06:15.0595 (UTC) FILETIME=[8E6707B0:01BEC405] Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > > * In 5.1.2: > > When the old view position number in the VIEW untagged response is > > non-zero, the effect of VIEW is a message inserted into the view at > > the position given by . The view position numbers of all > > subsequent messages inthge current view are incremented. > > > > When the new view position number in the VIEW untagged response is > > non-zero, the effect of VIEW is a message removed from the view at > > the position given by . The view position numbers of all > > subsequent messages inthe current view are decremented. > > > > In both of these, I think you mean "zero" where you say "non-zero". > > Yup, that's wrong in the document. *** I also think that you have the order of and view numbers reversed in your examples in this section relative to the definition of view response you give in 5.1.2 From owner-ietf-imapext Wed Jul 7 14:10:47 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA26979 for ietf-imapext-bks; Wed, 7 Jul 1999 14:10:47 -0700 (PDT) Received: from service.alpha.net (service.alpha.net [156.46.10.26]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA26966 for ; Wed, 7 Jul 1999 14:10:45 -0700 (PDT) Received: by service.alpha.net (8.9.0/8.9.0) id QAA18204; Wed, 7 Jul 1999 16:04:37 -0500 (CDT) Received: from server1.smtp.alpha.net (server1.smtp.alpha.net [156.46.10.27]) by service.alpha.net (8.9.0/8.9.0) with ESMTP id QAA00038 for ; Wed, 30 Jun 1999 16:09:07 -0500 (CDT) Received: from lists5.u.washington.edu (lists5.u.washington.edu [140.142.56.6]) by server1.smtp.alpha.net (8.9.1/8.9.1) with ESMTP id MAA26243 for ; Mon, 28 Jun 1999 12:20:38 -0500 (CDT) Received: from host (server@lists.u.washington.edu [140.142.56.13]) by lists5.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.01) with SMTP id KAA18469; Mon, 28 Jun 1999 10:17:27 -0700 Received: from mxu4.u.washington.edu (mxu4.u.washington.edu [140.142.33.8]) by lists.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.01) with ESMTP id KAA22422 for ; Mon, 28 Jun 1999 10:16:24 -0700 Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mxu4.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.06) with ESMTP id KAA25009 for ; Mon, 28 Jun 1999 10:16:18 -0700 Received: from ephesus.cyrusoft.com (ephesus.cyrusoft.com [206.31.218.204]) by darius.cyrusoft.com (8.8.5/8.8.5) with ESMTP id NAA10190; Mon, 28 Jun 1999 13:16:04 -0400 (EDT) Message-Id: <2862869525.930575805@ephesus.cyrusoft.com> Date: Mon, 28 Jun 1999 13:16:45 -0400 List-Help: List-Unsubscribe: List-Subscribe: List-Owner: (Human contact for the list) List-Post: From: Cyrus Daboo To: ietf-imapext@imc.org Cc: IMAP@u.washington.edu Subject: I-D ACTION:draft-daboo-imap-view-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Listprocessor-Version: 8.1 -- ListProcessor(tm) by CREN Status: O X-UID: 28 Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Hi folks, A new internet draft is available at: This is the first cut at moving towards a standardised sorting mechanism for IMAP. The extension proposed in this draft is actually a more general extension that is used to allow a client to operate on a sub-set of messages (as determined right now by an IMAP SEARCH command) as opposed to the entire set of messages in the mailbox. Basically this extension introduces a couple of new commands, together with some new responses, including a new FETCH item called 'VIEW' which is the message's position in the 'sub-set' or 'view'. Clients can then access messages by their view position using a new VIEW command that takes FETCH (and other commands) as arguments (inthe same way as the UID command already present in IMAP4). It is proposed that a future SORT extension will be used with the VIEW mechanism to allow sub-setting of sort results and to allow clients to access the messages in sorted order as opposed to sequence number order. Thus this draft represents the first step towards the goal of a sort command acceptable to all - hopefully! BTW that the VIEW mechanism can be used with other types of sub-setting we might want to think about in the future (e.g. message threading based on message-id/in-reply-to etc). Note that this document proposes a mechanism different from that discussed by various groups at recent IETF and IMC interop meetings. I can post a list of reasons why we feel this approach is better if there is interest. --Cyrus Daboo From owner-ietf-imapext Wed Jul 7 14:10:33 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA26941 for ietf-imapext-bks; Wed, 7 Jul 1999 14:10:33 -0700 (PDT) Received: from service.alpha.net (service.alpha.net [156.46.10.26]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA26937 for ; Wed, 7 Jul 1999 14:10:31 -0700 (PDT) Received: by service.alpha.net (8.9.0/8.9.0) id QAA18180; Wed, 7 Jul 1999 16:04:22 -0500 (CDT) Received: from server1.smtp.alpha.net (server1.smtp.alpha.net [156.46.10.27]) by service.alpha.net (8.9.0/8.9.0) with ESMTP id QAA00016 for ; Wed, 30 Jun 1999 16:08:56 -0500 (CDT) Received: from lists5.u.washington.edu (lists5.u.washington.edu [140.142.56.6]) by server1.smtp.alpha.net (8.9.1/8.9.1) with ESMTP id RAA01212 for ; Mon, 28 Jun 1999 17:00:27 -0500 (CDT) Received: from host (server@lists.u.washington.edu [140.142.56.13]) by lists5.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.01) with SMTP id OAA29456; Mon, 28 Jun 1999 14:57:19 -0700 Received: from mxu1.u.washington.edu (mxu1.u.washington.edu [140.142.32.8]) by lists.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.01) with ESMTP id OAA16864 for ; Mon, 28 Jun 1999 14:56:10 -0700 Received: from alms1.fw.att.com (alms1.att.com [192.128.167.146]) by mxu1.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.06) with ESMTP id OAA08436 for ; Mon, 28 Jun 1999 14:56:09 -0700 Received: from dns.maillennium.att.com ([135.25.114.99]) by alms1.fw.att.com (AT&T IPNS/MS-2.2) with ESMTP id RAA07221 for ; Mon, 28 Jun 1999 17:56:05 -0400 (EDT) Received: from att.com (hansenpc.bl-els.att.com[135.25.111.58](may be forged)) by maillennium.att.com (labmail) with SMTP id <19990628215414un129110fie>; Mon, 28 Jun 1999 21:54:14 +0000 Message-Id: <3777EEA4.A650B2F7@att.com> Date: Mon, 28 Jun 1999 17:52:36 -0400 Reply-To: tony@att.com List-Help: List-Unsubscribe: List-Subscribe: List-Owner: (Human contact for the list) List-Post: From: Tony Hansen To: Cyrus Daboo Cc: ietf-imapext@imc.org, IMAP@u.washington.edu Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt References: <2862869525.930575805@ephesus.cyrusoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Accept-Language: en X-Listprocessor-Version: 8.1 -- ListProcessor(tm) by CREN Status: O X-UID: 22 Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Cyrus Daboo wrote: > > A new internet draft is available at: > > > This is the first cut at moving towards a standardised sorting mechanism > for IMAP. The extension proposed in this draft is actually a more general > extension that is used to allow a client to operate on a sub-set of > messages (as determined right now by an IMAP SEARCH command) as opposed to > the entire set of messages in the mailbox. > > Basically this extension introduces a couple of new commands, together with > some new responses, including a new FETCH item called 'VIEW' which is the > message's position in the 'sub-set' or 'view'. Clients can then access > messages by their view position using a new VIEW command that takes FETCH > (and other commands) as arguments (inthe same way as the UID command > already present in IMAP4). > ... Our major problem with this proposal is not an issue with the extension itself. Instead, we have an issue with its impact on server performance when dealing with LARGE user populations (hundreds of thousands or millions). Each proposal such as this does increase the server load. Tony Hansen tony@att.com From owner-ietf-imapext Wed Jul 7 14:10:47 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA26973 for ietf-imapext-bks; Wed, 7 Jul 1999 14:10:47 -0700 (PDT) Received: from service.alpha.net (service.alpha.net [156.46.10.26]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA26964 for ; Wed, 7 Jul 1999 14:10:45 -0700 (PDT) Received: by service.alpha.net (8.9.0/8.9.0) id QAA18197; Wed, 7 Jul 1999 16:04:35 -0500 (CDT) Received: from server1.smtp.alpha.net (server1.smtp.alpha.net [156.46.10.27]) by service.alpha.net (8.9.0/8.9.0) with ESMTP id QAA00035 for ; Wed, 30 Jun 1999 16:09:05 -0500 (CDT) Received: from lists4.u.washington.edu (lists4.u.washington.edu [140.142.56.2]) by server1.smtp.alpha.net (8.9.1/8.9.1) with ESMTP id NAA26801 for ; Mon, 28 Jun 1999 13:05:54 -0500 (CDT) Received: from host (server@lists.u.washington.edu [140.142.56.13]) by lists4.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.01) with SMTP id KAA16947; Mon, 28 Jun 1999 10:57:52 -0700 Received: from mxu1.u.washington.edu (mxu1.u.washington.edu [140.142.32.8]) by lists.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.01) with ESMTP id KAA45486 for ; Mon, 28 Jun 1999 10:56:46 -0700 Received: from metal.mcom.com (h-208-12-60-75.netscape.com [208.12.60.75]) by mxu1.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.06) with ESMTP id KAA04549 for ; Mon, 28 Jun 1999 10:56:46 -0700 Received: from Netscape.COM ([208.12.60.75]) by metal.mcom.com (Netscape Messaging Server 3.6) with ESMTP id AAA1AA0; Mon, 28 Jun 1999 10:56:33 -0700 Message-Id: <3777B74A.CB6B0ABE@Netscape.COM> Date: Mon, 28 Jun 1999 10:56:26 -0700 List-Help: List-Unsubscribe: List-Subscribe: List-Owner: (Human contact for the list) List-Post: From: Mike Macgirvin To: Cyrus Daboo Cc: ietf-imapext@imc.org, IMAP@u.washington.edu Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt References: <2862869525.930575805@ephesus.cyrusoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Sender: "Mike Macgirvin" X-Accept-Language: en X-Listprocessor-Version: 8.1 -- ListProcessor(tm) by CREN Status: O X-UID: 27 Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: This appears to have the side effect of limiting you to one view. Multiple active views would require extensive client polling, and the notification events would only be active on one of them. I'd like to propose a modest enhancement, where the client can provide a (client generated) view-id, and subsequent changes to that view are tagged with the view-id. This permits multiple active views. Granted, there is server overhead involved, but this is the price of moving it off the client in the first place. Having the client generate an ID is better than having to match an untagged response with a search string. C: A143 VIEW SET 0001 SEARCH FROM "Smith" S: * 172 EXISTS 0001 23 S: A143 OK VIEW SET completed C: A144 VIEW SET 0002 SEARCH FROM "Myboss" S: * 172 EXISTS 0001 23 0002 6 S: A144 OK VIEW SET completed It probably isn't necessary that the results be chained in the EXISTS response, i.e. S: 172 EXISTS 0001 23 S: 172 EXISTS 0002 6 would be just fine. This would alter other responses appropriately. This way mailbox events can trigger updates of any active views. Thinking one step further, something to shut down an active view would likely be desirable in this model. C: A145 VIEW REMOVE 0001 S: A145 OK VIEW 0001 FROM "Smith" removed If I'm missing something obvious and all this isn't necessary, please correct me. From owner-ietf-imapext Wed Jul 7 14:10:30 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA26932 for ietf-imapext-bks; Wed, 7 Jul 1999 14:10:30 -0700 (PDT) Received: from service.alpha.net (service.alpha.net [156.46.10.26]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA26928 for ; Wed, 7 Jul 1999 14:10:29 -0700 (PDT) Received: by service.alpha.net (8.9.0/8.9.0) id QAA18177; Wed, 7 Jul 1999 16:04:21 -0500 (CDT) Received: from server1.smtp.alpha.net (server1.smtp.alpha.net [156.46.10.27]) by service.alpha.net (8.9.0/8.9.0) with ESMTP id QAA00013 for ; Wed, 30 Jun 1999 16:08:53 -0500 (CDT) Received: from lists5.u.washington.edu (lists5.u.washington.edu [140.142.56.6]) by server1.smtp.alpha.net (8.9.1/8.9.1) with ESMTP id RAA01651 for ; Mon, 28 Jun 1999 17:41:41 -0500 (CDT) Received: from host (server@lists.u.washington.edu [140.142.56.13]) by lists5.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.01) with SMTP id PAA01014; Mon, 28 Jun 1999 15:39:05 -0700 Received: from mxu2.u.washington.edu (mxu2.u.washington.edu [140.142.32.9]) by lists.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.01) with ESMTP id PAA42294 for ; Mon, 28 Jun 1999 15:37:55 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (groves@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mxu2.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.06) with ESMTP id PAA05090 for ; Mon, 28 Jun 1999 15:37:55 -0700 Message-Id: Date: Mon, 28 Jun 1999 15:05:38 -0700 (PDT) List-Help: List-Unsubscribe: List-Subscribe: List-Owner: (Human contact for the list) List-Post: From: Mark Crispin To: tony@att.com Cc: Cyrus Daboo , ietf-imapext@imc.org, IMAP@u.washington.edu Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt In-Reply-To: <3777EEA4.A650B2F7@att.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Sender: Mark Crispin X-Listprocessor-Version: 8.1 -- ListProcessor(tm) by CREN Status: O X-UID: 21 Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Mon, 28 Jun 1999 17:52:36 -0400, Tony Hansen wrote: > Our major problem with this proposal is not an issue with the extension > itself. Instead, we have an issue with its impact on server performance > when dealing with LARGE user populations (hundreds of thousands or > millions). Each proposal such as this does increase the server load. There's a tradeoff in all of these things. Some people consider the functionality of VIEW to be very important, and have blocked SORT and THREAD unless this functionality is provided. One of their concerns is that the SORT command uses communication bandwidth; for example, sorting a 2000 message mailbox results in a response that is 8900 octets long. SORT and THREAD are very important for UW since these extensions make a *HUGE* difference in Pine performance. So, it's important for us to get these concerns addressed, and preferably in an extensible mechanism. From owner-ietf-imapext Wed Jul 7 14:10:25 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA26903 for ietf-imapext-bks; Wed, 7 Jul 1999 14:10:25 -0700 (PDT) Received: from service.alpha.net (service.alpha.net [156.46.10.26]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA26896 for ; Wed, 7 Jul 1999 14:10:24 -0700 (PDT) Received: by service.alpha.net (8.9.0/8.9.0) id QAA18168; Wed, 7 Jul 1999 16:04:15 -0500 (CDT) Received: from server1.smtp.alpha.net (server1.smtp.alpha.net [156.46.10.27]) by service.alpha.net (8.9.0/8.9.0) with ESMTP id QAA29996 for ; Wed, 30 Jun 1999 16:08:48 -0500 (CDT) Received: from lists4.u.washington.edu (lists4.u.washington.edu [140.142.56.2]) by server1.smtp.alpha.net (8.9.1/8.9.1) with ESMTP id UAA02400 for ; Mon, 28 Jun 1999 20:45:54 -0500 (CDT) Received: from host (server@lists.u.washington.edu [140.142.56.13]) by lists4.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.01) with SMTP id SAA04902; Mon, 28 Jun 1999 18:44:00 -0700 Received: from mxu2.u.washington.edu (mxu2.u.washington.edu [140.142.32.9]) by lists.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.01) with ESMTP id SAA09454 for ; Mon, 28 Jun 1999 18:42:46 -0700 Received: from mailhost2.u.washington.edu (mailhost2.u.washington.edu [140.142.33.2]) by mxu2.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.06) with ESMTP id SAA25360 for ; Mon, 28 Jun 1999 18:42:46 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (rossi@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost2.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.01) with ESMTP id SAA10510; Mon, 28 Jun 1999 18:42:45 -0700 Message-Id: Date: Mon, 28 Jun 1999 18:40:54 -0700 (PDT) List-Help: List-Unsubscribe: List-Subscribe: List-Owner: (Human contact for the list) List-Post: From: Mark Crispin To: steve spear Cc: ietf-imapext@imc.org, IMAP@u.washington.edu Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt In-Reply-To: <37781577.37D9BAF1@maillennium.att.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Sender: Mark Crispin X-Listprocessor-Version: 8.1 -- ListProcessor(tm) by CREN Status: O X-UID: 18 Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Tue, 29 Jun 1999 00:38:15 +0000, steve spear wrote: > Can someone explain how traffic is reduced by SORT over clients that are > caching the headers and simply request messages headers they haven't seen > before? Most such clients are POP clients masquerading as IMAP clients. Consider true IMAP clients, which don't have a cache (and may well be a kiosk or other shared machine which shouldn't cache!), and don't want to load all those headers. From owner-ietf-imapext Wed Jul 7 14:10:19 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA26892 for ietf-imapext-bks; Wed, 7 Jul 1999 14:10:19 -0700 (PDT) Received: from service.alpha.net (service.alpha.net [156.46.10.26]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA26888 for ; Wed, 7 Jul 1999 14:10:17 -0700 (PDT) Received: by service.alpha.net (8.9.0/8.9.0) id QAA18141; Wed, 7 Jul 1999 16:03:49 -0500 (CDT) Received: from server1.smtp.alpha.net (server1.smtp.alpha.net [156.46.10.27]) by service.alpha.net (8.9.0/8.9.0) with ESMTP id QAA29971 for ; Wed, 30 Jun 1999 16:08:35 -0500 (CDT) Received: from lists2.u.washington.edu (lists2.u.washington.edu [140.142.56.1]) by server1.smtp.alpha.net (8.9.1/8.9.1) with ESMTP id OAA12079 for ; Tue, 29 Jun 1999 14:26:10 -0500 (CDT) Received: from host (server@lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.01) with SMTP id MAA08422; Tue, 29 Jun 1999 12:23:11 -0700 Received: from mxu2.u.washington.edu (mxu2.u.washington.edu [140.142.32.9]) by lists.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.01) with ESMTP id MAA09380 for ; Tue, 29 Jun 1999 12:21:56 -0700 Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mxu2.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.06) with ESMTP id MAA13487 for ; Tue, 29 Jun 1999 12:21:54 -0700 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id PAA08494; Tue, 29 Jun 1999 15:21:53 -0400 Received: from watson.ibm.com (mars.watson.ibm.com [9.2.2.58]) by mailhub1.watson.ibm.com (8.8.7/Feb-20-98) with ESMTP id PAA11052; Tue, 29 Jun 1999 15:21:53 -0400 Message-Id: <37791CD0.99397D08@watson.ibm.com> Date: Tue, 29 Jun 1999 15:21:52 -0400 List-Help: List-Unsubscribe: List-Subscribe: List-Owner: (Human contact for the list) List-Post: From: Barry Leiba To: Cyrus Daboo Cc: ietf-imapext@imc.org, IMAP@u.washington.edu Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt References: <2862869525.930575805@ephesus.cyrusoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-Accept-Language: en X-Listprocessor-Version: 8.1 -- ListProcessor(tm) by CREN Status: O X-UID: 11 Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: First comment: Can we take the IMAP mailing list out of the list on this discussion, and just hold it on the IMAPext mailing list? It seems silly to post the same discussion to both lists -- why do we have the IMAPext list at all, if we're going to do that? Other comments: * Section 4.1 refers to an "optional" sub-command, and (a) says that the VIEW SET command selects messages that "match the results of the sub-command". It doesn't make it clear what happens if there's no sub-command (all messages are selected, I presume). It also doesn't say much about the sub-command; if "SEARCH" is the only command in the base spec that applies, it should probably say so, to prevent people from wondering what commands apply. It might also say (which is also said elsewhere) that it's intended that future SORT and THREAD commands may go here. * In 4.1 (b), "c.f." is properly abbreviated "cf.", and, anyway, is the wrong Latin abbreviation here. "cf." means "compare" (from the Latin "confer"), and I don't think you want anyone to compare what you say here to what's said in 4.2. If you mean "see section 4.2", just say it. (Sorry... pet peeve about misuse of Latin abbreviations.) * In the example in 4.1 (g), correct spelling of "SEARCH". * In 4.2 you should make it clear what, if anything, it means to use a VIEW command without a VIEW SET being in effect. It seems to me that it's nonsensical (so should "VIEW FETCH" respond "NO" or "BAD" in that case?). * In 4.2, you say command response. However, server implementations MUST implicitly include the VIEW fetch item as part of any FETCH response caused by a VIEW command, regardless of whether a VIEW was specified as a message data item to the FETCH. ...but you've already said that a VIEW fetch item must be included if a VIEW SET is in effect. If I'm right in my previous note, then you probably shouldn't *also* say this. * In 5.1.1: A VIEW untagged response MUST NOT be sent when no command is in progress; nor while responding to a FETCH, SEARCH or STORE command. Understandable. But that means that a client that receives an EXISTS in response to a FETCH must then go issue a NOOP to get the corresponding VIEW response. Can we think of a better way? Also, it might not hurt to point out that IDLE can count as a command in progress. But, then, maybe that's too obvious to have to mention. * In 5.1.2: When the old view position number in the VIEW untagged response is non-zero, the effect of VIEW is a message inserted into the view at the position given by . The view position numbers of all subsequent messages inthge current view are incremented. When the new view position number in the VIEW untagged response is non-zero, the effect of VIEW is a message removed from the view at the position given by . The view position numbers of all subsequent messages inthe current view are decremented. In both of these, I think you mean "zero" where you say "non-zero". Also, fix "inthge" and "inthe". Also also, since you explicitly talk about incrementing and decrementing view position numbers, perhaps you should include a paragraph about what happens if both the old and new positions are non-zero... which also require renumbering other messages. No, *I* don't think it needs to be said, but, then, I'm always surprised at the interpretations that sometimes happen when one fails to say something. :-) * In the grammar: position ::= number ["." number] ;; position number of messages in the view ;; may be hierarchical if sub-command defines ;; hierarchic ordering of messages This makes some of the statements about "incrementing" and "decrementing" view positions harder to understand. Maybe all we should say about what happens after a VIEW response is that "view positions of subsequent [or intervening] messages must be adjusted appropriately" or some such. * Finally, just to clarify things... we'd had an extended discussion about whether it was reasonable to remove a message from a view, once it was in the view. Problems of side-effects and such -- for instance, what happens in the following case (abbreviating a little): c: t0 VIEW SET SEARCH UNSEEN s: * 25 VIEW 1234 0 4 c: t1 VIEW FETCH 4 BODY[1] s: * 25 FETCH (FLAGS (\Seen) VIEW 4 BODY[1] ... s: t1 OK done c: t2 NOOP s: * 25 VIEW 1234 4 0 [\Seen flag caused view to change] s: t2 OK done Now, as a side-effect of the FETCH, the client can no longer use VIEW FETCH on this message. Other cases are easy to imagine. It makes VIEW FETCH of questionable use. Clearly, the decision made in writing this draft was to have messages disappear from the view (during earlier discussions, some thought they should not, though it came out that that makes reconnecting after connection failures difficult). I just wanted to point out, for the record, that there were two sides to that discussion, and to point out, for the record, which one was adopted. (And, for the record, I agree with the choice.) But I would like to see some of these potential problems mentioned in the spec. I would also like to see some encouragement to use UIDs instead of view positions. In fact, I'd go as far as to say that I don't think we should *have* a VIEW FETCH, VIEW STORE, or VIEW COPY command, and that we should clearly state that UIDs are the things to use when you're using views. Barry Leiba, Internet Messaging Technology (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba From owner-ietf-imapext Wed Jul 7 14:10:15 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA26887 for ietf-imapext-bks; Wed, 7 Jul 1999 14:10:15 -0700 (PDT) Received: from service.alpha.net (service.alpha.net [156.46.10.26]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA26883 for ; Wed, 7 Jul 1999 14:10:13 -0700 (PDT) Received: by service.alpha.net (8.9.0/8.9.0) id QAA18152; Wed, 7 Jul 1999 16:04:03 -0500 (CDT) Received: from server1.smtp.alpha.net (server1.smtp.alpha.net [156.46.10.27]) by service.alpha.net (8.9.0/8.9.0) with ESMTP id QAA29962 for ; Wed, 30 Jun 1999 16:08:23 -0500 (CDT) Received: from lists5.u.washington.edu (lists5.u.washington.edu [140.142.56.6]) by server1.smtp.alpha.net (8.9.1/8.9.1) with ESMTP id SAA15822 for ; Tue, 29 Jun 1999 18:43:24 -0500 (CDT) Received: from host (server@lists.u.washington.edu [140.142.56.13]) by lists5.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.01) with SMTP id QAA12537; Tue, 29 Jun 1999 16:40:26 -0700 Received: from mxu4.u.washington.edu (mxu4.u.washington.edu [140.142.33.8]) by lists.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.01) with ESMTP id QAA47786 for ; Tue, 29 Jun 1999 16:39:19 -0700 Received: from mailhost1.u.washington.edu (mailhost1.u.washington.edu [140.142.32.2]) by mxu4.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.06) with ESMTP id QAA24890 for ; Tue, 29 Jun 1999 16:39:19 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (bwi@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost1.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.01) with ESMTP id QAA07056; Tue, 29 Jun 1999 16:39:15 -0700 Message-Id: Date: Tue, 29 Jun 1999 16:25:56 -0700 (PDT) List-Help: List-Unsubscribe: List-Subscribe: List-Owner: (Human contact for the list) List-Post: From: Mark Crispin To: Barry Leiba Cc: Cyrus Daboo , ietf-imapext@imc.org, IMAP@u.washington.edu Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt In-Reply-To: <37791CD0.99397D08@watson.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Sender: Mark Crispin X-Listprocessor-Version: 8.1 -- ListProcessor(tm) by CREN Status: O X-UID: 14 Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: First, an apology. My contribution to this document so far has been mostly architectural, so if I say something that doesn't fully mesh with what the document says, keep this in mind. > * Section 4.1 refers to an "optional" sub-command, and (a) says that > the VIEW SET command selects messages that "match the results of the > sub-command". It doesn't make it clear what happens if there's no > sub-command (all messages are selected, I presume). I thought that VIEW SET without a command was to cancel the view. If this isn't specified, it should be. > It also doesn't > say much about the sub-command; if "SEARCH" is the only command in > the base spec that applies, it should probably say so, to prevent > people from wondering what commands apply. It might also say (which > is also said elsewhere) that it's intended that future SORT and > THREAD commands may go here. Let's talk about the wordsmithing for this at Oslo. VIEW SET's command argument is a command that defines a set (and, potentially, ordering) of messages. I agree that this needs to be well-specified, but I don't want to tag/limit it to SEARCH/SORT/THREAD even if that's the actual situation today. > * In 4.2 you should make it clear what, if anything, it means to use a > VIEW command without a VIEW SET being in effect. It seems to me that > it's nonsensical (so should "VIEW FETCH" respond "NO" or "BAD" in that > case?). I think that it's a BAD. > I would also like to see some encouragement to use UIDs instead of > view positions. In fact, I'd go as far as to say that I don't think we > should *have* a VIEW FETCH, VIEW STORE, or VIEW COPY command, and that we > should clearly state that UIDs are the things to use when you're using > views. You need some way to express hierarchy in a VIEW (for threading), which is why neither sequence numbers nor UIDs are good enough. If you use either a sequence number or UID (I don't think that one should be preferred over the other, beyond what technical considerations indicate), then you have to maintain the map or some portion of it. The whole point for VIEW FETCH and friends is so you don't need to have the map at all. From owner-ietf-imapext Wed Jul 7 14:10:26 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA26904 for ietf-imapext-bks; Wed, 7 Jul 1999 14:10:26 -0700 (PDT) Received: from service.alpha.net (service.alpha.net [156.46.10.26]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA26894 for ; Wed, 7 Jul 1999 14:10:23 -0700 (PDT) Received: by service.alpha.net (8.9.0/8.9.0) id QAA18171; Wed, 7 Jul 1999 16:04:17 -0500 (CDT) Received: from server1.smtp.alpha.net (server1.smtp.alpha.net [156.46.10.27]) by service.alpha.net (8.9.0/8.9.0) with ESMTP id QAA00005 for ; Wed, 30 Jun 1999 16:08:49 -0500 (CDT) Received: from lists5.u.washington.edu (lists5.u.washington.edu [140.142.56.6]) by server1.smtp.alpha.net (8.9.1/8.9.1) with ESMTP id UAA02381 for ; Mon, 28 Jun 1999 20:41:27 -0500 (CDT) Received: from host (server@lists.u.washington.edu [140.142.56.13]) by lists5.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.01) with SMTP id SAA07137; Mon, 28 Jun 1999 18:38:43 -0700 Received: from mxu4.u.washington.edu (mxu4.u.washington.edu [140.142.33.8]) by lists.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.01) with ESMTP id SAA45144 for ; Mon, 28 Jun 1999 18:37:47 -0700 Received: from alms1.fw.att.com (alms1.att.com [192.128.167.146]) by mxu4.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.06) with ESMTP id SAA28067 for ; Mon, 28 Jun 1999 18:37:46 -0700 Received: from dns.maillennium.att.com ([135.25.114.99]) by alms1.fw.att.com (AT&T IPNS/MS-2.2) with ESMTP id VAA07782 for ; Mon, 28 Jun 1999 21:37:42 -0400 (EDT) Received: from maillennium.att.com ([135.197.86.177](may be forged)) by maillennium.att.com (labmail) with SMTP id <19990629013550un129110j2e>; Tue, 29 Jun 1999 01:35:51 +0000 Message-Id: <37781577.37D9BAF1@maillennium.att.com> Date: Tue, 29 Jun 1999 00:38:15 +0000 List-Help: List-Unsubscribe: List-Subscribe: List-Owner: (Human contact for the list) List-Post: From: steve spear To: ietf-imapext@imc.org Cc: IMAP@u.washington.edu Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt References: <155182.3139590486@creamofwheat-5.slip.andrew.cmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Sender: root@alms1.fw.att.com X-Accept-Language: en X-Listprocessor-Version: 8.1 -- ListProcessor(tm) by CREN Status: O X-UID: 19 Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Can someone explain how traffic is reduced by SORT over clients that are caching the headers and simply request messages headers they haven't seen before? As Tony Hansen pointed out - AT&T is trying to handle many millions of users. The thought of using more resources on the server instead of the clients that are largely idle is a concern of ours. We keep hearing about thin-client's, but the memory available in the thin clients still boggles the mind of those who had memory measured in Kilobytes ( not Megabytes ) 25+ years ago. If it makes sense we'll cheer for it, but we'd like to understand where the advantage is. Steve Spear AT&T Technology Consultant Cyrus Daboo wrote: > --On Mon, Jun 28, 1999 5:52 PM -0400 Tony Hansen wrote: > > > Our major problem with this proposal is not an issue with the extension > > itself. Instead, we have an issue with its impact on server performance > > when dealing with LARGE user populations (hundreds of thousands or > > millions). Each proposal such as this does increase the server load. > > Actually the hope for this proposal (wrt to sorting) is to REDUCE the > overall server load by removing the need for a client to download the > envelopes of all messages in order to sort them for the end-user. It should > also reduce client load and indeed allow thin-clients to present sorted or > sub-set views without having to do much work. > > -- > Cyrus From owner-ietf-imapext Wed Jul 7 14:11:16 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA27000 for ietf-imapext-bks; Wed, 7 Jul 1999 14:11:16 -0700 (PDT) Received: from service.alpha.net (service.alpha.net [156.46.10.26]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA26996 for ; Wed, 7 Jul 1999 14:11:14 -0700 (PDT) Received: by service.alpha.net (8.9.0/8.9.0) id QAA18183; Wed, 7 Jul 1999 16:04:24 -0500 (CDT) Received: from server1.smtp.alpha.net (server1.smtp.alpha.net [156.46.10.27]) by service.alpha.net (8.9.0/8.9.0) with ESMTP id QAA00024 for ; Wed, 30 Jun 1999 16:08:59 -0500 (CDT) Received: from lists4.u.washington.edu (lists4.u.washington.edu [140.142.56.2]) by server1.smtp.alpha.net (8.9.1/8.9.1) with ESMTP id NAA27408 for ; Mon, 28 Jun 1999 13:40:41 -0500 (CDT) Received: from host (server@lists.u.washington.edu [140.142.56.13]) by lists4.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.01) with SMTP id LAA18429; Mon, 28 Jun 1999 11:37:38 -0700 Received: from mxu4.u.washington.edu (mxu4.u.washington.edu [140.142.33.8]) by lists.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.01) with ESMTP id LAA16110 for ; Mon, 28 Jun 1999 11:36:36 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (klaus@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mxu4.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.06) with ESMTP id LAA05091 for ; Mon, 28 Jun 1999 11:36:36 -0700 Message-Id: Date: Mon, 28 Jun 1999 11:14:00 -0700 (PDT) List-Help: List-Unsubscribe: List-Subscribe: List-Owner: (Human contact for the list) List-Post: From: Mark Crispin To: Mike Macgirvin Cc: Cyrus Daboo , ietf-imapext@imc.org, IMAP@u.washington.edu Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt In-Reply-To: <3777B74A.CB6B0ABE@Netscape.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Sender: Mark Crispin X-Listprocessor-Version: 8.1 -- ListProcessor(tm) by CREN Status: O X-UID: 23 Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: My only comment about multiple simultaneous views is that this makes VIEW much more complicated to implement; and as such presents a barrier to prospective implementors. It may also contribute to the ongoing myth that IMAP is an expensive service to have on a machine. Nevertheless, this is just an observation and I don't oppose your proposal. Please bring it up at Oslo. From owner-ietf-imapext Wed Jul 7 14:11:09 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA26991 for ietf-imapext-bks; Wed, 7 Jul 1999 14:11:09 -0700 (PDT) Received: from service.alpha.net (service.alpha.net [156.46.10.26]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA26986 for ; Wed, 7 Jul 1999 14:11:06 -0700 (PDT) Received: by service.alpha.net (8.9.0/8.9.0) id QAA18187; Wed, 7 Jul 1999 16:04:28 -0500 (CDT) Received: from server1.smtp.alpha.net (server1.smtp.alpha.net [156.46.10.27]) by service.alpha.net (8.9.0/8.9.0) with ESMTP id QAA00028 for ; Wed, 30 Jun 1999 16:09:02 -0500 (CDT) Received: from lists3.u.washington.edu (lists3.u.washington.edu [140.142.56.3]) by server1.smtp.alpha.net (8.9.1/8.9.1) with ESMTP id NAA27520 for ; Mon, 28 Jun 1999 13:46:48 -0500 (CDT) Received: from host (server@lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.01) with SMTP id LAA24613; Mon, 28 Jun 1999 11:43:19 -0700 Received: from mxu4.u.washington.edu (mxu4.u.washington.edu [140.142.33.8]) by lists.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.01) with ESMTP id LAA25596 for ; Mon, 28 Jun 1999 11:37:36 -0700 Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mxu4.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.06) with ESMTP id LAA05272 for ; Mon, 28 Jun 1999 11:37:36 -0700 Received: from ephesus.cyrusoft.com (ephesus.cyrusoft.com [206.31.218.204]) by darius.cyrusoft.com (8.8.5/8.8.5) with ESMTP id OAA10619; Mon, 28 Jun 1999 14:37:25 -0400 (EDT) Message-Id: <2867750433.930580686@ephesus.cyrusoft.com> Date: Mon, 28 Jun 1999 14:38:06 -0400 List-Help: List-Unsubscribe: List-Subscribe: List-Owner: (Human contact for the list) List-Post: From: Cyrus Daboo To: Mike Macgirvin Cc: ietf-imapext@imc.org, IMAP@u.washington.edu Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt In-Reply-To: <3777B74A.CB6B0ABE@Netscape.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Listprocessor-Version: 8.1 -- ListProcessor(tm) by CREN Status: O X-UID: 24 Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Hi Mike, --On Monday, June 28, 1999, 10:56 AM -0700 Mike Macgirvin wrote: > This appears to have the side effect of limiting you to one view. Multiple > active views would require extensive client polling, and the notification > events would only be active on one of them. > > I'd like to propose a modest enhancement, where the client can provide a > (client generated) view-id, and subsequent changes to that view are tagged > with the view-id. This permits multiple active views. Granted, there is > server overhead involved, but this is the price of moving it off the > client in the first place. Having the client generate an ID is better > than having to match an untagged response with a search string. Multiple views would be nice. I thought of doing something similar too. However, I concluded that the added complexity of handling multiple views is too much for now. It requires a lot more than just modifying EXISTS. One major problem is that messages can be in more than one view. One way to handle this would be to redefine the 'position' syntax to be a list of 'view number'/'view position' pairs. For example, an EXPUNGE for a message in view #0001 and view #0003 would end up as: a EXPUNGE * 1 EXPUNGE 1234 ((0001 1)(0003 4)) a OK My personal feeling is to keep VIEW simple for now and see how implementation experience goes. There's no reason why later we can't define a new command to deal with multiple named views and redefine the existing VIEW syntax appropriately. e.g. 'VIEW SET' would be augmented by a 'VIEW NAMEDSET' command that could redfine the 'position' formal syntax item to be an S-Expression list (or whatever), and require a view name in addition to the sub-command in a VIEW command. --Cyrus From owner-ietf-imapext Wed Jul 7 14:10:28 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA26923 for ietf-imapext-bks; Wed, 7 Jul 1999 14:10:28 -0700 (PDT) Received: from service.alpha.net (service.alpha.net [156.46.10.26]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA26918 for ; Wed, 7 Jul 1999 14:10:27 -0700 (PDT) Received: by service.alpha.net (8.9.0/8.9.0) id QAA18174; Wed, 7 Jul 1999 16:04:18 -0500 (CDT) Received: from server1.smtp.alpha.net (server1.smtp.alpha.net [156.46.10.27]) by service.alpha.net (8.9.0/8.9.0) with ESMTP id QAA00008 for ; Wed, 30 Jun 1999 16:08:51 -0500 (CDT) Received: from lists3.u.washington.edu (lists3.u.washington.edu [140.142.56.3]) by server1.smtp.alpha.net (8.9.1/8.9.1) with ESMTP id TAA02094 for ; Mon, 28 Jun 1999 19:30:45 -0500 (CDT) Received: from host (server@lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.01) with SMTP id RAA08439; Mon, 28 Jun 1999 17:28:27 -0700 Received: from mxu1.u.washington.edu (mxu1.u.washington.edu [140.142.32.8]) by lists.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.01) with ESMTP id RAA18032 for ; Mon, 28 Jun 1999 17:27:20 -0700 Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mxu1.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.06) with ESMTP id RAA28829 for ; Mon, 28 Jun 1999 17:27:19 -0700 Received: from creamofwheat-5.slip.andrew.cmu.edu (CREAMOFWHEAT-5.SLIP.ANDREW.CMU.EDU [128.2.120.5]) by darius.cyrusoft.com (8.8.5/8.8.5) with ESMTP id UAA11810; Mon, 28 Jun 1999 20:27:08 -0400 (EDT) Message-Id: <155182.3139590486@creamofwheat-5.slip.andrew.cmu.edu> Date: Mon, 28 Jun 1999 20:28:06 -0400 List-Help: List-Unsubscribe: List-Subscribe: List-Owner: (Human contact for the list) List-Post: From: Cyrus Daboo To: tony@att.com Cc: ietf-imapext@imc.org, IMAP@u.washington.edu Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt In-Reply-To: <3777EEA4.A650B2F7@att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Listprocessor-Version: 8.1 -- ListProcessor(tm) by CREN Status: O X-UID: 20 Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: --On Mon, Jun 28, 1999 5:52 PM -0400 Tony Hansen wrote: > Our major problem with this proposal is not an issue with the extension > itself. Instead, we have an issue with its impact on server performance > when dealing with LARGE user populations (hundreds of thousands or > millions). Each proposal such as this does increase the server load. Actually the hope for this proposal (wrt to sorting) is to REDUCE the overall server load by removing the need for a client to download the envelopes of all messages in order to sort them for the end-user. It should also reduce client load and indeed allow thin-clients to present sorted or sub-set views without having to do much work. -- Cyrus From owner-ietf-imapext Wed Jul 7 14:10:40 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA26959 for ietf-imapext-bks; Wed, 7 Jul 1999 14:10:40 -0700 (PDT) Received: from service.alpha.net (service.alpha.net [156.46.10.26]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA26955 for ; Wed, 7 Jul 1999 14:10:39 -0700 (PDT) Received: by service.alpha.net (8.9.0/8.9.0) id QAA18194; Wed, 7 Jul 1999 16:04:31 -0500 (CDT) Received: from server1.smtp.alpha.net (server1.smtp.alpha.net [156.46.10.27]) by service.alpha.net (8.9.0/8.9.0) with ESMTP id QAA00032 for ; Wed, 30 Jun 1999 16:09:03 -0500 (CDT) Received: from lists2.u.washington.edu (lists2.u.washington.edu [140.142.56.1]) by server1.smtp.alpha.net (8.9.1/8.9.1) with ESMTP id NAA27058 for ; Mon, 28 Jun 1999 13:20:05 -0500 (CDT) Received: from host (server@lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.01) with SMTP id LAA24385; Mon, 28 Jun 1999 11:04:25 -0700 Received: from mxu2.u.washington.edu (mxu2.u.washington.edu [140.142.32.9]) by lists.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.01) with ESMTP id LAA25506 for ; Mon, 28 Jun 1999 11:03:03 -0700 Received: from metal.mcom.com (h-208-12-60-75.netscape.com [208.12.60.75]) by mxu2.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.06) with ESMTP id LAA31549 for ; Mon, 28 Jun 1999 11:03:03 -0700 Received: from Netscape.COM ([208.12.60.75]) by metal.mcom.com (Netscape Messaging Server 3.6) with ESMTP id AAA1DAA; Mon, 28 Jun 1999 11:02:57 -0700 Message-Id: <3777B8D1.F8075111@Netscape.COM> Date: Mon, 28 Jun 1999 11:02:57 -0700 List-Help: List-Unsubscribe: List-Subscribe: List-Owner: (Human contact for the list) List-Post: From: Mike Macgirvin To: Cyrus Daboo , ietf-imapext@imc.org, IMAP@u.washington.edu Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt References: <2862869525.930575805@ephesus.cyrusoft.com> <3777B74A.CB6B0ABE@Netscape.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Sender: "Mike Macgirvin" X-Accept-Language: en X-Listprocessor-Version: 8.1 -- ListProcessor(tm) by CREN Status: O X-UID: 26 Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Before somebody corrects me - yes I do know that EXISTS are untagged and require *. > It probably isn't necessary that the results be chained in the EXISTS > response, i.e. > S: * 172 EXISTS 0001 23 > S: * 172 EXISTS 0002 6 ............^ > would be just fine. From owner-ietf-imapext Wed Jul 7 14:10:39 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA26950 for ietf-imapext-bks; Wed, 7 Jul 1999 14:10:39 -0700 (PDT) Received: from service.alpha.net (service.alpha.net [156.46.10.26]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA26946 for ; Wed, 7 Jul 1999 14:10:38 -0700 (PDT) Received: by service.alpha.net (8.9.0/8.9.0) id QAA18190; Wed, 7 Jul 1999 16:04:30 -0500 (CDT) Received: from server1.smtp.alpha.net (server1.smtp.alpha.net [156.46.10.27]) by service.alpha.net (8.9.0/8.9.0) with ESMTP id QAA00020 for ; Wed, 30 Jun 1999 16:08:57 -0500 (CDT) Received: from lists2.u.washington.edu (lists2.u.washington.edu [140.142.56.1]) by server1.smtp.alpha.net (8.9.1/8.9.1) with ESMTP id OAA28912 for ; Mon, 28 Jun 1999 14:57:26 -0500 (CDT) Received: from host (server@lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.01) with SMTP id MAA28109; Mon, 28 Jun 1999 12:46:48 -0700 Received: from mxu3.u.washington.edu (mxu3.u.washington.edu [140.142.33.7]) by lists.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.01) with ESMTP id MAA18750 for ; Mon, 28 Jun 1999 12:45:47 -0700 Received: from metal.mcom.com (h-208-12-60-75.netscape.com [208.12.60.75]) by mxu3.u.washington.edu (8.9.3+UW99.02/8.9.3+UW99.06) with ESMTP id MAA19021 for ; Mon, 28 Jun 1999 12:45:46 -0700 Received: from Netscape.COM ([208.12.60.75]) by metal.mcom.com (Netscape Messaging Server 3.6) with ESMTP id AAA4E97; Mon, 28 Jun 1999 12:45:32 -0700 Message-Id: <3777D0DB.2105A918@Netscape.COM> Date: Mon, 28 Jun 1999 12:45:31 -0700 List-Help: List-Unsubscribe: List-Subscribe: List-Owner: (Human contact for the list) List-Post: From: Mike Macgirvin To: Mark Crispin Cc: Cyrus Daboo , ietf-imapext@imc.org, IMAP@u.washington.edu Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Sender: "Mike Macgirvin" X-Accept-Language: en X-Listprocessor-Version: 8.1 -- ListProcessor(tm) by CREN Status: O X-UID: 25 Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Mark Crispin wrote: > > My only comment about multiple simultaneous views is that this makes VIEW much > more complicated to implement; and as such presents a barrier to prospective > implementors. It may also contribute to the ongoing myth that IMAP is an > expensive service to have on a machine. > > Nevertheless, this is just an observation and I don't oppose your proposal. > Please bring it up at Oslo. I agree totally that it makes server implementation of this feature non-trivial. Without it I think the client ends up having to work just as hard by issuing multiple SEARCH and/or VIEW commands everytime anything in the mailbox changes - or doing all the work client-side. We can do that today without requiring any extensions, but it's hardly efficient. So this draft presents a way to avoid a lot of client overhead as long as you only define or "activate" only one view. Having worked a lot with views in the past, one is not very typical. The bell curve fits around 5 and 20 at least on INBOX and it's reasonable for a human to want to have all their views active in the sense that message counts are propogated in as near to real time as possible. I'll see if somebody else from here will be at Oslo and ask that they present these arguments - unfortunately, I have other obligations. From owner-ietf-imapext Wed Jul 7 15:07:06 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA28184 for ietf-imapext-bks; Wed, 7 Jul 1999 15:07:06 -0700 (PDT) Received: from baikonur.demo.ru ([194.87.43.111]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA28179 for ; Wed, 7 Jul 1999 15:07:01 -0700 (PDT) Received: from taxxi.com ([195.218.128.213]) by baikonur.demo.ru (Netscape Messaging Server 3.62) with ESMTP id 227; Thu, 8 Jul 1999 02:06:38 +0400 Message-ID: <3783CF47.22487D64@taxxi.com> Date: Thu, 08 Jul 1999 02:05:59 +0400 From: Alexey Melnikov X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: ru,en-US MIME-Version: 1.0 To: Mark Crispin , ietf-imapext@imc.org CC: Yuri Demchenko Subject: Re: Agenda due today References: <377BF502.DD02CE7@taxxi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Alexey Melnikov wrote: > Mark Crispin wrote: > > > On Fri, 2 Jul 1999, Alexey Melnikov wrote: > > > Probably we should discuss LANGUAGE extension. > > > > I propose that we form a small e-mail working sub-group of people > > interested this issue, rather than spend the limited time in Oslo. The > > Oslo meeting should just mention the existance of the sub-group and the > > mailing list for it. > > > > This is too complex and too important of an issue to be tossed into the > > agenda and made to compete with the other issues already in the agenda. > > > > I will oppose any "quick and dirty" proposal for LANGUAGE. We have to do > > this right, and doing it right requires careful consideration from all of > > us. > > > > We need to consider localization, internationalization, and > > mulilingualization; and from these draw up a list of desired > > functionalties. Among other things, we need to establish a transition > > mechanism from ASCII and charsets to pure UTF-8. > > > > I have no problem with a separate face-to-face meeting of people > > interested in LANGUAGE at Oslo. > > I don't mind. > > Let me know about date and time for LANGUAGE meeting. (BTW, I've recently > submitted SMTP LANG draft, we may discuss it as well). I will be in Oslo all > week. Mike will be in Oslo as well, so he will probably agree with me that we have to discuss LANGUAGE and all related problems. Alexey P.S. I will be offline from Friday up to Sunday, could we arrange this meeting now? From owner-ietf-imapext Thu Jul 15 05:25:21 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA23755 for ietf-imapext-bks; Thu, 15 Jul 1999 05:25:21 -0700 (PDT) Received: from foo.ietf.uninett.no (root@foo.ietf.uninett.no [128.39.10.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA23751 for ; Thu, 15 Jul 1999 05:25:20 -0700 (PDT) Received: from ariel (wldhcp10244.ietf.uninett.no [128.39.10.244]) by foo.ietf.uninett.no (8.9.3/8.9.3) with ESMTP id OAA15003; Thu, 15 Jul 1999 14:26:20 +0200 Received: from ecal.com (localhost [127.0.0.1]) by ariel (8.8.7/8.8.7) with ESMTP id OAA07125; Thu, 15 Jul 1999 14:27:27 +0200 Message-ID: <378DD3AF.1FE6FE56@ecal.com> Date: Thu, 15 Jul 1999 14:27:27 +0200 From: John Stracke X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 To: ietf-imapext@imc.org Subject: Annotations: alternate data model Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: (I'm sitting in the BOF right now, but this idea is both relatively unimportant and potentially inflammatory, so I'm not going to waste face-to-face time. :-) The strawman annotation model that was presented suggested a basic name/value data model, but also mentioned the possibility of wanting to permit values to be large binary blobs. Rather than develop a new syntax for doing this, you might want to adopt something like the WebDAV property model, in which a property is an XML element. The name of the element becomes the name of the property, and you get to use all the features of XML (structured data, internationalization, namespaces, etc.). (Of course, this may not make as much sense in IMAP as in WebDAV, where most of the protocol information is carried in XML in the first place.) I'm not on this list, so, if you want to flame me, you'll have to CC: me. I probably won't flame back, though, 'cause I'm not certain that I'm right; I just wanted to offer some cross-pollination. -- /=============================================================\ |John Stracke | My opinions are my own | S/MIME & HTML OK | |francis@ecal.com|============================================| |Chief Scientist | NT's lack of reliability is only surpassed | |eCal Corp. | by its lack of scalability. -- John Kirch | \=============================================================/ From owner-ietf-imapext Mon Jul 19 14:30:17 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA11984 for ietf-imapext-bks; Mon, 19 Jul 1999 14:30:17 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA11980 for ; Mon, 19 Jul 1999 14:30:16 -0700 (PDT) Received: from sardis.cyrusoft.com (sardis.cyrusoft.com [206.31.218.203]) by darius.cyrusoft.com (8.8.5/8.8.5) with ESMTP id RAA23311; Mon, 19 Jul 1999 17:31:43 -0400 (EDT) Date: Mon, 19 Jul 1999 17:33:45 -0400 From: Cyrus Daboo To: John Stracke , ietf-imapext@imc.org Subject: Re: Annotations: alternate data model Message-ID: <505104.3141394425@sardis.cyrusoft.com> In-Reply-To: <378DD3AF.1FE6FE56@ecal.com> Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431 X-Mailer: Mulberry (MacOS) [2.0.0a4, s/n S1-000001] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Hi John, --On Thu, Jul 15, 1999 2:27 PM +0200 John Stracke wrote: > The strawman annotation model that was presented suggested a basic > name/value data model, but also mentioned the possibility of wanting to > permit values to be large binary blobs. Rather than develop a new > syntax for doing this, you might want to adopt something like the WebDAV > property model, in which a property is an XML element. The name of the > element becomes the name of the property, and you get to use all the > features of XML (structured data, internationalization, namespaces, > etc.). I had another look at the WebDAV RFC after your comments and there are some interesting things there that could be applied to ANNOTATE. But... > (Of course, this may not make as much sense in IMAP as in WebDAV, where > most of the protocol information is carried in XML in the first place.) This is the issue. WebDAV has everything wrapped up in an XML document. It requires XML parsers on both the server and client. I'm not sure we want to lay this burden on IMAP servers and clients. Though not being a WebDAV/XML expert I'm certainly open to suggestions as to how this might be applied to ANNOTATE. -- Cyrus From owner-ietf-imapext Mon Jul 19 14:51:37 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA12324 for ietf-imapext-bks; Mon, 19 Jul 1999 14:51:37 -0700 (PDT) Received: from ecal.com (mail.appoint.net [207.242.168.162]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA12319 for ; Mon, 19 Jul 1999 14:51:30 -0700 (PDT) Received: from ariel.appoint.lan [209.218.166.130] by ecal.com with ESMTP (SMTPD32-5.04) id ADB13C810168; Mon, 19 Jul 1999 17:50:41 EDT Received: from ecal.com (localhost [127.0.0.1]) by ariel.appoint.lan (8.8.7/8.8.7) with ESMTP id RAA28423; Mon, 19 Jul 1999 17:52:44 -0400 Message-ID: <37939E2C.4199B8DD@ecal.com> Date: Mon, 19 Jul 1999 17:52:44 -0400 From: John Stracke X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 To: ietf-imapext@imc.org Subject: Re: Annotations: alternate data model References: <505104.3141394425@sardis.cyrusoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Cyrus Daboo wrote: > > (Of course, this may not make as much sense in IMAP as in WebDAV, where > > most of the protocol information is carried in XML in the first place.) > > This is the issue. WebDAV has everything wrapped up in an XML document. It > requires XML parsers on both the server and client. That is a point. On the other hand, XML parsers can be pretty small--I've written one that takes up only about 50K--and they're pretty common these days; many MUAs will already have one in the program somewhere. > I'm not sure we want to > lay this burden on IMAP servers and clients. To me, what it comes down to is: can you come up with anything else that does what you need (structured data, internationalization, clean namespaces for properties) and costs less? Of course, there are bits of XML that may not be worthwhile--for example, the requirement that any XML parser be able to grok the internal DTD gets a bit annoying. But you could probably specify that XML documents used by ANNOTATE must not include an internal DTD (that'd probably cut your minimal parser size in half). Up to you. I don't know enough about how IMAP is used to be able to figure the tradeoffs; I just know XML. -- /=============================================================\ |John Stracke | My opinions are my own | S/MIME & HTML OK | |francis@ecal.com|============================================| |Chief Scientist | NT's lack of reliability is only surpassed | |eCal Corp. | by its lack of scalability. -- John Kirch | \=============================================================/ From owner-ietf-imapext Mon Jul 19 15:42:12 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA14318 for ietf-imapext-bks; Mon, 19 Jul 1999 15:42:12 -0700 (PDT) Received: from demo.esys.ca (demo.esys.ca [207.167.22.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA14313 for ; Mon, 19 Jul 1999 15:42:11 -0700 (PDT) Received: from galileo.esys.ca (galileo.esys.ca [198.161.92.18]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id QAA07679 for ; Mon, 19 Jul 1999 16:43:44 -0600 From: Steve Hole Date: Mon, 19 Jul 1999 16:47:52 -0600 To: IMAP Extensions Working Group Subject: Oslo WG meeting notes Message-ID: X-Mailer: Execmail for Linux 5.1 b1 Build (1) -- Evaluation Copy MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Notes for the IMAP Extensions Working Group at the 45th IETF meeting in Oslo Norway, July 15, 1999. WG Chair - Pete Resnick Mailing List - Notes - Steve Hole Viewing the notes looks best in outline-mode of Emacs (if you care). Action items identified during the working group are tagged with a leading "A", followed by the action item owner (victim) and a description of the deliverable. A separate summary of action items will be posted to the list as a separate document. * Agenda bashing: ** Charter bashing ** View/sort/thread ** ACL ** Annotations ** ID ** Language ** VPIM ** Other Issues *** list rathole - we seek to avoid all discussion on extensions to the LIST command because it is a gigantic rathole. This will be discussed in future events. * WG Charter Bashing ** reviewed charter with exception of milestones ** charter accepted for use as a working group ** We will resolve milestones at end of meeting (if time) but otherwise on list. A - Pete Resnick - to post strawman wg milestones based to list for inclusion in charter. A - Pete Resnick - to post charter to IESG for approval as working group. * View extension - Cyrus Daboo ** Review of existing draft and proposal - goal is to provide a subsetting facility for IMAP - new commands "VIEW SET" and "VIEW" - result is to set a new context that results in a set of "view specifiers" that allows the client to access messages based on the specifiers (rather than sequence number and/or uid. - new data item for FETCH command named "VIEW" - new VIEW untagged response ** Is it worthwhile to proceed? - good concensus to proceed ** Overloaded SELECT - Mark C proposes an additional extension that is VIEW extended version of SELECT/EXAMINE - concensus to add this to the proposal - John M notes that this prevents getting EXISTS prior to issuing a VIEW ** Support for multiple VIEWS - very expensive for the server implementors - will clients actually use it? - there are examples of how a client might use it. - some vendors clearly expressed a desire to have it. - there are other workarounds (multiple connections, refining criteria on reissued VIEW) - punt issue to list A - Cyrus Daboo - raise issue of multiple views on list with a summary of discussion at Oslo. ** Dynamic views - yes or no? - concensus that we want dynamic insertion into the view. - do we want dynamic removal from the view? - difficult because proper UI behaviours are debatable - discussion on whether behaviour could be asked for - discussion on relative difficulty of supporting this in server - assertion that client MUST be able to specify the static vs. dynamic notification behaviour - breakout of technical issues on what information a client has to have to be able to deal with removal A - Cyrus Daboo - raise issue of dynamic views on list with a summary of dicussion at Oslo. ** Issues with VIEW SEARCH - assertion that VIEW SEARCH is inconsisten UID SEARCH - there is an easy fix to the spec to deal with this that Cyrus will make A - Cyrus Daboo - change spec to resolve VIEW SEARCH / UID SEARCH inconsistency. ** VIEW with SORT - original proposal by Mark Crispin to publish as historic/informational/experimental - extensions to original SORT with additional sort keys and better defined subject sort methodology. A - Mark Crispin - publish new version of original SORT extensionas an historical specification. A - Mark Crispin, Cyrus Daboo - publish a new SORT2 extension that uses the VIEW framework. ** VIEW with THREADING - create a THREAD extension based on VIEW - Mark C reviews his existing THREAD implementation A - Mark Crispin - raise issue of additional threading algorithms for threading extensions. Includes definition of mechanism for requesting desired threading mechanism. A - Mark Crispon - publish a new extended THREAD draft for discussion on the list. * ACLs - John Myers ** Issues with existing proposed standard described in RFC2086 - impose more restrictions on server semantics - identifier namespace for groups - difficulty in expressing underlying access semantics via ACL (ie. UNIX access modes via ACLs) A - John Myers - publish a new version of the ACL extension that includes feedback obtained from previous IMAPext sessions. ** Discussion on "expressability" of ACLs - issues with how clients can handle expression of tied rights etc. - a lot of discussion on how it might be possible to support requirements. - assertion that "mapping" of rights was a rathole in other protocol work. A - Mark Crispin - raise issue of expressing access semantics that reflect underlying filesystem and/or store access control semantics on list. Expressed as a set of requirements. * Annotate extension - Cyrus Daboo ** Strawman model - allow clients and servers to add metadata to messages - add FETCH ANNOTATION item - add STORE +ANNOTATION - add support for search and sort on annotation ** Issues *** Is this of interest? - good concensus that this is useful *** Is this mechanism acceptible? - good concensus that it is a good strawman model for a draft that addresses mailbox annotations *** Extend to include mailbox and server annotations? - mailbox sounds interesting - server may be interesting - resolution to be taken to list *** Are ACLs on annotations too complex for now? - yes A - Cyrus Daboo, Randy Gellens - publish mailbox annotations extension draft for discussion on list. A - Cyrus Daboo - raise issue on usefulness of mailbox level annoations. Are they to be considered in scope for the annotations work in the working group. A - Cyrus Daboo - raise issue on usefulness of store level annoations. Are they to be considered in scope for the annotations work in the working group. * Client ID - Tim Showalter (in absensia) ** Issues *** Do we want to do it? - *very* useful for tracking - assertion that some people will implement it no matter what - it is open to abuse (restrictions by server for a particular client set) *** Should it be in the scope of the working group? - it will not be discussed within the working group - discussion to the IMAP - not IMAPEXT working group * LANGUAGE - Mike Garhns ** Issues *** There are implementations of existing draft - the number of implementations is not large (apparently) *** Is LANGUAGE general enough? - it addresses one part of localization - doesn't address internationalization and other localization issues ** Solution - discussion about a full framework that has more of the complete work that would subsume the functionality of LANGUAGE later on. A - Mike Gharns - publish LANGUAGE as it is now modulo minor changes received via the list. A - Mike G., Mark C and others to work on full internationalization framework for doing extension work in the future and making sure that all working group items are internalization friendly. Go to the list to determine whether or not there are milestones for this work in the wg charter. * VPIM Extensions - Glen Parsons ** Review of existing draft - draft-ema-vpim-imap-01.txt ** Where should it be discussed (which working group)? - concensus that the parts that are general IMAP functionality should be discussed in IMAP extensions. - VPIM specific stuff goes into VPIM. ** Issues - assertion that there is danger about doing specific extensions to support a particular application ie. VPIM - resolved to try to make sure that we take a stance of general applicability to IMAP. *** Binary Attachment Transfer - pull a binary object from the store (remove encodings) - good concensus that this is both generally applicable and should be addressed by this group A - Randy Gellens, Stewart McRae, Glenn Parsons - publish BINARY fetch extension for discussion on list. *** External Reference - may be applicable to other applications - security issues raised *** Transcoding Request - assertion that there are substantial interoperability issues - better dealt with by picking standardized represention of content-type *** Streaming Audio Attachments - assertion that PARTIAL support is sufficient for this - we will not deal with this *** Message length indication - assertion that this is not an IMAP issue - it is MIME issue - we will not deal with this *** Body part read indication - assertion that there are other ways to do this - we will not deal with this * Other Extensions ** Child mailbox draft *** Issues - should we continue with this? - recommendation to come up with a general mechanism for handling LIST extensions in general. A - Mike Gharns - publish updated draft of CHILD for discussion on the list. --- Steve Hole Messaging Direct Mailto:Steve.Hole@MessagingDirect.com Phone: 780-424-4922 From owner-ietf-imapext Mon Jul 19 15:49:34 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA14418 for ietf-imapext-bks; Mon, 19 Jul 1999 15:49:34 -0700 (PDT) Received: from demo.esys.ca (demo.esys.ca [207.167.22.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA14414 for ; Mon, 19 Jul 1999 15:49:33 -0700 (PDT) Received: from galileo.esys.ca (galileo.esys.ca [198.161.92.18]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id QAA07727 for ; Mon, 19 Jul 1999 16:51:15 -0600 From: Steve Hole Date: Mon, 19 Jul 1999 16:55:23 -0600 To: IMAP Extensions Working Group Subject: Summary of actions from Oslo WG meeting Message-ID: X-Mailer: Execmail for Linux 5.1 b1 Build (1) -- Evaluation Copy MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Here is a summary of the actions resulting from the Oslo meeting. --- A - Pete Resnick - to post strawman wg milestones based to list for inclusion in charter. A - Pete Resnick - to post charter to IESG for approval as working group. A - Cyrus Daboo - raise issue of multiple views on list with a summary of discussion at Oslo. A - Cyrus Daboo - raise issue of dynamic views on list with a summary of dicussion at Oslo. A - Cyrus Daboo - change spec to resolve VIEW SEARCH / UID SEARCH inconsistency. A - Mark Crispin - publish new version of original SORT extensionas an historical specification. A - Mark Crispin, Cyrus Daboo - publish a new SORT2 extension that uses the VIEW framework. A - Mark Crispin - raise issue of additional threading algorithms for threading extensions. Includes definition of mechanism for requesting desired threading mechanism. A - Mark Crispon - publish a new extended THREAD draft for discussion on the list. A - John Myers - publish a new version of the ACL extension that includes feedback obtained from previous IMAPext sessions. A - Mark Crispin - raise issue of expressing access semantics that reflect underlying filesystem and/or store access control semantics on list. Expressed as a set of requirements. A - Cyrus Daboo, Randy Gellens - publish mailbox annotations extension draft for discussion on list. A - Cyrus Daboo - raise issue on usefulness of mailbox level annoations. Are they to be considered in scope for the annotations work in the working group. A - Cyrus Daboo - raise issue on usefulness of store level annoations. Are they to be considered in scope for the annotations work in the working group. A - Mike Gharns - publish LANGUAGE as it is now modulo minor changes received via the list. A - Mike Gharns, Mark Crispin and others to work on full internationalization framework for doing extension work in the future and making sure that all working group items are internalization friendly. Go to the list to determine whether or not there are milestones for this work in the wg charter. A - Randy Gellens, Stewart McRae, Glenn Parsons - publish BINARY fetch extension for discussion on list. A - Mike Gharns - publish updated draft of CHILD for discussion on the list. --- Steve Hole Messaging Direct Mailto:Steve.Hole@MessagingDirect.com Phone: 780-424-4922 From owner-ietf-imapext Mon Jul 19 16:40:12 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA15543 for ietf-imapext-bks; Mon, 19 Jul 1999 16:40:12 -0700 (PDT) Received: from demo.esys.ca (demo.esys.ca [207.167.22.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA15539 for ; Mon, 19 Jul 1999 16:40:11 -0700 (PDT) Received: from galileo.esys.ca (galileo.esys.ca [198.161.92.18]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id RAA07917; Mon, 19 Jul 1999 17:41:53 -0600 From: Steve Hole Date: Mon, 19 Jul 1999 17:46:01 -0600 To: John Stracke Subject: Re: Annotations: alternate data model Cc: ietf-imapext@imc.org In-Reply-To: <37939E2C.4199B8DD@ecal.com> References: <37939E2C.4199B8DD@ecal.com> <505104.3141394425@sardis.cyrusoft.com> Message-ID: X-Mailer: Execmail for Linux 5.1 b1 Build (1) -- Evaluation Copy MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Mon, 19 Jul 1999 17:52:44 -0400 John Stracke wrote: > That is a point. On the other hand, XML parsers can be pretty > small--I've > written one that takes up only about 50K--and they're pretty common these > days; many MUAs will already have one in the program somewhere. A validating parser? As soon as you make it validating it gets both much bigger and much slower. This may more may not be an issue, but they are certainly not without cost. > > I'm not sure we want to > > lay this burden on IMAP servers and clients. > > To me, what it comes down to is: can you come up with anything else that does > what you need (structured data, internationalization, clean namespaces for > properties) and costs less? An alternate model is a subset of what ACAP does. It has the advantage of an existing IMAP like syntax and semantic that both IMAP clients servers are familiar with. > Of course, there are bits of XML that may not be worthwhile--for example, the > requirement that any XML parser be able to grok the internal DTD gets a bit > annoying. But you could probably specify that XML documents used by ANNOTATE > must not include an internal DTD (that'd probably cut your minimal parser size > in half). Exactly. A well-formed parser like expat is not too big, but it still seems like a lot for what we want to do. The biggest issue is that the stuff that is pushed onto the server is semantically owned by the client. The server really doesn't need to know anything about the data -- it is simply a blob. This is true for everything but "magic" metadata supplied by the server, in which case a prearranged semantic agreement is made. This was dealt with in ACAP using either standard options or ACAP dataset class specifications. Even that seems somewhat heavy to me. Cheers. --- Steve Hole Messaging Direct Mailto:Steve.Hole@MessagingDirect.com Phone: 780-424-4922 From owner-ietf-imapext Tue Jul 20 06:18:56 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA21031 for ietf-imapext-bks; Tue, 20 Jul 1999 06:18:56 -0700 (PDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA21027 for ; Tue, 20 Jul 1999 06:18:55 -0700 (PDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id JAA10080 for ; Tue, 20 Jul 1999 09:20:40 -0400 Received: from watson.ibm.com (mars.watson.ibm.com [9.2.2.58]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with ESMTP id JAA12302 for ; Tue, 20 Jul 1999 09:20:39 -0400 Message-ID: <379477A7.4789586E@watson.ibm.com> Date: Tue, 20 Jul 1999 09:20:39 -0400 From: Barry Leiba Organization: Internet Messaging Technology; TR2_Xagent=WATSON X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: IMAP Extensions Working Group Subject: Re: Oslo WG meeting notes References: Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: There are a few items here that are sufficiently brief that I'd like a bit more information. > *** Transcoding Request > - assertion that there are substantial interoperability issues > - better dealt with by picking standardized represention of content-type Can someone summarize the discussion? In particular, how does "picking [a] standardized represen[ta]tion" address the issue of, say, sending a high-res, high-colour image on a low-bandwidth connection to a device that can only display 16 colours in low-res? I'd like to get some idea of what people were saying on this issue. > *** Message length indication > - assertion that this is not an IMAP issue - it is MIME issue What *is* this issue? > *** Body part read indication > - assertion that there are other ways to do this Again, a summary? What other ways are there to do this? Thanks. Sorry I couldn't be there. :-( Barry Leiba, Internet Messaging Technology (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba From owner-ietf-imapext Tue Jul 20 09:15:55 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA05625 for ietf-imapext-bks; Tue, 20 Jul 1999 09:15:55 -0700 (PDT) Received: from ecal.com (mail.appoint.net [207.242.168.162]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA05617 for ; Tue, 20 Jul 1999 09:15:53 -0700 (PDT) Received: from ariel.appoint.lan [209.218.166.130] by ecal.com with ESMTP (SMTPD32-5.04) id A09B1B2E0138; Tue, 20 Jul 1999 12:15:23 EDT Received: from ecal.com (localhost [127.0.0.1]) by ariel.appoint.lan (8.8.7/8.8.7) with ESMTP id MAA04253; Tue, 20 Jul 1999 12:17:36 -0400 Message-ID: <3794A120.148B6473@ecal.com> Date: Tue, 20 Jul 1999 12:17:36 -0400 From: John Stracke X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 To: ietf-imapext@imc.org Subject: Re: Annotations: alternate data model References: <37939E2C.4199B8DD@ecal.com> <505104.3141394425@sardis.cyrusoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Steve Hole wrote: > > That is a point. On the other hand, XML parsers can be pretty > > small--I've > > written one that takes up only about 50K--and they're pretty common these > > days; many MUAs will already have one in the program somewhere. > > A validating parser? No. I agree that a validating parser is likely to be heavier than you need. On the other hand, it may be the case that you don't need validation for a property model, since virtually everything interesting is going to be inside the property elements, which the DTD can't cover anyway. (Bias alert: I don't think validating parsers ever make sense, since a robust app is going to have to do its own double-checking anyway.) -- /=============================================================\ |John Stracke | My opinions are my own | S/MIME & HTML OK | |francis@ecal.com|============================================| |Chief Scientist | NT's lack of reliability is only surpassed | |eCal Corp. | by its lack of scalability. -- John Kirch | \=============================================================/ From owner-ietf-imapext Thu Jul 22 14:06:09 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA08995 for ietf-imapext-bks; Thu, 22 Jul 1999 14:06:09 -0700 (PDT) Received: from demo.esys.ca (demo.esys.ca [207.167.22.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA08991 for ; Thu, 22 Jul 1999 14:06:07 -0700 (PDT) Received: from galileo.esys.ca (galileo.esys.ca [198.161.92.18]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id PAA13905; Thu, 22 Jul 1999 15:08:03 -0600 From: Steve Hole Date: Thu, 22 Jul 1999 15:08:10 -0600 To: Barry Leiba Subject: Re: Oslo WG meeting notes Cc: IMAP Extensions Working Group In-Reply-To: <379477A7.4789586E@watson.ibm.com> References: <379477A7.4789586E@watson.ibm.com> Message-ID: X-Mailer: Execmail for Linux 5.1 b1 Build (1) -- Evaluation Copy MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Woops ... sorry Barry, I tuned out there for a second. Looked at the wrong mailing list. On Tue, 20 Jul 1999 09:20:39 -0400 Barry Leiba wrote: > There are a few items here that are sufficiently brief that I'd like a > bit more information. > > > *** Transcoding Request > > - assertion that there are substantial interoperability issues > > - better dealt with by picking standardized represention of content-type The concensus was that expecting servers to implement elaborate transcoding facilities, it would be much better if the VPIM folks could settle on a reasonable small set of mandatory or recommended to implement. I offer no opinion on whether this is a valid view or not, I simply summarize the conversation. > > *** Message length indication > > - assertion that this is not an IMAP issue - it is MIME issue > > What *is* this issue? VPIM would like to have an indication of the length of a part in other units ie. seconds for sound, pages for fax etc. We simply noted that this information, if added as proposed, is a new MIME header and didn't have anything to do with IMAP *except* that it is yet another new Content-{mumble} header that is a pain in the ass to retrieve via IMAP. > > *** Body part read indication > > - assertion that there are other ways to do this > > Again, a summary? What other ways are there to do this? The requirement itself was called into question. The premise for the requirement was that one body part was the "distinguished" body part of the message and reading it really indicates that the message has been "seen" by the user. It was noted that advice in the message headers that indicate which part is distringuished, thus providing advice to the client on when to explicitly set the seen flag is (perhaps) a better approach. In any event, the concensus was to punt this back for further thought. If push comes to shove, this requirement could be satisfied by ANNOTATE. My personal opinion is that this requirement was an attempt to cure a symptom that most IMAP clients allow the implicit SEEN flag setting to occur on messages as a result of fetching any body part. For the most part this is OK and saves round trips. It doesn't do what the VPIM folks want to do though. I think that really this is client behaviour problem and that providing advice through a header (pick your RFC822/MIME header candidate) would be sufficient to solve the problem rather than making this particular extension to the protocol. Cheers. --- Steve Hole Messaging Direct Mailto:Steve.Hole@MessagingDirect.com Phone: 780-424-4922 From owner-ietf-imapext Fri Jul 23 05:47:51 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA25735 for ietf-imapext-bks; Fri, 23 Jul 1999 05:47:51 -0700 (PDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA25731 for ; Fri, 23 Jul 1999 05:47:49 -0700 (PDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id IAA122376 for ; Fri, 23 Jul 1999 08:49:49 -0400 Received: from watson.ibm.com (mars.watson.ibm.com [9.2.2.58]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with ESMTP id IAA31684 for ; Fri, 23 Jul 1999 08:49:49 -0400 Message-ID: <379864EC.3ADE8DF4@watson.ibm.com> Date: Fri, 23 Jul 1999 08:49:48 -0400 From: Barry Leiba Organization: Internet Messaging Technology; TR2_Xagent=WATSON X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: IMAP Extensions Working Group Subject: Re: Oslo WG meeting notes References: <379477A7.4789586E@watson.ibm.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Steve, thanks for the summary, and thanks also to Alexey and Nick, who filled me in offline. > > > *** Transcoding Request > > > - assertion that there are substantial interoperability issues > > > - better dealt with by picking standardized represention of content-type > > The concensus was that expecting servers to implement elaborate > transcoding facilities, it would be much better if the VPIM folks could > settle on a reasonable small set of mandatory or recommended to implement. I agree with that as far as it goes, except that it only applies to the case of using transcoding with VPIM, and that it assumes that every device is able to implement the mandatory set. When we first started talking about transcoding, I saw it (and still see it) as a way to, say, ask for an image in a different format, to ask for a video with fewer frames, to ask for an OCR analysis of a fax, and stuff like that. Suppose I have a handheld that does 256 colours on a 200x200 screen. It does me little good to transfer a 1024x768 image with 64K colours. WIBNI I could ask the server (assuming support; yes, this is a nasty issue) to convert the image to something I could use, which wouldn't take so long to download over my cellular link that's giving me an effective transfer rate of only a few hundred bytes per second? Maybe you sent me a fax of a brochure, with lots of pictures and some text. What I need right now are the details of the conference -- dates, location, topics. I don't need to see the fax image; I want it put through OCR and I want to get the results as text on my handheld. Cool. I think it's useful to have such capability, and I think it's worth discussing how we might do it in an interoperable way. The tough bits will be defining the various transcodings that can be done, how to list them, how to specify them, how to add more, and so on. The basic mechanism shouldn't be terribly controversial. > > > *** Message length indication ... > VPIM would like to have an indication of the length of a part in other > units ie. seconds for sound, pages for fax etc. Ah, right; I didn't recognize it from the name. I remember some discussions about that. > have anything to do with IMAP *except* that it is yet another new > Content-{mumble} header that is a pain in the ass to retrieve via IMAP. Yeah, this, though, is something we *should* work on: a better, more easily extended way to return the content-xxx headers. The problem is that a client has to "fetch bodystructure", figure out all the part IDs, and then fetch "body[1.2.5.mime]" for each part. Or we have to extend the bodystructure response for each new item, and that gets icky fast. My colleague, Wolfgang Segmuller, had once proposed having a "fetch mimestructure" sort of thing, which parallels the bodystructure but which returns all the mime headers for the parts in the same way that, say, content-type parameters are returned now. So "fetch bodystructure" returns a set of nested, parenthesized part descriptors, and "fetch mimestructure" would return a set of similarly nested, parenthesized part header-lists. > > > *** Body part read indication ... > The requirement itself was called into question. The premise for the > requirement was that one body part was the "distinguished" body part of > the message and reading it really indicates that the message has been > "seen" by the user. Ah, right... from that aspect I agree. OTOH, I don't see a reason not to have "part flags", just as we have folder flags and message flags. This is distinct from the need for annotations. I can see several uses for part flags. For instance, suppose you send me 10 presentation slides, as 10 separate JPEG images. I might want to flag the one with a particular pie chart as "\flagged", because it's the one that's especially interesting to me. I also might want to know which of the JPEG images I've "\seen" and which I haven't, as I'm poking my way through your presentation. Barry Leiba, Internet Messaging Technology (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba From owner-ietf-imapext Fri Jul 23 07:20:03 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA26624 for ietf-imapext-bks; Fri, 23 Jul 1999 07:20:03 -0700 (PDT) Received: from demo.esys.ca (demo.esys.ca [207.167.22.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA26619 for ; Fri, 23 Jul 1999 07:20:02 -0700 (PDT) Received: from galileo.esys.ca (galileo.esys.ca [198.161.92.18]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id IAA14857; Fri, 23 Jul 1999 08:22:02 -0600 From: Steve Hole Date: Fri, 23 Jul 1999 08:22:15 -0600 To: Barry Leiba Subject: Re: per-part message flags (was: Oslo WG meeting notes) Cc: IMAP Extensions Working Group In-Reply-To: <379864EC.3ADE8DF4@watson.ibm.com> References: <379864EC.3ADE8DF4@watson.ibm.com> <379477A7.4789586E@watson.ibm.com> Message-ID: X-Mailer: Execmail for Linux 5.1 b1 Build (1) -- Evaluation Copy MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Fri, 23 Jul 1999 08:49:48 -0400 Barry Leiba wrote: > OTOH, I don't see a reason not to have "part flags", just as we have > folder flags and message flags. This is distinct from the need for > annotations. I can see several uses for part flags. For instance, > suppose you send me 10 presentation slides, as 10 separate JPEG images. > I might want to flag the one with a particular pie chart as "\flagged", > because it's the one that's especially interesting to me. I also might > want to know which of the JPEG images I've "\seen" and which I haven't, > as I'm poking my way through your presentation. You are an evil, evil man :-) There are certainly applications for per-part flags. If I implement annotations, a general mechanism for per-message metadata, then I'm not keen to do this as another extension as well. It is arguable that annotations would be more difficult to implement, but I'm not sure that that is true -- at least for our server. I have a hard time thinking of the architecture of other servers, so I admit that similarity of implementation may not be true for other servers. When I think about how to do either of these things in our server, ANNOTATE is only slightly harder than per-part flags, but is much more flexible and general. If we wanted to do this, I would propose some kind of profiled use of ANNOTATE. Much like the "standard options" in the ACAP Options dataset class. Cheers. --- Steve Hole Messaging Direct Mailto:Steve.Hole@MessagingDirect.com Phone: 780-424-4922 From owner-ietf-imapext Fri Jul 23 07:35:51 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA26805 for ietf-imapext-bks; Fri, 23 Jul 1999 07:35:51 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA26801 for ; Fri, 23 Jul 1999 07:35:49 -0700 (PDT) Received: from mw-122-188.ny.shownets.net (mw-122-188.ny.shownets.net [209.119.122.188]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id KAA03496; Fri, 23 Jul 1999 10:37:29 -0400 (EDT) Date: Fri, 23 Jul 1999 10:38:21 -0400 From: Cyrus Daboo To: Steve Hole , Barry Leiba cc: IMAP Extensions Working Group Subject: Re: per-part message flags (was: Oslo WG meeting notes) Message-ID: <403437.3141715101@mw-122-188.ny.shownets.net> In-Reply-To: Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431 X-Mailer: Mulberry (MacOS) [2.0.0a4, s/n S1-000001] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: --On Fri, Jul 23, 1999 8:22 AM -0600 Steve Hole wrote: > There are certainly applications for per-part flags. If I implement > annotations, a general mechanism for per-message metadata, then I'm not > keen to do this as another extension as well. It is arguable that > annotations would be more difficult to implement, but I'm not sure that > that is true -- at least for our server. I have a hard time thinking of > the architecture of other servers, so I admit that similarity of > implementation may not be true for other servers. When I think about > how to do either of these things in our server, ANNOTATE is only slightly > harder than per-part flags, but is much more flexible and general. > > If we wanted to do this, I would propose some kind of profiled use of > ANNOTATE. Much like the "standard options" in the ACAP Options dataset > class. That's indeed what I'm planning on including in the first cut of the ANNOTATE draft that Randy and I are working on (well he's not seen it yet - but soon). There will be an annotation 'hierarchy' that mimics the bodystructure of the message thus allowing per-part annotations. A 'flags' entry could then be defined in the spec with well-defined syntax for doing per-part flags. Of course there is a major problem of how to handle per-user per-part flags for shared mailboxes and that's going to require some careful design. -- Cyrus From owner-ietf-imapext Fri Jul 23 07:40:54 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA26867 for ietf-imapext-bks; Fri, 23 Jul 1999 07:40:54 -0700 (PDT) Received: from demo.esys.ca (demo.esys.ca [207.167.22.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA26863 for ; Fri, 23 Jul 1999 07:40:53 -0700 (PDT) Received: from galileo.esys.ca (galileo.esys.ca [198.161.92.18]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id IAA14875; Fri, 23 Jul 1999 08:42:50 -0600 From: Steve Hole Date: Fri, 23 Jul 1999 08:43:03 -0600 To: Cyrus Daboo Subject: Re: per-part message flags (was: Oslo WG meeting notes) Cc: Barry Leiba , IMAP Extensions Working Group In-Reply-To: <403437.3141715101@mw-122-188.ny.shownets.net> References: <403437.3141715101@mw-122-188.ny.shownets.net> Message-ID: X-Mailer: Execmail for Linux 5.1 b1 Build (1) -- Evaluation Copy MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Fri, 23 Jul 1999 10:38:21 -0400 Cyrus Daboo wrote: > Of course there is a major problem of how to handle > per-user per-part flags for shared mailboxes and that's going to require > some careful design. That's why Barry is evil :-) Actually, Barry's not evil, he's quite a nice guy. Just his ideas are evil. --- Steve Hole Messaging Direct Mailto:Steve.Hole@MessagingDirect.com Phone: 780-424-4922 From owner-ietf-imapext Fri Jul 23 11:11:34 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA29365 for ietf-imapext-bks; Fri, 23 Jul 1999 11:11:34 -0700 (PDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA29348 for ; Fri, 23 Jul 1999 11:09:57 -0700 (PDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id OAA165460 for ; Fri, 23 Jul 1999 14:11:57 -0400 Received: from watson.ibm.com (mars.watson.ibm.com [9.2.2.58]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with ESMTP id OAA23776 for ; Fri, 23 Jul 1999 14:11:56 -0400 Message-ID: <3798B06C.CCF61D56@watson.ibm.com> Date: Fri, 23 Jul 1999 14:11:56 -0400 From: Barry Leiba Organization: Internet Messaging Technology; TR2_Xagent=WATSON X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: IMAP Extensions Working Group Subject: Re: per-part message flags (was: Oslo WG meeting notes) References: <403437.3141715101@mw-122-188.ny.shownets.net> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > but soon). There will be an annotation 'hierarchy' that mimics the > bodystructure of the message thus allowing per-part annotations. A 'flags' > entry could then be defined in the spec with well-defined syntax for doing Yes, that'd be perfect; I hadn't thought the ANNOTATE extension was going to have (effectively) per-part annotations. Sure, with annotations, a flag just becomes a special case. > per-part flags. Of course there is a major problem of how to handle > per-user per-part flags for shared mailboxes and that's going to require Just as we have the issue of per-user and global message flags, we have the same issue of per-user and global annotations. Except, unlike with message flags, I think we must answer the question explicitly. That is, I think we must provide a definitive answer to the question of whether a particular annotation is user-specific or global. Otherwise we'll have an interoperability disaster. Evil Barry, Internet Messaging Technology (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba From owner-ietf-imapext Fri Jul 23 12:08:59 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA00166 for ietf-imapext-bks; Fri, 23 Jul 1999 12:08:59 -0700 (PDT) Received: from demo.esys.ca (demo.esys.ca [207.167.22.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA00161 for ; Fri, 23 Jul 1999 12:08:58 -0700 (PDT) Received: from galileo.esys.ca (galileo.esys.ca [198.161.92.18]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id NAA15602; Fri, 23 Jul 1999 13:10:59 -0600 From: Steve Hole Date: Fri, 23 Jul 1999 13:11:12 -0600 To: Barry Leiba Subject: Re: per-part message flags (was: Oslo WG meeting notes) Cc: IMAP Extensions Working Group In-Reply-To: <3798B06C.CCF61D56@watson.ibm.com> References: <3798B06C.CCF61D56@watson.ibm.com> <403437.3141715101@mw-122-188.ny.shownets.net> Message-ID: X-Mailer: Execmail for Linux 5.1 b1 Build (1) -- Evaluation Copy MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Fri, 23 Jul 1999 14:11:56 -0400 Barry Leiba wrote: > Just as we have the issue of per-user and global message flags, we have > the > same issue of per-user and global annotations. Except, unlike with message > flags, I think we must answer the question explicitly. That is, I think we > must provide a definitive answer to the question of whether a particular > annotation is user-specific or global. Otherwise we'll have an interoperability > disaster. You're right, we must. ** Begin semi-serious hypothesizing ** In fact, with some clever thinking we might be able to allow scoping management to be explicit, and have the standard per-message flags exposed as part of the annotation data. In that way we could expose the standard system flags to the explicit scoping management. That way systems that support shared folders can allow the application to specify the scoping for flags on messages in the folder. Call center management, help desk applications etc have wanted this capability for awhile. Don't know if I want to write that, but it would be cool. ** End semi-serious hypothesizing ** Cheers. --- Steve Hole Messaging Direct Mailto:Steve.Hole@MessagingDirect.com Phone: 780-424-4922 From owner-ietf-imapext Fri Jul 23 12:46:32 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA00805 for ietf-imapext-bks; Fri, 23 Jul 1999 12:46:32 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA00800 for ; Fri, 23 Jul 1999 12:46:31 -0700 (PDT) Received: from mw-122-188.ny.shownets.net (mw-122-188.ny.shownets.net [209.119.122.188]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id PAA04591; Fri, 23 Jul 1999 15:48:19 -0400 (EDT) Date: Fri, 23 Jul 1999 15:49:14 -0400 From: Cyrus Daboo To: Steve Hole , Barry Leiba cc: IMAP Extensions Working Group Subject: Re: per-part message flags (was: Oslo WG meeting notes) Message-ID: <1525213.3141733754@mw-122-188.ny.shownets.net> In-Reply-To: Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431 X-Mailer: Mulberry (MacOS) [2.0.0a4, s/n S1-000001] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: --On Fri, Jul 23, 1999 1:11 PM -0600 Steve Hole wrote: > In fact, with some clever thinking we might be able to allow scoping > management to be explicit, and have the standard per-message flags > exposed as part of the annotation data. In that way we could expose > the standard system flags to the explicit scoping management. That way > systems that support shared folders can allow the application to specify > the scoping for flags on messages in the folder. Call center > management, help desk applications etc have wanted this capability for > awhile. Don't know if I want to write that, but it would be cool. I'm reluctant to expose any existing IMAP data through the annotation mechanism (e.g. having an annotation that returns the current set of message flags or the ENVELOPE etc). Since there's already a way to get to this data there's no need for it in an annotation. What you're proposing above is more of a redifinition of the existing flags and I think that should be handled as a completely separate annotation mechanism rather than being tied to the existing IMAP flags. -- Cyrus From owner-ietf-imapext Wed Jul 28 07:15:16 1999 Received: by mail.proper.com (8.9.3/8.9.3) id HAA05059 for ietf-imapext-bks; Wed, 28 Jul 1999 07:15:16 -0700 (PDT) Received: from alms1.fw.att.com (alms1.att.com [192.128.167.146]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA05052 for ; Wed, 28 Jul 1999 07:15:15 -0700 (PDT) Received: from dns.maillennium.att.com ([135.25.114.99]) by alms1.fw.att.com (AT&T IPNS/MS-2.2) with ESMTP id KAA23796 for ; Wed, 28 Jul 1999 10:17:00 -0400 (EDT) Received: from att.com ([135.197.86.73](may be forged)) by maillennium.att.com (labmail) with SMTP id <19990728135638un100992cde>; Wed, 28 Jul 1999 13:56:38 +0000 Message-ID: <379F0C2F.98F3F4FD@att.com> Date: Wed, 28 Jul 1999 09:57:03 -0400 From: Tony Hansen Organization: AT&T Laboratories X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-imapext@imc.org CC: John Stracke Subject: Re: Annotations: alternate data model References: <505104.3141394425@sardis.cyrusoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Cyrus Daboo wrote: > > > The strawman annotation model that was presented suggested a basic > > name/value data model, but also mentioned the possibility of wanting to > > permit values to be large binary blobs. Rather than develop a new > > syntax for doing this, you might want to adopt something like the WebDAV > > property model, in which a property is an XML element. The name of the > > element becomes the name of the property, and you get to use all the > > features of XML (structured data, internationalization, namespaces, > > etc.). > > I had another look at the WebDAV RFC after your comments and there are some > interesting things there that could be applied to ANNOTATE. But... > > > (Of course, this may not make as much sense in IMAP as in WebDAV, where > > most of the protocol information is carried in XML in the first place.) > > This is the issue. WebDAV has everything wrapped up in an XML document. It > requires XML parsers on both the server and client. I'm not sure we want to > lay this burden on IMAP servers and clients. > > Though not being a WebDAV/XML expert I'm certainly open to suggestions as > to how this might be applied to ANNOTATE. Non-validating XML parsers are fairly cheap to implement and are freely available. You're going to have to have a parser anyway, and an XML parser isn't overly harder than a parser for any other data representation language. I've been using XML in some projects here and like a lot of its features. We did have to do something about representing binary values within XML, but otherwise are fairly pleased with XML as a data representation language. Tony Hansen tony@att.com From owner-ietf-imapext Wed Jul 28 08:28:16 1999 Received: by mail.proper.com (8.9.3/8.9.3) id IAA07871 for ietf-imapext-bks; Wed, 28 Jul 1999 08:28:16 -0700 (PDT) Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA07862 for ; Wed, 28 Jul 1999 08:28:14 -0700 (PDT) Received: from hpopd.pwd.hp.com (hpopd.pwd.hp.com [15.145.205.59]) by atlrel2.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id LAA01656; Wed, 28 Jul 1999 11:30:08 -0400 (EDT) Received: from pwd.hp.com (ilex.pwd.hp.com [15.145.204.106]) by hpopd.pwd.hp.com (8.8.6 (PHNE_15509)/8.8.6 CMSO Openmail) with ESMTP id QAA22317; Wed, 28 Jul 1999 16:30:26 +0100 (BST) Message-ID: <379F2211.752FB85E@pwd.hp.com> Date: Wed, 28 Jul 1999 16:30:25 +0100 From: John Haxby X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10 i686) X-Accept-Language: en MIME-Version: 1.0 To: tony@att.com CC: ietf-imapext@imc.org, francis@ecal.com Subject: Re: Annotations: alternate data model References: <505104.3141394425@sardis.cyrusoft.com> <379F0C2F.98F3F4FD@att.com> Content-Type: multipart/mixed; boundary="------------914A13F32093D2B4108DB02C" Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: This is a multi-part message in MIME format. --------------914A13F32093D2B4108DB02C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit tony@att.com wrote: > Non-validating XML parsers are fairly cheap to implement and are freely > available. Could you provide some pointers to these freely available parsers? > > I've been using XML in some projects here and like a lot of its > features. We did have to do something about representing binary values > within XML, but otherwise are fairly pleased with XML as a data > representation language. I have to agree here. It's certainly a lot easier to get to grips with than ASN.1! jch --------------914A13F32093D2B4108DB02C Content-Type: text/x-vcard; charset=us-ascii; name="jch.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for John Haxby Content-Disposition: attachment; filename="jch.vcf" begin:vcard n:Haxby;John tel;work:+44 1344 763711 x-mozilla-html:FALSE url:http://www.hp.com/go/OpenMail org:Hewlett Packard;OpenMail R&D adr:;;Nine Mile Ride;Wokingham;Berks;RG40 3LL;England version:2.1 email;internet:jch@pwd.hp.com x-mozilla-cpt:;14976 fn:John Haxby end:vcard --------------914A13F32093D2B4108DB02C-- From owner-ietf-imapext Wed Jul 28 18:05:22 1999 Received: by mail.proper.com (8.9.3/8.9.3) id SAA29055 for ietf-imapext-bks; Wed, 28 Jul 1999 18:05:22 -0700 (PDT) Received: from alms1.fw.att.com (alms1.att.com [192.128.167.146]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id SAA29046 for ; Wed, 28 Jul 1999 18:05:21 -0700 (PDT) Received: from dns.maillennium.att.com ([135.25.114.99]) by alms1.fw.att.com (AT&T IPNS/MS-2.2) with ESMTP id VAA22395 for ; Wed, 28 Jul 1999 21:07:19 -0400 (EDT) Received: from att.com ([135.197.86.117](may be forged)) by maillennium.att.com (labmail) with SMTP id <19990729010515un100992ufe>; Thu, 29 Jul 1999 01:05:16 +0000 Message-ID: <379FA8E6.B23F934B@att.com> Date: Wed, 28 Jul 1999 21:05:42 -0400 From: Tony Hansen Organization: AT&T Laboratories X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: John Haxby CC: ietf-imapext@imc.org Subject: Re: Annotations: alternate data model References: <505104.3141394425@sardis.cyrusoft.com> <379F0C2F.98F3F4FD@att.com> <379F2211.752FB85E@pwd.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: John Haxby wrote: > > > Non-validating XML parsers are fairly cheap to implement and are freely > > available. > > Could you provide some pointers to these freely available parsers? Some free parsers are available at: http://www.w3.org/Library/ non-validating (C) http://www.alphaworks.ibm.com/ validating (C++,Java) Tony Hansen tony@att.com From owner-ietf-imapext Tue Aug 3 07:45:13 1999 Received: by mail.proper.com (8.9.3/8.9.3) id HAA07627 for ietf-imapext-bks; Tue, 3 Aug 1999 07:45:13 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA07623 for ; Tue, 3 Aug 1999 07:45:03 -0700 (PDT) Received: from sardis.cyrusoft.com (sardis.cyrusoft.com [206.31.218.203]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id KAA04628 for ; Tue, 3 Aug 1999 10:47:48 -0400 (EDT) Date: Tue, 03 Aug 1999 10:50:15 -0400 From: Cyrus Daboo To: IMAP Extensions Working Group Subject: [VIEW] Dynamic vs static Message-ID: <4363929.3142666215@sardis.cyrusoft.com> Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431 X-Mailer: Mulberry (MacOS) [2.0.0a4, s/n S1-000001] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Hi folks, At the Oslo meeting we had discussions about whether the VIEW extenions should be dynamic or static with respect to message changing position in a view. This issue was not fully resolved and so I'm kicking off some list discussion about it. Right now the VIEW extension requires dynamic updates (via responses) from the server for: a) new messages arriving in the mailbox b) messages being expunged from the mailbox c) messages moving into or out of a view due to a change in some message state (right now only flags, but this may include annotations once that's available) Of these I think (a) and (b) MUST be present. We were all agreed in Oslo that (a) matches user expectations - i.e. the arrival of any new message that matches the current view criteria MUST result in that message appearing in the client's view. (b) is merely an extenion of the current expunge mechanism where messages have to be removed from the clients cache when an expunge occurs. (c) is really the issue of this debate. Should changes to a message's state be notified to the client via untagged responses? One argument against a dynamic view is to consider the case of a view set to display only unseen messages. As soon as a user tries to read such a message the \Seen flag is implicitly set (of course the client could use the .PEEK FETCH variant to stop this). At that point in a dynamic view, the message would be removed from the view via an untagged response, and suddenly the message the user is trying to read is now outside of the client's view! I think this is probably counter to user expectations. One solution to this is to say views are static with respect to changes in message state and to introduce a new 'VIEW UPDATE' command that the client can issue to 'refresh' its current view to the actually message state. This way the client is in control of view updates. What do people think? Should VIEW be fully dynamic (i.e. (a), (b) & (c) produce untagged responses), or should it be static (i.e. (a) and (b) are still dynamic, but (c) does not generate untagged responses)? -- Cyrus From owner-ietf-imapext Tue Aug 3 08:01:51 1999 Received: by mail.proper.com (8.9.3/8.9.3) id IAA08134 for ietf-imapext-bks; Tue, 3 Aug 1999 08:01:51 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA08130 for ; Tue, 3 Aug 1999 08:01:50 -0700 (PDT) Received: from sardis.cyrusoft.com (sardis.cyrusoft.com [206.31.218.203]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id LAA04718 for ; Tue, 3 Aug 1999 11:04:38 -0400 (EDT) Date: Tue, 03 Aug 1999 11:07:06 -0400 From: Cyrus Daboo To: IMAP Extensions Working Group Subject: [VIEW] Multiple views Message-ID: <4424710.3142667226@sardis.cyrusoft.com> Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431 X-Mailer: Mulberry (MacOS) [2.0.0a4, s/n S1-000001] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: The issue of whether the VIEW extension should support multiple views was raised in Oslo. Here are Steve's minutes on the subject for reference: > ** Support for multiple VIEWS > - very expensive for the server implementors > - will clients actually use it? > - there are examples of how a client might use it. > - some vendors clearly expressed a desire to have it. > - there are other workarounds (multiple connections, refining criteria > on reissued VIEW) > - punt issue to list I think it was clear that most server vendors felt this was adding too much complexity to VIEW from the outset and would provide too much of a hurdle for the adoption of the VIEW extension. Is this really how people feel about this now? One solution is to design VIEW now as a single VIEW mechanism but to allow a VIEW2 extension to extend it for multiple views once VIEW has proven itself to be useful and is widely adopted. If we were to do this it might be sensible to take this into account when designing VIEW. What I think we could do is make the definition of the view position more than just the hierarchical number currently proposed in the extension. If instead we allowed it to be single or multi-valued then we could add multiple view very easily in the future. For example, with multiple views we could say the view position specifier has two levels of hierarchy - the first is the multiple view number, the second the position of the message in the view. e.g. view position of 2.3 refers to the third message in view order in the second view. By also allowing the view position specifier to be multi-valued, changes to a single message that appears in multiple views could be communicated to the client in a single response. e.g. for new mail arrival we might have: C: NOOP S: * 173 EXISTS 24 S: * 1 RECENT S: * 173 VIEW 5274234 (1.14 2.3) S: NOOP complete A new message arrived and appeared at position 14 in view 1 and at position 3 in view 2. Note also that in the case of view operating with the THREAD extension, its clear that messages can appear in multiple positions in the SAME view. Thus defining the view position to be single or multi-valued also makes dealing with THREAD easier. Comments/other suggestions? -- Cyrus From owner-ietf-imapext Tue Aug 3 08:08:57 1999 Received: by mail.proper.com (8.9.3/8.9.3) id IAA08303 for ietf-imapext-bks; Tue, 3 Aug 1999 08:08:57 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA08299 for ; Tue, 3 Aug 1999 08:08:56 -0700 (PDT) Received: from sardis.cyrusoft.com (sardis.cyrusoft.com [206.31.218.203]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id LAA04772 for ; Tue, 3 Aug 1999 11:11:44 -0400 (EDT) Date: Tue, 03 Aug 1999 11:14:11 -0400 From: Cyrus Daboo To: IMAP Extensions Working Group Subject: [ANNOTATE] Mailbox and server level annotations Message-ID: <4450312.3142667651@sardis.cyrusoft.com> Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431 X-Mailer: Mulberry (MacOS) [2.0.0a4, s/n S1-000001] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: The current annotation extension being discussed is for message annotations only (i.e. each message could have its own set of annotations). Its also potentially useful to allow mailbox annotations and indeed server annotations. For example, mailbox annotations could include annotations describing what particular sort order a user likes to view this mailbox in, or the window position and size for displaying a particular mailbox, or a detailed description of the mailbox contents etc. Server annotations might include a URL to a webpage for managing accounts on the server or for doing password changing, a way to map user ids into user names for handling access control lists, a description of who to contact when things go wrong on the server etc Would people find these useful? If they are worth considering as an extension, they should probably be separate from message annotations, and indeed separate from each other (i.e. we end up with three annotation documents). Any comments? -- Cyrus From owner-ietf-imapext Tue Aug 3 12:33:25 1999 Received: by mail.proper.com (8.9.3/8.9.3) id MAA14240 for ietf-imapext-bks; Tue, 3 Aug 1999 12:33:25 -0700 (PDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA14236 for ; Tue, 3 Aug 1999 12:33:21 -0700 (PDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id PAA07548 for ; Tue, 3 Aug 1999 15:36:17 -0400 Received: from watson.ibm.com (mars.watson.ibm.com [9.2.2.58]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with ESMTP id PAA71508 for ; Tue, 3 Aug 1999 15:36:17 -0400 Message-ID: <37A744B0.FAE931B4@watson.ibm.com> Date: Tue, 03 Aug 1999 15:36:16 -0400 From: Barry Leiba Organization: Internet Messaging Technology; TR2_Xagent=WATSON X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: IMAP Extensions Working Group Subject: Re: [VIEW] Dynamic vs static References: <4363929.3142666215@sardis.cyrusoft.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Cyrus Daboo wrote: > (c) is really the issue of this debate. Should changes to a message's state > be notified to the client via untagged responses? > > One argument against a dynamic view is to consider the case of a view set > to display only unseen messages. As soon as a user tries to read such a ... > suddenly the message the user is trying to read is now outside of the > client's view! I think this is probably counter to user expectations. One thing to remember is that this has nothing to do with *user* expectations; it's purely a matter for the client to deal with. The original design of the "view" concept as an extension to "select" had it that messages outside the view weren't available to the client. That's no longer the case. Therefore, a client could easily retrieve the UIDs of the messages it presents to the user, and needn't remove those messages from the user's view when they're removed from the client's view. Another way of looking at it is that the client uses the view sequence numbers to build the UI, but thereafter refers to the messages by UID. I think the only reasonable and consistent thing to do, given the current design, is to make the view fully dynamic. Barry Leiba, Internet Messaging Technology (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba From owner-ietf-imapext Tue Aug 3 13:27:27 1999 Received: by mail.proper.com (8.9.3/8.9.3) id NAA14915 for ietf-imapext-bks; Tue, 3 Aug 1999 13:27:27 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA14911 for ; Tue, 3 Aug 1999 13:27:26 -0700 (PDT) Received: from ephesus.cyrusoft.com (ephesus.cyrusoft.com [206.31.218.204]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id QAA06150; Tue, 3 Aug 1999 16:30:03 -0400 (EDT) Date: Tue, 03 Aug 1999 16:30:26 -0400 From: Cyrus Daboo To: Barry Leiba , IMAP Extensions Working Group Subject: Re: [VIEW] Dynamic vs static Message-ID: <1689923456.933697826@ephesus.cyrusoft.com> In-Reply-To: <37A744B0.FAE931B4@watson.ibm.com> Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431 X-Mailer: Mulberry (Win32) [2.0.0a4, s/n S1-000001] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: --On Tuesday, August 03, 1999, 3:36 PM -0400 Barry Leiba wrote: > One thing to remember is that this has nothing to do with *user* > expectations; it's purely a matter for the client to deal with. The > original design of the "view" concept as an extension to "select" had > it that messages outside the view weren't available to the client. > That's no longer the case. Therefore, a client could easily retrieve > the UIDs of the messages it presents to the user, and needn't remove > those messages from the user's view when they're removed from the > client's view. > > Another way of looking at it is that the client uses the view sequence > numbers to build the UI, but thereafter refers to the messages by UID. No - this is counter to one of the main purposes of VIEW. What you are suggesting requires the client to cache the entire view position<->UID mappings for ALL messages in the view. But the one important point of VIEW is that clients only need to download information for those messages it needs to show to the user (i.e. virtual scrollbar). If you force the client to maintain its own map then its really no different from what Mark originally proposed with SORT. Basically a client should be able to solely rely on view positions as opposed to sequence numbers or UIDs if needs be. -- Cyrus From owner-ietf-imapext Tue Aug 3 14:02:39 1999 Received: by mail.proper.com (8.9.3/8.9.3) id OAA15277 for ietf-imapext-bks; Tue, 3 Aug 1999 14:02:39 -0700 (PDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA15273 for ; Tue, 3 Aug 1999 14:02:38 -0700 (PDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id RAA06556 for ; Tue, 3 Aug 1999 17:05:35 -0400 Received: from mars.watson.ibm.com (mars.watson.ibm.com [9.2.2.58]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with ESMTP id RAA72966 for ; Tue, 3 Aug 1999 17:05:34 -0400 From: Barry Leiba Date: Tue, 3 Aug 1999 17:05:24 -0400 To: IMAP Extensions Working Group Subject: Re: [VIEW] Dynamic vs static In-Reply-To: <1689923456.933697826@ephesus.cyrusoft.com> References: <1689923456.933697826@ephesus.cyrusoft.com> <37A744B0.FAE931B4@watson.ibm.com> Message-ID: X-Mailer: Execmail for Win32 5.1 b1 Build (1) -- Evaluation Copy MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > No - this is counter to one of the main purposes of VIEW. What you are > suggesting requires the client to cache the entire view position<->UID > mappings for ALL messages in the view. No, not at all. Only the messages it's shown the user. If the user hasn't seen the message, then the fact that it's disappeared from the view is irrelevant. Once the user has seen the message (it's come up in the virtual window), then the client has presumably picked up the ENVELOPE and FLAGS information, for instance (in order to display it in the UI), and, so, can also have picked up the UID at the same time. Barry Leiba, Internet Messaging Technology (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba From owner-ietf-imapext Tue Aug 3 17:16:18 1999 Received: by mail.proper.com (8.9.3/8.9.3) id RAA02372 for ietf-imapext-bks; Tue, 3 Aug 1999 17:16:18 -0700 (PDT) Received: from mailhost1.u.washington.edu (mailhost1.u.washington.edu [140.142.32.2]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA02368 for ; Tue, 3 Aug 1999 17:16:17 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (koma@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost1.u.washington.edu (8.9.3+UW99.06/8.9.3+UW99.01) with ESMTP id RAA28151; Tue, 3 Aug 1999 17:19:13 -0700 Date: Tue, 3 Aug 1999 17:14:29 -0700 (PDT) From: Mark Crispin Subject: re: [VIEW] Multiple views To: Cyrus Daboo cc: IMAP Extensions Working Group In-Reply-To: <4424710.3142667226@sardis.cyrusoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Tue, 03 Aug 1999 11:07:06 -0400, Cyrus Daboo wrote: > I think it was clear that most server vendors felt this was adding too much > complexity to VIEW from the outset and would provide too much of a hurdle > for the adoption of the VIEW extension. Is this really how people feel > about this now? If the VIEW extension ends up requiring support for multiple views, I probably won't implement it. > One solution is to design VIEW now as a single VIEW mechanism but to allow > a VIEW2 extension to extend it for multiple views once VIEW has proven > itself to be useful and is widely adopted. If we were to do this it might > be sensible to take this into account when designing VIEW. I agree that VIEW should claim to be a proper subset of all IMAP capabilities with begin with "VIEW", so as to provide extensibility. > What I think we > could do is make the definition of the view position more than just the > hierarchical number currently proposed in the extension. If instead we > allowed it to be single or multi-valued then we could add multiple view > very easily in the future. Ugh! Think about what would happen if people want multiple *nested* views. Please, let's not go here. > S: * 173 VIEW 5274234 (1.14 2.3) > A new message arrived and appeared at position 14 in view 1 > and at position 3 in view 2. > Note also that in the case of view operating with the THREAD extension, its > clear that messages can appear in multiple positions in the SAME view. Thus > defining the view position to be single or multi-valued also makes dealing > with THREAD easier. I don't understand this. The view position has to be multi-valued, meaning that the message appears in multiple places in the view. If you really wanted multiple view syntax, you would need something like: S: * 173 VIEW 5274234 (1.14) (2.3) From owner-ietf-imapext Tue Aug 3 17:11:00 1999 Received: by mail.proper.com (8.9.3/8.9.3) id RAA02243 for ietf-imapext-bks; Tue, 3 Aug 1999 17:11:00 -0700 (PDT) Received: from mailhost1.u.washington.edu (mailhost1.u.washington.edu [140.142.32.2]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA02238 for ; Tue, 3 Aug 1999 17:10:59 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (jesus@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost1.u.washington.edu (8.9.3+UW99.06/8.9.3+UW99.01) with ESMTP id RAA27873; Tue, 3 Aug 1999 17:13:54 -0700 Date: Tue, 3 Aug 1999 16:45:41 -0700 (PDT) From: Mark Crispin Subject: re: [VIEW] Dynamic vs static To: Cyrus Daboo cc: IMAP Extensions Working Group In-Reply-To: <4363929.3142666215@sardis.cyrusoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: One way of looking at this is that "what IMAP does is not necessarily what the client will show". We should focus on what is best for client implementations (because clients are what will benefit from it) and what is feasible for server implementations (because if it isn't feasible then servers won't implement it). I think that I reject any idea to be "smart", e.g. making a special exception for the \Seen or \Recent flags for "new" messages. I think that our choices are: 1) fully-static. Once a view is set, it's immutable. I guess that this means that if a message in the view is expunged, the view gets a hole. 2) semi-static. Once a message is entered into the view, it stays there even if its state changes in a way that would cause it to leave the view. However, expunged messages are removed from the view (so you can do math on view ids the way you can on sequences), and new messages are incorporated into the view as appropriate. 3) dynamic. Messages are added to the view via new messages or if the state of a non-viewed message changes. Messages are removed from the view via expunge or if the state of a viewed message changes. I think that (1) is probably a non-starter for client implementors. It would be the easiest to implement for server implementors, since it doesn't require us to remember the VIEW SET (as opposed to the map created by it). The problem with VIEW UPDATE is that it combines the worst of both worlds -- it requires the client to issue a command to fix the view, and it requires the server to remember the VIEW SET. Let's reject VIEW UPDATE for (1), say "with (1), the client must issue a new VIEW SET to update the view." (2) is probably what most people want and what server guys will acceed to. It's a pain for servers to have to remember the VIEW SET, but not as bad as (3). If clients really want messages to disappear from the view due to state changes, they can issue a new VIEW SET. VIEW UPDATE is a possibility here if people insist. (3) is a big pain for servers. There's all the burdern of (2), plus they must watch the state of all messages (either they have to get notified of the state change, or they have to scan periodically) and reassess any changed-state message against the VIEW SET. Also, it can cause unexpected behavior for users, so this extra "service" may not really be what clients want. From owner-ietf-imapext Wed Aug 4 09:37:23 1999 Received: by mail.proper.com (8.9.3/8.9.3) id JAA27613 for ietf-imapext-bks; Wed, 4 Aug 1999 09:37:23 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA27609 for ; Wed, 4 Aug 1999 09:37:22 -0700 (PDT) Received: from ephesus.cyrusoft.com (ephesus.cyrusoft.com [206.31.218.204]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id MAA08725; Wed, 4 Aug 1999 12:39:56 -0400 (EDT) Date: Wed, 04 Aug 1999 12:40:18 -0400 From: Cyrus Daboo To: Mark Crispin cc: IMAP Extensions Working Group Subject: re: [VIEW] Dynamic vs static Message-ID: <1762514794.933770418@ephesus.cyrusoft.com> In-Reply-To: Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431 X-Mailer: Mulberry (Win32) [2.0.0a4, s/n S1-000001] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: --On Tuesday, August 03, 1999, 4:45 PM -0700 Mark Crispin wrote: > One way of looking at this is that "what IMAP does is not necessarily > what the client will show". We should focus on what is best for client > implementations (because clients are what will benefit from it) and what > is feasible for server implementations (because if it isn't feasible then > servers won't implement it). Well I would like to throw something else into this equation - namely 'users'. Its all well and good to have this functionality available on client and server but if its too difficult for the user to use, or doesn't do what they really want it to, then its not going to be of much use. Its already the case that a number of client vendors have a VIEW type mechanism built into their clients, using client-based searching etc to determine the view. I know from our own experience (about a year's worth) that users want to have any new messages that arrive with matching view criteria immediately displayed to them. In other words new message arrival MUST result in dynamic VIEW responses. Also, having looked back at user discussions, its clear that they do NOT want a fully dynamic view at least in the sense that messages dissappear from the view if they no longer match because of a flag change. In other words option (2) as described in Mark's original post matches (our) users' expectations of how view should work. I think we should hear from otehr client vendors with a similar client-side mechanism to see what their usability studies suggest in this area. -- Cyrus From owner-ietf-imapext Wed Aug 4 09:47:36 1999 Received: by mail.proper.com (8.9.3/8.9.3) id JAA27881 for ietf-imapext-bks; Wed, 4 Aug 1999 09:47:36 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA27877 for ; Wed, 4 Aug 1999 09:47:35 -0700 (PDT) Received: from ephesus.cyrusoft.com (ephesus.cyrusoft.com [206.31.218.204]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id MAA08774; Wed, 4 Aug 1999 12:50:10 -0400 (EDT) Date: Wed, 04 Aug 1999 12:50:32 -0400 From: Cyrus Daboo To: Barry Leiba , IMAP Extensions Working Group Subject: Re: [VIEW] Dynamic vs static Message-ID: <1763129668.933771032@ephesus.cyrusoft.com> In-Reply-To: Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431 X-Mailer: Mulberry (Win32) [2.0.0a4, s/n S1-000001] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: --On Tuesday, August 03, 1999, 5:05 PM -0400 Barry Leiba wrote: > No, not at all. Only the messages it's shown the user. If the user > hasn't seen the message, then the fact that it's disappeared from the > view is irrelevant. Once the user has seen the message (it's come up > in the virtual window), then the client has presumably picked up the > ENVELOPE and FLAGS information, for instance (in order to display it > in the UI), and, so, can also have picked up the UID at the same time. Right, but from then on the client has to go through a complex procedure for figuring out which messages are in its display list and are part of the server view and which are not part of the server view. So if a user selects all the messages and then does a delete, the client ends up having to issue two commands to delete the message: 'VIEW STORE' for messages in the server view, and 'UID STORE' for messages outside the server view. It has to do the same sort of thing if the user just wants to search the message within the client's current view. There's no reason why a client can't do this, but I don't think we should force this complex behaviour by requiring VIEW to be fully dynamic, if most clients really want the static form of view. Remember, its easy for a client to take the static form of VIEW and effectively emulate a dynamic form by simply issuing a 'VIEW UPDATE' command everytime there's an unsolicted response from the server that might result in a change to the view. Its much harder to emulate the static mode when the server only supports the dynamic mode. There is another option that I didn't mention in my first port on this, and that is the possibility of allowing both dynamic and static views but have the client decide when the VIEW is set which it wants. -- Cyrus From owner-ietf-imapext Wed Aug 4 10:34:25 1999 Received: by mail.proper.com (8.9.3/8.9.3) id KAA29529 for ietf-imapext-bks; Wed, 4 Aug 1999 10:34:25 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (harley@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA29523 for ; Wed, 4 Aug 1999 10:34:24 -0700 (PDT) Date: Wed, 4 Aug 1999 10:27:15 -0700 (PDT) From: Mark Crispin Subject: re: [VIEW] Dynamic vs static To: Cyrus Daboo cc: IMAP Extensions Working Group In-Reply-To: <1762514794.933770418@ephesus.cyrusoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Wed, 04 Aug 1999 12:40:18 -0400, Cyrus Daboo wrote: > Well I would like to throw something else into this equation - namely > 'users'. Its all well and good to have this functionality available on > client and server but if its too difficult for the user to use, or doesn't > do what they really want it to, then its not going to be of much use. I'd like to move away from this sort of thinking. VIEW (for that matter, all of IMAP) is not for users to use. It is for client programmers. Users use the client program, *not* a protocol. The usability questions therefore revolve among the programmers. The server programmers must be able to implement it, and the client programmers must be able to use it. The client programmers also have the task of developing an interface for the users that the users can use; the question is then whether or not VIEW assists them in this goal and which proposed flavor of VIEW does so the best. That's quite different from how easy it is for users to use VIEW, or whether VIEW does what users want. I contend that these concerns are irrelevant, and have the risk of leading people down the garden path of designing less predictable "fuzzy" functionality into a protocol. That, in turn, ultimately renders the protocol less useful for clients with different designs. From owner-ietf-imapext Wed Aug 4 11:15:55 1999 Received: by mail.proper.com (8.9.3/8.9.3) id LAA00576 for ietf-imapext-bks; Wed, 4 Aug 1999 11:15:55 -0700 (PDT) Received: from resnick1.qualcomm.com (resnick1.qualcomm.com [206.139.85.98]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA00572 for ; Wed, 4 Aug 1999 11:15:53 -0700 (PDT) Received: from resnick2.qualcomm.com (206.139.85.99) by resnick1.qualcomm.com with ESMTP (Eudora Internet Mail Server 3.0a13); Wed, 4 Aug 1999 13:18:42 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: References: X-Mailer: Eudora [Macintosh version 4.2b??] Date: Wed, 4 Aug 1999 13:18:36 -0500 To: Mark Crispin From: Pete Resnick Subject: re: [VIEW] Dynamic vs static Cc: Cyrus Daboo , IMAP Extensions Working Group Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On 8/4/99 at 10:27 AM -0700, Mark Crispin wrote: >The client programmers also have the task of developing an interface for the >users that the users can use; the question is then whether or not VIEW assists >them in this goal and which proposed flavor of VIEW does so the best. > >That's quite different from how easy it is for users to use VIEW, or whether >VIEW does what users want. I contend that these concerns are irrelevant... I think Cyrus is just conflating some terms here, but his concerns are valid: We need to design the protocol so that the *semantics* of what the user wants to do are reflected in the *semantics* of the protocol. That's how we get VIEW to "assist" client programmers in their goal of implementing what the user wants. If you can't map the semantics of the protocol onto the semantics of the user action, then either you can't implement the user action, or it has to be done in an extra-protocol way (i.e., more work for the implementor, and potentially introducing interoperability problems). Personally, I think because of the above, static VIEW is just a non-starter. My guess is that some people will want to implement semi-dynamic and some will want to implement fully-dynamic and it actually doesn't make much of a difference to client writers which one the server implements so long as it can find out which one it is. pr -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (619)651-4478, Fax: (619)651-1102 From owner-ietf-imapext Thu Aug 5 07:30:26 1999 Received: by mail.proper.com (8.9.3/8.9.3) id HAA23324 for ietf-imapext-bks; Thu, 5 Aug 1999 07:30:26 -0700 (PDT) Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [198.81.209.6]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA23320 for ; Thu, 5 Aug 1999 07:30:25 -0700 (PDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw2.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id KAA127940 for ; Thu, 5 Aug 1999 10:33:14 -0400 Received: from watson.ibm.com (mars.watson.ibm.com [9.2.2.58]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with ESMTP id KAA20608 for ; Thu, 5 Aug 1999 10:31:58 -0400 Message-ID: <37A9A05E.C55D1BD4@watson.ibm.com> Date: Thu, 05 Aug 1999 10:31:58 -0400 From: Barry Leiba Organization: Internet Messaging Technology; TR2_Xagent=WATSON X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: IMAP Extensions Working Group Subject: Re: [VIEW] Dynamic vs static References: <1763129668.933771032@ephesus.cyrusoft.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: What I'm saying is basically the same as what Mark is saying... VIEW can perfectly well do things that affect how the *client* sees things without having to affect how the *user* sees things. In particular... Cyrus Daboo wrote: > Right, but from then on the client has to go through a complex procedure > for figuring out which messages are in its display list and are part of the > server view and which are not part of the server view. So if a user selects > all the messages and then does a delete, the client ends up having to issue > two commands to delete the message: 'VIEW STORE' for messages in the server > view, and 'UID STORE' for messages outside the server view. Yes, but it only has to do that for messages that it's been told have been removed from the view. That's not terrible, and not particularly "complex". And to my mind it's sensible. The client needs to be able to deal with these issues anyway if it wants to seamlessly reconnect after a communication problem. Simple enough to do: when the server tells you that a message was removed from the view, you set a flag on that message. Whenever you need to do anything with that message, you now use the UID instead of the view position. What's the big deal? > There is another option that I didn't mention in my first port on this, and > that is the possibility of allowing both dynamic and static views but have > the client decide when the VIEW is set which it wants. I could implement this, but I'd rather not; it seems more involved than necessary. I'd rather define the view semantics clearly and distinctly. One disagreement with Mark on this, BTW: > (3) is a big pain for servers. No... (3) is a big pain for *some* servers, and for the UW server in particular, perhaps. As it turns out, all three options are equally easy for me to implement in my server; it falls out of the "view" that's already designed in. I suspect that server implementations will vary as to which ones are easier or harder to do. Barry Leiba, Internet Messaging Technology (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba From owner-ietf-imapext Thu Aug 5 09:36:14 1999 Received: by mail.proper.com (8.9.3/8.9.3) id JAA26549 for ietf-imapext-bks; Thu, 5 Aug 1999 09:36:14 -0700 (PDT) Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA26545 for ; Thu, 5 Aug 1999 09:36:12 -0700 (PDT) Message-Id: <4.2.0.58.19990805093230.00a09b60@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 05 Aug 1999 09:36:43 -0700 To: ietf-imapext@imc.org From: Paul Hoffman / IMC Subject: New version of the ID draft In-Reply-To: <37A9A05E.C55D1BD4@watson.ibm.com> References: <1763129668.933771032@ephesus.cyrusoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Greetings. I just discovered that I had not put the ID draft on the list of extensions on the web page at . Given that the -03 version just came out, this is a tad late, but at least I got it there now. If you know of any other drafts that should be listed on that page, please let me know. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-imapext Thu Aug 5 11:05:27 1999 Received: by mail.proper.com (8.9.3/8.9.3) id LAA29715 for ietf-imapext-bks; Thu, 5 Aug 1999 11:05:27 -0700 (PDT) Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [198.81.209.6]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA29702 for ; Thu, 5 Aug 1999 11:05:26 -0700 (PDT) Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id OAA55406 for ; Thu, 5 Aug 1999 14:05:43 -0400 Received: from aspen.watson.ibm.com (aspen.watson.ibm.com [9.2.3.31]) by mailhub1.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id OAA07550 for ; Thu, 5 Aug 1999 14:04:27 -0400 Received: from BALLYB by aspen.watson.ibm.com (IBM OS/2 SENDMAIL VERSION 2.0/ISSC1.0) id OAA022.04; Thu, 5 Aug 1999 14:04:15 -0400 From: Wolfgang Segmuller Date: Thu, 5 Aug 1999 14:04:18 -0400 To: IMAP Working Group Subject: [View] Interactions with select Message-ID: X-Mailer: Execmail for Win32 Version 5.0 Build (41) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii"; name="ipm.txt" Content-Disposition: inline; filename="ipm.txt" Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: If a view is active and a select is issued, what is the status of the view. Is the last view still in effect. I think that this should be clearly spelled out in the proposal. Which way doesn't matter, but I would like to see select cancel a view. Wolfgang From owner-ietf-imapext Thu Aug 5 11:09:12 1999 Received: by mail.proper.com (8.9.3/8.9.3) id LAA29930 for ietf-imapext-bks; Thu, 5 Aug 1999 11:09:12 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (johan@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA29925 for ; Thu, 5 Aug 1999 11:09:11 -0700 (PDT) Date: Thu, 5 Aug 1999 11:09:18 -0700 (PDT) From: Mark Crispin Subject: re: [View] Interactions with select To: Wolfgang Segmuller cc: IMAP Working Group In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Thu, 5 Aug 1999 14:04:18 -0400, Wolfgang Segmuller wrote: > I think that this should be clearly spelled out in the proposal. Which way > doesn't matter, but I would like to see select cancel a view. I agree! From owner-ietf-imapext Thu Aug 5 11:19:40 1999 Received: by mail.proper.com (8.9.3/8.9.3) id LAA00297 for ietf-imapext-bks; Thu, 5 Aug 1999 11:19:40 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA00293 for ; Thu, 5 Aug 1999 11:19:38 -0700 (PDT) Received: from sardis.cyrusoft.com (sardis.cyrusoft.com [206.31.218.203]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id OAA12364; Thu, 5 Aug 1999 14:18:57 -0400 (EDT) Date: Thu, 05 Aug 1999 14:21:29 -0400 From: Cyrus Daboo To: Mark Crispin , Wolfgang Segmuller cc: IMAP Working Group Subject: re: [View] Interactions with select Message-ID: <934558.3142851689@sardis.cyrusoft.com> In-Reply-To: Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431 X-Mailer: Mulberry (MacOS) [2.0.0a4, s/n S1-000001] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: --On Thu, Aug 5, 1999 11:09 AM -0700 Mark Crispin wrote: >> I think that this should be clearly spelled out in the proposal. Which >> way doesn't matter, but I would like to see select cancel a view. > > I agree! Agreed, a SELECT or EXAMINE will reset any VIEW in effect at the time. I will ensure this is clearly spelled out in the next revision of the draft. -- Cyrus From owner-ietf-imapext Tue Aug 10 15:45:08 1999 Received: by mail.proper.com (8.9.3/8.9.3) id PAA15289 for ietf-imapext-bks; Tue, 10 Aug 1999 15:45:08 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA15285 for ; Tue, 10 Aug 1999 15:45:07 -0700 (PDT) Received: from elvira.innosoft.com ([192.160.253.135]) by INNOSOFT.COM (PMDF V5.2-32 #30494) with ESMTPS id <01JELVWBKWBA99E143@INNOSOFT.COM> for ietf-imapext@imc.org; Tue, 10 Aug 1999 15:44:29 PDT Received: from CONVERSION-DAEMON by elvira.innosoft.com (PMDF V5.2-32 #13579) id <0FG900F01TP43G@elvira.innosoft.com> for ietf-imapext@imc.org; Tue, 10 Aug 1999 15:41:28 -0700 (PDT) Received: from elwood.innosoft.com (ELWOOD.INNOSOFT.COM [192.160.253.235]) by elvira.innosoft.com (PMDF V5.2-32 #13579) with SMTP id <0FG900MWYTP40Z@elvira.innosoft.com> for ietf-imapext@imc.org; Tue, 10 Aug 1999 15:41:28 -0700 (PDT) Date: Tue, 10 Aug 1999 15:43:27 -0700 (PDT) From: Chris Newman Subject: [VIEW] Unsolicited response rules Originator-info: login-id=chris; server=THOR.INNOSOFT.COM To: IMAP Extensions Working Group Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Sorry I haven't been involved in this discussion until now and couldn't make it to Oslo. FWIW, I support the general VIEW approach and feel a bit more comfortable with it than with the modified SELECT. One subtlety which hasn't been addressed carefully is the rules for unsolicited responses. The rules for EXPUNGE responses need to be adjusted: An EXPUNGE reponse MUST NOT be sent when no command is in progress; nor while responding to a FETCH, STORE, SEARCH, VIEW FETCH, VIEW STORE or VIEW SEARCH. I'm wondering whether "VIEW SET" should also be in this list. If we don't add the "VIEW SELECT" feature, I'd say it has to be added. Otherwise I'm unsure. The rules for the VIEW responses is that they can not occur during a VIEW FETCH, VIEW STORE, or VIEW SEARCH. A VIEW response doesn't have any negative impact on a regular FETCH/STORE/SEARCH and certainly not on a UID FETCH/STORE/SEARCH. - Chris From owner-ietf-imapext Tue Aug 10 16:32:23 1999 Received: by mail.proper.com (8.9.3/8.9.3) id QAA16085 for ietf-imapext-bks; Tue, 10 Aug 1999 16:32:23 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA16081 for ; Tue, 10 Aug 1999 16:32:22 -0700 (PDT) Received: from elvira.innosoft.com ([192.160.253.135]) by INNOSOFT.COM (PMDF V5.2-32 #30494) with ESMTPS id <01JELXK4MJG299E25O@INNOSOFT.COM> for ietf-imapext@imc.org; Tue, 10 Aug 1999 16:31:55 PDT Received: from CONVERSION-DAEMON by elvira.innosoft.com (PMDF V5.2-32 #13579) id <0FG900K01VW7ZU@elvira.innosoft.com> for ietf-imapext@imc.org; Tue, 10 Aug 1999 16:28:56 -0700 (PDT) Received: from elwood.innosoft.com (ELWOOD.INNOSOFT.COM [192.160.253.235]) by elvira.innosoft.com (PMDF V5.2-32 #13579) with SMTP id <0FG900MY6VW70Z@elvira.innosoft.com> for ietf-imapext@imc.org; Tue, 10 Aug 1999 16:28:55 -0700 (PDT) Date: Tue, 10 Aug 1999 16:30:52 -0700 (PDT) From: Chris Newman Subject: Re: [VIEW] Dynamic vs static In-reply-to: <37A9A05E.C55D1BD4@watson.ibm.com> Originator-info: login-id=chris; server=THOR.INNOSOFT.COM To: IMAP Extensions Working Group Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: I'm really torn on the dynamic vs. static issue. The "static view" model is an order of magnitude easier and more efficient to implement on the server. But it clearly doesn't meet the needs of a client. The "semi-dynamic view" model is easier for a server to implement (as flag-change notifications don't have to update the view mapping), and seems to be closer to what most clients seem to want. But if the connection is dropped there is no way for the client to reconnect and get back to the same server state. That makes the engineer in me cringe, but I'm not sure it's a show-stopper. The "fully-dynamic view" model forces a "semi-dynamic" client to keep a UID-VIEW mapping for messages it's presented to the user. That mapping also allows it to gracefully deal with a server disconnect/reconnect situation. Furthermore if a client disconnects, reconnects, and re-issues the SELECT and VIEW SET commands, then the protocol state is the same as if the client had stayed connected. That "feels" better. Unfortunately, I think the bulk of the strong arguments seem to be leaning in the direction of the "semi-dynamic view" model, and perhaps that is "good enough" to get deployed and solve the problem. - Chris From owner-ietf-imapext Tue Aug 10 16:55:49 1999 Received: by mail.proper.com (8.9.3/8.9.3) id QAA16426 for ietf-imapext-bks; Tue, 10 Aug 1999 16:55:49 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA16420 for ; Tue, 10 Aug 1999 16:55:48 -0700 (PDT) Received: from elvira.innosoft.com ([192.160.253.135]) by INNOSOFT.COM (PMDF V5.2-32 #30494) with ESMTPS id <01JELYDXO7SU99E143@INNOSOFT.COM> for ietf-imapext@imc.org; Tue, 10 Aug 1999 16:55:10 PDT Received: from CONVERSION-DAEMON by elvira.innosoft.com (PMDF V5.2-32 #13579) id <0FG900001WYZL2@elvira.innosoft.com> for ietf-imapext@imc.org; Tue, 10 Aug 1999 16:52:11 -0700 (PDT) Received: from elwood.innosoft.com (ELWOOD.INNOSOFT.COM [192.160.253.235]) by elvira.innosoft.com (PMDF V5.2-32 #13579) with SMTP id <0FG900M0JWYY7B@elvira.innosoft.com>; Tue, 10 Aug 1999 16:52:11 -0700 (PDT) Date: Tue, 10 Aug 1999 16:54:10 -0700 (PDT) From: Chris Newman Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt In-reply-to: <37781577.37D9BAF1@maillennium.att.com> Originator-info: login-id=chris; server=THOR.INNOSOFT.COM To: steve spear Cc: IMAP Extensions Working Group Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Tue, 29 Jun 1999, steve spear wrote: > Can someone explain how traffic is reduced by SORT over clients that are > caching the headers and simply request messages headers they haven't seen > before? While I think a full disconnected-model IMAP client makes sense for a user's "primary mail reading machine" (I'm just waiting for a client vendor to implemented background cache updating :-), there is a high demand both for "kiosk" model usage (where a machine doesn't have a primary user) and for "travel" usage (where a user is away from their primary machine, and perhaps using someone else's primary machine). In both cases a proper cache doesn't exist, so the VIEW SORT model allows the client to download just what it needs rather than to populate a cache which it will just have to discard. One could argue that "web mail" products suffice for kiosk and travelling users, but I'm dubious of their scalability, let alone their usability. > As Tony Hansen pointed out - AT&T is trying to handle many millions > of users. The thought of using more resources on the server instead of the > clients that are largely idle is a concern of ours. I think it's important to note that CPU speed, disk space, RAM, server performance and client performance all are increasing by Moore's law. Network bandwidth and throughput between client&server are not, and if wireless continues to become more popular, average network bandwidth may *drop* from current levels. - Chris From owner-ietf-imapext Tue Aug 10 19:30:20 1999 Received: by mail.proper.com (8.9.3/8.9.3) id TAA00855 for ietf-imapext-bks; Tue, 10 Aug 1999 19:30:20 -0700 (PDT) Received: from sttlpop1.sttl.uswest.net (sttlpop1.sttl.uswest.net [206.81.192.1]) by mail.proper.com (8.9.3/8.9.3) with SMTP id TAA00849 for ; Tue, 10 Aug 1999 19:30:19 -0700 (PDT) Received: (qmail 18968 invoked by alias); 11 Aug 1999 02:30:42 -0000 Delivered-To: fixup-ietf-imapext@imc.org@fixme Received: (qmail 18914 invoked by uid 0); 11 Aug 1999 02:30:41 -0000 Received: from mdsl227.sttl.uswest.net (209.181.94.228) by sttlpop1.sttl.uswest.net with SMTP; 11 Aug 1999 02:30:41 -0000 Date: Tue, 10 Aug 1999 19:30:27 -0700 (Pacific Daylight Time) From: Terry Gray To: Chris Newman cc: steve spear , IMAP Extensions Working Group Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt In-Reply-To: Message-ID: Organization: University of Washington; Computing & Communications X-X-Sender: gray@shivams.cac.washington.edu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: I'll just add that folks who have no "primary" machine, but rather routinely use two or three different computers every day, may prefer clients that operate in "kiosk" mode rather than suffer with the startup and resynch delays that seem to go with many of today's offline and disconnected clients... (certainly I do! :) -teg On Tue, 10 Aug 1999, Chris Newman wrote: > On Tue, 29 Jun 1999, steve spear wrote: > > Can someone explain how traffic is reduced by SORT over clients that are > > caching the headers and simply request messages headers they haven't seen > > before? > > While I think a full disconnected-model IMAP client makes sense for a > user's "primary mail reading machine" (I'm just waiting for a client > vendor to implemented background cache updating :-), there is a high > demand both for "kiosk" model usage (where a machine doesn't have a > primary user) and for "travel" usage (where a user is away from their > primary machine, and perhaps using someone else's primary machine). In > both cases a proper cache doesn't exist, so the VIEW SORT model allows the > client to download just what it needs rather than to populate a cache > which it will just have to discard. > > One could argue that "web mail" products suffice for kiosk and travelling > users, but I'm dubious of their scalability, let alone their usability. (etc) From owner-ietf-imapext Tue Aug 10 20:15:22 1999 Received: by mail.proper.com (8.9.3/8.9.3) id UAA05243 for ietf-imapext-bks; Tue, 10 Aug 1999 20:15:22 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (clane@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id UAA05236 for ; Tue, 10 Aug 1999 20:15:21 -0700 (PDT) Date: Tue, 10 Aug 1999 20:15:40 -0700 (PDT) From: Mark Crispin To: Chris Newman cc: steve spear , IMAP Extensions Working Group Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt In-Reply-To: Message-ID: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Tue, 10 Aug 1999, Chris Newman wrote: > While I think a full disconnected-model IMAP client makes sense for a > user's "primary mail reading machine" (I'm just waiting for a client > vendor to implemented background cache updating :-), there is a high > demand both for "kiosk" model usage (where a machine doesn't have a > primary user) and for "travel" usage (where a user is away from their > primary machine, and perhaps using someone else's primary machine). Let's put it this way. I find *all* of the full disconnected-model IMAP clients to be intolerable. The only tolerable clients are those which permit turning off the disconnected-model. On a fast network, it's a completely unnecessary waste of client disk space. On a slow network, the first open of a 5000 message mailbox is ridiculously slow. > wireless continues to become more popular, average network bandwidth may > *drop* from current levels. Speaking as one who uses wireless a *lot*, I'm amazed at how well online model Pine performs, and how terribly disconnected model clients perform. -- Mark -- * RCW 19.190 notice: This email address is located in Washington State. * * Unsolicited commercial email may be billed $500 per message. * Science does not emerge from voting, party politics, or public debate. From owner-ietf-imapext Tue Aug 10 20:47:35 1999 Received: (from majordomo@localhost) by mail.proper.com (8.9.3/8.9.3) id UAA08676 for ietf-imapext-bks; Tue, 10 Aug 1999 20:47:35 -0700 (PDT) Received: from smtp1.cern.ch (smtp1.cern.ch [137.138.128.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id UAA08664 for ; Tue, 10 Aug 1999 20:47:33 -0700 (PDT) Received: from rsplus15.cern.ch (rsplus15.cern.ch [137.138.246.81]) by smtp1.cern.ch (8.9.3/8.9.3) with ESMTP id FAA23312; Wed, 11 Aug 1999 05:47:28 +0200 (MET DST) Received: from localhost (taddei@localhost) by rsplus15.cern.ch (8.8.5/8.8.5) with ESMTP id FAA136708; Wed, 11 Aug 1999 05:47:27 +0200 X-Authentication-Warning: rsplus15.cern.ch: taddei owned process doing -bs Date: Wed, 11 Aug 1999 05:47:27 +0200 (METDST) From: Arnaud Taddei X-Sender: taddei@rsplus15.cern.ch To: Terry Gray cc: Chris Newman , steve spear , IMAP Extensions Working Group Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Some operational feedback, if in addition you add all the _pathological_ cases like: - the IMAP cache is stored in files *without* locking mechanisms, when you start 2 instances of your clients and your home directory is coming from a central file server you have very nice corruptions (and it seems to be a very difficult message to pass to vendors!!!). It is even worse for the addressbook but this is a different _acap_/_ldap_ story. - corruptions of the local IMAP cache lead to a wide spectra of side effects - problems of synchronisation between the local cache with the subscription to folders model when you use other clients - problems due to the access to the disks of PCs which happens too often (we had very interesting surprises when we inspeceted fragmentation rate of users PC disks). This _slows_ down programs! - no button provided to users to force a resynchronisation between what is on the server and your cache So yes please anything which can be done to remove the local IMAP cache can only help by making sure the solution is to some extend truly location independent (we have 50,000 physicists travelling with all possible patterns and demands) and remove a wide range of operational problems. >From our user support team, the corruption of the local IMAP cache is by far the first problem they address on a daily basis for the support of thousands of users and we desigend our own tools and recipes to have quick ways to help users. my $0.01 On Tue, 10 Aug 1999, Terry Gray wrote: > I'll just add that folks who have no "primary" machine, but rather > routinely use two or three different computers every day, may prefer > clients that operate in "kiosk" mode rather than suffer with the startup > and resynch delays that seem to go with many of today's offline and > disconnected clients... (certainly I do! :) > > -teg > > On Tue, 10 Aug 1999, Chris Newman wrote: > > > On Tue, 29 Jun 1999, steve spear wrote: > > > Can someone explain how traffic is reduced by SORT over clients that are > > > caching the headers and simply request messages headers they haven't seen > > > before? > > > > While I think a full disconnected-model IMAP client makes sense for a > > user's "primary mail reading machine" (I'm just waiting for a client > > vendor to implemented background cache updating :-), there is a high > > demand both for "kiosk" model usage (where a machine doesn't have a > > primary user) and for "travel" usage (where a user is away from their > > primary machine, and perhaps using someone else's primary machine). In > > both cases a proper cache doesn't exist, so the VIEW SORT model allows the > > client to download just what it needs rather than to populate a cache > > which it will just have to discard. > > > > One could argue that "web mail" products suffice for kiosk and travelling > > users, but I'm dubious of their scalability, let alone their usability. > > (etc) > > ------------------------------------------------------------ Arnaud Taddei tel: +41 22 767 9349 IT Division 31 1-016 fax: +41 22 767 7155 CERN mail: Arnaud.Taddei@cern.ch CH-1211 Geneve 23 URL: http://home.cern.ch/taddei ------------------------------------------------------------ From owner-ietf-imapext Tue Aug 10 20:51:39 1999 Received: by mail.proper.com (8.9.3/8.9.3) id UAA09249 for ietf-imapext-bks; Tue, 10 Aug 1999 20:51:39 -0700 (PDT) Received: from smtp1.cern.ch (smtp1.cern.ch [137.138.128.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id UAA09241 for ; Tue, 10 Aug 1999 20:51:37 -0700 (PDT) Received: from rsplus15.cern.ch (rsplus15.cern.ch [137.138.246.81]) by smtp1.cern.ch (8.9.3/8.9.3) with ESMTP id FAA24523; Wed, 11 Aug 1999 05:51:33 +0200 (MET DST) Received: from localhost (taddei@localhost) by rsplus15.cern.ch (8.8.5/8.8.5) with ESMTP id FAA153788; Wed, 11 Aug 1999 05:51:32 +0200 X-Authentication-Warning: rsplus15.cern.ch: taddei owned process doing -bs Date: Wed, 11 Aug 1999 05:51:32 +0200 (METDST) From: Arnaud Taddei X-Sender: taddei@rsplus15.cern.ch To: Mark Crispin cc: Chris Newman , steve spear , IMAP Extensions Working Group Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Just for the anectdote try to oppen a 50,000 mailbox created by a user mail loop with, say, pine and Netscape or Outlook ... fortunately we have the robust, non caching, pine program with the 2 others this is nearly impossible to even get the cursor back after opening the folder. On Tue, 10 Aug 1999, Mark Crispin wrote: > On Tue, 10 Aug 1999, Chris Newman wrote: > > While I think a full disconnected-model IMAP client makes sense for a > > user's "primary mail reading machine" (I'm just waiting for a client > > vendor to implemented background cache updating :-), there is a high > > demand both for "kiosk" model usage (where a machine doesn't have a > > primary user) and for "travel" usage (where a user is away from their > > primary machine, and perhaps using someone else's primary machine). > > Let's put it this way. I find *all* of the full disconnected-model IMAP > clients to be intolerable. The only tolerable clients are those which > permit turning off the disconnected-model. > > On a fast network, it's a completely unnecessary waste of client disk > space. On a slow network, the first open of a 5000 message mailbox is > ridiculously slow. > > > wireless continues to become more popular, average network bandwidth may > > *drop* from current levels. > > Speaking as one who uses wireless a *lot*, I'm amazed at how well online > model Pine performs, and how terribly disconnected model clients perform. > > -- Mark -- > > * RCW 19.190 notice: This email address is located in Washington State. * > * Unsolicited commercial email may be billed $500 per message. * > Science does not emerge from voting, party politics, or public debate. > > ------------------------------------------------------------ Arnaud Taddei tel: +41 22 767 9349 IT Division 31 1-016 fax: +41 22 767 7155 CERN mail: Arnaud.Taddei@cern.ch CH-1211 Geneve 23 URL: http://home.cern.ch/taddei ------------------------------------------------------------ From owner-ietf-imapext Wed Aug 11 17:06:19 1999 Received: by mail.proper.com (8.9.3/8.9.3) id RAA19086 for ietf-imapext-bks; Wed, 11 Aug 1999 17:06:19 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA19082 for ; Wed, 11 Aug 1999 17:06:18 -0700 (PDT) Received: from elvira.innosoft.com ([192.160.253.135]) by INNOSOFT.COM (PMDF V5.2-32 #30494) with ESMTPS id <01JEND1ETIB699E1ZE@INNOSOFT.COM> for ietf-imapext@imc.org; Wed, 11 Aug 1999 17:05:46 PDT Received: from CONVERSION-DAEMON by elvira.innosoft.com (PMDF V5.2-32 #13579) id <0FGB00E01S4KDM@elvira.innosoft.com> for ietf-imapext@imc.org; Wed, 11 Aug 1999 17:02:45 -0700 (PDT) Received: from elwood.innosoft.com (ELWOOD.INNOSOFT.COM [192.160.253.235]) by elvira.innosoft.com (PMDF V5.2-32 #13579) with SMTP id <0FGB0024PS4K4X@elvira.innosoft.com>; Wed, 11 Aug 1999 17:02:44 -0700 (PDT) Date: Wed, 11 Aug 1999 17:04:42 -0700 (PDT) From: Chris Newman Subject: Re: Annotations: alternate data model In-reply-to: <379F2211.752FB85E@pwd.hp.com> Originator-info: login-id=chris; server=THOR.INNOSOFT.COM To: IMAP Extensions Working Group Cc: francis@ecal.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Wed, 28 Jul 1999, John Haxby wrote: > > I've been using XML in some projects here and like a lot of its > > features. We did have to do something about representing binary values > > within XML, but otherwise are fairly pleased with XML as a data > > representation language. > > I have to agree here. > > It's certainly a lot easier to get to grips with than ASN.1! I have to say that "use XML instead" is the correct response to anyone who is trying to use ASN.1. XML is and order of magnitude simpler than ASN.1, plus it's trendier and has more tools (the latter two being the only important issues to someone considering ASN.1). However, within the IMAP protocol, I prefer that we stick to the data encoding scheme described in section 4 of RFC 2060. It's at least an order of magnitude simpler than XML and all IMAP servers and clients already implement it. - Chris From owner-ietf-imapext Wed Aug 11 17:37:37 1999 Received: by mail.proper.com (8.9.3/8.9.3) id RAA19487 for ietf-imapext-bks; Wed, 11 Aug 1999 17:37:37 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA19483 for ; Wed, 11 Aug 1999 17:37:36 -0700 (PDT) Received: from elvira.innosoft.com ([192.160.253.135]) by INNOSOFT.COM (PMDF V5.2-32 #30494) with ESMTPS id <01JENE57C5NC99E1ZE@INNOSOFT.COM> for ietf-imapext@imc.org; Wed, 11 Aug 1999 17:37:03 PDT Received: from CONVERSION-DAEMON by elvira.innosoft.com (PMDF V5.2-32 #13579) id <0FGB00I01TKR3A@elvira.innosoft.com> for ietf-imapext@imc.org; Wed, 11 Aug 1999 17:34:03 -0700 (PDT) Received: from elwood.innosoft.com (ELWOOD.INNOSOFT.COM [192.160.253.235]) by elvira.innosoft.com (PMDF V5.2-32 #13579) with SMTP id <0FGB0025LTKQ4X@elvira.innosoft.com>; Wed, 11 Aug 1999 17:34:03 -0700 (PDT) Date: Wed, 11 Aug 1999 17:36:02 -0700 (PDT) From: Chris Newman Subject: transcoding service (was Re: Oslo WG meeting notes) In-reply-to: <379864EC.3ADE8DF4@watson.ibm.com> Originator-info: login-id=chris; server=THOR.INNOSOFT.COM To: Barry Leiba Cc: IMAP Extensions Working Group Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Fri, 23 Jul 1999, Barry Leiba wrote: > > > > *** Transcoding Request > > > > - assertion that there are substantial interoperability issues > > > > - better dealt with by picking standardized represention of content-type > > > > The concensus was that expecting servers to implement elaborate > > transcoding facilities, it would be much better if the VPIM folks could > > settle on a reasonable small set of mandatory or recommended to implement. > > ... > > I think it's useful to have such capability, and I think it's worth discussing > how we might do it in an interoperable way. The tough bits will be defining > the various transcodings that can be done, how to list them, how to specify > them, how to add more, and so on. The basic mechanism shouldn't be terribly > controversial. Actually, I'm 100% opposed to including any transcoding services (beyond removal of standard content-transfer-encodings) in IMAP itself. Transcoding is a general facility which could be applied to data coming from a mail store, web server, ftp site or any other source. Functional modularity suggests that IMAP has no business performing such a general purpose service. Given that, here's how I'd address the transcoding problem with respect to IMAP. The same approach could apply to the recurring issue of forwarding a message via an SMTP SUBMIT server without downloading it to a client. Add a simple extension to the IMAP server which allows a MIME entity (or message) to be accessed by an external service. This extension would return a URL to that MIME entity. Here's a very rough strawman: tag EXPORT "["[body-part-number]"]" * EXPORT [body-part-number] "imap://@/Joe/;uid=10/;section=[body-part-number]" Then the client can simply pass that URL to the transcoding service (or SMTP SUBMIT server) which can then log in to the IMAP server and access the body part(s). There a number of subtleties, especially related to security and persistance, but I think the general idea is workable. If all the details are nailed down correctly, then the transcoding server could come from a different vendor than the IMAP server and it would all interoperate. Given that transcoding expertise and IMAP server expertise are *very* different I think that's exactly as it should be. If efficiency is an issue, just co-locate the transcoding server with the IMAP server and document an efficient "IMAP export" API. - Chris From owner-ietf-imapext Wed Aug 11 22:50:53 1999 Received: (from majordomo@localhost) by mail.proper.com (8.9.3/8.9.3) id WAA18148 for ietf-imapext-bks; Wed, 11 Aug 1999 22:50:53 -0700 (PDT) Received: from mailgw1.netvision.net.il (mailgw1.netvision.net.il [194.90.1.14]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id WAA18140 for ; Wed, 11 Aug 1999 22:50:51 -0700 (PDT) Received: from goofy-ex.icomverse.com (efratgw.icomverse.com [199.203.140.6]) by mailgw1.netvision.net.il (8.9.3/8.9.3) with ESMTP id IAA26830; Thu, 12 Aug 1999 08:51:13 +0300 Received: by GOOFY_EX.QUANTUM.icomverse.com with Internet Mail Service (5.5.2448.0) id ; Thu, 12 Aug 1999 08:51:18 +0300 Message-ID: <5C5BA40F28F1D211AAE200105A057CB01C585B@GOOFY_EX.QUANTUM.icomverse.com> From: "Neystadt, John" To: "'Chris Newman'" Cc: IMAP Extensions Working Group Subject: RE: transcoding service (was Re: Oslo WG meeting notes) Date: Thu, 12 Aug 1999 08:51:15 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Chris, how would you solve the following scenario: 1. You have a voice mail system with proprietry transcoding. 2. Transcoding is a versy expensive (CPU) action. 2. There are some smart clients that are able to process messages of proprietry transcoding. 3. All other clients should get the messages transcoded to a standard one. For backward compatibility you can't require them to specify transcoding, sine today's Netscape or Outlook don't do it. John Neystadt john@neystadt.org http://www.neystadt.org/john/ > -----Original Message----- > From: Chris Newman [mailto:Chris.Newman@INNOSOFT.COM] > Sent: Thursday, August 12, 1999 3:36 AM > To: Barry Leiba > Cc: IMAP Extensions Working Group > Subject: transcoding service (was Re: Oslo WG meeting notes) > > > On Fri, 23 Jul 1999, Barry Leiba wrote: > > > > > *** Transcoding Request > > > > > - assertion that there are substantial interoperability issues > > > > > - better dealt with by picking standardized > represention of content-type > > > > > > The concensus was that expecting servers to implement elaborate > > > transcoding facilities, it would be much better if the > VPIM folks could > > > settle on a reasonable small set of mandatory or > recommended to implement. > > > > ... > > > > I think it's useful to have such capability, and I think > it's worth discussing > > how we might do it in an interoperable way. The tough bits > will be defining > > the various transcodings that can be done, how to list > them, how to specify > > them, how to add more, and so on. The basic mechanism > shouldn't be terribly > > controversial. > > Actually, I'm 100% opposed to including any transcoding > services (beyond > removal of standard content-transfer-encodings) in IMAP itself. > Transcoding is a general facility which could be applied to > data coming > from a mail store, web server, ftp site or any other source. > Functional > modularity suggests that IMAP has no business performing such > a general > purpose service. > > Given that, here's how I'd address the transcoding problem > with respect to > IMAP. The same approach could apply to the recurring issue > of forwarding > a message via an SMTP SUBMIT server without downloading it to > a client. > > Add a simple extension to the IMAP server which allows a MIME > entity (or > message) to be accessed by an external service. This extension would > return a URL to that MIME entity. > > Here's a very rough strawman: > > tag EXPORT "["[body-part-number]"]" > * EXPORT [body-part-number] > > "imap://@/Joe/;uid=10/;section=[body-par > t-number]" > > Then the client can simply pass that URL to the transcoding > service (or > SMTP SUBMIT server) which can then log in to the IMAP server > and access > the body part(s). There a number of subtleties, especially related to > security and persistance, but I think the general idea is workable. > > If all the details are nailed down correctly, then the > transcoding server > could come from a different vendor than the IMAP server and > it would all > interoperate. Given that transcoding expertise and IMAP > server expertise > are *very* different I think that's exactly as it should be. If > efficiency is an issue, just co-locate the transcoding server with the > IMAP server and document an efficient "IMAP export" API. > > - Chris > From owner-ietf-imapext Thu Aug 12 01:20:11 1999 Received: by mail.proper.com (8.9.3/8.9.3) id BAA24269 for ietf-imapext-bks; Thu, 12 Aug 1999 01:20:11 -0700 (PDT) Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id BAA24264 for ; Thu, 12 Aug 1999 01:20:09 -0700 (PDT) Received: from hpopd.pwd.hp.com (hpopd.pwd.hp.com [15.145.205.59]) by palrel3.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id BAA25157; Thu, 12 Aug 1999 01:20:35 -0700 (PDT) Received: from pwd.hp.com (ilex.pwd.hp.com [15.145.204.106]) by hpopd.pwd.hp.com (8.8.6 (PHNE_15509)/8.8.6 CMSO Openmail) with ESMTP id JAA13980; Thu, 12 Aug 1999 09:20:34 +0100 (BST) Message-ID: <37B283D1.910DD87C@pwd.hp.com> Date: Thu, 12 Aug 1999 09:20:33 +0100 From: John Haxby X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-imapext@imc.org CC: Chris.Newman@INNOSOFT.COM Subject: Re: Annotations: alternate data model References: Content-Type: multipart/mixed; boundary="------------1EAC61DE18969975CE948B2B" Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: This is a multi-part message in MIME format. --------------1EAC61DE18969975CE948B2B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Chris.Newman@INNOSOFT.COM wrote: > > I have to say that "use XML instead" is the correct response to anyone who > is trying to use ASN.1. XML is and order of magnitude simpler than ASN.1, > plus it's trendier and has more tools (the latter two being the only > important issues to someone considering ASN.1). > I'd stick to the "trendier" bit ... :-) > > However, within the IMAP protocol, I prefer that we stick to the data > encoding scheme described in section 4 of RFC 2060. It's at least an > order of magnitude simpler than XML and all IMAP servers and clients > already implement it. That's all well and good, but you then need a means of describing what goes in the parenthesised lists and how new annotations can be added and handled by clients. Where XML wins here is that the syntax deals with handling the unknown almost automatically. For example, the DTD could say that an annotation looks like ... anything you like here so long as it's valid XML ... The definition of the "xyzzy" annotation could then extend the DTD to encompass its own stuff. One could do this for IMAP's parenthesised lists, but first of all you'd have to agree a common framework into which the annotations could be dropped, and then you'd have to agree a common structure to which all annotation types must adhere (so that they can at least be read, if not understood), and then .... Well, there's still the problem of those clients and servers that *still* (after all this time) make a dog's dinner of handling literal strings. jch --------------1EAC61DE18969975CE948B2B Content-Type: text/x-vcard; charset=us-ascii; name="jch.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for John Haxby Content-Disposition: attachment; filename="jch.vcf" begin:vcard n:Haxby;John tel;work:+44 1344 763711 x-mozilla-html:FALSE url:http://www.hp.com/go/OpenMail org:Hewlett Packard;OpenMail R&D adr:;;Nine Mile Ride;Wokingham;Berks;RG40 3LL;England version:2.1 email;internet:jch@pwd.hp.com x-mozilla-cpt:;14976 fn:John Haxby end:vcard --------------1EAC61DE18969975CE948B2B-- From owner-ietf-imapext Thu Aug 12 10:36:43 1999 Received: by mail.proper.com (8.9.3/8.9.3) id KAA06463 for ietf-imapext-bks; Thu, 12 Aug 1999 10:36:43 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA06459 for ; Thu, 12 Aug 1999 10:36:42 -0700 (PDT) Received: from elvira.innosoft.com ([192.160.253.135]) by INNOSOFT.COM (PMDF V5.2-32 #30494) with ESMTPS id <01JEODPTATKQ99E1ZE@INNOSOFT.COM> for ietf-imapext@imc.org; Thu, 12 Aug 1999 10:36:13 PDT Received: from CONVERSION-DAEMON by elvira.innosoft.com (PMDF V5.2-32 #13579) id <0FGD006014RA99@elvira.innosoft.com> for ietf-imapext@imc.org; Thu, 12 Aug 1999 10:33:11 -0700 (PDT) Received: from nifty-jr.innosoft.com (Nifty-Jr.INNOSOFT.COM [192.160.253.35]) by elvira.innosoft.com (PMDF V5.2-32 #13579) with ESMTP id <0FGD002PW4R84X@elvira.innosoft.com>; Thu, 12 Aug 1999 10:33:09 -0700 (PDT) Date: Thu, 12 Aug 1999 10:34:55 -0700 From: Chris Newman Subject: RE: transcoding service (was Re: Oslo WG meeting notes) In-reply-to: <5C5BA40F28F1D211AAE200105A057CB01C585B@GOOFY_EX.QUANTUM.icomverse.com> Originator-info: login-id=chris; server=thor.innosoft.com To: "Neystadt, John" Cc: IMAP Extensions Working Group Message-id: <180791.3143442895@nifty-jr.innosoft.com> MIME-version: 1.0 X-Mailer: Mulberry (MacOS) [2.0.0a2, s/n S-100003] Content-type: text/plain; charset=us-ascii Content-disposition: inline Content-transfer-encoding: 7BIT Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: The two obvious choices are: (1) at final delivery time, perform the transcoding (since a user isn't waiting) and transform that part into a multipart/alternative. Good IMAP clients will only download the part they can use. (2) use the "EXPORT" facility only when transcoding is needed; the user will just have to wait if the transcoding CPUs are busy. - Chris --On Thu, Aug 12, 1999 8:51 +0300 "Neystadt, John" wrote: > Chris, how would you solve the following scenario: > > 1. You have a voice mail system with proprietry transcoding. > 2. Transcoding is a versy expensive (CPU) action. > 2. There are some smart clients that are able to process messages of > proprietry transcoding. > 3. All other clients should get the messages transcoded to a standard one. > For backward compatibility you can't require them to specify transcoding, > sine today's Netscape or Outlook don't do it. From owner-ietf-imapext Wed Aug 18 20:59:30 1999 Received: (from majordomo@localhost) by mail.proper.com (8.9.3/8.9.3) id UAA19679 for ietf-imapext-bks; Wed, 18 Aug 1999 20:59:30 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (jjs@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id UAA19672 for ; Wed, 18 Aug 1999 20:59:28 -0700 (PDT) Date: Wed, 18 Aug 1999 21:00:32 -0700 (PDT) From: Mark Crispin To: IMAP Extensions WG Subject: SORT and THREAD documents Message-ID: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Apparently, these got delayed because they somehow think that these documents are not part of the IMAPEXT working group, so the Powers That Be objected to them being submitted as draft-ietf-imapext-... Damned if I know why the WG chair didn't educate them to the contrary. We did talk about both of these at some length in Oslo. -- Mark -- * RCW 19.190 notice: This email address is located in Washington State. * * Unsolicited commercial email may be billed $500 per message. * Science does not emerge from voting, party politics, or public debate. ---------- Forwarded message ---------- Date: Thu, 12 Aug 1999 07:06:44 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Subject: I-D ACTION:draft-crispin-imapext-sort-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : INTERNET MESSAGE ACCESS PROTOCOL - SORT EXTENSION Author(s) : M. Crispin Filename : draft-crispin-imapext-sort-00.txt Pages : 8 Date : 11-Aug-99 This document describes an experimental server-based sorting extension to the IMAP4rev1 protocol, as implemented by the University of Washington's IMAP toolkit. This extension provides substantial performance improvements for IMAP clients which offer sorted views. A server which supports this extension indicates this with a capability name of 'SORT'. Client implementations SHOULD accept any capability name which begins with 'SORT' as indicating support for the extension 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-crispin-imapext-sort-00.txt 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-crispin-imapext-sort-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-crispin-imapext-sort-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. ---------- Forwarded message ---------- Date: Thu, 12 Aug 1999 07:06:50 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Subject: I-D ACTION:draft-crispin-imapext-thread-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : INTERNET MESSAGE ACCESS PROTOCOL - THREAD EXTENSION Author(s) : M. Crispin Filename : draft-crispin-imapext-thread-00.txt Pages : 7 Date : 11-Aug-99 This document describes the server-based threading extension to the IMAP4rev1 protocol. This extension provides substantial performance improvements for IMAP clients which offer threaded views. A server which supports this extension indicates this with more 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-crispin-imapext-thread-00.txt 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-crispin-imapext-thread-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-crispin-imapext-thread-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. From owner-ietf-imapext Wed Aug 18 21:54:53 1999 Received: by mail.proper.com (8.9.3/8.9.3) id VAA22483 for ietf-imapext-bks; Wed, 18 Aug 1999 21:54:53 -0700 (PDT) Received: from resnick1.qualcomm.com (resnick1.qualcomm.com [206.139.85.98]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id VAA22478 for ; Wed, 18 Aug 1999 21:54:51 -0700 (PDT) Received: from resnick2.qualcomm.com (206.139.85.99) by resnick1.qualcomm.com with ESMTP (Eudora Internet Mail Server 3.0a14); Wed, 18 Aug 1999 23:55:46 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: References: X-Mailer: Eudora [Macintosh version 4.2b??] Date: Wed, 18 Aug 1999 23:55:39 -0500 To: Mark Crispin From: Pete Resnick Subject: Re: SORT and THREAD documents Cc: IMAP Extensions WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On 8/18/99 at 9:00 PM -0700, Mark Crispin wrote: >Apparently, these got delayed because they somehow think that these >documents are not part of the IMAPEXT working group, so the Powers That Be >objected to them being submitted as draft-ietf-imapext-... > >Damned if I know why the WG chair didn't educate them to the contrary. We >did talk about both of these at some length in Oslo. Damn! I dropped the ball on this one. I was away on vacation when all this went on, and when I came back I didn't get the message off to the I-D editor to put them in the WG namespace. I will do so immediately. Sorry for the inconvenience. Pete: 1 demerit. Mark: 1 gold star for getting the docs in so quickly. pr -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102 From owner-ietf-imapext Wed Aug 18 22:49:29 1999 Received: by mail.proper.com (8.9.3/8.9.3) id WAA24359 for ietf-imapext-bks; Wed, 18 Aug 1999 22:49:29 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (rid@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id WAA24348 for ; Wed, 18 Aug 1999 22:49:28 -0700 (PDT) Date: Wed, 18 Aug 1999 22:50:30 -0700 (PDT) From: Mark Crispin To: Pete Resnick cc: IMAP Extensions WG Subject: Re: SORT and THREAD documents In-Reply-To: Message-ID: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Wed, 18 Aug 1999, Pete Resnick wrote: > Damn! I dropped the ball on this one. I was away on vacation when all > this went on, and when I came back I didn't get the message off to > the I-D editor to put them in the WG namespace. I will do so > immediately. Sorry for the inconvenience. Thanks for the update. You weren't the only one to have been on vacation. What I saw on my end, just before I left on vacation, was a response to the effect that I was not allowed to post ietf-imapext drafts, and that the SORT and THREAD drafts would have to wait until you approved them or some timeout expired at which point they'd be posted as a private draft (which seems to have happened). I always thought that you used the WG name if an active WG was in progress on the specification, and used your name only if there wasn't an active WG. Did they change the policy as a result of some of the recent catfights? If so, perhaps the cure is worse than the disease. Sigh. Anyway, would people please look at the SORT and THREAD drafts and see if they accurately reflect what I described at Oslo. Also, please start thinking about how THREAD would work with VIEW, and about additional standard threading algorithms. Although I'd like to make THREAD=ORDEREDSUBJECT mandatory, I think that a standards-track THREAD needs at least two other algorithms, one to do Message-ID/In-Reply-To and the other to do Message-ID/References. I'd also like for someone (other than me!!) who is familiar with the UW implementation to verify that the THREAD draft accurately describes the UW implementation of THREAD. The purpose of the THREAD document is to document how the UW implementation works (and once confirmed that it does so propose it as our way of doing threading). If there is a contradiction between the document and the UW implementation, the document is the one that needs to be fixed. Another point is that there needs to be a second client and server implementation of THREAD that is shown to interoperate with the UW implementation. Before we even think about pushing THREAD further, we need this. I suspect that we need to get the additional algorithms established too, since ORDEREDSUBJECT threading doesn't do nesting and each message only appears once. We need threaders that break these assumptions. One last thing -- this SORT draft is the *unextended* SORT. It's to document today's status quo. SORT *will* be extended, but not in this document. The sooner we get this document to RFC (as either Experimental or Informational...I'd prefer Informational), the sooner that we can talk about the extensions to produce a standards-track SORT (and VIEW SET SORT). -- Mark -- * RCW 19.190 notice: This email address is located in Washington State. * * Unsolicited commercial email may be billed $500 per message. * Science does not emerge from voting, party politics, or public debate. From owner-ietf-imapext Mon Sep 13 13:28:36 1999 Received: by mail.proper.com (8.9.3/8.9.3) id NAA10571 for ietf-imapext-bks; Mon, 13 Sep 1999 13:28:36 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (terianne@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA10566 for ; Mon, 13 Sep 1999 13:28:35 -0700 (PDT) Date: Mon, 13 Sep 1999 13:15:54 -0700 (PDT) From: Mark Crispin Subject: multi-append To: IMAP Extensions WG Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: I would like to add an extension called MULTIAPPEND. This is an upwards compatible extension to the RFC 2060 APPEND command. A server which advertises the MULTIAPPEND capability permits more than one message in the same append command. In other words, the APPEND grammar becomes: append = "APPEND" SPACE mailbox 1*append_message append_message = [SPACE flag_list] [SPACE date_time] SPACE literal MULTIAPPEND provides the same RTT savings offered by the LITERAL+ extension with the current APPEND. When MULTIAPPEND is used in conjunction with LITERAL+, the entire upload is a single RTT. There is another advantage, which is a major win for my server; the procedure for opening and closing the destination mailbox only needs to be done once instead of per-message. We've determined that for the standard UNIX format of mail, the open/close and lock/unlock overhead is a major part of the overall time spent in multiple appends. I believe that this extension should be non-controversial; it is upwards compatible and is at least a minor win for everybody (because of RTTs) and can potentially be a major win. Does anyone disagree? If not, do we have concensus to put out an ID and give it accelerated approval in the WG (with hopefully minimal discussion) as a Proposed Standard? The one issue of contention may be what happens on a partial failure; e.g. running out of disk quota after several messages but before the last message. I think that consistancy with the rest of IMAP, as well as the impossibility of the client knowing what succeeded and what failed if LITERAL+ is used with this feature, mandates that the entire APPEND fail and the mailbox be reverted to the state prior to the APPEND. From owner-ietf-imapext Mon Sep 13 14:02:48 1999 Received: by mail.proper.com (8.9.3/8.9.3) id OAA10842 for ietf-imapext-bks; Mon, 13 Sep 1999 14:02:48 -0700 (PDT) Received: from sparky.isocor.com (sparky.isocor.com [198.6.228.217]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA10838 for ; Mon, 13 Sep 1999 14:02:41 -0700 (PDT) Received: from erik.isocor.com (198.6.228.71) by sparky.isocor.com (NPlex 4.5.002) id 37D8609E000009B2; Mon, 13 Sep 1999 14:05:42 -0700 From: Erik Forsberg To: Mark Crispin Cc: IMAP Extensions WG Subject: Re: multi-append In-Reply-To: Message-ID: Date: Mon, 13 Sep 1999 14:05:42 -0700 (Pacific Daylight Time) X-Mailer: Simeon for Win32 Version 4.1.5 Build (43) X-Authentication: none MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Implementation difficulty here. It doesnt seem like you can detect the last append_message without reading ahead and detecting that next token is SPACE (instead of what goes in a tag) That causes problems in my server implementation as I make a distinction between waiting for the next IMAP4 command (because the client is idle, you need to check for new mail, flag updates, etc) and simply waiting for the next token within a command. On Mon, 13 Sep 1999 13:15:54 -0700 Mark Crispin wrote: > I would like to add an extension called MULTIAPPEND. This is an upwards > compatible extension to the RFC 2060 APPEND command. > > A server which advertises the MULTIAPPEND capability permits more than one > message in the same append command. In other words, the APPEND grammar > becomes: > > append = "APPEND" SPACE mailbox 1*append_message > append_message = [SPACE flag_list] [SPACE date_time] SPACE literal > > MULTIAPPEND provides the same RTT savings offered by the LITERAL+ extension > with the current APPEND. When MULTIAPPEND is used in conjunction with > LITERAL+, the entire upload is a single RTT. > > There is another advantage, which is a major win for my server; the procedure > for opening and closing the destination mailbox only needs to be done once > instead of per-message. We've determined that for the standard UNIX format of > mail, the open/close and lock/unlock overhead is a major part of the overall > time spent in multiple appends. > > I believe that this extension should be non-controversial; it is upwards > compatible and is at least a minor win for everybody (because of RTTs) and can > potentially be a major win. Does anyone disagree? If not, do we have > concensus to put out an ID and give it accelerated approval in the WG (with > hopefully minimal discussion) as a Proposed Standard? > > The one issue of contention may be what happens on a partial failure; e.g. > running out of disk quota after several messages but before the last message. > I think that consistancy with the rest of IMAP, as well as the impossibility > of the client knowing what succeeded and what failed if LITERAL+ is used with > this feature, mandates that the entire APPEND fail and the mailbox be reverted > to the state prior to the APPEND. > ---------------------- Erik Forsberg erik.forsberg@isocor.com From owner-ietf-imapext Mon Sep 13 14:21:11 1999 Received: by mail.proper.com (8.9.3/8.9.3) id OAA11009 for ietf-imapext-bks; Mon, 13 Sep 1999 14:21:11 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (dmt@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA11000 for ; Mon, 13 Sep 1999 14:19:02 -0700 (PDT) Date: Mon, 13 Sep 1999 14:11:24 -0700 (PDT) From: Mark Crispin Subject: Re: multi-append To: Erik Forsberg cc: IMAP Extensions WG In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Mon, 13 Sep 1999 14:05:42 -0700 (Pacific Daylight Time), Erik Forsberg wrote: > Implementation difficulty here. > It doesnt seem like you can detect the last append_message without reading > ahead and detecting that next token is SPACE (instead of what goes in a tag) Actually, it's detecting that the next token is a SPACE as opposed to a CRLF (marking end of command). You wouldn't look for a tag until you get to the start-of-command portion of your parse loop. This isn't the only command which has this characteristic; SEARCH stands out in the base specification; and the SORT, THREAD, and extended LIST proposals also act in the same way. > That causes problems in my server implementation as I make a distinction > between waiting for the next IMAP4 command (because the client is idle, you > need to check for new mail, flag updates, etc) and simply waiting for the > next token within a command. Is the issue that you actually enter command execution for APPEND when you receive the literal, as opposed to waiting until you get the CRLF to end the command? What happens if the client does 001 APPEND foobar {3} zap barf Do you append "zap" to mailbox foobar then return a BAD for "barf"? If so, that's wrong; foobar should not be affected by this command at all (or if it is, it should be reverted to its prior state). In any case, MULTIAPPEND is an extension and hence optional; there's no requirement that you implement it in your server, and no client will send you one unless you advertise it. So, you could ignore MULTIAPPEND if it presents implementation problems and remain fully-compliant. I don't implement all the extensions either. Is there something that I'm missing that would cause you problems? From owner-ietf-imapext Mon Sep 13 14:41:17 1999 Received: by mail.proper.com (8.9.3/8.9.3) id OAA11174 for ietf-imapext-bks; Mon, 13 Sep 1999 14:41:17 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA11170 for ; Mon, 13 Sep 1999 14:41:15 -0700 (PDT) Date: Mon, 13 Sep 1999 14:29:56 -0700 (PDT) From: Mark Crispin Subject: Re: multi-append To: Lyndon Nerenberg cc: IMAP Extensions WG In-Reply-To: <199909132125.PAA374179@zappa.esys.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Mon, 13 Sep 1999 15:25:18 -0600, Lyndon Nerenberg wrote: > This would be my concern as well. For the UW server backing out should be > easy -- just don't rename the new mailbox file over the old one. Actually, it's "ftruncate() the mailbox file back to its old size and adjust the dates." You can't "rename the new mailbox file over the old one" with the standard UNIX format; too many mail delivery agents depend upon system call locking on the mail file (as opposed to .lock files) which mandate that the inode be preserved. A *major* hassle. > It would > be more of a problem for us as we would have to do additional checkpointing, > and wrap the whole thing up in a transaction in case we had to do a roll > back. Well, let's talk about this. I'm willing to discuss a mechanism to indicate "partial success" for multi-append. It may be a good idea anyway; it seems wasteful to toss out all that work. Perhaps have some mechanism to indicate total size of the append? > Then again, because of how we store our messages, multiple APPEND > operations are not a performance hit for us. Don't you have to do various stat()s and/or database lookups/locks to validate the mailbox and plop additional messages down into the mailbox? Even if your format does this faster than standard UNIX format (just about anything is better than standard UNIX format!!), I still think that you can't do a streaming upload without per-message pauses. > The minor increase in > throughput from eliminating the extra RTTs wouldn't justify the increased > complexity it would introduce, so it's unlikely we would implement this > extension in our server. Really? LITERAL+ eliminates 50% of the RTTs and was supposedly a major win for those servers which support it. The combination of MULTIAPPEND and LITERAL+ would eliminate all but one RTT. So, what about some sort of additional untagged response to indicate what got appended and what didn't, on the line of the UIDPLUS stuff? I appreciate your expression of non-opposition, but I'd like to see if something can be done to make you guys be enthusiastic supporters. From owner-ietf-imapext Mon Sep 13 14:23:09 1999 Received: by mail.proper.com (8.9.3/8.9.3) id OAA11048 for ietf-imapext-bks; Mon, 13 Sep 1999 14:23:09 -0700 (PDT) Received: from zappa.esys.ca (zappa.esys.ca [198.161.92.28]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA11044 for ; Mon, 13 Sep 1999 14:23:08 -0700 (PDT) Received: (from lyndon@localhost) by zappa.esys.ca (8.9.3/8.9.3) id PAA374179; Mon, 13 Sep 1999 15:25:18 -0600 (MDT) Message-Id: <199909132125.PAA374179@zappa.esys.ca> To: Mark Crispin cc: IMAP Extensions WG Subject: Re: multi-append In-reply-to: Your message of "Mon, 13 Sep 1999 13:15:54 PDT." Date: Mon, 13 Sep 1999 15:25:18 -0600 From: Lyndon Nerenberg Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: >>>>> "Mark" == Mark Crispin writes: Mark> The one issue of contention may be what happens on a partial Mark> failure; e.g. running out of disk quota after several Mark> messages but before the last message. I think that Mark> consistancy with the rest of IMAP, as well as the Mark> impossibility of the client knowing what succeeded and what Mark> failed if LITERAL+ is used with this feature, mandates that Mark> the entire APPEND fail and the mailbox be reverted to the Mark> state prior to the APPEND. This would be my concern as well. For the UW server backing out should be easy -- just don't rename the new mailbox file over the old one. It would be more of a problem for us as we would have to do additional checkpointing, and wrap the whole thing up in a transaction in case we had to do a roll back. Then again, because of how we store our messages, multiple APPEND operations are not a performance hit for us. The minor increase in throughput from eliminating the extra RTTs wouldn't justify the increased complexity it would introduce, so it's unlikely we would implement this extension in our server. (Which is not the same as saying I would oppose the extension.) --lyndon From owner-ietf-imapext Mon Sep 13 14:47:26 1999 Received: by mail.proper.com (8.9.3/8.9.3) id OAA11230 for ietf-imapext-bks; Mon, 13 Sep 1999 14:47:26 -0700 (PDT) Received: from sparky.isocor.com (sparky.isocor.com [198.6.228.217]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA11226 for ; Mon, 13 Sep 1999 14:47:25 -0700 (PDT) Received: from erik.isocor.com (198.6.228.71) by sparky.isocor.com (NPlex 4.5.002) id 37D8609E000009F6; Mon, 13 Sep 1999 14:50:37 -0700 From: Erik Forsberg To: Mark Crispin Cc: IMAP Extensions WG Subject: Re: multi-append In-Reply-To: Message-ID: Date: Mon, 13 Sep 1999 14:50:37 -0700 (Pacific Daylight Time) X-Mailer: Simeon for Win32 Version 4.1.5 Build (43) X-Authentication: none MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Argh, of course it is CRLF (instead of a literal) I am looking for. Forget my objection. Responded too quickly. On Mon, 13 Sep 1999 14:11:24 -0700 Mark Crispin wrote: > On Mon, 13 Sep 1999 14:05:42 -0700 (Pacific Daylight Time), Erik Forsberg > wrote: > > Implementation difficulty here. > > It doesnt seem like you can detect the last append_message without reading > > ahead and detecting that next token is SPACE (instead of what goes in a tag) > > Actually, it's detecting that the next token is a SPACE as opposed to a CRLF > (marking end of command). You wouldn't look for a tag until you get to the > start-of-command portion of your parse loop. > > This isn't the only command which has this characteristic; SEARCH stands out > in the base specification; and the SORT, THREAD, and extended LIST proposals > also act in the same way. > > > That causes problems in my server implementation as I make a distinction > > between waiting for the next IMAP4 command (because the client is idle, you > > need to check for new mail, flag updates, etc) and simply waiting for the > > next token within a command. > > Is the issue that you actually enter command execution for APPEND when you > receive the literal, as opposed to waiting until you get the CRLF to end the > command? What happens if the client does > 001 APPEND foobar {3} > zap barf > Do you append "zap" to mailbox foobar then return a BAD for "barf"? If so, > that's wrong; foobar should not be affected by this command at all (or if it > is, it should be reverted to its prior state). > > In any case, MULTIAPPEND is an extension and hence optional; there's no > requirement that you implement it in your server, and no client will send you > one unless you advertise it. So, you could ignore MULTIAPPEND if it presents > implementation problems and remain fully-compliant. I don't implement all the > extensions either. > > Is there something that I'm missing that would cause you problems? > ---------------------- Erik Forsberg erik.forsberg@isocor.com From owner-ietf-imapext Mon Sep 13 15:04:01 1999 Received: by mail.proper.com (8.9.3/8.9.3) id PAA11503 for ietf-imapext-bks; Mon, 13 Sep 1999 15:04:01 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA11499 for ; Mon, 13 Sep 1999 15:03:59 -0700 (PDT) Received: from sardis.cyrusoft.com (sardis.cyrusoft.com [206.31.218.203]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id SAA28646; Mon, 13 Sep 1999 18:06:35 -0400 (EDT) Date: Mon, 13 Sep 1999 18:10:20 -0400 From: Cyrus Daboo To: Mark Crispin , Lyndon Nerenberg cc: IMAP Extensions WG Subject: Re: multi-append Message-ID: <1000609.3146235020@sardis.cyrusoft.com> In-Reply-To: X-Mailer: Mulberry (MacOS) [2.0.0a6, s/n S1-000001] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: --On Monday, September 13, 1999 2:29 PM -0700 Mark Crispin wrote: > Really? LITERAL+ eliminates 50% of the RTTs and was supposedly a major > win for those servers which support it. The combination of MULTIAPPEND > and LITERAL+ would eliminate all but one RTT. > > So, what about some sort of additional untagged response to indicate what > got appended and what didn't, on the line of the UIDPLUS stuff? > > I appreciate your expression of non-opposition, but I'd like to see if > something can be done to make you guys be enthusiastic supporters. It seems to me if the client uses non-synchronising literals to do the multi-append then there is no real way to recover from a failure other than a NO/BAD to the entire command. If the client were prepared to tolerate this in order to eliminate RTTs that would be fine. However, if RTTs were not so much of an issue as opposed to the server overhead of multiple APPEND commands, then its possible to use a combination of non-non-synchronising literals for the message interpersed with non-synchronising literals to check with the server to see if the last append completed: S: a APPEND INBOX {11}+ C: From: Cyrus C: {0} S: + [OK MULTIAPPEND TOTAL 1] C: {10}+ S: From: Mark C: {0} S: + [NO MULTIAPPEND TOTAL 1] C: S: OK MULTIAPPEND succeeded for 1 message -- Cyrus From owner-ietf-imapext Mon Sep 13 15:18:01 1999 Received: by mail.proper.com (8.9.3/8.9.3) id PAA11598 for ietf-imapext-bks; Mon, 13 Sep 1999 15:18:01 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (trungt@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA11594 for ; Mon, 13 Sep 1999 15:18:01 -0700 (PDT) Date: Mon, 13 Sep 1999 15:09:34 -0700 (PDT) From: Mark Crispin Subject: Re: multi-append To: Cyrus Daboo cc: Mark Crispin , Lyndon Nerenberg , IMAP Extensions WG In-Reply-To: <1000609.3146235020@sardis.cyrusoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Mon, 13 Sep 1999 18:10:20 -0400, Cyrus Daboo wrote: > It seems to me if the client uses non-synchronising literals to do the > multi-append then there is no real way to recover from a failure other than > a NO/BAD to the entire command. There is another choice. We could have two flavors of multi-append, one which does a NO/BAD to the entire command if there is any failure, and the other which will succeed with appends up to the point of the failure. It would then return an untagged response indicating the extent of the partial success, and then the NO/BAD. This would make append a rather odd bird as far as IMAP goes. The likelihood is high that the server would not buffer up all the messages and then start appending at the terminating CRLF (which a strict interpretation of IMAP would mandate), but instead would append as the messages come in (which makes much more implementation and operational sense). Where this becomes strange is that a syntactically invalid command could also have this behavior (hence "NO/BAD" rather than "NO"). I don't think that we should worry too much about this since bad syntax never happens with the software we experts write. ;-) ;-) ;-) ;-) ;-) > S: a APPEND INBOX {11}+ > C: From: Cyrus > C: {0} > S: + [OK MULTIAPPEND TOTAL 1] > C: {10}+ > S: From: Mark > C: {0} > S: + [NO MULTIAPPEND TOTAL 1] > C: > S: OK MULTIAPPEND succeeded for 1 message With synchronized literals: S: a APPEND INBOX {11} C: From: Cyrus C: {0} S: + I got that message! C: {10} S: NO [APPEND 1] MULTIAPPEND failed after 1 message due to disk quota exceeded From owner-ietf-imapext Mon Sep 13 16:15:40 1999 Received: by mail.proper.com (8.9.3/8.9.3) id QAA12066 for ietf-imapext-bks; Mon, 13 Sep 1999 16:15:40 -0700 (PDT) Received: from zappa.esys.ca (zappa.esys.ca [198.161.92.28]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA12060 for ; Mon, 13 Sep 1999 16:15:25 -0700 (PDT) Received: (from lyndon@localhost) by zappa.esys.ca (8.9.3/8.9.3) id RAA367327; Mon, 13 Sep 1999 17:17:39 -0600 (MDT) Message-Id: <199909132317.RAA367327@zappa.esys.ca> To: Mark Crispin cc: Lyndon Nerenberg , IMAP Extensions WG Subject: Re: multi-append In-reply-to: Your message of "Mon, 13 Sep 1999 14:29:56 PDT." Date: Mon, 13 Sep 1999 17:17:38 -0600 From: Lyndon Nerenberg Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: >>>>> "Mark" == Mark Crispin writes: Mark> Actually, it's "ftruncate() the mailbox file back to its old Yup, sorry, brain in neutral :-P Mark> Perhaps have some mechanism to indicate total size of the Mark> append? Maybe; is that 1GB of MULTIAPPEND two 500MB messages, a 1MB message followed by a 999MB message, or 500 2MB messages? The potential failure modes are quite different. Without the indidivual message component sizes, the server can't make an intelligent decision about whether it can realistically accept the request. And even with sizes, it cannot bail out halfway through when the disk fills up for reasons outside the server's control. Mark> Don't you have to do various stat()s and/or database Mark> lookups/locks to validate the mailbox and plop additional Mark> messages down into the mailbox? Yes, but much of this is cached, so it's not that big of an issue performance wise. Mark> [ ... ] I still think that Mark> you can't do a streaming upload without per-message pauses. But we can make the pauses very short. Again, this is a direct benefit of the threading (and caching) model we employ. Mark> So, what about some sort of additional untagged response to Mark> indicate what got appended and what didn't, on the line of Mark> the UIDPLUS stuff? It seems to me that the failure case will almost always be resource starvation (no disk, inodes, ...) after which your odds of being able to handle succeeding messages in the multiappend approaches zero (over the likely time period during which the MULTIAPPEND will try to complete.) You want to communicate this failure ASAP, which means sending partial completion status between messages, which negates most of the benefit (by adding that evil RTT back in). Factor the abort processing in with intelligent size handling and you've engineered APPEND. So, where I see MULTIAPPEND being a win is for servers that use a single- file-per-mailbox (or equivelent) format where streamed appends are cheap, but append transactions aren't. In it's current state, I wouldn't implement it soley as a protocol performance enhancement, for the reasons I outline above. I don't see how those issues can be addressed without turning it back into the existing APPEND. --lyndon From owner-ietf-imapext Tue Sep 14 00:32:49 1999 Received: by mail.proper.com (8.9.3/8.9.3) id AAA23050 for ietf-imapext-bks; Tue, 14 Sep 1999 00:32:49 -0700 (PDT) Received: from mailgw1.netvision.net.il (mailgw1.netvision.net.il [194.90.1.14]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id AAA23044 for ; Tue, 14 Sep 1999 00:32:47 -0700 (PDT) Received: from unity-ex.icomverse.com (unity-ex.icomverse.com [199.203.140.35]) by mailgw1.netvision.net.il (8.9.3/8.9.3) with ESMTP id JAA29730 for ; Tue, 14 Sep 1999 09:35:58 +0200 Received: by UNITY-EX.QUANTUM.icomverse.com with Internet Mail Service (5.5.2448.0) id ; Tue, 14 Sep 1999 10:36:54 +0300 Message-ID: <71230E2CB02FD31181710004AC1509D70EAE00@UNITY-EX.QUANTUM.icomverse.com> From: "Rubinstein, Dmitry" To: IMAP Extensions WG Subject: RE: multi-append Date: Tue, 14 Sep 1999 10:36:52 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > From: Mark Crispin [mailto:MRC@cac.washington.edu] > > I would like to add an extension called MULTIAPPEND. This is > an upwards > compatible extension to the RFC 2060 APPEND command. [skip] > MULTIAPPEND provides the same RTT savings offered by the > LITERAL+ extension > with the current APPEND. When MULTIAPPEND is used in conjunction with > LITERAL+, the entire upload is a single RTT. I have a couple of questions: 1) What happens if you just stream multiple messages through the conventional APPEND without waiting for the response after each message? Don't you save almost as many RTTs as with MULTIAPPEND (except for RTTs of server responses, but that's not your bottleneck)? > There is another advantage, which is a major win for my > server; the procedure > for opening and closing the destination mailbox only needs to > be done once > instead of per-message. We've determined that for the > standard UNIX format of > mail, the open/close and lock/unlock overhead is a major part > of the overall > time spent in multiple appends. 2) Isn't it an implementation issue specific to your server? Perhaps, you can cache mailbox until next command (after the APPEND), and if it's again an APPEND to the same mailbox - no overhead is needed. 3) When would the client want to append multiple messages to the mailbox? Where does the need come from? -- Dmitry Rubinstein From owner-ietf-imapext Tue Sep 14 01:14:53 1999 Received: by mail.proper.com (8.9.3/8.9.3) id BAA24146 for ietf-imapext-bks; Tue, 14 Sep 1999 01:14:53 -0700 (PDT) Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id BAA24142 for ; Tue, 14 Sep 1999 01:14:52 -0700 (PDT) Received: from hpopd.pwd.hp.com (hpopd.pwd.hp.com [15.145.205.59]) by atlrel1.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id EAA26172 for ; Tue, 14 Sep 1999 04:17:28 -0400 (EDT) Received: from pwd.hp.com (ilex.pwd.hp.com [15.145.204.106]) by hpopd.pwd.hp.com (8.8.6 (PHNE_15509)/8.8.6 CMSO Openmail) with ESMTP id JAA28449 for ; Tue, 14 Sep 1999 09:18:04 +0100 (BST) Message-ID: <37DE04BA.BF8D59E9@pwd.hp.com> Date: Tue, 14 Sep 1999 09:18:02 +0100 From: John Haxby X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 CC: ietf-imapext@imc.org Subject: Re: multi-append References: Content-Type: multipart/mixed; boundary="------------3AE20F4D527E29374F889916" Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: This is a multi-part message in MIME format. --------------3AE20F4D527E29374F889916 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MRC@cac.washington.edu wrote: > I would like to add an extension called MULTIAPPEND. This is an upwards > compatible extension to the RFC 2060 APPEND command. > If I recall correctly, this is outside the charter of imap-ext. However, I don't see the advantage of this over streaming APPEND commands, unless, as you point out, the server doesn't cache the most recently opened mailbox. (And in this case, this is a server performance issue, not a protocol deficiency issue -- our server does just this caching to avoid re-opening mailboxes for any reason.) jch --------------3AE20F4D527E29374F889916 Content-Type: text/x-vcard; charset=us-ascii; name="jch.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for John Haxby Content-Disposition: attachment; filename="jch.vcf" begin:vcard n:Haxby;John tel;work:+44 1344 763711 x-mozilla-html:FALSE url:http://www.hp.com/go/OpenMail org:Hewlett Packard;OpenMail R&D adr:;;Nine Mile Ride;Wokingham;Berks;RG40 3LL;England version:2.1 email;internet:jch@pwd.hp.com x-mozilla-cpt:;14976 fn:John Haxby end:vcard --------------3AE20F4D527E29374F889916-- From owner-ietf-imapext Tue Sep 14 07:30:30 1999 Received: by mail.proper.com (8.9.3/8.9.3) id HAA02703 for ietf-imapext-bks; Tue, 14 Sep 1999 07:30:30 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA02699 for ; Tue, 14 Sep 1999 07:30:28 -0700 (PDT) Received: from ephesus.cyrusoft.com (ephesus.cyrusoft.com [206.31.218.204]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id KAA00052; Tue, 14 Sep 1999 10:33:17 -0400 (EDT) Date: Tue, 14 Sep 1999 10:33:12 -0400 From: Cyrus Daboo To: "Rubinstein, Dmitry" , IMAP Extensions WG Subject: RE: multi-append Message-ID: <1002322253.937305192@ephesus.cyrusoft.com> In-Reply-To: <71230E2CB02FD31181710004AC1509D70EAE00@UNITY-EX.QUANTUM.icomverse.com> X-Mailer: Mulberry (Win32) [2.0.0a6, s/n S1-000001] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: --On Tuesday, September 14, 1999 10:36 AM +0300 "Rubinstein, Dmitry" wrote: > 3) When would the client want to append multiple messages to the mailbox? > Where does the need come from? Server-to-server mailbox copies, disconnected operation synchronisation, conversion of local POP3 mailboxes to IMAP, etc -- Cyrus From owner-ietf-imapext Tue Sep 14 13:53:33 1999 Received: by mail.proper.com (8.9.3/8.9.3) id NAA08671 for ietf-imapext-bks; Tue, 14 Sep 1999 13:53:33 -0700 (PDT) Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.5]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA08667 for ; Tue, 14 Sep 1999 13:53:32 -0700 (PDT) Received: from mailhost2.u.washington.edu (mailhost2.u.washington.edu [140.142.33.2]) by mxout1.cac.washington.edu (8.9.3+UW99.09/8.9.3+UW99.08) with ESMTP id NAA08009; Tue, 14 Sep 1999 13:56:52 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (chince@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost2.u.washington.edu (8.9.3+UW99.09/8.9.3+UW99.08) with ESMTP id NAA28073; Tue, 14 Sep 1999 13:56:52 -0700 Date: Tue, 14 Sep 1999 13:50:51 -0700 (PDT) From: Mark Crispin Subject: Re: multi-append To: Lyndon Nerenberg cc: IMAP Extensions WG In-Reply-To: <199909132317.RAA367327@zappa.esys.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Mon, 13 Sep 1999 17:17:38 -0600, Lyndon Nerenberg wrote: > You want to communicate this failure ASAP, which means sending > partial completion status between messages, which negates most of > the benefit (by adding that evil RTT back in). At worst (with no LITERAL+ since you decided you want the failures ASAP), multi-append is no better than single APPEND with LITERAL+, but it is no worse. However, I suspect that multi-append is easier to implement (in an implementation starting from scratch) than LITERAL+ Multi-append without LITERAL+ also avoids the sending of the literal, which is a consideration on slow links -- you don't want to use LITERAL+ with radio!! From owner-ietf-imapext Tue Sep 14 14:01:52 1999 Received: by mail.proper.com (8.9.3/8.9.3) id OAA08895 for ietf-imapext-bks; Tue, 14 Sep 1999 14:01:52 -0700 (PDT) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA08891 for ; Tue, 14 Sep 1999 14:01:51 -0700 (PDT) Received: from mailhost2.u.washington.edu (mailhost2.u.washington.edu [140.142.33.2]) by mxout2.cac.washington.edu (8.9.3+UW99.09/8.9.3+UW99.08) with ESMTP id OAA27067; Tue, 14 Sep 1999 14:05:10 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (clane@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost2.u.washington.edu (8.9.3+UW99.09/8.9.3+UW99.08) with ESMTP id OAA28975; Tue, 14 Sep 1999 14:05:10 -0700 Date: Tue, 14 Sep 1999 13:56:59 -0700 (PDT) From: Mark Crispin Subject: RE: multi-append To: "Rubinstein, Dmitry" cc: IMAP Extensions WG In-Reply-To: <71230E2CB02FD31181710004AC1509D70EAE00@UNITY-EX.QUANTUM.icomverse.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Tue, 14 Sep 1999 10:36:52 +0300, Rubinstein, Dmitry wrote: > 1) What happens if you just stream multiple messages through the > conventional APPEND without waiting for the response after each message? How many client and server implementations out there implement streaming (as stipulated by RFC 2060) completely and correctly? Are you certain that you can stream multiple APPEND commands? It seems to run afoul of the ambiguity rules. > Don't you save almost as many RTTs as with MULTIAPPEND (except for RTTs of > server responses, but that's not your bottleneck)? Multi-append without LITERAL+ saves as many RTTs as single append with LITERAL+. However, I speculate that multi-append is easier to implement than LITERAL+. Nor does multi-append have the problem of sending a literal over a slow link (like radio) that is going to be discarded immediately. Multi-append combined with LITERAL+ requires just a single RTT, and it doesn't have the ambiguity issues of streaming APPEND. > 2) Isn't it an implementation issue specific to your server? No, it is NOT an implementation issue specific to my server. It is an issue specific to any legacy UNIX mailbox. > Perhaps, you > can cache mailbox until next command (after the APPEND), and if it's again > an APPEND to the same mailbox - no overhead is needed. Wrong. The overhead is in locking and unlocking. You can't keep the mailbox locked between commands. > 3) When would the client want to append multiple messages to the mailbox? > Where does the need come from? Any upload of messages, including multi-message save from a mailbox on one server to another, or simply transfer of mailboxes from one user to another. From owner-ietf-imapext Thu Sep 16 09:57:55 1999 Received: by mail.proper.com (8.9.3/8.9.3) id JAA20217 for ietf-imapext-bks; Thu, 16 Sep 1999 09:57:55 -0700 (PDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA20211 for ; Thu, 16 Sep 1999 09:57:49 -0700 (PDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id NAA06302 for ; Thu, 16 Sep 1999 13:01:08 -0400 Received: from watson.ibm.com (mars.watson.ibm.com [9.2.2.58]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with ESMTP id NAA34390 for ; Thu, 16 Sep 1999 13:01:07 -0400 Message-ID: <37E12252.C546FD73@watson.ibm.com> Date: Thu, 16 Sep 1999 13:01:06 -0400 From: Barry Leiba Organization: Internet Messaging Technology; TR2_Xagent=WATSON X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: IMAP Extensions WG Subject: Re: multi-append References: Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Mark Crispin wrote: > How many client and server implementations out there implement streaming (as > stipulated by RFC 2060) completely and correctly? None that I know of. What's worse is that there's no way for a client to know whether a server does or doesn't (which is where the temptation to do things like potentially long SEARCHes in another session comes from). Perhaps we need to have an extension spec that defines explicitly what it means to support streamed commands, and have that spec add a CAPABILITY string that asserts that this server supports it. > Are you certain that you can stream multiple APPEND commands? It seems to run > afoul of the ambiguity rules. I don't see why. Can you explain? > LITERAL+. However, I speculate that multi-append is easier to implement than > LITERAL+. For me, LITERAL+ was absolutely trivial to implement; I suppose it depends upon exactly how your literal-processing code is written. Multi-append would also be trivial for me to implement *IF* I don't have to do rollback. The requirement for rollback would stop me from bothering, since, as with Lyndon, there's not very much startup overhead for me in an APPEND command. I think that requiring a UIDPLUS-style response for multi-append, with, say, zeroes for the UIDs for those messages that failed, would take care of that issue. Something like this: c: sends multi-append command with 5 messages s: does appends, the fourth and fifth ones fail s: TAG OK [APPENDUID 22 23 25 0 0] APPEND completed ^ (should this be OK or NO?) > It is an issue specific to any legacy UNIX mailbox. I don't mean to be combative; I know this is a touchy item: what other servers support legacy UNIX mailboxes? > Wrong. The overhead is in locking and unlocking. You can't keep the mailbox > locked between commands. You can if you can see that there's already another APPEND command in the pipe. I agree that this won't be perfect; it's possible that the client has tried to stream APPEND commands but the next one isn't ready when you go to check. But in most cases it will be there, and you can avoid unlocking. It means that you have to be able to check for the presence of another command without blocking if one isn't there. Barry Leiba, Internet Messaging Technology (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba From owner-ietf-imapext Thu Sep 16 10:23:24 1999 Received: by mail.proper.com (8.9.3/8.9.3) id KAA20597 for ietf-imapext-bks; Thu, 16 Sep 1999 10:23:24 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (johnl@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA20593 for ; Thu, 16 Sep 1999 10:23:23 -0700 (PDT) Date: Thu, 16 Sep 1999 10:08:31 -0700 (PDT) From: Mark Crispin Subject: Re: multi-append To: Barry Leiba cc: IMAP Extensions WG In-Reply-To: <37E12252.C546FD73@watson.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Thu, 16 Sep 1999 13:01:06 -0400, Barry Leiba wrote: > Perhaps we need to have an extension > spec that defines explicitly what it means to support streamed commands, and > have that spec add a CAPABILITY string that asserts that this server > supports it. I wouldn't oppose this, if it could be explained to me what would be different if this capability existed. Off hand, I can't think of a situation where the client would be better off knowing that the server does not support streaming. > > Are you certain that you can stream multiple APPEND commands? It seems to > > run afoul of the ambiguity rules. > I don't see why. Can you explain? Let's consider an append of three messages. The second is a godzillagram which will pop the user's quota (and hence won't succeed in append). If you stream the three appends, then the first and third would be appended. It's therefore ambiguous whether or not the third message is appended after the second message. Also, without recourse to the last sentence of the second paragraph of 5.5 (which in itself requires acknowledgement that a forbidden ambiguity exists), there's no guarantee that the three messages will be appended in the order sent by the client (reference second sentence of first paragraph of 5.5). We can define our way out of this mess, but the base specification doesn't do it for us. > Multi-append would also > be trivial for me to implement *IF* I don't have to do rollback. What if it's a client specified option? I would probably use the non-rollback form in my client code, but I don't think that I can justify making non-rollback the only form. > I think that requiring a UIDPLUS-style response for multi-append, with, say, > zeroes for the UIDs for those messages that failed, would take care of that > issue. Something like this: > c: sends multi-append command with 5 messages > s: does appends, the fourth and fifth ones fail > s: TAG OK [APPENDUID 22 23 25 0 0] APPEND completed > ^ > (should this be OK or NO?) Hmm. How would be indicate this if the client uses LITERAL+ on a non-UIDPLUS server? The answer "that means the client doesn't care" is a valid answer. > I don't mean to be combative; I know this is a touchy item: what other > servers support legacy UNIX mailboxes? At least two other servers that I know of. However, it doesn't matter. The market share of my server, using legacy UNIX mailboxes, easily dwarfs that of all other servers combined. I'm not particularly proud about that fact (the part that they use that format); I wish to proclaim the legacy UNIX mailbox format dead and buried. But it ain't gonna happen. > > Wrong. The overhead is in locking and unlocking. You can't keep the > > mailbox locked between commands. > You can if you can see that there's already another APPEND command in the > pipe. But that only works if the client streams. And that gets back to the point that you acknowledged that nobody seems to implement streaming completely or correctly. From owner-ietf-imapext Thu Sep 16 12:24:48 1999 Received: by mail.proper.com (8.9.3/8.9.3) id MAA22376 for ietf-imapext-bks; Thu, 16 Sep 1999 12:24:48 -0700 (PDT) Received: from mailgw1.netvision.net.il (mailgw1.netvision.net.il [194.90.1.14]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA22372 for ; Thu, 16 Sep 1999 12:24:44 -0700 (PDT) Received: from unity-ex.icomverse.com (unity-ex.icomverse.com [199.203.140.35]) by mailgw1.netvision.net.il (8.9.3/8.9.3) with ESMTP id VAA10990 for ; Thu, 16 Sep 1999 21:28:02 +0200 Received: by UNITY-EX.QUANTUM.icomverse.com with Internet Mail Service (5.5.2448.0) id ; Thu, 16 Sep 1999 19:58:56 +0300 Message-ID: <71230E2CB02FD31181710004AC1509D70EAE0E@UNITY-EX.QUANTUM.icomverse.com> From: "Rubinstein, Dmitry" To: IMAP Extensions WG Subject: RE: multi-append Date: Thu, 16 Sep 1999 19:58:46 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-2" Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > From: Barry Leiba [mailto:leiba@watson.ibm.com] > Sent: Thursday, September 16, 1999 7:01 PM > To: IMAP Extensions WG > Subject: Re: multi-append > > > Mark Crispin wrote: > > How many client and server implementations out there > implement streaming (as > > stipulated by RFC 2060) completely and correctly? > > None that I know of. > What's worse is that there's no way for a client to know > whether a server does > or doesn't (which is where the temptation to do things like > potentially long > SEARCHes in another session comes from). Perhaps we need to > have an extension > spec that defines explicitly what it means to support > streamed commands, and > have that spec add a CAPABILITY string that asserts that this > server supports > it. What DOES it mean to support streaming commands server side? I just can't see what can be different from non-streaming: you read one command at a time (assuming you can tell when a command is over and a new one begins, otherwise - goto RFC2060). Once a command is processed, you send a response and fetch another command. IMVHO, all the complexity of streaming commands is on the client side. What am I missing? -- Dmitry Rubinstein From owner-ietf-imapext Mon Sep 27 06:49:08 1999 Received: by mail.imc.org (8.9.3/8.9.3) id GAA04408 for ietf-imapext-bks; Mon, 27 Sep 1999 06:49:08 -0700 (PDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id GAA04404 for ; Mon, 27 Sep 1999 06:49:07 -0700 (PDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id JAA04534 for ; Mon, 27 Sep 1999 09:49:45 -0400 Received: from watson.ibm.com (mars.watson.ibm.com [9.2.2.58]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with ESMTP id JAA20692 for ; Mon, 27 Sep 1999 09:49:45 -0400 Message-ID: <37EF75F9.FA74224A@watson.ibm.com> Date: Mon, 27 Sep 1999 09:49:45 -0400 From: Barry Leiba Organization: Internet Messaging Technology; TR2_Xagent=WATSON X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: IMAP Extensions WG Subject: Re: multi-append References: <71230E2CB02FD31181710004AC1509D70EAE0E@UNITY-EX.QUANTUM.icomverse.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: "Rubinstein, Dmitry" wrote: > What DOES it mean to support streaming commands server side? I just can't > see what can be different from non-streaming: you read one command at a time > (assuming you can tell when a command is over and a new one begins, > otherwise - goto RFC2060). Once a command is processed, you send a response > and fetch another command. > > IMVHO, all the complexity of streaming commands is on the client side. What > am I missing? Why would the client do that (that is, what benefit would it get from it)? The answer is that the benefit is overlapped execution of commands. For instance: c: c: 001 SEARCH BODY "frobozz" c: s: c: c: 002 FETCH 5272 BODY[1] s: * 5272 FETCH (BODY[1] {386} ... s: 002 OK fetch done c: s: * SEARCH 852 5319 5512 s: 001 OK search done c: In order for this to be useful, the server must accept and process the FETCH command before the SEARCH command is completed. Otherwise, the user is stuck watching the "searching..." indicator until the search is done. And the problem is that the client has no way to know what will happen when it does this. Some clients want to solve that problem by opening a second session for the SEARCH, but that's a problem with some server configurations, where two sessions can't select the same mailbox at the same time. The difficulty on the server side is that it needs to be smart enough not only to process multiple commands at the same time in the same session (which is relatively easy, once you set up the multi-threading stuff), but also to know what commands can safely be multi-threaded, and when something has to wait. For instance, you can't overlap SEARCH processing, though that would be a lovely thing to do, because the client has no way to distinguish the untagged responses. You can't send a response or any sort while a literal is being transmitted. Things like that. It can be tricky. Barry Leiba, Internet Messaging Technology (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba From owner-ietf-imapext Tue Sep 28 13:35:09 1999 Received: by mail.imc.org (8.9.3/8.9.3) id NAA01265 for ietf-imapext-bks; Tue, 28 Sep 1999 13:35:09 -0700 (PDT) Received: from alpha.netvision.net.il (alpha.netvision.net.il [194.90.1.13]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id NAA01261 for ; Tue, 28 Sep 1999 13:35:06 -0700 (PDT) Received: from unity-ex.icomverse.com (unity-ex.icomverse.com [199.203.140.35]) by alpha.netvision.net.il (8.9.3/8.8.6) with ESMTP id WAA15525 for ; Tue, 28 Sep 1999 22:35:45 +0200 (IST) Received: by UNITY-EX.QUANTUM.icomverse.com with Internet Mail Service (5.5.2448.0) id ; Tue, 28 Sep 1999 22:36:24 +0300 Message-ID: <71230E2CB02FD31181710004AC1509D70EAE40@UNITY-EX.QUANTUM.icomverse.com> From: "Rubinstein, Dmitry" To: IMAP Extensions WG Subject: RE: multi-append Date: Tue, 28 Sep 1999 22:36:19 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-2" Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > From: Barry Leiba [mailto:leiba@watson.ibm.com] > Sent: Monday, September 27, 1999 3:50 PM > To: IMAP Extensions WG > Subject: Re: multi-append > > > IMVHO, all the complexity of streaming commands is on the > client side. What > > am I missing? > > Why would the client do that (that is, what benefit would it > get from it)? > The answer is that the benefit is overlapped execution of > commands. [explanation of why streaming commands is tricky on the server side is skipped] OK, I had to choose the phrasing more carefully. Please, allow me to rephrase: What DOES it mean to support streaming commands server side in context of 'streaming APPEND' vs. MULTI-APPEND? In either case the user will probably be presented with some pop-up message box or some revolving sand clock or whatever indication to the fact, that the client is currently involved in time consuming operation. Unless there's a mechanism in MULTIAPPEND for aborting the transfer? But how?... In short, streaming commands is tricky. But not always. There's at least one place where it seems to be OK, and that is multiple APPENDs. -- Dmitry Rubinstein From owner-ietf-imapext Mon Oct 4 04:07:35 1999 Received: by mail.imc.org (8.9.3/8.9.3) id EAA01616 for ietf-imapext-bks; Mon, 4 Oct 1999 04:07:35 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id EAA01612 for ; Mon, 4 Oct 1999 04:07:33 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27190; Mon, 4 Oct 1999 07:08:16 -0400 (EDT) Message-Id: <199910041108.HAA27190@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-gahrns-imap-language-01.txt Date: Mon, 04 Oct 1999 07:08:15 -0400 Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IMAP4 Language Extension Author(s) : M. Gahrns Filename : draft-gahrns-imap-language-01.txt Pages : 8 Date : 01-Oct-99 The Internet Message Access Protocol [RFC-2060] allows server responses to include human-readable text that in many cases needs to be presented to the user. This document specifies a way for a client to negotiate which language the server should use when sending human-readable text. It provides an extensible mechanism so that it may be used as a framework for full internationalization of other IMAP extensions such as SORT. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-gahrns-imap-language-01.txt 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-gahrns-imap-language-01.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-gahrns-imap-language-01.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: <19991001073726.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-gahrns-imap-language-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-gahrns-imap-language-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991001073726.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-imapext Mon Oct 4 08:07:48 1999 Received: (from majordomo@localhost) by mail.imc.org (8.9.3/8.9.3) id IAA07541 for ietf-imapext-bks; Mon, 4 Oct 1999 08:07:48 -0700 (PDT) Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id IAA07537 for ; Mon, 4 Oct 1999 08:07:46 -0700 (PDT) Received: from PTROUTE.dfpt.extest.microsoft.com (PTROUTE [172.30.236.83]) by doggate.exchange.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id TYGSNGTN; Mon, 4 Oct 1999 08:08:28 -0700 Received: from PTDOG.dfpt.extest.microsoft.com ([172.30.236.159]) by PTROUTE.dfpt.extest.microsoft.com with Microsoft SMTPSVC(5.0.2124.15.0.2124.1); Mon, 4 Oct 1999 08:10:28 -0700 Received: from mikega9 ([172.30.46.130]) by PTDOG.dfpt.extest.microsoft.com with Microsoft SMTPSVC(5.0.2124.15.0.2124.1); Mon, 4 Oct 1999 08:10:25 -0700 Message-ID: <001101bf0e7a$36de98e0$3cc1d13f@gwcc.com> From: "Mike Gahrns" To: Cc: References: <04855D0BAA0ED311BA7800A0C9C74D0F0DDDAE@PTDOG.dfpt.extest.microsoft.com> <37F82413.32BA78F6@messagingdirect.com> Subject: Re: draft-gahrns-imap-language-01 Date: Mon, 4 Oct 1999 08:07:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-OriginalArrivalTime: 04 Oct 1999 15:10:25.0464 (UTC) FILETIME=[95F9D380:01BF0E7A] Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Hi Alexey, *** Comments within. P.S. I will have very limited access to e-mail the next 2.5 weeks, so I will be slow in responding to any comments. > Hi Mike, > > Here is some comments about the last draft: > > 1). If server supports both LANGUAGE and NAMESPACE it MUST return NAMESPACE > response: > I would rather replace MUST with SHOULD, because when you describe TRANSLATION, you > says that > TRANSLATION response SHOULD be sent. So if TRANSLATION response couldn't be sent and > NAMESPACE hasn't been changed - why send NAMESPACE response at all? *** To make it a MUST was a request I receivedd on the previous draft. The rational was that it made it slightly easier for clients if they knew to always expect a NAMESPACE response (if the server supports NAMESPACE). I don't have strong feelings here, either way, but tend to agree that always sending the response could make things simpler. > > 2). LANGUAGE_Command = "LANGUAGE" [SP ] [*EXTENSION] > ; A client should not issue the optional extension parameter > ; unless a server has indicated in its capabilities that it > ; supports that extension > > I can't imagine any case when you want to use LANGUAGE command without specifying > language_tag. If somebody really wants this capability, I suggest to create new > command. So, my proposition is > > LANGUAGE_Command = "LANGUAGE" [SP [*EXTENSION] ] *** In earlier discussions, it was thought that being able to enumerate the languages available on the server would be helpful. I agree, if at only for diagnosis purposes. > > 3). EXTENSION = SP "(" string SP "(" string *(SP string)")" ")" > > I suspect that first parameter in the list is LANGUAGE extension name. I prefer to > mention that. **** this is correct and I good suggestion I will incorporate into a future revision > > 4). Primary language: Accordingly to Alvestrand RFC language tag is not always > hierarchical. This means that you can't always assume that x-y-z is sublanguage of x-y. > This means that server should have some additional knowledge about languages it > supports. *** Can you suggest some text to address this? > > 5). Does TRANSLATION NAMESPACE extension eliminates the need to change namespace > prefixes? *** Yes, that is the idea. (this would allow for things like preserving urls across messages, and leave it up to the client to translate namespaces if necessary) > I would suggest adding something like "SHOULD NOT change namespace prefix" *** I can add this. > > > Alexey > From owner-ietf-imapext Mon Oct 4 10:17:45 1999 Received: by mail.imc.org (8.9.3/8.9.3) id KAA10887 for ietf-imapext-bks; Mon, 4 Oct 1999 10:17:45 -0700 (PDT) Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id KAA10883 for ; Mon, 4 Oct 1999 10:17:43 -0700 (PDT) Received: from chagall.esys.ca by rembrandt.esys.ca (local) with ESMTP; Mon, 4 Oct 1999 11:18:41 -0700 From: Alexey Melnikov Date: Mon, 4 Oct 1999 11:21:12 -0600 To: Mike Gahrns Subject: Re: draft-gahrns-imap-language-01 Cc: ietf-imapext@imc.org, Alexey.Melnikov@messagingdirect.com In-Reply-To: <001101bf0e7a$36de98e0$3cc1d13f@gwcc.com> References: <001101bf0e7a$36de98e0$3cc1d13f@gwcc.com> <04855D0BAA0ED311BA7800A0C9C74D0F0DDDAE@PTDOG.dfpt.extest.microsoft.com> <37F82413.32BA78F6@messagingdirect.com> Message-ID: X-Mailer: Execmail for Win32 5.1 b1 Build (1) -- Evaluation Copy MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Mon, 4 Oct 1999 08:07:44 -0700 Mike Gahrns wrote: > Hi Alexey, > > *** Comments within. > > P.S. I will have very limited access to e-mail the next 2.5 weeks, so I > will be slow in responding to any comments. > > > > > Hi Mike, > > > > Here is some comments about the last draft: > > > > 1). If server supports both LANGUAGE and NAMESPACE it MUST return > NAMESPACE > > response: > > I would rather replace MUST with SHOULD, because when you describe > TRANSLATION, you > > says that > > TRANSLATION response SHOULD be sent. So if TRANSLATION response couldn't > be sent and > > NAMESPACE hasn't been changed - why send NAMESPACE response at all? > *** To make it a MUST was a request I receivedd on the previous draft. The > rational was that it made it slightly easier for clients if they knew to > always expect a NAMESPACE response (if the server supports NAMESPACE). I > don't have strong feelings here, either way, but tend to agree that always > sending the response could make things simpler. > I don't mind, but draft should state that explicitely. Without this comment "MUST" doesn't make sense. > > 2). LANGUAGE_Command = "LANGUAGE" [SP ] [*EXTENSION] > > ; A client should not issue the optional extension parameter > > ; unless a server has indicated in its capabilities that it > > ; supports that extension > > > > I can't imagine any case when you want to use LANGUAGE command without > specifying > > language_tag. If somebody really wants this capability, I suggest to > create new > > command. So, my proposition is > > > > LANGUAGE_Command = "LANGUAGE" [SP [*EXTENSION] ] > *** In earlier discussions, it was thought that being able to enumerate the > languages available on the server would be helpful. I agree, if at only for > diagnosis purposes. I meant other case: Does something like "LANGUAGE (extension1 data1)" make sense? What is the semantics of this command. > > 4). Primary language: Accordingly to Alvestrand RFC language tag is not > always > > hierarchical. This means that you can't always assume that x-y-z is > sublanguage of x-y. > > This means that server should have some additional knowledge about > languages it > > supports. > *** Can you suggest some text to address this? Yes, I will. --------------- Alexey Melnikov Software Developer phone: (780) 424 4922 x 357 MessagingDirect Ltd. fax : (780) 424 4925 mailto:mel@messagingdirect.com http://www.MessagingDirect.com * This e-mail message was sent with Execmail V5.0 * From owner-ietf-imapext Mon Oct 4 11:53:37 1999 Received: by mail.imc.org (8.9.3/8.9.3) id LAA13666 for ietf-imapext-bks; Mon, 4 Oct 1999 11:53:37 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (seung@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id LAA13662 for ; Mon, 4 Oct 1999 11:53:36 -0700 (PDT) Date: Mon, 4 Oct 1999 11:25:22 -0700 (PDT) From: Mark Crispin Subject: Re: draft-gahrns-imap-language-01 To: Alexey Melnikov cc: Mike Gahrns , ietf-imapext@imc.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Although I understand the motivation for the TRANSLATION extension to NAMESPACE, I feel that there is a major problem with it. The example shows a namespace called "Other Users/" with a translation of "Autres Utilisateurs/". Leaving aside the bogosity of the missing "#" (particularly in light of the personal namespace), this example is going to give certain individuals a strong feeling that "Autres Utilisateurs/" is a valid namespace name. This, in turn, implies that it is valid to use it in URLs. I strongly oppose localization of strings that could appear in a mailbox name and/or a URL. It's enough of a problem that they can be internationalized. I suggest instead that we add a field in namespace called COMMENT or DESCRIPTION, and that this new field can be localized. This opens the possibility for this field to be English; #public/ and #shared/ are very two different things in my server, but that fact is not obvious from those names. Since this no longer changes the namespace names, the draft can be simplied and the troublesome rules between LANGUAGE and NAMESPACE can be deleted. This has another desirable effect. It may break client implementors of the deplorable habit of treating the NAMESPACE command as simply another level of hierarchy to a common root. I've learned not to underestimate the grim determination of certain client vendors to do the wrong thing in the face of intense pressure from the specification otherwise. ;-) But, maybe by having the localized string as a comment, it may tip the balance towards treating namespaces as independent hierarchies. From owner-ietf-imapext Mon Oct 4 12:05:06 1999 Received: by mail.imc.org (8.9.3/8.9.3) id MAA13992 for ietf-imapext-bks; Mon, 4 Oct 1999 12:05:06 -0700 (PDT) Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id MAA13985 for ; Mon, 4 Oct 1999 12:05:04 -0700 (PDT) Received: from PTROUTE.dfpt.extest.microsoft.com (PTROUTE [172.30.236.83]) by doggate.exchange.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id TYGSNJX4; Mon, 4 Oct 1999 12:05:46 -0700 Received: from PTDOG.dfpt.extest.microsoft.com ([172.30.236.159]) by PTROUTE.dfpt.extest.microsoft.com with Microsoft SMTPSVC(5.0.2124.15.0.2124.1); Mon, 4 Oct 1999 12:07:52 -0700 Received: from mikega9 ([172.30.44.166]) by PTDOG.dfpt.extest.microsoft.com with Microsoft SMTPSVC(5.0.2124.15.0.2124.1); Mon, 4 Oct 1999 12:07:51 -0700 Message-ID: <000f01bf0e9b$60d7d320$3cc1d13f@gwcc.com> From: "Mike Gahrns" To: "Alexey Melnikov" Cc: References: <001101bf0e7a$36de98e0$3cc1d13f@gwcc.com> <04855D0BAA0ED311BA7800A0C9C74D0F0DDDAE@PTDOG.dfpt.extest.microsoft.com> <37F82413.32BA78F6@messagingdirect.com> Subject: Prohibitting enumaration of languages when specifying an extension Date: Mon, 4 Oct 1999 12:05:08 -0700 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 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-OriginalArrivalTime: 04 Oct 1999 19:07:51.0180 (UTC) FILETIME=[C11594C0:01BF0E9B] Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: *** Within > > > 2). LANGUAGE_Command = "LANGUAGE" [SP ] [*EXTENSION] > > > ; A client should not issue the optional extension parameter > > > ; unless a server has indicated in its capabilities that it > > > ; supports that extension > > > > > > I can't imagine any case when you want to use LANGUAGE command without > > specifying > > > language_tag. If somebody really wants this capability, I suggest to > > create new > > > command. So, my proposition is > > > > > > LANGUAGE_Command = "LANGUAGE" [SP [*EXTENSION] ] > > *** In earlier discussions, it was thought that being able to enumerate the > > languages available on the server would be helpful. I agree, if at only for > > diagnosis purposes. > > I meant other case: Does something like "LANGUAGE (extension1 data1)" > make sense? What is the semantics of this command. *** I am not sure how this would be used, but thought that we shouldn't artificially limit this in case some extension wanted it. e.g. Give me the LIST of server languages that are supported by server, and then pass in the FOO extension parameter. Perhaps the FOO extension without any tags would mean list in a response the languages you support for the FOO extension.... From owner-ietf-imapext Mon Oct 4 17:22:34 1999 Received: by mail.imc.org (8.9.3/8.9.3) id RAA19203 for ietf-imapext-bks; Mon, 4 Oct 1999 17:22:34 -0700 (PDT) Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id RAA19197 for ; Mon, 4 Oct 1999 17:22:33 -0700 (PDT) Received: from messagingdirect.com (actually chagall.esys.ca) by rembrandt.esys.ca (local) with ESMTP; Mon, 4 Oct 1999 18:21:27 -0700 Message-ID: <37F9451F.58B6D7F7@messagingdirect.com> Date: Mon, 04 Oct 1999 18:23:59 -0600 From: Alexey Melnikov X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Gahrns CC: ietf-imapext@imc.org Subject: Re: Prohibitting enumaration of languages when specifying an extension References: <001101bf0e7a$36de98e0$3cc1d13f@gwcc.com> <04855D0BAA0ED311BA7800A0C9C74D0F0DDDAE@PTDOG.dfpt.extest.microsoft.com> <37F82413.32BA78F6@messagingdirect.com> <000f01bf0e9b$60d7d320$3cc1d13f@gwcc.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Mike Gahrns wrote: > *** Within > > > > > 2). LANGUAGE_Command = "LANGUAGE" [SP ] [*EXTENSION] > > > > ; A client should not issue the optional extension parameter > > > > ; unless a server has indicated in its capabilities that it > > > > ; supports that extension > > > > > > > > I can't imagine any case when you want to use LANGUAGE command without > > > specifying > > > > language_tag. If somebody really wants this capability, I suggest to > > > create new > > > > command. So, my proposition is > > > > > > > > LANGUAGE_Command = "LANGUAGE" [SP [*EXTENSION] ] > > > *** In earlier discussions, it was thought that being able to enumerate > the > > > languages available on the server would be helpful. I agree, if at only > for > > > diagnosis purposes. > > > > I meant other case: Does something like "LANGUAGE (extension1 data1)" > > make sense? What is the semantics of this command. > *** I am not sure how this would be used, but thought that we shouldn't > artificially limit this in case some extension wanted it. e.g. Give me > the LIST of server languages that are supported by server, and then pass in > the FOO extension parameter. Perhaps the FOO extension without any tags > would mean list in a response the languages you support for the FOO > extension.... This make sense. Alexey From owner-ietf-imapext Thu Oct 7 08:23:54 1999 Received: by mail.imc.org (8.9.3/8.9.3) id IAA17714 for ietf-imapext-bks; Thu, 7 Oct 1999 08:23:54 -0700 (PDT) Received: from colin.iconmedialab.fi (colin.iconmedialab.fi [193.66.237.50]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id IAA17709 for ; Thu, 7 Oct 1999 08:23:51 -0700 (PDT) Received: from iconmedialab.fi (pispala.iconmedialab.fi [193.65.176.91]) by colin.iconmedialab.fi (8.9.3/8.9.3) with ESMTP id SAA26258 for ; Thu, 7 Oct 1999 18:24:49 +0300 (EET DST) Message-ID: <37FCBB3F.40CEA9C2@iconmedialab.fi> Date: Thu, 07 Oct 1999 18:24:47 +0300 From: Marko Karppinen Reply-To: marko.karppinen@iconmedialab.fi Organization: Icon Medialab X-Mailer: Mozilla 4.7 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ietf-imapext@imc.org Subject: draft-karppinen-imap-conman-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, I'm just writing to let you all know that a new extension to the IMAP4 protocol is being proposed in our new Internet-Draft, available from: http://www.ietf.org/internet-drafts/draft-karppinen-imap-conman-00.txt The basic idea is to allow multiple user sessions during a single socket connection to an IMAP4 server. The context in which this proved to be neccessary involves internal components of a web based email service. However special our application may seem, we at Icon Medialab and Chek believe that standardizing this sort of functionality before it gets implemented in various different ways is in everyone's interests. We hope our Internet-Draft is a good starting point in discussing the need and possible implementations for this new functionality. Best regards, Marko Karppinen Icon Medialab On behalf of the authors -- "Difficult to see, it is... always in motion is the future." From owner-ietf-imapext Thu Oct 7 10:02:09 1999 Received: (from majordomo@localhost) by mail.imc.org (8.9.3/8.9.3) id KAA20492 for ietf-imapext-bks; Thu, 7 Oct 1999 10:02:09 -0700 (PDT) Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id KAA20488 for ; Thu, 7 Oct 1999 10:02:07 -0700 (PDT) Received: from PTROUTE.dfpt.extest.microsoft.com (PTROUTE [172.30.236.83]) by doggate.exchange.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id 42Y6993F; Thu, 7 Oct 1999 10:03:03 -0700 Received: from PTPUP.dfpt.extest.microsoft.com ([172.30.236.191]) by PTROUTE.dfpt.extest.microsoft.com with Microsoft SMTPSVC(5.0.2124.15.0.2124.1); Thu, 7 Oct 1999 10:05:06 -0700 Thread-Index: Ab8Q2V2JEZdYrYRmR/+7+zukABEETAAC4f7g content-class: urn:content-classes:message From: "Larry Osterman \(Platinum\)" To: , Subject: RE: draft-karppinen-imap-conman-00.txt Date: Thu, 7 Oct 1999 10:04:57 -0700 Message-ID: <6FAB07F22809D311830C00A0C9C74EB90188FCAB@PTPUP.dfpt.extest.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_27A1E_01BF10AB.6E0F9430" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-karppinen-imap-conman-00.txt X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.5600 X-OriginalArrivalTime: 07 Oct 1999 17:05:06.0827 (UTC) FILETIME=[1AD3BDB0:01BF10E6] Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_27A1E_01BF10AB.6E0F9430 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I might humbly suggest that there are easier ways of acheiving your desired goals than extending the protocol. For example, there's no requirement that you run the IMAP server in a "one-process-per-connection" mode. This DOES simplify some aspects of the IMAP logic, but (as you have noted) the costs of creating and destroying a process per connection can be overwhelming. There are alternative models for the networking logic that do not require one process per connection, for example, you could use a thread per connection, or (if your platform supports it) use an asynchronous I/O which allows a few threads to process all the I/O for your client. I would strongly encourage you to investigate these possibilities, otherwise I suspect that you will discover that you STILL have performance issues, all this change does is to move the choke-point location. Larry Osterman Sent from larryo-laptop.dns.microsoft.com running NT5 and Outlook 2000 and Exchange Server 5.5. Please notify the sender of any difficulties > -----Original Message----- > From: owner-ietf-imapext@imc.org [mailto:owner-ietf-imapext@imc.org]On > Behalf Of Marko Karppinen > Sent: Thursday, October 07, 1999 8:25 AM > To: ietf-imapext@imc.org > Subject: draft-karppinen-imap-conman-00.txt >=20 >=20 > Hi, >=20 > I'm just writing to let you all know that a new extension to the > IMAP4 protocol is being proposed in our new Internet-Draft, > available from: >=20 > http://www.ietf.org/internet-drafts/draft-karppinen-imap-conman-00.txt >=20 > The basic idea is to allow multiple user sessions during a > single socket connection to an IMAP4 server. The context > in which this proved to be neccessary involves internal > components of a web based email service. However special > our application may seem, we at Icon Medialab and Chek believe > that standardizing this sort of functionality before it gets > implemented in various different ways is in everyone's interests. >=20 > We hope our Internet-Draft is a good starting point in discussing > the need and possible implementations for this new functionality. >=20 > Best regards, >=20 > Marko Karppinen > Icon Medialab >=20 > On behalf of the authors >=20 > -- > "Difficult to see, it is... always in motion is the future." >=20 ------=_NextPart_000_27A1E_01BF10AB.6E0F9430 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-karppinen-imap-conman-00.txt

I might humbly suggest that there are easier ways of = acheiving your desired goals than extending the protocol.  For = example, there's no requirement that you run the IMAP server in a = "one-process-per-connection" mode.  This DOES simplify = some aspects of the IMAP logic, but (as you have noted) the costs of = creating and destroying a process per connection can be = overwhelming.

There are alternative models for the networking logic = that do not require one process per connection, for example, you could = use a thread per connection, or (if your platform supports it) use an = asynchronous I/O which allows a few threads to process all the I/O for = your client.  I would strongly encourage you to investigate these = possibilities, otherwise I suspect that you will discover that you STILL = have performance issues, all this change does is to move the choke-point = location.

Larry Osterman
Sent from larryo-laptop.dns.microsoft.com running NT5 = and Outlook 2000
and Exchange Server 5.5.  Please notify the = sender of any difficulties



> -----Original Message-----
> From: owner-ietf-imapext@imc.org [mailto:owner-ietf-imapext@imc.= org]On
> Behalf Of Marko Karppinen
> Sent: Thursday, October 07, 1999 8:25 AM
> To: ietf-imapext@imc.org
> Subject: = draft-karppinen-imap-conman-00.txt
>
>
> Hi,
>
> I'm just writing to let you all know that a new = extension to the
> IMAP4 protocol is being proposed in our new = Internet-Draft,
> available from:
>
> http://www.ietf.org/internet-drafts/draft-karppinen-ima= p-conman-00.txt
>
> The basic idea is to allow multiple user = sessions during a
> single socket connection to an IMAP4 server. The = context
> in which this proved to be neccessary involves = internal
> components of a web based email service. However = special
> our application may seem, we at Icon Medialab = and Chek believe
> that standardizing this sort of functionality = before it gets
> implemented in various different ways is in = everyone's interests.
>
> We hope our Internet-Draft is a good starting = point in discussing
> the need and possible implementations for this = new functionality.
>
> Best regards,
>
> Marko Karppinen
> Icon Medialab
>
> On behalf of the authors
>
> --
> "Difficult to see, it is... always in = motion is the future."
>

------=_NextPart_000_27A1E_01BF10AB.6E0F9430-- From owner-ietf-imapext Thu Oct 7 10:20:13 1999 Received: by mail.imc.org (8.9.3/8.9.3) id KAA21332 for ietf-imapext-bks; Thu, 7 Oct 1999 10:20:13 -0700 (PDT) Received: from zappa.esys.ca (zappa.esys.ca [198.161.92.28]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id KAA21324 for ; Thu, 7 Oct 1999 10:20:11 -0700 (PDT) Received: (from lyndon@localhost) by zappa.esys.ca (8.9.3/8.9.3) id LAA700462; Thu, 7 Oct 1999 11:21:10 -0600 (MDT) Message-Id: <199910071721.LAA700462@zappa.esys.ca> To: marko.karppinen@iconmedialab.fi, ietf-imapext@imc.org Subject: Re: draft-karppinen-imap-conman-00.txt In-reply-to: Your message of "Thu, 07 Oct 1999 10:04:57 PDT." <6FAB07F22809D311830C00A0C9C74EB90188FCAB@PTPUP.dfpt.extest.microsoft.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Date: Thu, 07 Oct 1999 11:21:09 -0600 From: Lyndon Nerenberg Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: There's another problem with this. It's not going to work in the presence of SASL session integrity or protection. There's no provision in 2060 for turning either of these off once they've been established, and I don't see how an extension could change the base spec in a manner that allowed this without resetting the standards-track clock. As Barry said, deficiencies in the implementation should be fixed in the implementation. (I can say that, because we just went through this specific exercise :-) --lyndon From owner-ietf-imapext Thu Oct 7 11:10:29 1999 Received: by mail.imc.org (8.9.3/8.9.3) id LAA23839 for ietf-imapext-bks; Thu, 7 Oct 1999 11:10:29 -0700 (PDT) Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id LAA23832 for ; Thu, 7 Oct 1999 11:10:22 -0700 (PDT) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.122.2]) by smtp1.andrew.cmu.edu (8.9.3/8.9.3) with SMTP id OAA07747; Thu, 7 Oct 1999 14:11:12 -0400 (EDT) Date: 7 Oct 1999 14:11:17 -0400 Message-ID: From: Lawrence Greenfield X-Mailer: BatIMail version 3.2 To: ietf-imapext@imc.org, marko.karppinen@iconmedialab.fi In-reply-to: <199910071721.LAA700462@zappa.esys.ca> Subject: Re: draft-karppinen-imap-conman-00.txt References: <199910071721.LAA700462@zappa.esys.ca> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: There's another problem with this. It's not going to work in the presence of SASL session integrity or protection. There's no provision in 2060 for turning either of these off once they've been established, and I don't see how an extension could change the base spec in a manner that allowed this without resetting the standards-track clock. The SASL specification says that a layer ends when another layer is turned on, but that doesn't help with the other problems. As Barry said, deficiencies in the implementation should be fixed in the implementation. (I can say that, because we just went through this specific exercise :-) I've considered adding a PROXY command so that a suitably privileged user can do something like: A001 PROXY leg LIST "" "*imap*" for some thoughts I've had about IMAP proxys to help with scalability, I've come to the conclusion that almost any of this is best done outside of the protocol. The PROXY command would be a pain (without adding that much) to work with SELECT or any more complicated commands than LIST, etc. Larry From owner-ietf-imapext Thu Oct 7 11:23:30 1999 Received: (from majordomo@localhost) by mail.imc.org (8.9.3/8.9.3) id LAA24525 for ietf-imapext-bks; Thu, 7 Oct 1999 11:23:30 -0700 (PDT) Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id LAA24520 for ; Thu, 7 Oct 1999 11:23:29 -0700 (PDT) Received: from PTROUTE.dfpt.extest.microsoft.com (PTROUTE [172.30.236.83]) by doggate.exchange.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id 42Y699VS; Thu, 7 Oct 1999 11:24:28 -0700 Received: from PTPUP.dfpt.extest.microsoft.com ([172.30.236.191]) by PTROUTE.dfpt.extest.microsoft.com with Microsoft SMTPSVC(5.0.2124.15.0.2124.1); Thu, 7 Oct 1999 11:26:32 -0700 Thread-Index: Ab8Q8CYmu4e0lDjAQyGjuatvJBgWwQAAFKmg content-class: urn:content-classes:message From: "Larry Osterman \(Platinum\)" To: "Lawrence Greenfield" , , Subject: RE: draft-karppinen-imap-conman-00.txt Date: Thu, 7 Oct 1999 11:26:28 -0700 Message-ID: <6FAB07F22809D311830C00A0C9C74EB9573AF3@PTPUP.dfpt.extest.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_2A01F_01BF10B6.CE534840" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-karppinen-imap-conman-00.txt X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.5600 X-OriginalArrivalTime: 07 Oct 1999 18:26:32.0468 (UTC) FILETIME=[7AE56540:01BF10F1] Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_2A01F_01BF10B6.CE534840 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In general, "proxy" is virtually indistinguishable from "tunneling", and it is almost always a bad idea. The only place that I know of where tunneling is reasonable is when passing through a firewall, otherwise it's a nightmare. And I know of NO situation where tunneling increases scalability, because the throughput is almost always limited by the throughput of the proxy server. What is more interesting w.r.t. scalability is the Front-End/Back-End scenario where the client talks to one of several front-end machines each of which shares the same DNS A record (ie imap.myisp.net). The front-end machine then uses some protocol (possibly IMAP, possibly CIFS, possibly NFS) to talk to the actual message store. A solution of this nature allows 2-way scalability without impacting the client - if you overload your front-end machines, you can simply add more without changing client configuration, similarly, if you find you are overloading your back-end servers, you can again add more of them if necessary. Larry Osterman Sent from larryo-laptop.dns.microsoft.com running NT5 and Outlook 2000 and Exchange Server 5.5. Please notify the sender of any difficulties > -----Original Message----- > From: owner-ietf-imapext@imc.org [mailto:owner-ietf-imapext@imc.org]On > Behalf Of Lawrence Greenfield > Sent: Thursday, October 07, 1999 11:11 AM > To: ietf-imapext@imc.org; marko.karppinen@iconmedialab.fi > Subject: Re: draft-karppinen-imap-conman-00.txt=20 >=20 >=20 > There's another problem with this. It's not going to work in > the presence of SASL session integrity or protection. There's > no provision in 2060 for turning either of these off once they've > been established, and I don't see how an extension could change > the base spec in a manner that allowed this without resetting the > standards-track clock. >=20 > The SASL specification says that a layer ends when another layer is > turned on, but that doesn't help with the other problems. >=20 > As Barry said, deficiencies in the implementation should be fixed > in the implementation. (I can say that, because we just=20 > went through > this specific exercise :-)=20 >=20 > I've considered adding a PROXY command so that a suitably privileged > user can do something like: >=20 > A001 PROXY leg LIST "" "*imap*" >=20 > for some thoughts I've had about IMAP proxys to help with scalability, > I've come to the conclusion that almost any of this is best done > outside of the protocol. The PROXY command would be a pain (without > adding that much) to work with SELECT or any more complicated commands > than LIST, etc. >=20 > Larry >=20 ------=_NextPart_000_2A01F_01BF10B6.CE534840 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-karppinen-imap-conman-00.txt

In general, "proxy" is virtually = indistinguishable from "tunneling", and it is almost always a = bad idea.  The only place that I know of where tunneling is = reasonable is when passing through a firewall, otherwise it's a = nightmare.  And I know of NO situation where tunneling increases = scalability, because the throughput is almost always limited by the = throughput of the proxy server.

What is more interesting w.r.t. scalability is the = Front-End/Back-End scenario where the client talks to one of several = front-end machines each of which shares the same DNS A record (ie = imap.myisp.net).  The front-end machine then uses some protocol = (possibly IMAP, possibly CIFS, possibly NFS) to talk to the actual = message store.  A solution of this nature allows 2-way scalability = without impacting the client - if you overload your front-end machines, = you can simply add more without changing client configuration, = similarly, if you find you are overloading your back-end servers, you = can again add more of them if necessary.

Larry Osterman
Sent from larryo-laptop.dns.microsoft.com running NT5 = and Outlook 2000
and Exchange Server 5.5.  Please notify the = sender of any difficulties



> -----Original Message-----
> From: owner-ietf-imapext@imc.org [mailto:owner-ietf-imapext@imc.= org]On
> Behalf Of Lawrence Greenfield
> Sent: Thursday, October 07, 1999 11:11 AM
> To: ietf-imapext@imc.org; = marko.karppinen@iconmedialab.fi
> Subject: Re: draft-karppinen-imap-conman-00.txt =
>
>
>    There's another problem with = this. It's not going to work in
>    the presence of SASL session = integrity or protection. There's
>    no provision in 2060 for = turning either of these off once they've
>    been established, and I don't = see how an extension could change
>    the base spec in a manner that = allowed this without resetting the
>    standards-track clock.
>
> The SASL specification says that a layer ends = when another layer is
> turned on, but that doesn't help with the other = problems.
>
>    As Barry said, deficiencies in = the implementation should be fixed
>    in the implementation. (I can = say that, because we just
> went through
>    this specific exercise :-) =
>
> I've considered adding a PROXY command so that a = suitably privileged
> user can do something like:
>
> A001 PROXY leg LIST "" = "*imap*"
>
> for some thoughts I've had about IMAP proxys to = help with scalability,
> I've come to the conclusion that almost any of = this is best done
> outside of the protocol.  The PROXY command = would be a pain (without
> adding that much) to work with SELECT or any = more complicated commands
> than LIST, etc.
>
> Larry
>

------=_NextPart_000_2A01F_01BF10B6.CE534840-- From owner-ietf-imapext Thu Oct 7 11:20:54 1999 Received: by mail.imc.org (8.9.3/8.9.3) id LAA24396 for ietf-imapext-bks; Thu, 7 Oct 1999 11:20:54 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (rfort@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id LAA24392 for ; Thu, 7 Oct 1999 11:20:52 -0700 (PDT) Date: Thu, 7 Oct 1999 10:08:05 -0700 (PDT) From: Mark Crispin Subject: RE: draft-karppinen-imap-conman-00.txt To: marko.karppinen@iconmedialab.fi cc: ietf-imapext@imc.org In-Reply-To: <6FAB07F22809D311830C00A0C9C74EB90188FCAB@PTPUP.dfpt.extest.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Unfortunately, I have to concur with Larry and Lyndon. Internet history is littered with ideas that were technically excellent and would have provided a useful facility, but were nonetheless unsuccessful. I'm afraid this is one of them. This is not the first time this idea has been proposed for IMAP, but the same reluctant conclusion resulted. The problem is that the perceived need for this facility in IMAP is based upon two assumptions: 1) The IMAP protocol requires one process per connection. 2) The costs of creating and destroying a process per connection are high. If either assumption is false, the need collapses. Examples can be found that demonstrate either (or both) assumption(s), but that does not mean that the assumptions are valid in all cases. As Larry and Lydon have pointed out, assumption (1) is particularly weak. Assumption (2) also has clay feet; process creation/destruction is slow because OS vendors have never felt the need to fix it. I can guarantee that if a multi-billion dollar contract for Microsoft depended upon fast process management, the next version of NT would be blindingly fast. ;-) Another way around this would be if the operating system allowed process recycling; that is, instead of the process being destroyed upon log out, that it be permitted to place itself into a "standby" state. In "standby", it regains root and is suspended at its start address. [Leaving aside the small matter of programming here...but implementing conman would also require programming, and in every client and server for every affected protocol.] There's a third assumption, which is completely false and fatal to the proposal: (3) The servers that could benefit from this proposal would implement it. Unfortunately, this won't happen. In the case of my server, it won't happen. The entire security model of my server depends upon one process per connection; servers setuid() themselves to the target user to discard their root privileges irrecoverably, and all access control is done by file system protections. In order to implement conman, I would have to create an entirely different security model. But if I did that, there would be no reason to maintain the current "one process per connection" other than laziness. If I am lazy, I wouldn't implement conman; if I am not lazy, I'd use a architecture such as threading and conman would be unnecessary. In conclusion, conman is unnecesary in those servers in which it would be relatively easy to implement it; in the servers which conman would benefit, it is incredibly difficult to implement and it would be easier to solve the problem with a different server architecture. Plus, a different server architecture would not require any client changes. From owner-ietf-imapext Thu Oct 7 13:20:13 1999 Received: (from majordomo@localhost) by mail.imc.org (8.9.3/8.9.3) id NAA29399 for ietf-imapext-bks; Thu, 7 Oct 1999 13:20:13 -0700 (PDT) Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id NAA29393 for ; Thu, 7 Oct 1999 13:20:10 -0700 (PDT) Received: from dns.maillennium.att.com ([135.25.114.99]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id QAA07765 for ; Thu, 7 Oct 1999 16:21:10 -0400 (EDT) Received: from att.com ([135.197.90.156]) by maillennium.att.com (labmail) with SMTP id <1999100720185109916130rfe>; Thu, 7 Oct 1999 20:18:51 +0000 Message-ID: <37FD0088.FF64AE3F@att.com> Date: Thu, 07 Oct 1999 16:20:24 -0400 From: Tony Hansen Organization: AT&T Laboratories X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-imapext@imc.org Subject: Re: draft-karppinen-imap-conman-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Marko Karppinen wrote: > > I'm just writing to let you all know that a new extension to the > IMAP4 protocol is being proposed in our new Internet-Draft, > available from: > http://www.ietf.org/internet-drafts/draft-karppinen-imap-conman-00.txt > The basic idea is to allow multiple user sessions during a > single socket connection to an IMAP4 server. The context > in which this proved to be neccessary involves internal > components of a web based email service. However special > our application may seem, we at Icon Medialab and Chek believe > that standardizing this sort of functionality before it gets > implemented in various different ways is in everyone's interests. In a similar context, we were forced to implement a private extension almost exactly like USERLOGOUT and have found it EXTREMELY useful. We'd love to switch to a standard name for the capability. So far, the arguments I've seen against it seem somewhat specious. Larry wrote: > For example, there's no requirement that you run the > IMAP server in a "one-process-per-connection" mode. Mark wrote: > The problem is that the perceived need for this facility in IMAP is based upon > two assumptions: > 1) The IMAP protocol requires one process per connection. No, there's no such assumption in this extension. The two concepts are totally orthogonal. Each IMAP connection is a totally separate entity, in and of itself, whether it maps into a thread on the server, or a process, or whatever. Being able to manage those connections in a way that lets the client reuse them is useful, for SOME CLIENTS. > 2) The costs of creating and destroying a process per connection are high. > > Assumption (2) also has clay feet; process creation/destruction is slow > because OS vendors have never felt the need to fix it. Bad assumption in the counter argument, as this may not have anything to do with creating and destroying a process per connection. If the server were implemented using threads, or some other paradigm that avoids process creation and destruction per connection, the fact remains that the very act of creating a socket connection is expensive on most current OS's. Maybe someday these limitations will also disappear, but that doesn't mean that the problem doesn't exist today and isn't worth providing for. > There's a third assumption, which is completely false and fatal to the > proposal: > (3) The servers that could benefit from this proposal would implement it. Sorry to disappoint you, Mark. You need to look at this from total system perspective. It's not the servers that would benefit from the proposal, but instead embedded systems acting as IMAP clients. These clients are using the IMAP servers in certain fashions of which you haven't yet considered all the ramifications. Marko's example of a web based email service is such an embedded system. I work with developers of similar systems as well, and this type of extension has already being implemented for them. The "combination of the client and server both supporting and using this extension" definitely can benefit from the extension, and have already done so. Lyndon wrote: > There's another problem with this. It's not going to work in > the presence of SASL session integrity or protection. There's > no provision in 2060 for turning either of these off once they've > been established, and I don't see how an extension could change > the base spec in a manner that allowed this without resetting the > standards-track clock. Lawrence's reply answers this objection sufficiently: > The SASL specification says that a layer ends when another layer is > turned on, .... No, it's not something that most clients will utilize, nor is it something that all servers need implement. But in some contexts, such as the web-based email service mentioned by Marko, o it is extremely useful in those contexts o it's already been implemented differently in at least two implementations o it's worth standardizing on a single syntax o (from the draft) "persistent IMAP4 connections can lead to a performance increase of an order of magnitude when compared to separate IMAP4 connections per mailbox action" Tony Hansen tony@att.com From owner-ietf-imapext Thu Oct 7 13:45:43 1999 Received: by mail.imc.org (8.9.3/8.9.3) id NAA00458 for ietf-imapext-bks; Thu, 7 Oct 1999 13:45:43 -0700 (PDT) Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id NAA00454 for ; Thu, 7 Oct 1999 13:45:41 -0700 (PDT) Received: from messagingdi