Received: by ns.secondary.com (8.9.3/8.9.3) id PAA18876 for ietf-imapext-bks; Wed, 29 Nov 2000 15:36:21 -0800 (PST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA18869; Wed, 29 Nov 2000 15:36:18 -0800 (PST) Received: from westmail2.West.Sun.COM ([129.153.100.30]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA18254; Wed, 29 Nov 2000 15:37:51 -0800 (PST) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA01239; Wed, 29 Nov 2000 15:37:50 -0800 (PST) Date: Wed, 29 Nov 2000 15:37:09 -0800 From: Chris Newman To: Lyndon Nerenberg cc: IMAP Extensions WG , ietf-imap-voice@imc.org Subject: Re: draft-nerenberg-imap-binary-00.txt Message-ID: <3867275.3184501029@nifty-jr.west.sun.com> In-Reply-To: <200011291833.eATIXXT01603@gollum.esys.ca> X-Mailer: Mulberry/2.0.5 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I read that spec. It addresses point 3 from my previous post, and partially addresses point 1. However, it introduces additional syntax issues: (1a) I'm not convinced that the syntax model is appropriately general for similar conversion operations. While I'm not opposed to binary moving forward by itself, it shouldn't move forward until we are confident that we're not creating lots of special case syntax variants. (1b) I'm not convinced the restriction to leaf nodes is a good idea. For example, a disconnected client which is caching entire messages could recognize a significant performance benefit if it fetched the entire message with all base64/QP encoding that's not in a security multipart removed. (1c) It does not specify a syntax to request the size of a decoded body part. A minor nit -- I wouldn't call a binary literal "literal8". Vanilla IMAP literals already support 8-bit (when appropriately labelled). - Chris --On Wednesday, November 29, 2000 11:33 -0700 Lyndon Nerenberg wrote: > Chris, have you seen the -01 version of the draft? It contains two > substantial changes: > > 1) The command syntax was changed to "FETCH n BINARY[x.y]" > > 2) The literal8 syntax is now "~{nnn}CRLF..." > > The -01 document was submitted last week but isn't yet in the > repository. For now you can FTP it from: > > ftp://ftp.messagingdirect.com/pub/staff/lyndon/drafts/draft-nerenberg-ima > p-bina ry-01.txt > > --lyndon > Received: by ns.secondary.com (8.9.3/8.9.3) id KAA01536 for ietf-imapext-bks; Wed, 29 Nov 2000 10:33:43 -0800 (PST) Received: from gollum.esys.ca (dhcp198-59.esys.ca [198.161.92.59]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA01503; Wed, 29 Nov 2000 10:33:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gollum.esys.ca (8.11.1/8.11.1) with ESMTP id eATIXXT01603; Wed, 29 Nov 2000 11:33:33 -0700 (MST) (envelope-from lyndon@gollum.esys.ca) Message-Id: <200011291833.eATIXXT01603@gollum.esys.ca> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Lyndon Nerenberg To: Chris Newman cc: IMAP Extensions WG , ietf-imap-voice@imc.org Subject: Re: draft-nerenberg-imap-binary-00.txt In-reply-to: Your message of "Tue, 28 Nov 2000 16:20:14 PST." <2540808.3184417214@nifty-jr.west.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Nov 2000 11:33:33 -0700 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Chris, have you seen the -01 version of the draft? It contains two substantial changes: 1) The command syntax was changed to "FETCH n BINARY[x.y]" 2) The literal8 syntax is now "~{nnn}CRLF..." The -01 document was submitted last week but isn't yet in the repository. For now you can FTP it from: ftp://ftp.messagingdirect.com/pub/staff/lyndon/drafts/draft-nerenberg-imap-bina ry-01.txt --lyndon Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA18602 for ietf-imapext-bks; Tue, 28 Nov 2000 16:19:29 -0800 (PST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA18598; Tue, 28 Nov 2000 16:19:27 -0800 (PST) Received: from westmail2.West.Sun.COM ([129.153.100.30]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11817; Tue, 28 Nov 2000 16:20:54 -0800 (PST) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA14702; Tue, 28 Nov 2000 16:20:53 -0800 (PST) Date: Tue, 28 Nov 2000 16:20:14 -0800 From: Chris Newman To: Lyndon Nerenberg cc: IMAP Extensions WG , ietf-imap-voice@imc.org Subject: Re: draft-nerenberg-imap-binary-00.txt Message-ID: <2540808.3184417214@nifty-jr.west.sun.com> In-Reply-To: <200011212238.eALMcK804217@gollum.esys.ca> X-Mailer: Mulberry/2.0.5 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Issues with the binary extension: (1) I concur with Mark's comments about syntax. The current proposed syntax is unacceptable, the XFETCH strawman seems workable (with associated XFETCH response). I could also deal with a fetch-item modifier as an alternative to a new command: C: A002 FETCH 1:5 BODY[1] S: * 1 FETCH (BODY[1] {#}...) or C: A002 FETCH 1:5 BODY[1] S: * 1 FETCH (BODY[1] {#}...) With that syntax, each modifier would have to describe how it interacts with various fetch items, for example, SIZE would return the size after removal of base64/QP encoding. (2) I am currently opposed to a distinguished syntax for binary literals on the grounds that it introduces two silly states: a binary literal with non-binary content and a non-binary literal with binary content. (In unextended IMAP, the latter is simply a protocol violation which robust implementations should detect.) I would much prefer the statement that if the server advertises XFETCH BINARY, then the prohibition on the client sending binary literals for message content is lifted, and if the client issues the XFETCH command with BINARY option, then the prohibition on the server sending binary message content is lifted. (3) If the concensus is against me on point 2, then I object to using a suffix to indicate a binary literal on the grounds that it breaks existing LITERAL+ detectors. That objection would not apply to a prefix character. (4) If a server advertises XFETCH BINARY, that should permit the use of binary CTE and binary literal content in APPEND. (5) An unextended IMAP server is required to convert a body part with a binary CTE to base64. An IMAP message store could receive a binary body part via the binary SMTP extension or an APPEND command (it is currently illegal protocol to have a true binary CTE in an APPEND). If we ever want to support binary body parts signed by PGP or S/MIME, then we need a way to distinguish the canonical CTE from the requested/supplied CTE. I don't have a strong opinion one way or the other, but the issue needs to be considered. (6) BINARY and CHARSET=UTF8 conversions are no brainers (since an IMAP server with a halfway decent SEARCH command already implements them internally). But the CHANNEL model is both very important for conversions not likely to be built into an IMAP server and rather tricky to get right due to security/firewall issues. (7) I suggest we have an XFETCH (MD5) modifier, which computes the MD5 hash of the specified fetch BODY item -- MD5 is just a content conversion which happens to have a fixed size output. May make channel security issues simpler, and could permit verification of PGP or S/MIME signatures without fetching all parts. Note that I believe the CHANNEL mechanism in combination with an extension to the SMTP-SUBMIT protocol is the correct way to provide the ability to forward/resend an attachment without downloading it. - Chris Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA11937 for ietf-imapext-bks; Fri, 24 Nov 2000 10:56:53 -0800 (PST) Received: from gollum.esys.ca (dhcp198-59.esys.ca [198.161.92.59]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA11893; Fri, 24 Nov 2000 10:56:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gollum.esys.ca (8.11.1/8.11.1) with ESMTP id eAOIvDg00977; Fri, 24 Nov 2000 11:57:13 -0700 (MST) (envelope-from lyndon@gollum.esys.ca) Message-Id: <200011241857.eAOIvDg00977@gollum.esys.ca> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Lyndon Nerenberg To: IMAP Extensions WG , ietf-imap-voice@imc.org Subject: IMAP BINARY -01 draft available X-URL: http://www.messagingdirect.com/ Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_-19606496970" Date: Fri, 24 Nov 2000 11:57:13 -0700 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart MIME message. --==_Exmh_-19606496970 Content-Type: text/plain; charset=us-ascii I've upodated the draft to include this weeks feedback. I also fleshed out the missing pieces. At this point I consider it pretty much complete. The I-D submission autoreponder message isn't clear (to me) about whether this will get published before the San Diego meeting. Meanwhile, you can grab a copy from: ftp://ftp.esys.ca/pub/staff/lyndon/drafts/draft-nerenberg-imap-binary-01.txt --lyndon --==_Exmh_-19606496970 Content-Type: message/external-body; name="draft-nerenberg-imap-binary-01.txt"; site="ftp.messagingdirect.com"; access-type=ANON-FTP; directory="/pub/staff/lyndon/drafts"; mode="ascii" Content-Description: draft-nerenberg-imap-binary-01.txt Content-Disposition: attachment; filename="imap-binary-extref" Content-Type: text/plain Content-ID: --==_Exmh_-19606496970-- Received: by ns.secondary.com (8.9.3/8.9.3) id JAA04457 for ietf-imapext-bks; Fri, 24 Nov 2000 09:04:02 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (rossi@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA04453 for ; Fri, 24 Nov 2000 09:04:01 -0800 (PST) Date: Fri, 24 Nov 2000 09:03:02 -0800 (PST) From: Mark Crispin Subject: re: Commands starting with X To: Paul Overell cc: ietf-imapext@imc.org In-Reply-To: <8IxOU1ANtjH6QAmk@turnpike.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 24 Nov 2000 09:56:29 +0000, Paul Overell wrote: > Is it a good idea to invent new commands starting with X (XLIST XFETCH > etc)? XLIST and XFETCH are just placeholders for the purpose of discussion; the actual names will be something else. IMAP forbids the use of "X" in a standards-track command name. Received: by ns.secondary.com (8.9.3/8.9.3) id BAA01358 for ietf-imapext-bks; Fri, 24 Nov 2000 01:58:32 -0800 (PST) Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA01346 for ; Fri, 24 Nov 2000 01:58:30 -0800 (PST) Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2]) by internal.mail.demon.net with ESMTP id JAA16934; Fri, 24 Nov 2000 09:59:31 GMT Message-ID: <8IxOU1ANtjH6QAmk@turnpike.com> Date: Fri, 24 Nov 2000 09:56:29 +0000 To: ietf-imapext@imc.org From: Paul Overell Subject: Commands starting with X MIME-Version: 1.0 X-Mailer: Turnpike Integrated Version 5.01 M Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Is it a good idea to invent new commands starting with X (XLIST XFETCH etc)? I only raise this as X is commonly used for non-standard or experimental features, whereas these new commands are presumably intended to become mainstream. C.f. The NNTP group are sufficiently bothered by this to want to rename XOVER and XPAT as OVER and PAT. Regards - -- Paul Overell T U R N P I K E -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQA/AwUBOh47TR8WRy+wdge+EQJhzgCfcbHfLDWdkXwcmQrmH9RQN3mRhtYAoPSF XaXRqnn3GZLPQVmf6L4ZtU2P =vkwS -----END PGP SIGNATURE----- Received: by ns.secondary.com (8.9.3/8.9.3) id QAA07503 for ietf-imapext-bks; Wed, 22 Nov 2000 16:22:13 -0800 (PST) Received: from mail.connectedsystems.com (host16.connectedsystems.com [205.227.183.113]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA07493; Wed, 22 Nov 2000 16:22:12 -0800 (PST) Received: from software-caleb (red.hq.connsys.com [192.168.0.32]) by mail.connectedsystems.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id WMN2D8WD; Wed, 22 Nov 2000 16:19:37 -0800 From: "Caleb Clausen" To: IMAP Extensions WG , ietf-imap-voice@imc.org Date: Wed, 22 Nov 2000 16:24:35 -0800 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: draft-nerenberg-imap-binary-00.txt Message-ID: <3A1BF343.30676.1866F93@localhost> In-reply-to: <200011212208.eALM8o803996@gollum.esys.ca> References: Message from Mark Crispin of "Tue, 21 Nov 2000 12:58:19 PST." X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From: Lyndon Nerenberg > > I believe therefore that this functionality belongs in a new command, e.g. > > something like > > tag XFETCH (BINARY) 1 BODY[x.y] > > tag XFETCH (CHARSET=UTF-8) 1 BODY[x.y] > > tag XFETCH (BINARY CHANNEL=[1.2.3.4]:432) 1 BODY[x.y] > > etc. These examples are to demonstrate the concept; the exact syntax to be > > determined. > > I hadn't realized that you and Steve had been discussing this, otherwise > I would have held off with BINARY for a bit. I like the XFETCH architecture, > however I'm not convinced (yet) that a server should have to implement > external channel support just to get BINARY. At this point I think the i would like to go on the record as one imap client implementor that would be very much interested in a BINARY FETCH. we have no use for CHANNEL at the moment... so i think these 2 concepts definitely should be separated. i'd also like to enumerate some of the problems i see with CHANNEL as sketched out in the example above. transport protocol it isn't too clear from the example whether udp or tcp transport is envisioned. i think that the original impetus for this proposal within vpim was to enable the voice data to be delivered via voip (that is, rtp over udp.) in that context, tcp transport doesn't gain anything. if udp is used for delivery, you then have to consider what happens when a packet gets dropped. voip uses fancy error-tolerant codecs to handle this case. the codec currently on the table for ivm (gsm) has no such abilities, so when a packet gets dropped, the rest of the file will be corrupted. of course, you could have the server translate the voice data into a fancy error-tolerant codec on the fly. probably a good use for the data-conversion feature of XFETCH? nat embedding ip addresses and port numbers within tcp payload is a sure way to break network address translators. it also makes imap dependant on ipv4, complicating the transition to ipv6. these are two reasons to avoid it altogether. if ip addresses and ports must be embedded, you should at least try to avoid the minor disaster that ftp creates for nat by always 0- padding the ip address octets and the port so that they always come out to exactly the same length. for example, instead of: tag XFETCH (BINARY CHANNEL=[1.2.3.4]:432) 1 BODY[x.y] you'd have: tag XFETCH (BINARY CHANNEL=[001.002.003.004]:00432) 1 BODY[x.y] (sorry about the line wrap.) this will still break nat, of course, but at least it will be easier to write a custom nat protocol handler for imap. "The battle for mental territory is glory. End of story." --KRS-ONE Received: by ns.secondary.com (8.9.3/8.9.3) id QAA07465 for ietf-imapext-bks; Wed, 22 Nov 2000 16:22:05 -0800 (PST) Received: from mail.connectedsystems.com (host16.connectedsystems.com [205.227.183.113]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA07457; Wed, 22 Nov 2000 16:22:03 -0800 (PST) Received: from software-caleb (red.hq.connsys.com [192.168.0.32]) by mail.connectedsystems.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id WMN2D8WF; Wed, 22 Nov 2000 16:19:37 -0800 From: "Caleb Clausen" To: IMAP Extensions WG , ietf-imap-voice@imc.org Date: Wed, 22 Nov 2000 16:24:35 -0800 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: RE: draft-nerenberg-imap-binary-00.txt Message-ID: <3A1BF343.14592.1866F6A@localhost> References: <488891341182D4118A870000F80822E782B74B@zcard00p.ca.nortel.com> In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From: Lyndon Nerenberg > > Steve indicated to me last week that he would combine the first two into one > > proposal. Do we expect two proposals now? > > Steve's proposal for XFETCH includes support for both binary fetch and > specifying external transfer channels for a fetch. (Among other > things.) > > My proposal provides binary fetch (only) for servers that don't want/need > to support XFETCH. > > The two can live side-by-side. Time will show if BINARY has enough > support (in the presence of XFETCH) to move forward. since everyone likes the XFETCH syntax so much better, why not do this: have separate capabilities for XFETCH itself, as well as all of it's options. so, the XFETCH document would define the following capabilities: XFETCH XFETCH-BINARY XFETCH-CHANNEL XFETCH-CHARSET etc. that way, servers which just want to provide a binary version of fetch could declare just XFETCH and XFETCH-BINARY. servers that want all of it would declare all the XFETCH capabilities. or is this too great a proliferation of capabilities? one question: will XFETCH work with the UID command? ie, will i be able to say, tag UID XFETCH (BINARY) 1009 etc... "The battle for mental territory is glory. End of story." --KRS-ONE Received: by ns.secondary.com (8.9.3/8.9.3) id OAA05036 for ietf-imapext-bks; Wed, 22 Nov 2000 14:40:35 -0800 (PST) Received: from gollum.esys.ca (dhcp198-59.esys.ca [198.161.92.59]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA05022; Wed, 22 Nov 2000 14:40:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gollum.esys.ca (8.11.1/8.11.1) with ESMTP id eAMMaZl44204; Wed, 22 Nov 2000 15:36:35 -0700 (MST) (envelope-from lyndon@messagingdirect.com) Date: Wed, 22 Nov 2000 15:36:35 -0700 (MST) From: Lyndon Nerenberg X-Sender: lyndon@gollum.esys.ca To: Glenn Parsons cc: IMAP Extensions WG , ietf-imap-voice@imc.org Subject: RE: draft-nerenberg-imap-binary-00.txt In-Reply-To: <488891341182D4118A870000F80822E782B74B@zcard00p.ca.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Steve indicated to me last week that he would combine the first two into one > proposal. Do we expect two proposals now? Steve's proposal for XFETCH includes support for both binary fetch and specifying external transfer channels for a fetch. (Among other things.) My proposal provides binary fetch (only) for servers that don't want/need to support XFETCH. The two can live side-by-side. Time will show if BINARY has enough support (in the presence of XFETCH) to move forward. --lyndon Received: by ns.secondary.com (8.9.3/8.9.3) id OAA14282 for ietf-imapext-bks; Tue, 21 Nov 2000 14:37:51 -0800 (PST) Received: from gollum.esys.ca (dhcp198-59.esys.ca [198.161.92.59]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14269; Tue, 21 Nov 2000 14:37:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gollum.esys.ca (8.11.1/8.11.1) with ESMTP id eALMcK804217; Tue, 21 Nov 2000 15:38:20 -0700 (MST) (envelope-from lyndon@gollum.esys.ca) Message-Id: <200011212238.eALMcK804217@gollum.esys.ca> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Mark Crispin cc: IMAP Extensions WG , ietf-imap-voice@imc.org Subject: Re: draft-nerenberg-imap-binary-00.txt In-Reply-To: Message from Mark Crispin of "Tue, 21 Nov 2000 14:10:31 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Nov 2000 15:38:20 -0700 From: Lyndon Nerenberg Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Isn't converting QP and BASE64 to BINARY a form of data conversion? No, it's a change of transport encoding. The contents of the body part at the client matches the contents of what the sender sent regardless of where the transport encoding is undone (i.e. at the client vs. at the server). The decoded data is the same, so it's not a data conversion. If, however, the server _also_ does character set manipulations on the way through, the decoded data at the client might not match what the sender initially sent. _That_ I consider to be data conversion. > > I hadn't realized that you and Steve had been discussing this, otherwise > > I would have held off with BINARY for a bit. > That's why I was a bit surprised to see your document! :-) So was Steve :-) I apologise for starting all this confusion. > I suggest some added little token in literal8, perhaps {###}~ instead of {###} > to indicate its special nature. I can live with that. If people are okay with the syntax I'll incorporate that into the next draft. Any suggestions for a modified FETCH...BINARY syntax while we're at it? --lyndon Received: by ns.secondary.com (8.9.3/8.9.3) id OAA13893 for ietf-imapext-bks; Tue, 21 Nov 2000 14:21:04 -0800 (PST) Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA13889; Tue, 21 Nov 2000 14:21:03 -0800 (PST) Received: from mailhost1.u.washington.edu (mailhost1.u.washington.edu [140.142.32.2]) by mxout1.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW99.09) with ESMTP id OAA28380; Tue, 21 Nov 2000 14:21:51 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (foo@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost1.u.washington.edu (8.9.3+UW00.02/8.9.3+UW00.01) with ESMTP id OAA13943; Tue, 21 Nov 2000 14:21:50 -0800 Date: Tue, 21 Nov 2000 14:10:31 -0800 (PST) From: Mark Crispin Subject: Re: draft-nerenberg-imap-binary-00.txt To: Lyndon Nerenberg cc: IMAP Extensions WG , ietf-imap-voice@imc.org In-Reply-To: <200011212208.eALM8o803996@gollum.esys.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 21 Nov 2000 15:08:50 -0700, Lyndon Nerenberg wrote: > > However, I object strongly to the "BODY[x.y.BINARY]" syntax. > I'll agree with that. I'm not particularly happy with that syntax either. > I needed something as a starting point OK, good. I'm happy with a stipulation that we're going to fix that. I don't want to stand in the way of the functionality, but that particular syntax has got to go. > And this is something VPIM originally requested (general conversions). I > don't like overloading (or combining, I guess) BINARY with data conversion. Isn't converting QP and BASE64 to BINARY a form of data conversion? > I hadn't realized that you and Steve had been discussing this, otherwise > I would have held off with BINARY for a bit. That's why I was a bit surprised to see your document! :-) > I like the XFETCH architecture, > however I'm not convinced (yet) that a server should have to implement > external channel support just to get BINARY. At this point I think the > two are really distinct issues, and should be separate extensions. OK with me. My guiding principle (consider XLIST) is that if it's trivial to bundle two things together and less work than having them separate, then bundle them; but if there's a reason why someone may want one and not the other, then keep them separate. If you feel that BINARY vs. external channel support is the latter, I won't squawk. [I'd appreciate the return favor when we talk about XLIST vs. subscriptions........] > > XFETCH that would output on the IMAP channel, so the client can > > distinguish a literal8 from an ordinary literal. > This shouldn't be necessary. The server will only send a literal8 at > the specific request of the client, and they will never show up in > an unsolicited response. It's not a big deal, though. If concensus is > for a unique syntax for literal8 that's an easy change to make. Mr. IMAP Architecture says that it's presumptious to say that "they will never show up in an unsolicited responses." The presumption may be valid for literal8 (and certainly right now it is), but it isn't for literal; and that's what creates the ambiguity. We don't want the situation where a client gets a literal and thinks that it's a literal8. I suggest some added little token in literal8, perhaps {###}~ instead of {###} to indicate its special nature. Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA13870 for ietf-imapext-bks; Tue, 21 Nov 2000 14:20:33 -0800 (PST) Received: from gollum.esys.ca (dhcp198-59.esys.ca [198.161.92.59]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA13866 for ; Tue, 21 Nov 2000 14:20:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gollum.esys.ca (8.11.1/8.11.1) with ESMTP id eALMLA804133 for ; Tue, 21 Nov 2000 15:21:10 -0700 (MST) (envelope-from lyndon@gollum.esys.ca) Message-Id: <200011212221.eALMLA804133@gollum.esys.ca> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Lyndon Nerenberg To: ietf-imapext@imc.org Subject: (resend) Re; BINARY X-URL: http://www.messagingdirect.com/ Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Nov 2000 15:21:10 -0700 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [Sorry folks, this bounced first time around. >> == Mark, > == me.] >> The subject draft attempts to fufill a needed requirement for the >>VPIM folks. > >Initially that was the case, although I certainly think this extension has >a use outside of that context. > >> However, I object strongly to the "BODY[x.y.BINARY]" syntax. Unlike other >> section specifiers, this one would stipulate a transformation of a section >> rather than identify a unique section. It also adds complexity >>(the "terminal >> MIME body part" rule) as a side effect of overloading location syntax (the >> section specifier) with transformation instructions ("BINARY"). > >I'll agree with that. I'm not particularly happy with that syntax either. >I needed something as a starting point (and was under the gun to meet >the submission deadline, so I didn't have a chance to work out anything >better), so I went with the syntax in the original VPIM proposal. > >> Furthermore, this extension does not really address the complete need, which >> is a general ability to transform/deliver message data in extended >>forms. For >> example, a streaming application may wish to specify a separate >>host/port for >> delivery of the data. It may be desireable to request the server >>to transform >> text data to UTF-8. > >And this is something VPIM originally requested (general conversions). I >don't like overloading (or combining, I guess) BINARY with data conversion. >BINARY provides a single piece of functionality: undoing of content >transfer encodings. This is neutral to the actual content. If there is >a need to do actual conversion of the underlying data, that should be >handled separately. Character set conversions (such as your UTF8 example) >are a bit fuzzy, sitting in between BINARY and general data conversions. >I'm not sure where that actually fits in, but again I think that's a >separate issue from BINARY itself. > >> I believe therefore that this functionality belongs in a new command, e.g. >> something like >> tag XFETCH (BINARY) 1 BODY[x.y] >> tag XFETCH (CHARSET=UTF-8) 1 BODY[x.y] >> tag XFETCH (BINARY CHANNEL=[1.2.3.4]:432) 1 BODY[x.y] >> etc. These examples are to demonstrate the concept; the exact syntax to be >> determined. > >I hadn't realized that you and Steve had been discussing this, otherwise >I would have held off with BINARY for a bit. I like the XFETCH architecture, >however I'm not convinced (yet) that a server should have to implement >external channel support just to get BINARY. At this point I think the >two are really distinct issues, and should be separate extensions. I don't >think implementing channel necessarily requires the BINARY extensions >be present. The external channel may already be 8bit clean, and the >specification for that profile of the channel target mechanism could >explicitly state that the channel is 8bit clean, therefore there's >no need for the server to also implement BINARY if the implementer doesn't >feel it adds significant value. It's still very early in the game, though, >so I don't consider any of this cast in stone. I'm looking forward to >seeing a more complete specification for XFETCH. > >> We should also have a syntax for literal8s that are output in the case of an >> XFETCH that would output on the IMAP channel, so the client can >>distinguish a >> literal8 from an ordinary literal. Otherwise there would be an >>ambiguity due >> to the unsolicited data model of IMAP, and the client would have to depend >> upon a command modality that IMAP espressly forbids. > >This shouldn't be necessary. The server will only send a literal8 at >the specific request of the client, and they will never show up in >an unsolicited response. It's not a big deal, though. If concensus is >for a unique syntax for literal8 that's an easy change to make. > >--lyndon Received: by ns.secondary.com (8.9.3/8.9.3) id NAA13007 for ietf-imapext-bks; Tue, 21 Nov 2000 13:51:49 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13003 for ; Tue, 21 Nov 2000 13:51:45 -0800 (PST) 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 QAA00064 for ; Tue, 21 Nov 2000 16:51:31 -0500 (EST) Date: Tue, 21 Nov 2000 16:52:33 -0500 From: Cyrus Daboo To: IMAP Extensions WG Subject: View draft for San Diego Message-ID: <1435577.3183814353@sardis.cyrusoft.com> X-Mailer: Mulberry/2.0.5 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'd like to get an update to the VIEW draft out before the deadline (and before the current one expires, though I could just re-sub,it it as it is with a change of expiry date). The debate on VIEW was left somewhat open-ended after the last round of discussions on the list (a couple of months ago now). I think the issues wrt SORT & THREAD working with VIEW may best be left for the meeting, but a couple of issues for VIEW did come out of that round of discussions: 1) VIEW responses are too chatty. The proposal I had to solve this (Message-ID: <3223946.3175613932@socrates.cyrusoft.com>) was to collapse all the VIEW 'position changed' responses into a single * VIEW response with three parts to it: > Right now we have a * VIEW for each change. We could compress this down > to a single * VIEW for all changes during the command in progress. > Something along the lines off: > > * VIEW (1:3,5) (10 11 15 16) (1:2,20) > > The three groups represent: > > 1) View positions of messages removed from the view > 2) Pairs of view positions for messages moving in the view > 3) View positions of new messages added to the view > > This removes both UIDs and sequence numbers from the original * VIEW > response. 2) Clients need a way to get the VIEW-UID map so that they can utilise existing cached data when changing from one view to another. There was a proposal to add a new VIEW WINDOW command that would allow this to work: tag VIEW WINDOW ... This would return a list of message UIDs corresponding to the range of view position ids requested. There are some issues about how to make this work with threads where the positions may represent different levels of hierarchy. Are there any objections to these changes? Should we just wait until San Diego before deciding on ANY changes to VIEW, to allow the issues with SORT etc to be resolved first? -- Cyrus Daboo Received: by ns.secondary.com (8.9.3/8.9.3) id NAA12944 for ietf-imapext-bks; Tue, 21 Nov 2000 13:45:19 -0800 (PST) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA12939 for ; Tue, 21 Nov 2000 13:45:18 -0800 (PST) Received: from messagingdirect.com (gagarin.esys.ca [198.161.92.84]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id eALLk9022779; Tue, 21 Nov 2000 14:46:09 -0700 Message-ID: <3A1AED20.68CE1CC@messagingdirect.com> Date: Tue, 21 Nov 2000 14:46:09 -0700 From: Alexey Melnikov X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Crispin , IMAP Extensions WG Subject: Re: draft-nerenberg-imap-binary-00.txt References: <3A1AEBFC.9198A541@messagingdirect.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Oops. Hit Send button too fast. Sorry :-(. To the best of my knowledge Lyndon will be writing another draft (superset of the current) that will address VPIM stuff (general ability to transform/deliver message in a different format or over a different channel). The draft that Lyndon submitted is generally useful for conserving bandwidth. It is possible that in the future there will be only a single extension. Alexey Received: by ns.secondary.com (8.9.3/8.9.3) id NAA12862 for ietf-imapext-bks; Tue, 21 Nov 2000 13:40:32 -0800 (PST) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA12858 for ; Tue, 21 Nov 2000 13:40:31 -0800 (PST) Received: from messagingdirect.com (gagarin.esys.ca [198.161.92.84]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id eALLfH022703; Tue, 21 Nov 2000 14:41:17 -0700 Message-ID: <3A1AEBFC.9198A541@messagingdirect.com> Date: Tue, 21 Nov 2000 14:41:16 -0700 From: Alexey Melnikov X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Crispin CC: IMAP Extensions WG Subject: Re: draft-nerenberg-imap-binary-00.txt References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > The subject draft attempts to fufill a needed requirement for the VPIM folks. > > However, I object strongly to the "BODY[x.y.BINARY]" syntax. Unlike other > section specifiers, this one would stipulate a transformation of a section > rather than identify a unique section. It also adds complexity (the "terminal > MIME body part" rule) as a side effect of overloading location syntax (the > section specifier) with transformation instructions ("BINARY"). > > Furthermore, this extension does not really address the complete need, which > is a general ability to transform/deliver message data in extended forms. For > example, a streaming application may wish to specify a separate host/port for > delivery of the data. It may be desireable to request the server to transform > text data to UTF-8. > > I believe therefore that this functionality belongs in a new command, e.g. > something like > tag XFETCH (BINARY) 1 BODY[x.y] > tag XFETCH (CHARSET=UTF-8) 1 BODY[x.y] > tag XFETCH (BINARY CHANNEL=[1.2.3.4]:432) 1 BODY[x.y] > etc. These examples are to demonstrate the concept; the exact syntax to be > determined. > > We should also have a syntax for literal8s that are output in the case of an > XFETCH that would output on the IMAP channel, so the client can distinguish a > literal8 from an ordinary literal. Otherwise there would be an ambiguity due > to the unsolicited data model of IMAP, and the client would have to depend > upon a command modality that IMAP espressly forbids. Received: by ns.secondary.com (8.9.3/8.9.3) id NAA12494 for ietf-imapext-bks; Tue, 21 Nov 2000 13:11:32 -0800 (PST) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA12490 for ; Tue, 21 Nov 2000 13:11:30 -0800 (PST) Received: from mailhost1.u.washington.edu (mailhost1.u.washington.edu [140.142.32.2]) by mxout2.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW99.09) with ESMTP id NAA18608 for ; Tue, 21 Nov 2000 13:12:21 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tpb@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost1.u.washington.edu (8.9.3+UW00.02/8.9.3+UW00.01) with ESMTP id NAA00361 for ; Tue, 21 Nov 2000 13:12:21 -0800 Date: Tue, 21 Nov 2000 12:58:19 -0800 (PST) From: Mark Crispin Subject: draft-nerenberg-imap-binary-00.txt To: IMAP Extensions WG Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The subject draft attempts to fufill a needed requirement for the VPIM folks. However, I object strongly to the "BODY[x.y.BINARY]" syntax. Unlike other section specifiers, this one would stipulate a transformation of a section rather than identify a unique section. It also adds complexity (the "terminal MIME body part" rule) as a side effect of overloading location syntax (the section specifier) with transformation instructions ("BINARY"). Furthermore, this extension does not really address the complete need, which is a general ability to transform/deliver message data in extended forms. For example, a streaming application may wish to specify a separate host/port for delivery of the data. It may be desireable to request the server to transform text data to UTF-8. I believe therefore that this functionality belongs in a new command, e.g. something like tag XFETCH (BINARY) 1 BODY[x.y] tag XFETCH (CHARSET=UTF-8) 1 BODY[x.y] tag XFETCH (BINARY CHANNEL=[1.2.3.4]:432) 1 BODY[x.y] etc. These examples are to demonstrate the concept; the exact syntax to be determined. We should also have a syntax for literal8s that are output in the case of an XFETCH that would output on the IMAP channel, so the client can distinguish a literal8 from an ordinary literal. Otherwise there would be an ambiguity due to the unsolicited data model of IMAP, and the client would have to depend upon a command modality that IMAP espressly forbids. Received: by ns.secondary.com (8.9.3/8.9.3) id NAA17361 for ietf-imapext-bks; Fri, 17 Nov 2000 13:48:52 -0800 (PST) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA17355 for ; Fri, 17 Nov 2000 13:48:50 -0800 (PST) Received: from messagingdirect.com (gagarin.esys.ca [198.161.92.84]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id eAHLuKC22447; Fri, 17 Nov 2000 14:56:20 -0700 Message-ID: <3A15A983.2A13E6C0@messagingdirect.com> Date: Fri, 17 Nov 2000 14:56:19 -0700 From: Alexey Melnikov X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Chris Newman CC: Steve Hole , IMAP Extensions WG Subject: Re: LIST Extensions Requirements References: <4412999.3183452300@nifty-jr.west.sun.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > One thing I would ask. Can you keep track of the individual requirements > > that progress through the discussion? > > I'm too busy to do a good job keeping track of such a list (I only get to > IMAPEXT every couple weeks). Furthermore, someone who is more neutral than > I on some of the controversial issues would be better. The WG chair or > document editor would be a better choice, IMHO. I can try to compile the list if there are no objections. Alexey Received: by ns.secondary.com (8.9.3/8.9.3) id MAA21622 for ietf-imapext-bks; Fri, 17 Nov 2000 12:11:08 -0800 (PST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA21611 for ; Fri, 17 Nov 2000 12:11:06 -0800 (PST) Received: from westmail2.West.Sun.COM ([129.153.100.30]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA19886; Fri, 17 Nov 2000 12:18:45 -0800 (PST) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA28599; Fri, 17 Nov 2000 12:18:43 -0800 (PST) Date: Fri, 17 Nov 2000 12:18:20 -0800 From: Chris Newman To: Steve Hole cc: IMAP Extensions WG Subject: Re: LIST Extensions Requirements Message-ID: <4412999.3183452300@nifty-jr.west.sun.com> In-Reply-To: X-Mailer: Mulberry/2.0.5 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Thursday, November 16, 2000 9:46 -0700 Steve Hole wrote: > One thing I would ask. Can you keep track of the individual requirements > that progress through the discussion? I'm too busy to do a good job keeping track of such a list (I only get to IMAPEXT every couple weeks). Furthermore, someone who is more neutral than I on some of the controversial issues would be better. The WG chair or document editor would be a better choice, IMHO. - Chris Received: by ns.secondary.com (8.9.3/8.9.3) id JAA27511 for ietf-imapext-bks; Thu, 16 Nov 2000 09:47:09 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (tonyb@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA27504 for ; Thu, 16 Nov 2000 09:47:07 -0800 (PST) Date: Thu, 16 Nov 2000 09:47:23 -0800 (PST) From: Mark Crispin Subject: re: RFC 2193 & RFC 2221 To: Cynthia_Mamacos@lotus.com cc: ietf-imapext@imc.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 16 Nov 2000 12:40:04 -0500, Cynthia_Mamacos@lotus.com wrote: > Interested in RFC 2193 IMAP4 Mailbox Referrals & RFC 2221IMAP4 Login > Referrals. How well adopted are these ? What's happening in this area ? Pine and most other good-quality client implementations fully implement referrals at the client level. I am aware of at least two servers which support referrals, either with a full implementation or with hooks to a local management facility. Received: by ns.secondary.com (8.9.3/8.9.3) id JAA23482 for ietf-imapext-bks; Thu, 16 Nov 2000 09:33:28 -0800 (PST) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA23471 for ; Thu, 16 Nov 2000 09:33:25 -0800 (PST) From: Cynthia_Mamacos@lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id MAA21045 for ; Thu, 16 Nov 2000 12:44:07 -0500 (EST) Received: from ismail.lotus.com (ISMAIL.lotus.com [9.95.4.115]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id MAA23189 for ; Thu, 16 Nov 2000 12:40:29 -0500 (EST) To: ietf-imapext@imc.org Subject: RFC 2193 & RFC 2221 X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: Date: Thu, 16 Nov 2000 12:40:04 -0500 X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Build V506_11132000 |November 13, 2000) at 11/16/2000 12:40:06 PM, Serialize complete at 11/16/2000 12:40:06 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0060C73E85256999_=" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0060C73E85256999_= Content-Type: text/plain; charset="us-ascii" All, Interested in RFC 2193 IMAP4 Mailbox Referrals & RFC 2221IMAP4 Login Referrals. How well adopted are these ? What's happening in this area ? Any assistance would be greatly appreciated. Cynthia Mamacos Lotus Development Corp. --=_alternative 0060C73E85256999_= Content-Type: text/html; charset="us-ascii"
All,  
Interested in RFC 2193 IMAP4 Mailbox Referrals & RFC 2221IMAP4 Login Referrals.  How well adopted are these ?  What's happening in this area ?
Any assistance would be greatly appreciated.

Cynthia Mamacos
Lotus Development Corp.
 --=_alternative 0060C73E85256999_=-- Received: by ns.secondary.com (8.9.3/8.9.3) id IAA07766 for ietf-imapext-bks; Thu, 16 Nov 2000 08:39:36 -0800 (PST) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA07757 for ; Thu, 16 Nov 2000 08:39:35 -0800 (PST) Received: from kepler (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id eAGGlAC05201; Thu, 16 Nov 2000 09:47:10 -0700 From: Steve Hole Date: Thu, 16 Nov 2000 09:46:01 -0700 To: Chris Newman Subject: Re: LIST Extensions Requirements Cc: IMAP Extensions WG Message-ID: X-Mailer: Execmail for Win32 5.1.1 Build (10) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 15 Nov 2000 12:04:59 -0800 Chris Newman wrote: > Here's a first shot at requirements for the "XLIST" command. This is a > brainstorm of ideas I recall being mentioned or have thought about, so > please don't assume you know my position just because an item showed up > in the list. Looks good Chris. There are things that I would like to discuss about the namespace issues and reference arguments, but that should wait for a face-to-face. One thing I would ask. Can you keep track of the individual requirements that progress through the discussion? I think that we want to collect a requirements table that lists all the requirements that people propose, along with a state that is one of: Accepted - concensus to include as a requirement Rejected - concensus to reject as a requirement Discussion - further discussion required to reach accept or reject Proposed - proposed requirement but no discussion had yet There are probably other states, but that should do for a starter. If you can't, then can someone else do this? It will greatly improve our ability to have a rational design discussion if we avoid rehashing things that we have already reached concensus on. Good work Chris. Cheers. --- Steve Hole Chief Technical Officer Messaging Direct Mailto:Steve.Hole@MessagingDirect.com Phone: 780-424-4922 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA27298 for ietf-imapext-bks; Thu, 16 Nov 2000 03:20:47 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA27270 for ; Thu, 16 Nov 2000 03:20:37 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09130; Thu, 16 Nov 2000 06:28:10 -0500 (EST) Message-Id: <200011161128.GAA09130@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-thread-05.txt Date: Thu, 16 Nov 2000 06:28:09 -0500 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF. Title : INTERNET MESSAGE ACCESS PROTOCOL - THREAD EXTENSION Author(s) : M. Crispin, K. Murchison Filename : draft-ietf-imapext-thread-05.txt Pages : 13 Date : 15-Nov-00 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-ietf-imapext-thread-05.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-ietf-imapext-thread-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imapext-thread-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001115091746.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-thread-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-thread-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001115091746.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: by ns.secondary.com (8.9.3/8.9.3) id OAA17808 for ietf-imapext-bks; Wed, 15 Nov 2000 14:47:56 -0800 (PST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA17798 for ; Wed, 15 Nov 2000 14:47:55 -0800 (PST) Received: from westmail2.West.Sun.COM ([129.153.100.30]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA24329; Wed, 15 Nov 2000 14:55:18 -0800 (PST) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA06142; Wed, 15 Nov 2000 14:55:17 -0800 (PST) Date: Wed, 15 Nov 2000 14:54:58 -0800 From: Chris Newman To: Simon Josefsson cc: IMAP Extensions WG Subject: Re: LIST Extensions Requirements Message-ID: <840379.3183288898@nifty-jr.west.sun.com> In-Reply-To: X-Mailer: Mulberry/2.0.5 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Wednesday, November 15, 2000 23:21 +0100 Simon Josefsson wrote: > * It must not break old mailbox names -- if `/' is the new delimiter > there must be a way to escape `/' within a mailbox name. That's not a requirement for XLIST, IMHO. If you want to use "/" as a character in a mailbox names, then don't implement XLIST. > * Because escaping might be ugly, I suggest that we could consider a > delimiter agnostic solution -- * XLIST ... "INBOX" "whatever" > "whatother" I'd rather not. That's too much work to parse, manage and map to URL semantics (which use "/" as the one true delimiter). > * I feel the "display delimiter" might be as complicated as the > current delimiter situation, is it really worth having? I'd prefer to do without it, but it's certainly simpler than the status quo where a client has to support all delimiters (including NIL) and translate mailbox names accordingly. With a "display delimiter", the majority of clients which use hierarchy don't care, only those which display full paths to mailboxes need to worry about it. > * Permit a facility to discover mailboxes with newly arrived mail How do you define "newly arrived mail"? Mailboxes with unseen messages? Or Mailboxes with \Recent messages (meaning messages have arrived since the last time you or perhaps someone else selected the mailbox). >> * Layered facility for virtual scrollbars in very large mailbox list >> (e.g. #news/alt/%) >> >> * Limit on number of returned mailboxes (with limit exceeded notice) > > IMHO these should be optional and only used upon client request. For the former I'd agree. For the later, I'd actually be tempted to force clients to always specify the maximum number of returned mailboxes they can deal with. I'm sick and tired of clients that crash or hang my machine when I point them at a server with too many mailboxes. - Chris Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA15704 for ietf-imapext-bks; Wed, 15 Nov 2000 14:39:15 -0800 (PST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA15700 for ; Wed, 15 Nov 2000 14:39:14 -0800 (PST) Received: from westmail2.West.Sun.COM ([129.153.100.30]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA10110 for ; Wed, 15 Nov 2000 14:46:38 -0800 (PST) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA03786 for ; Wed, 15 Nov 2000 14:29:19 -0800 (PST) Date: Wed, 15 Nov 2000 14:28:59 -0800 From: Chris Newman To: IMAP Extensions WG Subject: re: LIST Extensions Requirements Message-ID: <746635.3183287339@nifty-jr.west.sun.com> In-Reply-To: X-Mailer: Mulberry/2.0.5 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Wednesday, November 15, 2000 12:14 -0800 Mark Crispin wrote: > Server MUST be able to refuse LSUB or STATUS functionality. Consequently > extended LIST will never deprecate LSUB or STATUS, and clients MUST be > able to use LSUB and STATUS. That point is controversial and I doubt further debate on the list would be productive. I _suggest_ resolving face to face. > This has the potential to be a major rathole. Suggest that debate on > this be deferred to the end and/or be time-limited ahead of time. > > I believe that "generic extensible command" is a solution in search of a > problem. I concur. I don't mind people structuring the command using some sort of extensible command model, as long as it isn't a separate document and doesn't waste a lot of time. >> * Only permit "/" as delimiter in new list command. > > How does this interact with newsgroups? > > How did URLs solve the problem? Did they make the newsgroup namespace > flat? I don't think that #news/comp/mail/misc will please the users, but > maybe #news/comp.mail.misc is OK. This would make % equivalent to *, but > as a practical matter this seems to be how many clients treat news anyway. The newsgroup namespace is flat in URLs (news:). I suspect that's the right answer. >> * Always use UTF-8 in new list command. > > Yes, definitely. That was my thought at first, but now I'm unsure. If UTF-8 shows up in mailbox names from extended list, then SELECT, CREATE, DELETE, etc. all have to support UTF-8. Should the presence of the extended LIST modify the behavior of other commands? I'd like to see more discussion. Perhaps use of UTF-8 is inherently orthogonal to extended list and thus has to be a separate independent extension (unfortunately)? >> * Permit a facility to discover newly created mailboxes. >> * Permit a facility to discover newly deleted mailboxes. >> * Permit a facility to discover mailboxes which have changed >> since last disconnected synchronization. >> * Layered facility for virtual scrollbars in very large mailbox list >> (e.g. #news/alt/%) > > ...Umm...as long as it is server-optional. That's the direction I lean as well. But IMAP's lack of the ability to get a list of newly created newsgroups is the major protocol reason people won't migrate from NNTP to IMAP for client access, so I hope most servers will choose to implement that facility. > ... due to the incorrect implementation in Cyrus; The Cyrus implementation was done in good faith and complied with RFC 2060. John and I had a long discussion of what is a "breakout" character in a news-style namespace. The conclusion we came to was that when a user types "comp.sys.mac" they are always referring to a top-level news folder. News didn't have a way to refer to relative namespaces, but the obvious choice was to use a "." prefix for relative names, since names lacking a prefix "." were absolute. We were trying our best to interpret the reference argument reasonably given the namespace semantics we were using. When URLs came along and made Unix path semantics the standard path semantics for the Internet, our interpretation (and choice of path delimiter) became inappropriate. When Pine came along and used the reference argument in a way we didn't expect, it failed to interoperate with Cyrus. The best fix at that point was to change Cyrus (and derivative servers) to match the URL path semantics which Pine assumed. - Chris Received: by ns.secondary.com (8.9.3/8.9.3) id OAA15480 for ietf-imapext-bks; Wed, 15 Nov 2000 14:26:41 -0800 (PST) Received: from dolk.extundo.com (dolk.extundo.com [195.42.214.242]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA15476 for ; Wed, 15 Nov 2000 14:26:38 -0800 (PST) Received: from barbar.josefsson.org (localhost.localdomain [127.0.0.1]) (authenticated) by dolk.extundo.com (8.11.1/8.11.1) with ESMTP id eAFMY9q28827 for ; Wed, 15 Nov 2000 23:34:10 +0100 To: Chris Newman Cc: IMAP Extensions WG Subject: Re: LIST Extensions Requirements References: <226931.3183278699@nifty-jr.west.sun.com> From: Simon Josefsson In-Reply-To: <226931.3183278699@nifty-jr.west.sun.com> Date: 15 Nov 2000 23:21:41 +0100 Message-ID: Lines: 35 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Some random thoughts about some of the issues... > * Only permit "/" as delimiter in new list command. > (Possibly have "display delimiter" attribute for clients that display > full mailbox names). * It must not break old mailbox names -- if `/' is the new delimiter there must be a way to escape `/' within a mailbox name. * Because escaping might be ugly, I suggest that we could consider a delimiter agnostic solution -- * XLIST ... "INBOX" "whatever" "whatother" * I feel the "display delimiter" might be as complicated as the current delimiter situation, is it really worth having? > * Permit a facility to discover newly created mailboxes. > > * Permit a facility to discover newly deleted mailboxes. > > * Permit a facility to discover mailboxes which have changed > since last disconnected synchronization. I'll add another idea: * Permit a facility to discover mailboxes with newly arrived mail > * Layered facility for virtual scrollbars in very large mailbox list > (e.g. #news/alt/%) > > * Limit on number of returned mailboxes (with limit exceeded notice) IMHO these should be optional and only used upon client request. Thanks Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA08110 for ietf-imapext-bks; Wed, 15 Nov 2000 13:09:13 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (icz@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA08093 for ; Wed, 15 Nov 2000 13:09:08 -0800 (PST) Date: Wed, 15 Nov 2000 12:14:45 -0800 (PST) From: Mark Crispin Subject: re: LIST Extensions Requirements To: Chris Newman cc: IMAP Extensions WG In-Reply-To: <226931.3183278699@nifty-jr.west.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 15 Nov 2000 12:04:59 -0800, Chris Newman wrote: > * The command should be structured so that clients only request the > information they really need and will actually use. Yes, definitely > * New list command subsumes functionality of LIST, LSUB, RLIST, RLSUB and > STATUS commands. Server MUST be able to refuse LSUB or STATUS functionality. Consequently extended LIST will never deprecate LSUB or STATUS, and clients MUST be able to use LSUB and STATUS. > * New list command subsumes child mailbox functionality. > * The command should have the option of returning ACL and myrights > information for mailboxes. > * The command should support mailbox annotations > * Avoid silly states. Use tri-state or multi-state variables instead of > interrelated flags to avoid them. All these are fine. > * Design around a "generic extensible command" model This has the potential to be a major rathole. Suggest that debate on this be deferred to the end and/or be time-limited ahead of time. I believe that "generic extensible command" is a solution in search of a problem. > * Only permit "/" as delimiter in new list command. How does this interact with newsgroups? How did URLs solve the problem? Did they make the newsgroup namespace flat? I don't think that #news/comp/mail/misc will please the users, but maybe #news/comp.mail.misc is OK. This would make % equivalent to *, but as a practical matter this seems to be how many clients treat news anyway. > * Always use UTF-8 in new list command. Yes, definitely. > * Permit a facility to discover newly created mailboxes. > * Permit a facility to discover newly deleted mailboxes. > * Permit a facility to discover mailboxes which have changed > since last disconnected synchronization. > * Layered facility for virtual scrollbars in very large mailbox list > (e.g. #news/alt/%) ...Umm...as long as it is server-optional. > * Limit on number of returned mailboxes (with limit exceeded notice) Yes. > * Way to request Quota information? Need review/overhaul of existing QUOTA specification. > * Don't include the reference argument in the replacement list command > (only using the "/" delimiter is the prerequisite for this). No. The only way to avoid the reference argument is to have a CWD command in IMAP. The last time this issue came up it wasted at least a year of everybody's time several years ago. It wasted time again a few years later due to the incorrect implementation in Cyrus; fortunately that is now fixed, and we had to leave a monument in RFC 2683 as to why the old Cyrus implementation was incorrect. However, in the meantime many users of Cyrus IMAP servers were inconvenienced. Reviving this dead issue will waste everybody's time all over again, and with many people this time the potential time wasted is worse than a year. > Explicitly note for clients that permit users to type a mailbox > name in context that if a user refers to ~/... or ~user/..., that > is likely shorthand for the Personal or Other Users namespaces > respectively. That proposal would create a UNIX-centric kludge. The need for context is wider than UNIX, and as such these kludges would need to be specified for every operating system (and future operating systems). The reference argument solves the problem, in a far simpler and cleaner way than such kludges. The reference argument also has the advantage of being in the IMAP base today. Let's leave it alone. > * What should be required for the base list replacement command If it is a "LIST replacement", then it must NOT replace LSUB or STATUS. Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA28839 for ietf-imapext-bks; Wed, 15 Nov 2000 11:57:56 -0800 (PST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA28814 for ; Wed, 15 Nov 2000 11:57:51 -0800 (PST) Received: from westmail2.West.Sun.COM ([129.153.100.30]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA13354 for ; Wed, 15 Nov 2000 12:05:21 -0800 (PST) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA16678 for ; Wed, 15 Nov 2000 12:05:16 -0800 (PST) Date: Wed, 15 Nov 2000 12:04:59 -0800 From: Chris Newman To: IMAP Extensions WG Subject: LIST Extensions Requirements Message-ID: <226931.3183278699@nifty-jr.west.sun.com> X-Mailer: Mulberry/2.0.5 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Here's a first shot at requirements for the "XLIST" command. This is a brainstorm of ideas I recall being mentioned or have thought about, so please don't assume you know my position just because an item showed up in the list. Believed Non-Controversial Requirements: ---------------------------------------- * The command should be structured so that clients only request the information they really need and will actually use. * Clients which don't need subscription flag won't ask for it. * Clients which care about remote mailboxes, but don't need referrals until select time can request that. * New list command subsumes functionality of LIST, LSUB, RLIST, RLSUB and STATUS commands. CAVEAT: Controversy exists as to what set of these should be required as part of the XLIST base spec and which ones should be layered XLIST extensions with their own capability string. * New list command subsumes child mailbox functionality. * The command should have the option of returning ACL and myrights information for mailboxes. * The command should support mailbox annotations CAVEAT: per-user and shared issue will rear its ugly head. As will annotation namespace issue. * Avoid silly states. Use tri-state or multi-state variables instead of interrelated flags to avoid them. * Design around a "generic extensible command" model that could be applied to other IMAP command extension situtations. CAVEAT: Controversy over whether "generic extensible command" model should be a separate standard. Ideas for requirements which need debate: ----------------------------------------- * Only permit "/" as delimiter in new list command. (Possibly have "display delimiter" attribute for clients that display full mailbox names). * Always use UTF-8 in new list command. * Permit a facility to discover newly created mailboxes. * Permit a facility to discover newly deleted mailboxes. * Permit a facility to discover mailboxes which have changed since last disconnected synchronization. * Layered facility for virtual scrollbars in very large mailbox list (e.g. #news/alt/%) * Limit on number of returned mailboxes (with limit exceeded notice) * Way to request Quota information? * Don't include the reference argument in the replacement list command (only using the "/" delimiter is the prerequisite for this). Explicitly note for clients that permit users to type a mailbox name in context that if a user refers to ~/... or ~user/..., that is likely shorthand for the Personal or Other Users namespaces respectively. Controversial requirement ideas: -------------------------------- * What should be required for the base list replacement command, as opposed to extensions to the list replacement command? Proposed litmus test: If it is common practice for IMAP clients to kludge around a deficiency in the LIST/LSUB/etc suite, then that facility should be part of the base XLIST command. For example, many clients currently do "LIST "" %" and "LIST "" %/%" when \HasChildren information isn't available. When XLIST is implemented this kludge should never be necessary. Additional litmus test: If there's a reasonable trivial implemention to comply, then include it in the XLIST base spec. For example, a non-referral IMAP server can support clients that request referrals simply by never returning any. Anything not meeting one of these litmus tests should be an XLIST extension. * Have "generic extensible command" model as a separate standard. - Chris Received: by ns.secondary.com (8.9.3/8.9.3) id MAA04858 for ietf-imapext-bks; Sat, 4 Nov 2000 12:21:13 -0800 (PST) Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA04854 for ; Sat, 4 Nov 2000 12:21:12 -0800 (PST) Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14]) by ogma.cisco.com (Postfix) with ESMTP id A8A8E569; Sat, 4 Nov 2000 21:27:17 +0100 (MET) Received: from [192.168.1.129] (ssh-sj1.cisco.com [171.68.225.134]) by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id VAA02905; Sat, 4 Nov 2000 21:27:13 +0100 (MET) Mime-Version: 1.0 X-Sender: pfaltstr@192.168.1.129 Message-Id: Date: Sat, 4 Nov 2000 15:26:43 -0500 To: "RL 'Bob' Morgan" From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: moderate or restrict IMAPEXT Cc: IMAP Extensions WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10.17 -0800 00-11-04, RL 'Bob' Morgan wrote: >Having seen this issue go by on several mailing lists, and seen more or >less the same answer be suggested, I wonder whether this wisdom is >captured anywhere official? http://www.ietf.org/IESG/STATEMENTS/moderated-lists.txt paf > > - RL "Bob" > >> As an IESG member which _IS_ subscribed to the list, let me explain >> what we normally say in these cases: >> >> This is the algorithm which we think is ok: >> >> IF the sender address is subscribed to the mailing list, OR >> on a special list for "approved subscribers" THEN >> Send the mail to the mailing list >> ELSE >> forward the mail to a human >> IF the mail is spam THEN >> >/dev/null >> FI >> IF the mail is not according to list policy THEN >> return message to sender, informing of what happened >> FI >> forward the mail to the mailing list >> FI >> >> I.e. filtering is ok, but you need a human which manually takes care >> of rejected messages. Received: by ns.secondary.com (8.9.3/8.9.3) id MAA04744 for ietf-imapext-bks; Sat, 4 Nov 2000 12:10:30 -0800 (PST) Received: from episteme-software.com (presnick-fw.flexabit.net [64.198.230.34]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA04739 for ; Sat, 4 Nov 2000 12:10:28 -0800 (PST) Received: from presnick-35.flexabit.net (64.198.230.35) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.0.2a2) for ; Sat, 4 Nov 2000 12:49:58 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: X-Mailer: Eudora [Macintosh version 5.1a1-12.00] Date: Sat, 4 Nov 2000 12:49:56 -0600 To: IMAP Extensions WG From: "RL 'Bob' Morgan" () Subject: RE: moderate or restrict IMAPEXT Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Having seen this issue go by on several mailing lists, and seen more or less the same answer be suggested, I wonder whether this wisdom is captured anywhere official? - RL "Bob" > As an IESG member which _IS_ subscribed to the list, let me explain > what we normally say in these cases: > > This is the algorithm which we think is ok: > > IF the sender address is subscribed to the mailing list, OR > on a special list for "approved subscribers" THEN > Send the mail to the mailing list > ELSE > forward the mail to a human > IF the mail is spam THEN > >/dev/null > FI > IF the mail is not according to list policy THEN > return message to sender, informing of what happened > FI > forward the mail to the mailing list > FI > > I.e. filtering is ok, but you need a human which manually takes care > of rejected messages. Received: by ns.secondary.com (8.9.3/8.9.3) id MAA04743 for ietf-imapext-bks; Sat, 4 Nov 2000 12:10:30 -0800 (PST) Received: from episteme-software.com (presnick-fw.flexabit.net [64.198.230.34]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA04734 for ; Sat, 4 Nov 2000 12:10:28 -0800 (PST) Received: from presnick-35.flexabit.net (64.198.230.35) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.0.2a2) for ; Sat, 4 Nov 2000 12:48:43 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: X-Mailer: Eudora [Macintosh version 5.1a1-12.00] Date: Sat, 4 Nov 2000 12:48:41 -0600 To: ietf-imapext@imc.org From: Lawrence Greenfield () Subject: Re: comments on LIST extensions Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From: "Mike Gahrns" Cc: Date: Fri, 3 Nov 2000 16:18:33 -0800 [...] How about something like the following? 3a) tag LIST "" % (REMOTE) includes in the LIST response folders that are remote and somehow marked as such in the LIST response 3b)tag LIST "" % (REFERRAL) include in the LIST response folders that are remote along with their remote URL referral data However, I am somewhat unsure as to the scenario where it would be desirable for the client to request to have the folder's referral URL returned to it in the LIST command, rather than obtaining this info on demand when needed during the SELECT command. I really want advisory referrals---I have a server that will silently proxy for non-referral aware clients and handout referrals to clients that execute an RLIST or RLSUB (yes, it's a mode, and yes, it's an ugly hack). So I'd like the way that referrals are discovered to happen before a SELECT---even an advisory referral on SELECT will require my proxy server to open a connection to the backend server, to give the rest of the data on SELECT. Larry Received: by ns.secondary.com (8.9.3/8.9.3) id LAA03643 for ietf-imapext-bks; Sat, 4 Nov 2000 11:54:21 -0800 (PST) Received: from smtp5.andrew.cmu.edu (SMTP5.ANDREW.CMU.EDU [128.2.10.85]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA03638 for ; Sat, 4 Nov 2000 11:54:19 -0800 (PST) Received: from PENGUIN.ANDREW.CMU.EDU (PENGUIN.ANDREW.CMU.EDU [128.2.122.2]) (authenticated as leg with KERBEROS_V4 (56 bits)) by smtp5.andrew.cmu.edu (8.11.1/8.11.1) with ESMTP id eA4K0sK15409 for ; Sat, 4 Nov 2000 15:00:54 -0500 X-Sieve: cmu-sieve 2.0 Received: from mail1.andrew.cmu.edu (MAIL1.ANDREW.CMU.EDU [128.2.10.131]) by mail3.andrew.cmu.edu (8.11.0/8.11.0) with ESMTP id eA4HP7B16535 for ; Sat, 4 Nov 2000 12:25:07 -0500 (EST) Received: (from root@localhost) by mail1.andrew.cmu.edu (8.9.3/8.9.3) id MAA23899 for leg@mail3.andrew.cmu.edu; Sat, 4 Nov 2000 12:25:07 -0500 (EST) X-Sieve: cmu-sieve 2.0 Received: from smtp4.andrew.cmu.edu (SMTP4.ANDREW.CMU.EDU [128.2.10.84]) by mail1.andrew.cmu.edu (8.9.3/8.9.3) with ESMTP id MAA23892 for ; Sat, 4 Nov 2000 12:25:06 -0500 (EST) Received: from PENGUIN.ANDREW.CMU.EDU (PENGUIN.ANDREW.CMU.EDU [128.2.122.2]) (authenticated as leg with KERBEROS_V4 (56 bits)) by smtp4.andrew.cmu.edu (8.11.1/8.11.0) with ESMTP id eA4HP6V17033; Sat, 4 Nov 2000 12:25:06 -0500 Date: Sat, 4 Nov 2000 12:25:06 -0500 Message-Id: <200011041725.eA4HP6V17033@smtp4.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.2 To: Mike Gahrns Cc: ietf-imapext@imc.org In-reply-to: <000401c045f4$c8950500$8dfc3b9d@redmond.corp.microsoft.com> Subject: Re: comments on LIST extensions References: <000401c045f4$c8950500$8dfc3b9d@redmond.corp.microsoft.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From: "Mike Gahrns" Cc: Date: Fri, 3 Nov 2000 16:18:33 -0800 [...] How about something like the following? 3a) tag LIST "" % (REMOTE) includes in the LIST response folders that are remote and somehow marked as such in the LIST response 3b)tag LIST "" % (REFERRAL) include in the LIST response folders that are remote along with their remote URL referral data However, I am somewhat unsure as to the scenario where it would be desirable for the client to request to have the folder's referral URL returned to it in the LIST command, rather than obtaining this info on demand when needed during the SELECT command. I really want advisory referrals---I have a server that will silently proxy for non-referral aware clients and handout referrals to clients that execute an RLIST or RLSUB (yes, it's a mode, and yes, it's an ugly hack). So I'd like the way that referrals are discovered to happen before a SELECT---even an advisory referral on SELECT will require my proxy server to open a connection to the backend server, to give the rest of the data on SELECT. Larry Received: by ns.secondary.com (8.9.3/8.9.3) id JAA27735 for ietf-imapext-bks; Sat, 4 Nov 2000 09:17:44 -0800 (PST) Received: from episteme-software.com (presnick-fw.flexabit.net [64.198.230.34]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA27731 for ; Sat, 4 Nov 2000 09:17:43 -0800 (PST) Received: from presnick-35.flexabit.net (64.198.230.35) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.0.2a2); Sat, 4 Nov 2000 11:23:48 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: References: X-Mailer: Eudora [Macintosh version 5.1a1-12.00] Date: Sat, 4 Nov 2000 11:23:44 -0600 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= From: Pete Resnick Subject: RE: moderate or restrict IMAPEXT Cc: "Eric Burger" , "Mark Crispin" , "IMAP Extensions WG" Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 11/4/00 at 12:19 PM -0500, Patrik Fδltstrφm wrote: >I.e. filtering is ok, but you need a human which manually takes care >of rejected messages. Yes, I got e-mail from Paul (our list manager), and what you describe is exactly what we will do. pr -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA27638 for ietf-imapext-bks; Sat, 4 Nov 2000 09:15:38 -0800 (PST) Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA27634 for ; Sat, 4 Nov 2000 09:15:36 -0800 (PST) Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14]) by ogma.cisco.com (Postfix) with ESMTP id 71F9AF8; Sat, 4 Nov 2000 18:21:41 +0100 (MET) Received: from [192.168.1.129] (ssh-sj1.cisco.com [171.68.225.134]) by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id SAA22151; Sat, 4 Nov 2000 18:21:24 +0100 (MET) Mime-Version: 1.0 X-Sender: pfaltstr@192.168.1.129 Message-Id: In-Reply-To: References: Date: Sat, 4 Nov 2000 12:19:21 -0500 To: Pete Resnick , "Eric Burger" From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: moderate or restrict IMAPEXT Cc: "Mark Crispin" , "IMAP Extensions WG" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 16.54 -0600 00-11-03, Pete Resnick wrote: >On 11/3/00 at 5:38 PM -0500, Eric Burger wrote: > >>What if we just limit posting to subscribers? That reduces the chance of an >>amature spammer succeeding, without the pain for the moderator. > >And it would proceed to disallow people like IESG members and others >who don't subscribe to the list from posting. I heavily object to >that. I'll moderate if we can work that out. As an IESG member which _IS_ subscribed to the list, let me explain what we normally say in these cases: This is the algorithm which we think is ok: IF the sender address is subscribed to the mailing list, OR on a special list for "approved subscribers" THEN Send the mail to the mailing list ELSE forward the mail to a human IF the mail is spam THEN >/dev/null FI IF the mail is not according to list policy THEN return message to sender, informing of what happened FI forward the mail to the mailing list FI I.e. filtering is ok, but you need a human which manually takes care of rejected messages. Patrik Received: by ns.secondary.com (8.9.3/8.9.3) id QAA21992 for ietf-imapext-bks; Fri, 3 Nov 2000 16:17:44 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA21988 for ; Fri, 3 Nov 2000 16:17:42 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 3 Nov 2000 16:18:00 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 03 Nov 2000 16:18:41 -0800 (Pacific Standard Time) Received: from mikega10 ([157.59.252.141]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 3 Nov 2000 16:18:40 -0800 Message-ID: <000401c045f4$c8950500$8dfc3b9d@redmond.corp.microsoft.com> From: "Mike Gahrns" To: "Mark Crispin" Cc: References: Subject: Re: comments on LIST extensions Date: Fri, 3 Nov 2000 16:18:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-OriginalArrivalTime: 04 Nov 2000 00:18:40.0543 (UTC) FILETIME=[C88D8AF0:01C045F4] Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: >So, would it work for you that: > > 1) tag LIST "" % > does not include referral mailboxes > > 2) tag RLIST "" % > tag LIST "" % () > include referral mailboxes, but do not return referal data > > 3) tag LIST "" % (REFERRAL) > include referral mailboxes and return referral data *** If we went the LIST extension route, I think I would like to see RLIST eventually deprecated. As such, I think there would need to be a way to get just the list of remote mailboxes, and not their remote url location for the perf reasons I mentioned in my previous post. The remote url location for can be easily obtained via SELECT, and saves having the server need to supply the info on a potentially large number of folders that may never be accessed during the session. (Hopefully clients smart enough to use this extension would not be blindly getting a whole public folder tree, but none-the-less it would still be common to have potentially hundreds of folders in a single level of hierarchy.) How about something like the following? 3a) tag LIST "" % (REMOTE) includes in the LIST response folders that are remote and somehow marked as such in the LIST response 3b)tag LIST "" % (REFERRAL) include in the LIST response folders that are remote along with their remote URL referral data However, I am somewhat unsure as to the scenario where it would be desirable for the client to request to have the folder's referral URL returned to it in the LIST command, rather than obtaining this info on demand when needed during the SELECT command. Received: by ns.secondary.com (8.9.3/8.9.3) id PAA21176 for ietf-imapext-bks; Fri, 3 Nov 2000 15:44:02 -0800 (PST) Received: from mail15a.boca15-verio.com (mail15a.boca15-verio.com [208.55.91.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA21172 for ; Fri, 3 Nov 2000 15:44:01 -0800 (PST) Received: from www.snowshore.com (128.241.144.247) by mail15a.boca15-verio.com (RS ver 1.0.57s) with SMTP id 02562983; Fri, 3 Nov 2000 18:50:23 -0500 (EST) From: "Eric Burger" To: "Pete Resnick" , "Mark Crispin" Cc: "IMAP Extensions WG" Subject: RE: moderate or restrict IMAPEXT Date: Fri, 3 Nov 2000 18:49:53 -0500 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: X-Loop-Detect: 1 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: What if we just limit posting to subscribers? That reduces the chance of an amature spammer succeeding, without the pain for the moderator. -- - Eric -----Original Message----- From: owner-ietf-imapext@mail.imc.org [mailto:owner-ietf-imapext@mail.imc.org]On Behalf Of Pete Resnick Sent: Friday, November 03, 2000 1:24 PM To: Mark Crispin Cc: IMAP Extensions WG Subject: Re: moderate or restrict IMAPEXT On 11/3/00 at 9:48 AM -0800, Mark Crispin wrote: >Please establish moderation on IMAPEXT Paul, I'm perfectly willing to do this if you have a method. If we can use IMAP mailboxes to do this (perhaps an incoming IMAP mailbox on your server that I moderate and transfer to another mailbox on your server that you send out to the list), it would be perfectly easy for me. pr -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA20652 for ietf-imapext-bks; Fri, 3 Nov 2000 15:11:47 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (jeff@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA20648 for ; Fri, 3 Nov 2000 15:11:46 -0800 (PST) Date: Fri, 3 Nov 2000 15:16:34 -0800 (PST) From: Mark Crispin Subject: Re: comments on LIST extensions To: Mike Gahrns cc: Barry Leiba , ietf-imapext@imc.org In-Reply-To: <000401c045e6$d545a600$8dfc3b9d@redmond.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 3 Nov 2000 14:38:42 -0800, Mike Gahrns wrote: > *** For Exchange, there will be some hit in getting the referral data. > Probably not devasting, but likely noticeable in the time it takes the LIST > response to come back. From a general design point of view, it is probably > best to not include the referral details in a response. Why generate this > info until it is needed? Not to mention sending the extra info across the > wire, (which if there are multiple replicas could get large). So, would it work for you that: 1) tag LIST "" % does not include referral mailboxes 2) tag RLIST "" % tag LIST "" % () include referral mailboxes, but do not return referal data 3) tag LIST "" % (REFERRAL) include referral mailboxes and return referral data Received: by ns.secondary.com (8.9.3/8.9.3) id PAA20591 for ietf-imapext-bks; Fri, 3 Nov 2000 15:08:49 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (dchap@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA20586 for ; Fri, 3 Nov 2000 15:08:48 -0800 (PST) Date: Fri, 3 Nov 2000 15:10:20 -0800 (PST) From: Mark Crispin Subject: Re: comments on LIST extensions To: Mike Gahrns cc: ietf-imapext@imc.org In-Reply-To: <000f01c045e1$af45a8b0$8dfc3b9d@redmond.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 3 Nov 2000 14:01:57 -0800, Mike Gahrns wrote: > How did you envision your suggestion working? Assuming that the LIST command is extended with a third argument, containing a parenthesized list of additional attributes desired, then: A two-argument LIST command will work as now; it may have expansion attributes in the response but will never return additional data. A three-argument LIST command will result in responses that include referral messages and possibly also referral data. The replacement for RLIST is a three-argument LIST with zero members in the additional attribute list. Received: by ns.secondary.com (8.9.3/8.9.3) id PAA20489 for ietf-imapext-bks; Fri, 3 Nov 2000 15:02:22 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA20485 for ; Fri, 3 Nov 2000 15:02:21 -0800 (PST) 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 SAA12194; Fri, 3 Nov 2000 18:07:36 -0500 (EST) Date: Fri, 03 Nov 2000 18:08:37 -0500 From: Cyrus Daboo To: Pete Resnick , Eric Burger cc: Mark Crispin , IMAP Extensions WG Subject: RE: moderate or restrict IMAPEXT Message-ID: <1583220.3182263717@sardis.cyrusoft.com> In-Reply-To: X-Mailer: Mulberry/2.0.5 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Friday, November 3, 2000 4:54 PM -0600 Pete Resnick wrote: >> What if we just limit posting to subscribers? That reduces the chance >> of an amature spammer succeeding, without the pain for the moderator. > > And it would proceed to disallow people like IESG members and others who > don't subscribe to the list from posting. I heavily object to that. I'll > moderate if we can work that out. Also a number of us don't subscribe directly but instead pipe the list into a shared imap mailbox via a specific email address - one of the many useful features of IMAP! -- Cyrus Daboo Received: by ns.secondary.com (8.9.3/8.9.3) id PAA20462 for ietf-imapext-bks; Fri, 3 Nov 2000 15:01:26 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA20458 for ; Fri, 3 Nov 2000 15:01:25 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 3 Nov 2000 14:38:10 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 03 Nov 2000 14:38:51 -0800 (Pacific Standard Time) Received: from mikega10 ([157.59.252.141]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 3 Nov 2000 14:38:48 -0800 Message-ID: <000401c045e6$d545a600$8dfc3b9d@redmond.corp.microsoft.com> From: "Mike Gahrns" To: "Barry Leiba" , References: <2579962729.973242571@mars.trees.watson.ibm.com> Subject: Re: comments on LIST extensions Date: Fri, 3 Nov 2000 14:38:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-OriginalArrivalTime: 03 Nov 2000 22:38:48.0988 (UTC) FILETIME=[D54ECDC0:01C045E6] Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Barry Leiba writes: > The only concern I have here is that a referral-capable server might > know quickly that a mailbox is remote, but might have a slower time > actually retrieving the referral information. So there *might* be some use > in letting the server tell you "this mailbox exists somewhere else", but > not actually tell you *where* until you try to do something with it (if, > for example, there are 50 remote mailboxes and it takes 1 second to > retrieve the referral data for each, adding 50 seconds to the LIST > (REFERRALS) command would be bad, and it might be better to make you try > a SELECT when you actually want to use one of them). Do any servers > besides Exchange support mailbox referrals now? How fast is it for Exchange (or > other servers) to retrieve the referral details? *** For Exchange, there will be some hit in getting the referral data. Probably not devasting, but likely noticeable in the time it takes the LIST response to come back. From a general design point of view, it is probably best to not include the referral details in a response. Why generate this info until it is needed? Not to mention sending the extra info across the wire, (which if there are multiple replicas could get large). Received: by ns.secondary.com (8.9.3/8.9.3) id OAA20217 for ietf-imapext-bks; Fri, 3 Nov 2000 14:48:05 -0800 (PST) Received: from episteme-software.com (presnick-fw.flexabit.net [64.198.230.34]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA20213 for ; Fri, 3 Nov 2000 14:48:04 -0800 (PST) Received: from presnick-35.flexabit.net (64.198.230.35) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.0.2a2); Fri, 3 Nov 2000 16:54:06 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: References: X-Mailer: Eudora [Macintosh version 5.1a1-12.00] Date: Fri, 3 Nov 2000 16:54:04 -0600 To: "Eric Burger" From: Pete Resnick Subject: RE: moderate or restrict IMAPEXT Cc: "Mark Crispin" , "IMAP Extensions WG" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 11/3/00 at 5:38 PM -0500, Eric Burger wrote: >What if we just limit posting to subscribers? That reduces the chance of an >amature spammer succeeding, without the pain for the moderator. And it would proceed to disallow people like IESG members and others who don't subscribe to the list from posting. I heavily object to that. I'll moderate if we can work that out. pr -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA19767 for ietf-imapext-bks; Fri, 3 Nov 2000 14:33:31 -0800 (PST) Received: from mail15a.boca15-verio.com (mail15a.boca15-verio.com [208.55.91.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA19762 for ; Fri, 3 Nov 2000 14:33:30 -0800 (PST) Received: from www.snowshore.com (128.241.144.247) by mail15a.boca15-verio.com (RS ver 1.0.57s) with SMTP id 02549864; Fri, 3 Nov 2000 17:39:29 -0500 (EST) From: "Eric Burger" To: "Pete Resnick" , "Mark Crispin" Cc: "IMAP Extensions WG" Subject: RE: moderate or restrict IMAPEXT Date: Fri, 3 Nov 2000 17:38:58 -0500 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: X-Loop-Detect: 1 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: What if we just limit posting to subscribers? That reduces the chance of an amature spammer succeeding, without the pain for the moderator. -- - Eric -----Original Message----- From: owner-ietf-imapext@mail.imc.org [mailto:owner-ietf-imapext@mail.imc.org]On Behalf Of Pete Resnick Sent: Friday, November 03, 2000 1:24 PM To: Mark Crispin Cc: IMAP Extensions WG Subject: Re: moderate or restrict IMAPEXT On 11/3/00 at 9:48 AM -0800, Mark Crispin wrote: >Please establish moderation on IMAPEXT Paul, I'm perfectly willing to do this if you have a method. If we can use IMAP mailboxes to do this (perhaps an incoming IMAP mailbox on your server that I moderate and transfer to another mailbox on your server that you send out to the list), it would be perfectly easy for me. pr -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA19089 for ietf-imapext-bks; Fri, 3 Nov 2000 14:01:35 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA19085 for ; Fri, 3 Nov 2000 14:01:34 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 3 Nov 2000 14:01:17 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 03 Nov 2000 14:01:59 -0800 (Pacific Standard Time) Received: from mikega10 ([157.59.252.141]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 3 Nov 2000 14:01:58 -0800 Message-ID: <000f01c045e1$af45a8b0$8dfc3b9d@redmond.corp.microsoft.com> From: "Mike Gahrns" To: "Mark Crispin" Cc: References: Subject: Re: comments on LIST extensions Date: Fri, 3 Nov 2000 14:01:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-OriginalArrivalTime: 03 Nov 2000 22:01:58.0143 (UTC) FILETIME=[AF8AA0F0:01C045E1] Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: > My idea was that you would not show referrals unless you asked for referral > information in the extended LIST. This could work. My assumptions were that the extended LIST info would be always coming back. How did you envision your suggestion working? Are you proposing a command to turn on extend LIST responses, or a command to include referral info in an extended LIST response? This seems like it would be adding "modes" to IMAP, which I thought there were strong objections to in the past... With a command like XLIST, it was explicit that the client was requesting this additional info and had to be prepared to handle it. Received: by ns.secondary.com (8.9.3/8.9.3) id NAA18729 for ietf-imapext-bks; Fri, 3 Nov 2000 13:48:16 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (warner@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA18724 for ; Fri, 3 Nov 2000 13:48:15 -0800 (PST) Date: Fri, 3 Nov 2000 13:53:07 -0800 (PST) From: Mark Crispin Subject: Re: comments on LIST extensions To: Mike Gahrns cc: Steve Hole , Tony Hansen , Barry Leiba , ietf-imapext@imc.org In-Reply-To: <000a01c045e0$2e125c80$8dfc3b9d@redmond.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 3 Nov 2000 13:51:06 -0800, Mike Gahrns wrote: > *** One drawback of extending LIST through upwards-compatible syntax instead > of creating a new command like XLIST, is that it will create problems in > the referral case. My idea was that you would not show referrals unless you asked for referral information in the extended LIST. Received: by ns.secondary.com (8.9.3/8.9.3) id NAA18667 for ietf-imapext-bks; Fri, 3 Nov 2000 13:46:02 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA18663 for ; Fri, 3 Nov 2000 13:46:00 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 3 Nov 2000 13:50:31 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 03 Nov 2000 13:51:12 -0800 (Pacific Standard Time) Received: from mikega10 ([157.59.252.141]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 3 Nov 2000 13:51:11 -0800 Message-ID: <000a01c045e0$2e125c80$8dfc3b9d@redmond.corp.microsoft.com> From: "Mike Gahrns" To: "Mark Crispin" , "Steve Hole" Cc: "Tony Hansen" , "Barry Leiba" , References: Subject: Re: comments on LIST extensions Date: Fri, 3 Nov 2000 13:51:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-OriginalArrivalTime: 03 Nov 2000 21:51:11.0865 (UTC) FILETIME=[2E546E90:01C045E0] Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: > I am not yet convinced that we can not extend LIST through upwards-compatible > syntax. Shouldn't we proceed as if we can do so, with the understanding that > XLIST is not out of the question if we hit an otherwise insurmountable > obstacle? *** One drawback of extending LIST through upwards-compatible syntax instead of creating a new command like XLIST, is that it will create problems in the referral case. Even if we add referral info in a LIST response that presumably would be ignored by non-referral enabled clients, these non-referral enabled clients would still likely show these remote folders to their users. This was deemed undesirable during the initial referral discussions. e.g. The user experience would be bad in that users would try to select these remote folders, and have the SELECT command fail when accessed. Received: by ns.secondary.com (8.9.3/8.9.3) id MAA16921 for ietf-imapext-bks; Fri, 3 Nov 2000 12:26:25 -0800 (PST) Received: from episteme-software.com (presnick-fw.flexabit.net [64.198.230.34]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA16915 for ; Fri, 3 Nov 2000 12:26:22 -0800 (PST) Received: from presnick-35.flexabit.net (64.198.230.35) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.0.2a2); Fri, 3 Nov 2000 13:44:00 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: <2598967901.973261576@mars.trees.watson.ibm.com> References: <2598967901.973261576@mars.trees.watson.ibm.com> X-Mailer: Eudora [Macintosh version 5.1a1-12.00] Date: Fri, 3 Nov 2000 13:43:57 -0600 To: Barry Leiba From: Pete Resnick Subject: Re: comments on LIST extensions Cc: ietf-imapext@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 11/3/00 at 2:26 PM -0500, Barry Leiba wrote: >OK, then... since all the discussions about what XLIST might be have >so far been ad hoc discussion among a few of us, why don't we get >some time on the agenda at San Diego and have a proper discussion of >it. I'll take that discussion and come up with a first pass at the >requirements, and then we can discuss it further on the mailing list. > >If that's the way everyone wants to go, then I'll not make any >updates to the LIST Extensions draft now, and the next revision will >just be the first draft of the new XLIST command. Shall we do it >that way? Barry, I am more inclined to have you write *something* before the meeting if you can, even if it is just a straw man to bat around. We've still got two weeks to discuss this a bit on the list and maybe get Barry enough stuff to throw into an I-D before the November 17 deadline. If we can't, such is life, but let's see what we can do. In either case, this will still be an important item on the agenda. pr -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA16918 for ietf-imapext-bks; Fri, 3 Nov 2000 12:26:24 -0800 (PST) Received: from episteme-software.com (presnick-fw.flexabit.net [64.198.230.34]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA16911 for ; Fri, 3 Nov 2000 12:26:22 -0800 (PST) Received: from presnick-35.flexabit.net (64.198.230.35) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.0.2a2); Fri, 3 Nov 2000 12:24:14 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: References: X-Mailer: Eudora [Macintosh version 5.1a1-12.00] Date: Fri, 3 Nov 2000 12:24:02 -0600 To: Mark Crispin From: Pete Resnick Subject: Re: moderate or restrict IMAPEXT Cc: IMAP Extensions WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 11/3/00 at 9:48 AM -0800, Mark Crispin wrote: >Please establish moderation on IMAPEXT Paul, I'm perfectly willing to do this if you have a method. If we can use IMAP mailboxes to do this (perhaps an incoming IMAP mailbox on your server that I moderate and transfer to another mailbox on your server that you send out to the list), it would be perfectly easy for me. pr -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA14247 for ietf-imapext-bks; Fri, 3 Nov 2000 11:19:49 -0800 (PST) Received: from igw8.watson.ibm.com (igw8.watson.ibm.com [198.81.209.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA14243 for ; Fri, 3 Nov 2000 11:19:47 -0800 (PST) Received: from sp1n190at0.watson.ibm.com (sp1n190at0.watson.ibm.com [9.2.104.63]) by igw8.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id OAA20376 for ; Fri, 3 Nov 2000 14:26:17 -0500 Received: from mars.trees.watson.ibm.com (mars.watson.ibm.com [9.2.40.64]) by sp1n190at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id OAA26526 for ; Fri, 3 Nov 2000 14:26:17 -0500 Date: Fri, 03 Nov 2000 14:26:16 -0500 From: Barry Leiba To: ietf-imapext@imc.org Subject: Re: comments on LIST extensions Message-ID: <2598967901.973261576@mars.trees.watson.ibm.com> In-Reply-To: X-Mailer: Mulberry/2.0.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Mark is right, we need a set of requirements that we can get concensus on. > From there we can design the thing we want. OK, then... since all the discussions about what XLIST might be have so far been ad hoc discussion among a few of us, why don't we get some time on the agenda at San Diego and have a proper discussion of it. I'll take that discussion and come up with a first pass at the requirements, and then we can discuss it further on the mailing list. If that's the way everyone wants to go, then I'll not make any updates to the LIST Extensions draft now, and the next revision will just be the first draft of the new XLIST command. Shall we do it that way? Barry Leiba, Living Lab Services (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba Received: by ns.secondary.com (8.9.3/8.9.3) id LAA13955 for ietf-imapext-bks; Fri, 3 Nov 2000 11:17:07 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (rodriguez@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA13949 for ; Fri, 3 Nov 2000 11:17:06 -0800 (PST) Date: Fri, 3 Nov 2000 10:46:54 -0800 (PST) From: Mark Crispin Subject: Re: comments on LIST extensions To: Steve Hole cc: Tony Hansen , Barry Leiba , ietf-imapext@imc.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Obviously, base LIST and LSUB have to be left alone. However, base LIST and LSUB does have an extension mechanism for attributes, so the server can utter extraneous attributes to a base client. I am not yet convinced that we can not extend LIST through upwards-compatible syntax. Shouldn't we proceed as if we can do so, with the understanding that XLIST is not out of the question if we hit an otherwise insurmountable obstacle? Unless I'm completely off-base, there are three things that need to be done: 1) Add additional attributes. Completely compatible with base spec. 2) Add additional arguments to LIST command. Must be governed by capability. 3) Add additional return values to LIST response. Must be governed by use of an extended LIST command from (2). Whether or not we also do XLIST, I think that we should do these steps to LIST. Received: by ns.secondary.com (8.9.3/8.9.3) id KAA11560 for ietf-imapext-bks; Fri, 3 Nov 2000 10:49:37 -0800 (PST) Received: from demo.esys.ca (IDENT:root@demo.esys.ca [207.167.22.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA11553 for ; Fri, 3 Nov 2000 10:49:35 -0800 (PST) Received: from kepler.esys.ca (kepler.esys.ca [198.161.92.108]) by demo.esys.ca (8.9.3 (MessagingDirect 1.0.4)/8.9.3) with ESMTP id LAA21311; Fri, 3 Nov 2000 11:42:25 -0700 From: Steve Hole Date: Fri, 3 Nov 2000 11:41:48 -0700 To: Mark Crispin Subject: Re: comments on LIST extensions Cc: Tony Hansen , Barry Leiba , ietf-imapext@imc.org In-Reply-To: References: Message-ID: X-Mailer: Execmail for Linux 5.3 b1 Build (1) -- Evaluation Copy MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 3 Nov 2000 10:12:18 -0800 (PST) Mark Crispin wrote: > Leaving aside the issue of LIST vs. XLIST, I recommend that there be a > statement or position paper about these "actual requirements." > > This is to ensure that we are all on the same wavelength. What you feel that > "we have learned" may be very different from what people here that "we have > learned." > > Having created and agreed to such a list, we should use that list in the > resulting design. We get into trouble when we don't have a fixed (and mutual) > statement of requirements. Sounds good to me. > This statement scares me. Backward compatibility is a good thing, and should > be abandoned only with a great deal of reluctance. > > The current LIST architecture definitely has problems, but those problems > happened for a reason. Ya ... it sounds worse than it was meant to. I think my point is that LIST did happen for a reason and it was successful in providing a bridge from pre-IMAP4 functionality to IMAP4. That is why I would like to leave LIST and LSUB alone. It is part of the base spec and mandatory to implement. With XLIST we have an opportunity to take the good stuff from LIST (like the basic mailbox metaphor) and create a new command that has all of that, plus all of the good stuff from the other extensions to LIST (like referrals etc.) and unify it all together. I think we can do that because everyone has to implement LIST and LSUB no matter what and we can make sure that everyone interoperates. The risk is that we try to build something that is mutually incompatible from a basic principles point of view and that makes implementation on the server (and possibly in the client) completely impractical. We just shouldn't do that. Of course, it is exactly this issue that has gotten us into trouble before -- where is the line for impractical implementation. Mark is right, we need a set of requirements that we can get concensus on. >From there we can design the thing we want. Cheers. --- Steve Hole Chief Technology Officer MessagingDirect Ltd. Phone: 780-424-4922 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA11149 for ietf-imapext-bks; Fri, 3 Nov 2000 10:40:13 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (guest@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA11141 for ; Fri, 3 Nov 2000 10:40:11 -0800 (PST) Date: Fri, 3 Nov 2000 10:34:31 -0800 (PST) From: Mark Crispin Subject: Re: comments on LIST extensions To: Barry Leiba cc: ietf-imapext@imc.org In-Reply-To: <2595573948.973258182@mars.trees.watson.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 03 Nov 2000 13:29:42 -0500, Barry Leiba wrote: > Right, but I think that what Steve means is that we should leave LIST and > LSUB alone, and that provides the backward compatibility... and then we can > make a new XLIST command that's unencumbered by those issues. That's OK as far as it goes. However, the underlying reasons for why those issues came to be can't be ignored. For example, although I understand the desire for greater client control over server behavior, nonetheless you can't forbid the server from making decisions that overrule client desires. Servers have a right (some would say obligation) to protect themselves. LIST * is the obvious example of this. A possible solution may be to expand responses so that it is clear when the server is declining to give information (or otherwise do something). Suppose, for example, there was a \Select and an \Inferiors attribute in LIST; in that case () would mean "server declines to say" rather than ambiguous between that and (\Select \Inferiors). However, this brings us to the "silly state" argument whenever we have a three way state such as this represented by binary flags; there's a fourth, silly, state. I abhor such silly states as bad architecture. Plus, sooner or later, some clown will do it, and software has to figure out what to do. So, when designing this facility, we should use mechanisms that avoid silly states. In other words, if it's a three-way state, then use a three-way protocol mechanism instead of a pair of binary mechanisms. Received: by ns.secondary.com (8.9.3/8.9.3) id KAA10432 for ietf-imapext-bks; Fri, 3 Nov 2000 10:26:14 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA10428 for ; Fri, 3 Nov 2000 10:26:13 -0800 (PST) Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [206.31.218.216]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id NAA11326; Fri, 3 Nov 2000 13:27:49 -0500 (EST) Date: Fri, 03 Nov 2000 13:28:48 -0500 From: Cyrus Daboo To: Steve Hole , Tony Hansen cc: Barry Leiba , ietf-imapext@imc.org Subject: Re: comments on LIST extensions Message-ID: <1189319.973258128@socrates.cyrusoft.com> In-Reply-To: X-Mailer: Mulberry/2.1.0d1 (MacOS-PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Friday, November 3, 2000 10:52 AM -0700 Steve Hole wrote: >> I think the charter has us, among other things, working on >> augmenting/fixing LIST. I don't think the charter constrains us to the >> form those augmentations or fixes must take. > > Exactly. Even if the charter did constrain, I would suggest cutting > LIST extension out of imapext and proceeding with an XLIST outside of > imapext. Mark is exactly right that messing with LIST and LSUB has two > major problems: > > 1. It constrains the final solution unacceptibly because we have a > learned a great deal about the actual requirements for managing mailbox > namespaces. We will be forced to tradeoffs for backward compatibility > that we don't want to make. > > 2. It will confuse new developers tremendously. The interoperability > with LIST and LSUB will get worse than it already is. I think your XLIST is really covered under the auspices of the mailbox annotations extension, which I believe we did agree to cover in the WG, once the message annotation issues were worked out. Note that mailbox annotations can encompose a lot of other extensions through unification. It would naturally include all the existing LIST flags, and include CHILDREN and RLIST. But it can go further and include STATUS, access control and quota information, in addition to arbitrary attribute-value data, thus giving a single command syntax to cover nearly all mailbox specific operations. -- Cyrus Daboo Received: by ns.secondary.com (8.9.3/8.9.3) id KAA10376 for ietf-imapext-bks; Fri, 3 Nov 2000 10:23:16 -0800 (PST) Received: from igw8.watson.ibm.com (igw8.watson.ibm.com [198.81.209.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA10372 for ; Fri, 3 Nov 2000 10:23:14 -0800 (PST) Received: from sp1n190at0.watson.ibm.com (sp1n190at0.watson.ibm.com [9.2.104.63]) by igw8.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id NAA19938 for ; Fri, 3 Nov 2000 13:29:43 -0500 Received: from mars.trees.watson.ibm.com (mars.watson.ibm.com [9.2.40.64]) by sp1n190at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id NAA46546 for ; Fri, 3 Nov 2000 13:29:43 -0500 Date: Fri, 03 Nov 2000 13:29:42 -0500 From: Barry Leiba To: ietf-imapext@imc.org Subject: Re: comments on LIST extensions Message-ID: <2595573948.973258182@mars.trees.watson.ibm.com> In-Reply-To: X-Mailer: Mulberry/2.0.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> We will be forced to tradeoffs for backward compatibility >> that we don't want to make. > > This statement scares me. Backward compatibility is a good thing, and > should be abandoned only with a great deal of reluctance. Right, but I think that what Steve means is that we should leave LIST and LSUB alone, and that provides the backward compatibility... and then we can make a new XLIST command that's unencumbered by those issues. Barry Received: by ns.secondary.com (8.9.3/8.9.3) id KAA10281 for ietf-imapext-bks; Fri, 3 Nov 2000 10:17:18 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (v92ti@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA10276 for ; Fri, 3 Nov 2000 10:17:17 -0800 (PST) Date: Fri, 3 Nov 2000 10:12:18 -0800 (PST) From: Mark Crispin Subject: Re: comments on LIST extensions To: Steve Hole cc: Tony Hansen , Barry Leiba , ietf-imapext@imc.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 3 Nov 2000 10:52:38 -0700, Steve Hole wrote: > 1. It constrains the final solution unacceptibly because we have a > learned a great deal about the actual requirements for managing mailbox > namespaces. Leaving aside the issue of LIST vs. XLIST, I recommend that there be a statement or position paper about these "actual requirements." This is to ensure that we are all on the same wavelength. What you feel that "we have learned" may be very different from what people here that "we have learned." Having created and agreed to such a list, we should use that list in the resulting design. We get into trouble when we don't have a fixed (and mutual) statement of requirements. > We will be forced to tradeoffs for backward compatibility > that we don't want to make. This statement scares me. Backward compatibility is a good thing, and should be abandoned only with a great deal of reluctance. The current LIST architecture definitely has problems, but those problems happened for a reason. Received: by ns.secondary.com (8.9.3/8.9.3) id KAA10175 for ietf-imapext-bks; Fri, 3 Nov 2000 10:13:39 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA10169 for ; Fri, 3 Nov 2000 10:13:38 -0800 (PST) Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [206.31.218.216]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id NAA11282; Fri, 3 Nov 2000 13:18:54 -0500 (EST) Date: Fri, 03 Nov 2000 13:19:53 -0500 From: Cyrus Daboo To: Mark Crispin , IMAP Extensions WG Subject: Re: moderate or restrict IMAPEXT Message-ID: <1157111.973257593@socrates.cyrusoft.com> In-Reply-To: X-Mailer: Mulberry/2.1.0d1 (MacOS-PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Friday, November 3, 2000 9:48 AM -0800 Mark Crispin wrote: > It happened again today. IMAPEXT polluted my mailbox with a spam for a > fake love potion. > > No, I do not want to hear offers for quack medicines, dirty pictures, > pyramid schemes, et nauseum. > > Please establish moderation on IMAPEXT; or at least restrict posting > privileges to list members. > > -- Mark -- > > http://staff.washington.edu/mrc > Science does not emerge from voting, party politics, or public debate. > >From what I can see the 'spam' arriving on this list has not included imapext in To, CC addresses. There were two messages in that category that were not spam, but I think its reasonable to expect posts to this list to contain the imapext address in either the To or CC headers. Thus a simple SIEVE script like the following would work as a reasonable filter for the time being: # SIEVE Script # Name: imapext spam discard # Date: Fri, 03 Nov 2000 13:18:32 -0500 # User-Agent : Mulberry 2.1.0d1 # Rule 1: imapext spam discard # Generated from GUI if not address :contains ["To", "CC"] "ietf-imapext@imc.org" { discard; } # SIEVE Script ends here -- Cyrus Daboo Received: by ns.secondary.com (8.9.3/8.9.3) id KAA09870 for ietf-imapext-bks; Fri, 3 Nov 2000 10:00:25 -0800 (PST) Received: from demo.esys.ca (IDENT:root@demo.esys.ca [207.167.22.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA09865 for ; Fri, 3 Nov 2000 10:00:23 -0800 (PST) Received: from kepler.esys.ca (kepler.esys.ca [198.161.92.108]) by demo.esys.ca (8.9.3 (MessagingDirect 1.0.4)/8.9.3) with ESMTP id KAA21191; Fri, 3 Nov 2000 10:53:14 -0700 From: Steve Hole Date: Fri, 3 Nov 2000 10:52:38 -0700 To: Tony Hansen Subject: Re: comments on LIST extensions Cc: Barry Leiba , ietf-imapext@imc.org In-Reply-To: <3A02D36E.A3A891F3@att.com> References: <3A02D36E.A3A891F3@att.com> <2578869589.973241478@mars.trees.watson.ibm.com> Message-ID: X-Mailer: Execmail for Linux 5.3 b1 Build (1) -- Evaluation Copy MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 03 Nov 2000 10:02:06 -0500 Tony Hansen wrote: > I think the charter has us, among other things, working on > augmenting/fixing LIST. I don't think the charter constrains us to the > form those augmentations or fixes must take. Exactly. Even if the charter did constrain, I would suggest cutting LIST extension out of imapext and proceeding with an XLIST outside of imapext. Mark is exactly right that messing with LIST and LSUB has two major problems: 1. It constrains the final solution unacceptibly because we have a learned a great deal about the actual requirements for managing mailbox namespaces. We will be forced to tradeoffs for backward compatibility that we don't want to make. 2. It will confuse new developers tremendously. The interoperability with LIST and LSUB will get worse than it already is. Cheers. --- Steve Hole Chief Technology Officer MessagingDirect Ltd. Phone: 780-424-4922 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA08895 for ietf-imapext-bks; Fri, 3 Nov 2000 09:41:49 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (koma@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA08891 for ; Fri, 3 Nov 2000 09:41:47 -0800 (PST) Date: Fri, 3 Nov 2000 09:48:16 -0800 (PST) From: Mark Crispin To: IMAP Extensions WG Subject: moderate or restrict IMAPEXT Message-ID: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It happened again today. IMAPEXT polluted my mailbox with a spam for a fake love potion. No, I do not want to hear offers for quack medicines, dirty pictures, pyramid schemes, et nauseum. Please establish moderation on IMAPEXT; or at least restrict posting privileges to list members. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: by ns.secondary.com (8.9.3/8.9.3) id HAA29830 for ietf-imapext-bks; Fri, 3 Nov 2000 07:00:36 -0800 (PST) Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA29823 for ; Fri, 3 Nov 2000 07:00:34 -0800 (PST) Received: from dns.maillennium.att.com ([135.25.114.99]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.3) with ESMTP id KAA02306 for ; Fri, 3 Nov 2000 10:06:33 -0500 (EST) Received: from att.com ([135.197.86.244]) by maillennium.att.com (labmail) with SMTP id <20001103150631099005qh39e> (Authid: tony@maillennium.att.com); Fri, 3 Nov 2000 15:06:32 +0000 Message-ID: <3A02D36E.A3A891F3@att.com> Date: Fri, 03 Nov 2000 10:02:06 -0500 From: Tony Hansen Organization: AT&T Laboratories X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Barry Leiba CC: ietf-imapext@imc.org Subject: Re: comments on LIST extensions References: <2578869589.973241478@mars.trees.watson.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think the charter has us, among other things, working on augmenting/fixing LIST. I don't think the charter constrains us to the form those augmentations or fixes must take. Tony Barry Leiba wrote: > > > Actually Barry, while I applaud the extensible LIST argument attempt, what > > I am most interested in is an entirely new, all consuming LIST command. > > Call it XLIST for the purpose of discussion. > > Yes, we've talked about this, and I agree, and I want to work on that. It > was my understanding, though, that doing that was beyond the scope of the > IMAPExt WG, and that the LIST extensions that the WG decided to work on > were of the sort described in this draft. Pete R., can you clarify? I'll > be happy to shift this draft toward a complete revision of the LIST > command, if the WG considers it to be within its scope. Otherwise I'll > continue with this as the interim answer, and work on the "XLIST" (or > whatever) afterward. Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA24692 for ietf-imapext-bks; Fri, 3 Nov 2000 06:03:06 -0800 (PST) Received: from igw8.watson.ibm.com (igw8.watson.ibm.com [198.81.209.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA24688 for ; Fri, 3 Nov 2000 06:03:04 -0800 (PST) Received: from sp1n190at0.watson.ibm.com (sp1n190at0.watson.ibm.com [9.2.104.63]) by igw8.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id JAA09662 for ; Fri, 3 Nov 2000 09:09:32 -0500 Received: from mars.trees.watson.ibm.com (mars.watson.ibm.com [9.2.40.64]) by sp1n190at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id JAA31058 for ; Fri, 3 Nov 2000 09:09:31 -0500 Date: Fri, 03 Nov 2000 09:09:31 -0500 From: Barry Leiba To: ietf-imapext@imc.org Subject: Re: comments on LIST extensions Message-ID: <2579962729.973242571@mars.trees.watson.ibm.com> In-Reply-To: X-Mailer: Mulberry/2.0.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Remember, subscriptions were defined specifically to support a > pre-existing functionality, and that this functionality is in use. > Compatibility with this functionality must be retained. > > If I understand your proposal correctly, you're doing this. Yes, by keeping LSUB as is and recommending its continued use. >> 2. Maybe add wording to clarify that flags returned by LSUB may not be >> accurate. This should probably be in the base spec, actually. > > It isn't that the flags are inaccurate; they are different. For example, > \NoSelect means something different in LSUB. The list of flags may also not include flags that would be included in a LIST. I don't mean to say that flags would appear spuriously, so it's probably more accurate to say that "the flags returned by LSUB may be incomplete, and some may have different meanings." The point is that a client can't know whether "()" means there are no flags set or that this server can't return the list of flags in LSUB. In fact, there's nothing stopping a server from returning, say, "(\Marked)" in response to LSUB and "(\Marked \NoInferiors)" in response to LIST (or some other similar example). > I'll be happy to consider suggested changes to the base spec wording for > this. Please review what's in the current draft, not RFC 2060. I'll do that and post something separately about it; thanks. > OK, so by omitting LIST-SUBSCRIBED, I can implement the other options > (and use them), correct? > > Put another way, there is no requirement to implement LIST-SUBSCRIBED in > order to implement any other piece of this technology, correct? Exactly; that's the intent here. I'm recommending that you implement LIST-SUBSCRIBED, because clients can and will get that information anyway if they really want it, at greater cost... but its implementation is entirely optional. > "\NonExistant" => "\NonExistent" Glrf. Thanks. I hate when I misspel things. :-) >> 6. Add a new mailbox flag, "\PlaceHolder" (alternative name?), intended >> to indicate, when necessary, that "this mailbox does not meet your >> selection criteria, but it has a child that might (or, stronger, does?)". > > How will this work with LSUB, given the need to maintain compatibility? I > suggest that it be allowed in LSUB, but *with* the overloaded \NoSelect, > e.g. * LSUB (\NoSelect \PlaceHolder) "/" foo > to make it unambiguous that the \NoSelect is the overloaded form. Yes, that was also the intent, and I didn't mention that. To be general: LSUB MUST behave as it always has, but MAY also include the new flags. Clients MAY use the new flags for the information they convey, but MUST NOT assume that their absence means anything. Side issue here: if a client sees "\NonExistent" or "\PlaceHolder" in one LSUB response line, can it now assume that their absence in other response lines is meaningful? Maybe it's best not to address this. > I think that we should do it. I've been convinced that we should have > another value in the LIST response, containing a parenthesized list of > property/value pairs. > * LIST () "/" foo (REFERRAL "..." BLOOP soop) > > The purpose of the parentheses is to enable to addition of another value > in the response in the future if it turns out that attribute or > property/value aren't enough. Absolutely, on the parentheses; I think it's valuable to group things that way for extensibility. OK, since everyone who's chimed in agrees that the referral data should be presented(*), I'll work that in. Should that go in this spec, or into a revision of the MAILBOX-REFERRALS spec? (*) The only concern I have here is that a referral-capable server might know quickly that a mailbox is remote, but might have a slower time actually retrieving the referral information. So there *might* be some use in letting the server tell you "this mailbox exists somewhere else", but not actually tell you *where* until you try to do something with it (if, for example, there are 50 remote mailboxes and it takes 1 second to retrieve the referral data for each, adding 50 seconds to the LIST (REFERRALS) command would be bad, and it might be better to make you try a SELECT when you actually want to use one of them). Do any servers besides Exchange support mailbox referrals now? How fast is it for Exchange (or other servers) to retrieve the referral details? Barry Leiba, Living Lab Services (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba Received: by ns.secondary.com (8.9.3/8.9.3) id FAA23708 for ietf-imapext-bks; Fri, 3 Nov 2000 05:44:52 -0800 (PST) Received: from igw8.watson.ibm.com (igw8.watson.ibm.com [198.81.209.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA23704 for ; Fri, 3 Nov 2000 05:44:51 -0800 (PST) Received: from sp1n190at0.watson.ibm.com (sp1n190at0.watson.ibm.com [9.2.104.63]) by igw8.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id IAA09552 for ; Fri, 3 Nov 2000 08:51:19 -0500 Received: from mars.trees.watson.ibm.com (mars.watson.ibm.com [9.2.40.64]) by sp1n190at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id IAA30302 for ; Fri, 3 Nov 2000 08:51:18 -0500 Date: Fri, 03 Nov 2000 08:51:18 -0500 From: Barry Leiba To: ietf-imapext@imc.org Subject: Re: comments on LIST extensions Message-ID: <2578869589.973241478@mars.trees.watson.ibm.com> In-Reply-To: X-Mailer: Mulberry/2.0.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Actually Barry, while I applaud the extensible LIST argument attempt, what > I am most interested in is an entirely new, all consuming LIST command. > Call it XLIST for the purpose of discussion. Yes, we've talked about this, and I agree, and I want to work on that. It was my understanding, though, that doing that was beyond the scope of the IMAPExt WG, and that the LIST extensions that the WG decided to work on were of the sort described in this draft. Pete R., can you clarify? I'll be happy to shift this draft toward a complete revision of the LIST command, if the WG considers it to be within its scope. Otherwise I'll continue with this as the interim answer, and work on the "XLIST" (or whatever) afterward. > 1. I would like to see the orginal extension framework draft revived, > Included the restriction on applicable command set if people still feel > it is necessary. I agree, and I think that I asked for comments on this resurrection a while ago and got insufficient support, considering the objections from Mark and Chris. If there's enough support for it to try to get past their objections, I'm certainly eager to pursue it, and I think Cyrus is too. I'd rather discuss it here, unless Pete objects, rather than on the IMAP list, but I think it's outside the scope of the IMAPExt WG. Barry Leiba, Living Lab Services (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA18426 for ietf-imapext-bks; Fri, 3 Nov 2000 03:59:13 -0800 (PST) Received: from dns.wsbx.com ([202.99.11.67]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA18417 for ; Fri, 3 Nov 2000 03:59:09 -0800 (PST) Date: Fri, 3 Nov 2000 03:59:09 -0800 (PST) From: hv@of-hachetal.de Message-Id: <200011031159.DAA18417@ns.secondary.com> Received: from h809 (1cust188.tnt3.mia5.da.uu.net [63.30.200.188]) by dns.wsbx.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id V8F2G3HT; Fri, 3 Nov 2000 20:08:30 +0800 To: hv@of-hachetal.de Subject: At last, Herbal V, the all natural alternative to V----A! Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Herbal V: An Incredible All-Natural Healthy Alternative Herbal V is the All Natural Approach to Male Virility, Vitality and Pleasure. Available N o w ! Welcome to the New Sexual Revolution. It's the all natural male potency and pleasure pill that men everywhere are buzzing about. Herbal V is safe, natural and specifically formulated to help support male sexual function and pleasure. You just take two easy-to-swallow tablets one hour before sex. And there's more great news - you can get Herbal V for less than $1 a pill. Amazing word of mouth praise on Herbal V has been spreading like wildfire-already over 1,500,000 men have chosen Herbal V. Since it is 100% natural you will never have to worry about safety. Try doctor-recommended Herbal V today and have the greatest night of your life! Herbal V... Bringing Back the Magic! 1,585,000 men can't be wrong. To date over 1 million men have tried the super supplement Herbal V. Here is why: No Doctor Visit Required Available Over the Counter Not a Drug 100% Natural Safe, No Worries Highest Quality Pharmaceutical-Grade Pure Nutriceuticals Guaranteed Potency & Purity Be a Real Man Again! Questions and Answers What is Herbal V? Herbal V is a proprietary blend that was specifically developed as a safe alternative for men who prefer an all-natural approach to address impotence and boost sexual performance. This amazing formula first became popular with Hollywood insiders and the wealthy elite. They were maximizing their sex lives, long before it was available to the general public. How does Herbal V work? Developed by a team whose goal was to create the perfect all-natural aphrodisiac. Herbal V is the result of that remarkable effort. The Herbal V formula contains a precise blend of cutting edge pro-sexual nutrients from around the world that provide nutritional support, making it possible for a man to have a pleasurable sexual experience. What can Herbal V do for me? Herbal V helps support male sexual function and pleasure in a safe and natural manner. Simply put, it can make your sex life incredible. Is Herbal V Safe? One of the great things about Herbal V is that it is not a drug. It is an incredible herbal dietary supplement that provides nutritional support for male sexual function and pleasure. One of the most comforting features of Herbal V is that you never have to worry about safety. Herbal V: Safe - Natural - Exciting Many have speculated that because Herbal V is so popular with men, it must contain prescription drugs or chemical components. Herbal V does not contain any elements or traces of any prescription drug. Herbal V is made using the world's most technologically advanced state-of-the-art cold processing equipment to ensure maximum purity. Herbal V has been independently analyzed by the nation's premier testing facility to ensure purity, quality and to end the rumors that, because it is so popular, it must somehow be chemical. It is not. Herbal V is natural - just as it says on the label. Herbal V is simply fantastic! Herbal V: Ingredients Yohimbe, saw palmetto, avena sativa, androstenedione, guarana, taurine, siberian ginseng, tribulus terrestris. Tribulus Terrestis is certified to enhanced testosterone levels by increasing Luteinzing hormone (LH) levels. Androstenedione which is a precursor to testosterone unlocks bound testosterone and makes it biologically active again quickly. This means a dramatic surge in desire. Avena Sativa Stimulates the neurotransmitter pleasure centers to maximum capacity. This greatly intensifies pleasure. Just listen to what Herbal V has done for the sex lives of people like you! “On a scale of 1 to 10, it's a 15. Electrifying. It's like a wonder pill!” — Justin Q B., New Haven, Texas “I haven't had sexual relations in 11 years. Then with Herbal V it was... wow! It works again!” — Sid R., Lakeland, Florida “I had sex four times in one night. It made me feel like a 19-year-old again.” — Chip S, Beech Mountain, North Carolina “Herbal V has turned my husband into a Sexual Superman! I like the fact that it's all natural and has no side effects. It's bringing back the good old days.” — Jennifer B, Beverly Hills, California The above testimonials are from product literature, and we have not independently verified them. However, the following testimonial is from a "senior" gentleman who has purchased his second bottle of Herbal V. When we heard his words with our own ears, we asked his permission to print them here. “Man! I'm wild as I can be! I feel like I'm 25 years old again! I'm not believing this!” — Mr. Murphy, age 64, Lampart, IL. Risk Free: Double Your Money Back Guarantee If Herbal V does not give the desired results as stated above, simply return the unused portion for a double-your money back refund. No questions asked ! Order Now: Safe, Fast, Secure, Private Herbal V with its DOUBLE YOUR MONEY BACK GUARANTEE is available only through this special promotional offer. Herbal V arrives in plain packaging for your privacy. Any and all information is kept strictly confidential. Payment Methods You may FAX or Postal Mail Checks, MasterCard, Visa, & American Express.payments. Money Orders are accepted only by Postal Mail. Each bottle of Herbal V contains 30 tablets, approximately a 1 month supply. Step 1: Place a check by your desired quanity. ______ 1 Bottle of Herbal V $28 ______ 2 Bottles of Herbal V $48 ______ 3 Bottles of Herbal V $59 Please add $6 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$34, 2 bottles=$54, 3 bottles=$65 ] International Orders Please add $16 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$40, 2 bottles=$60, 3 bottles=$75 ] We cannot accept foreign checks. International money orders or credit cards only. Step 2: Place a check by your desired payment method and complete fields if necessary. _____Check or CHECK-BY-FAX [details below] _____Money Order _____American Express Account Number__________________ Exp____/____ _____Visa Account Number__________________ Exp____/____ _____MasterCard Account Number__________________ Exp____/____ Please make your check or money order payable to "Lion Sciences National". Step 3: Please complete and print the following fields clearly. Name ___________________________________________________ Address _________________________________________________ City ____________________________________________________ State ___________________________________________________ Zip _____________________________________________________ E-mail __________________________________________________ Signature _________________________________________________ [ required for check and credit card orders] Toll Free FAX Order Line: 1-800-940-6590 If faxing in your order, please state whether you require a fax, email, or no confirmation at all. Allow up to one day for confirmation, if requested. FAX orders are processed immediately. Or, print & mail to: LSN 3502 N. Powerline Rd. #525 Pompano Beach, FL 33069 ______________________________________________________ *CHECK BY FAX ORDERS: Complete the check as normal. Tape the check in the area below. Below the check, clearly write the check number, all numbers at the bottom of the check, & your name. Tape the check below and fax the check to the toll free FAX number above. Void the check. Our merchant will electronically debit your account for the amount of the check; your reference number for this transaction will be your check number. Nothing could be safer & easier ! TAPE CHECK BELOW _____________________________________________________________ This is a one time mailing: Removal is automatic and no further contact is necessary. Please Note: Herbal V is not intended to diagnose, treat, cure or prevent any disease. As individuals differ, so will results. Herbal V helps provide herbal and nutritional support for male sexual performance. The FDA has not evaluated these statements. For details about our double your money back guarantee, please write to the above address, attention consumer affairs department; enclose a self addressed stamped envelope for this and any requested contact information. Thank You. Received: by ns.secondary.com (8.9.3/8.9.3) id NAA13079 for ietf-imapext-bks; Thu, 2 Nov 2000 13:54:00 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13075 for ; Thu, 2 Nov 2000 13:53:59 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 2 Nov 2000 13:56:34 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 02 Nov 2000 13:57:10 -0800 (Pacific Standard Time) Received: from mikega10 ([157.59.252.141]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 2 Nov 2000 13:57:10 -0800 Message-ID: <000901c04517$e6f564a0$8dfc3b9d@redmond.corp.microsoft.com> From: "Mike Gahrns" To: "Barry Leiba" , References: <2513123103.973175731@mars.trees.watson.ibm.com> Subject: Re: comments on LIST extensions Date: Thu, 2 Nov 2000 13:57:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-OriginalArrivalTime: 02 Nov 2000 21:57:10.0043 (UTC) FILETIME=[D9684EB0:01C04517] Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Barry Leiba writes: > We also have to do something with the REMOTE (or REFERRALS) option. I > agree with those who think that we should add referral information to the > LIST response, but I'd really like to hear from Mike Gahrns or Raymond > Cheng about it. Yes, including referral information in a "general LIST response type extension" is a good idea, and something that many of us discussed at various events like the IMC interops and IETF meetings. Assuming we went with the approach Steve Hole suggested with a new command like XLIST (insted of a general LIST response extension) this type of mechanism could simplify referrals in removing the need for the RLIST command. Recall, RLIST was added to referrals since in general one would not want a non-referral enabled client displaying remote mailboxes that would not be accessible to a user. If a mailbox was flagged as \remote (or whatever was agreed upon), it would need to be explicitly stated in the XLIST extension that the mailbox should not be displayed to the user unless the client was a referral enabled client. Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA13073 for ietf-imapext-bks; Thu, 2 Nov 2000 13:53:53 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (bruce@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13069 for ; Thu, 2 Nov 2000 13:53:51 -0800 (PST) Date: Thu, 2 Nov 2000 13:37:33 -0800 (PST) From: Mark Crispin Subject: Re: comments on LIST extensions To: Barry Leiba cc: ietf-imapext@imc.org In-Reply-To: <2513123103.973175731@mars.trees.watson.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Barry - I think that your latest message on this topic is good, and we can move forward with it. I figured that I should get *that* data point said before going into the long response. On Thu, 02 Nov 2000 14:35:31 -0500, Barry Leiba wrote: > It seems that Mark's got the main complaint, and that complaint involves > the interaction between subscriptions and other options. Specifically, in > Mark's model of how subscriptions work, it doesn't generally make sense to > combine SUBSCRIBED with other options. Remember, subscriptions were defined specifically to support a pre-existing functionality, and that this functionality is in use. Compatibility with this functionality must be retained. If I understand your proposal correctly, you're doing this. > That said, many servers *do* implement "subscribed to" as a mailbox > attribute, and in those servers it *does* make sense to have SUBSCRIBED be > an option, and to allow its combination with other options. I agree that it is alright as an option that does not break or otherwise restrict existing software. This implies that it should be permissible to implement other options without implementing this one. > 1. Change wording so it doesn't suggest deprecating LSUB. Add wording to > indicate that LSUB will remain *unchanged*, and that clients that don't > need more function than is provided by LSUB should continue to use LSUB. OK > 2. Maybe add wording to clarify that flags returned by LSUB may not be > accurate. This should probably be in the base spec, actually. It isn't that the flags are inaccurate; they are different. For example, \NoSelect means something different in LSUB. I'll be happy to consider suggested changes to the base spec wording for this. Please review what's in the current draft, not RFC 2060. > 3. The LISTEXT capability will announce support for the general method of > specifying LIST options and for the CHILDREN option. OK. > 4. The LIST-SUBSCRIBED capability will announce support for the SUBSCRIBED > option. OK, so by omitting LIST-SUBSCRIBED, I can implement the other options (and use them), correct? Put another way, there is no requirement to implement LIST-SUBSCRIBED in order to implement any other piece of this technology, correct? If the answer to both of these is "yes", you may consider my objections as having been satisfied and consequently are dropped. > Note that this means (and I will make it clear) that "LSUB" and "LIST > (SUBSCRIBED)" are *not* the same, and that clients that do not need the > extra function provided by the latter SHOULD NOT use it. OK > 5. Add a new mailbox flag, "\NonExistant", intended to be applied to a > mailbox that's subscribed to but that doesn't actually exist. "\NonExistant" => "\NonExistent" > 6. Add a new mailbox flag, "\PlaceHolder" (alternative name?), intended to > indicate, when necessary, that "this mailbox does not meet your selection > criteria, but it has a child that might (or, stronger, does?)". How will this work with LSUB, given the need to maintain compatibility? I suggest that it be allowed in LSUB, but *with* the overloaded \NoSelect, e.g. * LSUB (\NoSelect \PlaceHolder) "/" foo to make it unambiguous that the \NoSelect is the overloaded form. LIST-SUBSCRIBED, on the other hand, won't have \NoSelect. > We also have to do something with the REMOTE (or REFERRALS) option. I > agree with those who think that we should add referral information to the > LIST response, but I'd really like to hear from Mike Gahrns or Raymond > Cheng about it. I think that we should do it. I've been convinced that we should have another value in the LIST response, containing a parenthesized list of property/value pairs. * LIST () "/" foo (REFERRAL "..." BLOOP soop) The purpose of the parentheses is to enable to addition of another value in the response in the future if it turns out that attribute or property/value aren't enough. Received: by ns.secondary.com (8.9.3/8.9.3) id NAA11900 for ietf-imapext-bks; Thu, 2 Nov 2000 13:09:18 -0800 (PST) Received: from demo.esys.ca (IDENT:root@demo.esys.ca [207.167.22.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA11896 for ; Thu, 2 Nov 2000 13:09:17 -0800 (PST) Received: from kepler.esys.ca (kepler.esys.ca [198.161.92.108]) by demo.esys.ca (8.9.3 (MessagingDirect 1.0.4)/8.9.3) with ESMTP id OAA19993; Thu, 2 Nov 2000 14:01:56 -0700 From: Steve Hole Date: Thu, 2 Nov 2000 14:01:20 -0700 To: Barry Leiba Subject: Re: comments on LIST extensions Cc: ietf-imapext@imc.org In-Reply-To: <2513123103.973175731@mars.trees.watson.ibm.com> References: <2513123103.973175731@mars.trees.watson.ibm.com> <39E685D1.15CEB9A0@messagingdirect.com> Message-ID: X-Mailer: Execmail for Linux 5.3 b1 Build (1) -- Evaluation Copy MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Actually Barry, while I applaud the extensible LIST argument attempt, what I am most interested in is an entirely new, all consuming LIST command. Call it XLIST for the purpose of discussion. All of the things that you put in your message, modulo the bits that define interaction between LIST and LSUB, would go into the XLIST extension command. In XLIST, mailboxes can express a number of different attributes, including user/application defined ones (annotations) and they can all be searched/retrieved using the XLIST and related commands. Great. People will either implement or not in the true spirit of the IMAP world -- if it is useful lots of people will do it. Leave LIST and LSUB alone. Their semantics are defined and implemented in a number of products, and messing with them is just going to cause confusion. It will certainly cause lots of disagreement -- as it already has. ... I also think that your original draft that provided a general IMAP command argument extension framework was a damned good idea. Certainly, the new XLIST command could employ it straight off. Some people didn't like the possibility of command extension for the commands available in the non-authenticated state. Fine. Stipulate that that set of commands cannot be extended in this way. Otherwise, if you want to extend the arguments for a base command, this is the way to do it. Personally, I don't understand what the issue is for the commands available in the non-authenticated state. And yes, I have heard the arguments -- please don't send them again. I just don't agree with them. In my opinion, they are not sound arguments and the examples provided are very much contrived. ... To summarize: 1. I would like to see the orginal extension framework draft revived, Included the restriction on applicable command set if people still feel it is necessary. 2. I would like to see a draft for a brand new command that can be used as an alternative to the existing LIST and LSUB commands that has the unified semantics of the various LIST extensions, plus an explicit extension mechanism for folder metadata. Cheers. --- Steve Hole Chief Technology Officer MessagingDirect Ltd. Phone: 780-424-4922 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA07108 for ietf-imapext-bks; Thu, 2 Nov 2000 11:29:10 -0800 (PST) Received: from igw8.watson.ibm.com (igw8.watson.ibm.com [198.81.209.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA07101 for ; Thu, 2 Nov 2000 11:29:08 -0800 (PST) Received: from sp1n190at0.watson.ibm.com (sp1n190at0.watson.ibm.com [9.2.104.63]) by igw8.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id OAA11286 for ; Thu, 2 Nov 2000 14:35:33 -0500 Received: from mars.trees.watson.ibm.com (mars.watson.ibm.com [9.2.40.64]) by sp1n190at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id OAA36402 for ; Thu, 2 Nov 2000 14:35:32 -0500 Date: Thu, 02 Nov 2000 14:35:31 -0500 From: Barry Leiba To: ietf-imapext@imc.org Subject: Re: comments on LIST extensions Message-ID: <2513123103.973175731@mars.trees.watson.ibm.com> In-Reply-To: <39E685D1.15CEB9A0@messagingdirect.com> X-Mailer: Mulberry/2.0.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: OK, it seems that the discussion has settled down -- nothing for a couple of weeks -- so I'll do a little summary and a proposal. It seems that Mark's got the main complaint, and that complaint involves the interaction between subscriptions and other options. Specifically, in Mark's model of how subscriptions work, it doesn't generally make sense to combine SUBSCRIBED with other options. Further, the idea that SUBSCRIBED is an option on the LIST command implies that "being subscribed to" is an attribute of a mailbox, and that wasn't Mark's intent. He strongly wants to keep the LSUB command separate, and that's partly to make it clear that the list of subscriptions is a completely separate list. That said, many servers *do* implement "subscribed to" as a mailbox attribute, and in those servers it *does* make sense to have SUBSCRIBED be an option, and to allow its combination with other options. Further, a client that wants to have an accurate list of mailbox flags on subscribed mailboxes (for instance) *will* get that information, and as it stands it has to do it by combinations of LSUB and multiple LIST commands. OK, so here's what I propose as a change to the current LIST extensions draft: 1. Change wording so it doesn't suggest deprecating LSUB. Add wording to indicate that LSUB will remain *unchanged*, and that clients that don't need more function than is provided by LSUB should continue to use LSUB. 2. Maybe add wording to clarify that flags returned by LSUB may not be accurate. This should probably be in the base spec, actually. 3. The LISTEXT capability will announce support for the general method of specifying LIST options and for the CHILDREN option. 4. The LIST-SUBSCRIBED capability will announce support for the SUBSCRIBED option. This option may be combined with other options, guarantees accurate flags, and so forth (I'll put in appropriate wording). Note that this means (and I will make it clear) that "LSUB" and "LIST (SUBSCRIBED)" are *not* the same, and that clients that do not need the extra function provided by the latter SHOULD NOT use it. Servers, such as Mark's, which have to do extra work to, for example, get accurate flags for subscribed mailboxes, MUST do so if they implement LIST-SUBSCRIBED. I think such servers would do well to do so, since, as noted above, a client that wants the information will get it anyway, and at greater cost to both client and server. 5. Add a new mailbox flag, "\NonExistant", intended to be applied to a mailbox that's subscribed to but that doesn't actually exist. This will distingush between * LIST () "/" "Banana" and * LIST (\NonExistant) "/" "Banana" The LSUB command MAY use the \NonExistant flag as a hint, but the "LIST (SUBSCRIBED)" MUST use it. 6. Add a new mailbox flag, "\PlaceHolder" (alternative name?), intended to indicate, when necessary, that "this mailbox does not meet your selection criteria, but it has a child that might (or, stronger, does?)". This will eliminate the overloading of \NoSelect for this purpose, which, once we implement the SUBSCRIBED option, has to be done. Example: A1 LIST (SUBSCRIBED CHILDREN) "" "%" * LIST (\NoInferiors) "/" "inbox" * LIST (\NoSelect \HasChildren) "/" "xyz" * LIST (\NonExistant) "/" "abc" * LIST (\PlaceHolder \HasChildren) "/" "def" * LIST (\HasChildren) "/" "ghi" A1 OK done A2 LIST (SUBSCRIBED CHILDREN) "" "%/%" * LIST (\HasChildren) "/" "def/xxx" * LIST (\HasNoChildren) "/" "ghi/yyy" * LIST (\HasNoChildren) "/" "ghi/zzz" A2 OK done Here, note that "inbox" and "abc" do not have CHILDREN flags, because the \NoInferiors and \NonExistant flags make them unnecessary. Mailbox "xyz" is subscribed to, but is not selectable; it has children, and, as it turns out, none of those children are subscribed to. "abc" is subscribed to, but doesn't actually exist. "def" is not subscribed to, but it has children that are. "ghi" is subscribed to and has children; we don't know whether any of its children are subscribed to -- the second LIST shows us that they are. Does this all make sense? Mark, does it satisfy your concerns? Others, does it meet your needs too? We also have to do something with the REMOTE (or REFERRALS) option. I agree with those who think that we should add referral information to the LIST response, but I'd really like to hear from Mike Gahrns or Raymond Cheng about it. Barry Leiba, Living Lab Services (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba Received: by ns.secondary.com (8.9.3/8.9.3) id PAA18876 for ietf-imapext-bks; Wed, 29 Nov 2000 15:36:21 -0800 (PST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA18869; Wed, 29 Nov 2000 15:36:18 -0800 (PST) Received: from westmail2.West.Sun.COM ([129.153.100.30]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA18254; Wed, 29 Nov 2000 15:37:51 -0800 (PST) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA01239; Wed, 29 Nov 2000 15:37:50 -0800 (PST) Date: Wed, 29 Nov 2000 15:37:09 -0800 From: Chris Newman To: Lyndon Nerenberg cc: IMAP Extensions WG , ietf-imap-voice@imc.org Subject: Re: draft-nerenberg-imap-binary-00.txt Message-ID: <3867275.3184501029@nifty-jr.west.sun.com> In-Reply-To: <200011291833.eATIXXT01603@gollum.esys.ca> X-Mailer: Mulberry/2.0.5 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I read that spec. It addresses point 3 from my previous post, and partially addresses point 1. However, it introduces additional syntax issues: (1a) I'm not convinced that the syntax model is appropriately general for similar conversion operations. While I'm not opposed to binary moving forward by itself, it shouldn't move forward until we are confident that we're not creating lots of special case syntax variants. (1b) I'm not convinced the restriction to leaf nodes is a good idea. For example, a disconnected client which is caching entire messages could recognize a significant performance benefit if it fetched the entire message with all base64/QP encoding that's not in a security multipart removed. (1c) It does not specify a syntax to request the size of a decoded body part. A minor nit -- I wouldn't call a binary literal "literal8". Vanilla IMAP literals already support 8-bit (when appropriately labelled). - Chris --On Wednesday, November 29, 2000 11:33 -0700 Lyndon Nerenberg wrote: > Chris, have you seen the -01 version of the draft? It contains two > substantial changes: > > 1) The command syntax was changed to "FETCH n BINARY[x.y]" > > 2) The literal8 syntax is now "~{nnn}CRLF..." > > The -01 document was submitted last week but isn't yet in the > repository. For now you can FTP it from: > > ftp://ftp.messagingdirect.com/pub/staff/lyndon/drafts/draft-nerenberg-ima > p-bina ry-01.txt > > --lyndon > Received: by ns.secondary.com (8.9.3/8.9.3) id KAA01536 for ietf-imapext-bks; Wed, 29 Nov 2000 10:33:43 -0800 (PST) Received: from gollum.esys.ca (dhcp198-59.esys.ca [198.161.92.59]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA01503; Wed, 29 Nov 2000 10:33:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gollum.esys.ca (8.11.1/8.11.1) with ESMTP id eATIXXT01603; Wed, 29 Nov 2000 11:33:33 -0700 (MST) (envelope-from lyndon@gollum.esys.ca) Message-Id: <200011291833.eATIXXT01603@gollum.esys.ca> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Lyndon Nerenberg To: Chris Newman cc: IMAP Extensions WG , ietf-imap-voice@imc.org Subject: Re: draft-nerenberg-imap-binary-00.txt In-reply-to: Your message of "Tue, 28 Nov 2000 16:20:14 PST." <2540808.3184417214@nifty-jr.west.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Nov 2000 11:33:33 -0700 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Chris, have you seen the -01 version of the draft? It contains two substantial changes: 1) The command syntax was changed to "FETCH n BINARY[x.y]" 2) The literal8 syntax is now "~{nnn}CRLF..." The -01 document was submitted last week but isn't yet in the repository. For now you can FTP it from: ftp://ftp.messagingdirect.com/pub/staff/lyndon/drafts/draft-nerenberg-imap-bina ry-01.txt --lyndon Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA18602 for ietf-imapext-bks; Tue, 28 Nov 2000 16:19:29 -0800 (PST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA18598; Tue, 28 Nov 2000 16:19:27 -0800 (PST) Received: from westmail2.West.Sun.COM ([129.153.100.30]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11817; Tue, 28 Nov 2000 16:20:54 -0800 (PST) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA14702; Tue, 28 Nov 2000 16:20:53 -0800 (PST) Date: Tue, 28 Nov 2000 16:20:14 -0800 From: Chris Newman To: Lyndon Nerenberg cc: IMAP Extensions WG , ietf-imap-voice@imc.org Subject: Re: draft-nerenberg-imap-binary-00.txt Message-ID: <2540808.3184417214@nifty-jr.west.sun.com> In-Reply-To: <200011212238.eALMcK804217@gollum.esys.ca> X-Mailer: Mulberry/2.0.5 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Issues with the binary extension: (1) I concur with Mark's comments about syntax. The current proposed syntax is unacceptable, the XFETCH strawman seems workable (with associated XFETCH response). I could also deal with a fetch-item modifier as an alternative to a new command: C: A002 FETCH 1:5 BODY[1] S: * 1 FETCH (BODY[1] {#}...) or C: A002 FETCH 1:5 BODY[1] S: * 1 FETCH (BODY[1] {#}...) With that syntax, each modifier would have to describe how it interacts with various fetch items, for example, SIZE would return the size after removal of base64/QP encoding. (2) I am currently opposed to a distinguished syntax for binary literals on the grounds that it introduces two silly states: a binary literal with non-binary content and a non-binary literal with binary content. (In unextended IMAP, the latter is simply a protocol violation which robust implementations should detect.) I would much prefer the statement that if the server advertises XFETCH BINARY, then the prohibition on the client sending binary literals for message content is lifted, and if the client issues the XFETCH command with BINARY option, then the prohibition on the server sending binary message content is lifted. (3) If the concensus is against me on point 2, then I object to using a suffix to indicate a binary literal on the grounds that it breaks existing LITERAL+ detectors. That objection would not apply to a prefix character. (4) If a server advertises XFETCH BINARY, that should permit the use of binary CTE and binary literal content in APPEND. (5) An unextended IMAP server is required to convert a body part with a binary CTE to base64. An IMAP message store could receive a binary body part via the binary SMTP extension or an APPEND command (it is currently illegal protocol to have a true binary CTE in an APPEND). If we ever want to support binary body parts signed by PGP or S/MIME, then we need a way to distinguish the canonical CTE from the requested/supplied CTE. I don't have a strong opinion one way or the other, but the issue needs to be considered. (6) BINARY and CHARSET=UTF8 conversions are no brainers (since an IMAP server with a halfway decent SEARCH command already implements them internally). But the CHANNEL model is both very important for conversions not likely to be built into an IMAP server and rather tricky to get right due to security/firewall issues. (7) I suggest we have an XFETCH (MD5) modifier, which computes the MD5 hash of the specified fetch BODY item -- MD5 is just a content conversion which happens to have a fixed size output. May make channel security issues simpler, and could permit verification of PGP or S/MIME signatures without fetching all parts. Note that I believe the CHANNEL mechanism in combination with an extension to the SMTP-SUBMIT protocol is the correct way to provide the ability to forward/resend an attachment without downloading it. - Chris Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA11937 for ietf-imapext-bks; Fri, 24 Nov 2000 10:56:53 -0800 (PST) Received: from gollum.esys.ca (dhcp198-59.esys.ca [198.161.92.59]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA11893; Fri, 24 Nov 2000 10:56:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gollum.esys.ca (8.11.1/8.11.1) with ESMTP id eAOIvDg00977; Fri, 24 Nov 2000 11:57:13 -0700 (MST) (envelope-from lyndon@gollum.esys.ca) Message-Id: <200011241857.eAOIvDg00977@gollum.esys.ca> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Lyndon Nerenberg To: IMAP Extensions WG , ietf-imap-voice@imc.org Subject: IMAP BINARY -01 draft available X-URL: http://www.messagingdirect.com/ Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_-19606496970" Date: Fri, 24 Nov 2000 11:57:13 -0700 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart MIME message. --==_Exmh_-19606496970 Content-Type: text/plain; charset=us-ascii I've upodated the draft to include this weeks feedback. I also fleshed out the missing pieces. At this point I consider it pretty much complete. The I-D submission autoreponder message isn't clear (to me) about whether this will get published before the San Diego meeting. Meanwhile, you can grab a copy from: ftp://ftp.esys.ca/pub/staff/lyndon/drafts/draft-nerenberg-imap-binary-01.txt --lyndon --==_Exmh_-19606496970 Content-Type: message/external-body; name="draft-nerenberg-imap-binary-01.txt"; site="ftp.messagingdirect.com"; access-type=ANON-FTP; directory="/pub/staff/lyndon/drafts"; mode="ascii" Content-Description: draft-nerenberg-imap-binary-01.txt Content-Disposition: attachment; filename="imap-binary-extref" Content-Type: text/plain Content-ID: --==_Exmh_-19606496970-- Received: by ns.secondary.com (8.9.3/8.9.3) id JAA04457 for ietf-imapext-bks; Fri, 24 Nov 2000 09:04:02 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (rossi@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA04453 for ; Fri, 24 Nov 2000 09:04:01 -0800 (PST) Date: Fri, 24 Nov 2000 09:03:02 -0800 (PST) From: Mark Crispin Subject: re: Commands starting with X To: Paul Overell cc: ietf-imapext@imc.org In-Reply-To: <8IxOU1ANtjH6QAmk@turnpike.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 24 Nov 2000 09:56:29 +0000, Paul Overell wrote: > Is it a good idea to invent new commands starting with X (XLIST XFETCH > etc)? XLIST and XFETCH are just placeholders for the purpose of discussion; the actual names will be something else. IMAP forbids the use of "X" in a standards-track command name. Received: by ns.secondary.com (8.9.3/8.9.3) id BAA01358 for ietf-imapext-bks; Fri, 24 Nov 2000 01:58:32 -0800 (PST) Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA01346 for ; Fri, 24 Nov 2000 01:58:30 -0800 (PST) Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2]) by internal.mail.demon.net with ESMTP id JAA16934; Fri, 24 Nov 2000 09:59:31 GMT Message-ID: <8IxOU1ANtjH6QAmk@turnpike.com> Date: Fri, 24 Nov 2000 09:56:29 +0000 To: ietf-imapext@imc.org From: Paul Overell Subject: Commands starting with X MIME-Version: 1.0 X-Mailer: Turnpike Integrated Version 5.01 M Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Is it a good idea to invent new commands starting with X (XLIST XFETCH etc)? I only raise this as X is commonly used for non-standard or experimental features, whereas these new commands are presumably intended to become mainstream. C.f. The NNTP group are sufficiently bothered by this to want to rename XOVER and XPAT as OVER and PAT. Regards - -- Paul Overell T U R N P I K E -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQA/AwUBOh47TR8WRy+wdge+EQJhzgCfcbHfLDWdkXwcmQrmH9RQN3mRhtYAoPSF XaXRqnn3GZLPQVmf6L4ZtU2P =vkwS -----END PGP SIGNATURE----- Received: by ns.secondary.com (8.9.3/8.9.3) id QAA07503 for ietf-imapext-bks; Wed, 22 Nov 2000 16:22:13 -0800 (PST) Received: from mail.connectedsystems.com (host16.connectedsystems.com [205.227.183.113]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA07493; Wed, 22 Nov 2000 16:22:12 -0800 (PST) Received: from software-caleb (red.hq.connsys.com [192.168.0.32]) by mail.connectedsystems.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id WMN2D8WD; Wed, 22 Nov 2000 16:19:37 -0800 From: "Caleb Clausen" To: IMAP Extensions WG , ietf-imap-voice@imc.org Date: Wed, 22 Nov 2000 16:24:35 -0800 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: draft-nerenberg-imap-binary-00.txt Message-ID: <3A1BF343.30676.1866F93@localhost> In-reply-to: <200011212208.eALM8o803996@gollum.esys.ca> References: Message from Mark Crispin of "Tue, 21 Nov 2000 12:58:19 PST." X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From: Lyndon Nerenberg > > I believe therefore that this functionality belongs in a new command, e.g. > > something like > > tag XFETCH (BINARY) 1 BODY[x.y] > > tag XFETCH (CHARSET=UTF-8) 1 BODY[x.y] > > tag XFETCH (BINARY CHANNEL=[1.2.3.4]:432) 1 BODY[x.y] > > etc. These examples are to demonstrate the concept; the exact syntax to be > > determined. > > I hadn't realized that you and Steve had been discussing this, otherwise > I would have held off with BINARY for a bit. I like the XFETCH architecture, > however I'm not convinced (yet) that a server should have to implement > external channel support just to get BINARY. At this point I think the i would like to go on the record as one imap client implementor that would be very much interested in a BINARY FETCH. we have no use for CHANNEL at the moment... so i think these 2 concepts definitely should be separated. i'd also like to enumerate some of the problems i see with CHANNEL as sketched out in the example above. transport protocol it isn't too clear from the example whether udp or tcp transport is envisioned. i think that the original impetus for this proposal within vpim was to enable the voice data to be delivered via voip (that is, rtp over udp.) in that context, tcp transport doesn't gain anything. if udp is used for delivery, you then have to consider what happens when a packet gets dropped. voip uses fancy error-tolerant codecs to handle this case. the codec currently on the table for ivm (gsm) has no such abilities, so when a packet gets dropped, the rest of the file will be corrupted. of course, you could have the server translate the voice data into a fancy error-tolerant codec on the fly. probably a good use for the data-conversion feature of XFETCH? nat embedding ip addresses and port numbers within tcp payload is a sure way to break network address translators. it also makes imap dependant on ipv4, complicating the transition to ipv6. these are two reasons to avoid it altogether. if ip addresses and ports must be embedded, you should at least try to avoid the minor disaster that ftp creates for nat by always 0- padding the ip address octets and the port so that they always come out to exactly the same length. for example, instead of: tag XFETCH (BINARY CHANNEL=[1.2.3.4]:432) 1 BODY[x.y] you'd have: tag XFETCH (BINARY CHANNEL=[001.002.003.004]:00432) 1 BODY[x.y] (sorry about the line wrap.) this will still break nat, of course, but at least it will be easier to write a custom nat protocol handler for imap. "The battle for mental territory is glory. End of story." --KRS-ONE Received: by ns.secondary.com (8.9.3/8.9.3) id QAA07465 for ietf-imapext-bks; Wed, 22 Nov 2000 16:22:05 -0800 (PST) Received: from mail.connectedsystems.com (host16.connectedsystems.com [205.227.183.113]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA07457; Wed, 22 Nov 2000 16:22:03 -0800 (PST) Received: from software-caleb (red.hq.connsys.com [192.168.0.32]) by mail.connectedsystems.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id WMN2D8WF; Wed, 22 Nov 2000 16:19:37 -0800 From: "Caleb Clausen" To: IMAP Extensions WG , ietf-imap-voice@imc.org Date: Wed, 22 Nov 2000 16:24:35 -0800 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: RE: draft-nerenberg-imap-binary-00.txt Message-ID: <3A1BF343.14592.1866F6A@localhost> References: <488891341182D4118A870000F80822E782B74B@zcard00p.ca.nortel.com> In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From: Lyndon Nerenberg > > Steve indicated to me last week that he would combine the first two into one > > proposal. Do we expect two proposals now? > > Steve's proposal for XFETCH includes support for both binary fetch and > specifying external transfer channels for a fetch. (Among other > things.) > > My proposal provides binary fetch (only) for servers that don't want/need > to support XFETCH. > > The two can live side-by-side. Time will show if BINARY has enough > support (in the presence of XFETCH) to move forward. since everyone likes the XFETCH syntax so much better, why not do this: have separate capabilities for XFETCH itself, as well as all of it's options. so, the XFETCH document would define the following capabilities: XFETCH XFETCH-BINARY XFETCH-CHANNEL XFETCH-CHARSET etc. that way, servers which just want to provide a binary version of fetch could declare just XFETCH and XFETCH-BINARY. servers that want all of it would declare all the XFETCH capabilities. or is this too great a proliferation of capabilities? one question: will XFETCH work with the UID command? ie, will i be able to say, tag UID XFETCH (BINARY) 1009 etc... "The battle for mental territory is glory. End of story." --KRS-ONE Received: by ns.secondary.com (8.9.3/8.9.3) id OAA05036 for ietf-imapext-bks; Wed, 22 Nov 2000 14:40:35 -0800 (PST) Received: from gollum.esys.ca (dhcp198-59.esys.ca [198.161.92.59]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA05022; Wed, 22 Nov 2000 14:40:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gollum.esys.ca (8.11.1/8.11.1) with ESMTP id eAMMaZl44204; Wed, 22 Nov 2000 15:36:35 -0700 (MST) (envelope-from lyndon@messagingdirect.com) Date: Wed, 22 Nov 2000 15:36:35 -0700 (MST) From: Lyndon Nerenberg X-Sender: lyndon@gollum.esys.ca To: Glenn Parsons cc: IMAP Extensions WG , ietf-imap-voice@imc.org Subject: RE: draft-nerenberg-imap-binary-00.txt In-Reply-To: <488891341182D4118A870000F80822E782B74B@zcard00p.ca.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Steve indicated to me last week that he would combine the first two into one > proposal. Do we expect two proposals now? Steve's proposal for XFETCH includes support for both binary fetch and specifying external transfer channels for a fetch. (Among other things.) My proposal provides binary fetch (only) for servers that don't want/need to support XFETCH. The two can live side-by-side. Time will show if BINARY has enough support (in the presence of XFETCH) to move forward. --lyndon Received: by ns.secondary.com (8.9.3/8.9.3) id OAA14282 for ietf-imapext-bks; Tue, 21 Nov 2000 14:37:51 -0800 (PST) Received: from gollum.esys.ca (dhcp198-59.esys.ca [198.161.92.59]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14269; Tue, 21 Nov 2000 14:37:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gollum.esys.ca (8.11.1/8.11.1) with ESMTP id eALMcK804217; Tue, 21 Nov 2000 15:38:20 -0700 (MST) (envelope-from lyndon@gollum.esys.ca) Message-Id: <200011212238.eALMcK804217@gollum.esys.ca> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Mark Crispin cc: IMAP Extensions WG , ietf-imap-voice@imc.org Subject: Re: draft-nerenberg-imap-binary-00.txt In-Reply-To: Message from Mark Crispin of "Tue, 21 Nov 2000 14:10:31 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Nov 2000 15:38:20 -0700 From: Lyndon Nerenberg Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Isn't converting QP and BASE64 to BINARY a form of data conversion? No, it's a change of transport encoding. The contents of the body part at the client matches the contents of what the sender sent regardless of where the transport encoding is undone (i.e. at the client vs. at the server). The decoded data is the same, so it's not a data conversion. If, however, the server _also_ does character set manipulations on the way through, the decoded data at the client might not match what the sender initially sent. _That_ I consider to be data conversion. > > I hadn't realized that you and Steve had been discussing this, otherwise > > I would have held off with BINARY for a bit. > That's why I was a bit surprised to see your document! :-) So was Steve :-) I apologise for starting all this confusion. > I suggest some added little token in literal8, perhaps {###}~ instead of {###} > to indicate its special nature. I can live with that. If people are okay with the syntax I'll incorporate that into the next draft. Any suggestions for a modified FETCH...BINARY syntax while we're at it? --lyndon Received: by ns.secondary.com (8.9.3/8.9.3) id OAA13893 for ietf-imapext-bks; Tue, 21 Nov 2000 14:21:04 -0800 (PST) Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA13889; Tue, 21 Nov 2000 14:21:03 -0800 (PST) Received: from mailhost1.u.washington.edu (mailhost1.u.washington.edu [140.142.32.2]) by mxout1.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW99.09) with ESMTP id OAA28380; Tue, 21 Nov 2000 14:21:51 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (foo@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost1.u.washington.edu (8.9.3+UW00.02/8.9.3+UW00.01) with ESMTP id OAA13943; Tue, 21 Nov 2000 14:21:50 -0800 Date: Tue, 21 Nov 2000 14:10:31 -0800 (PST) From: Mark Crispin Subject: Re: draft-nerenberg-imap-binary-00.txt To: Lyndon Nerenberg cc: IMAP Extensions WG , ietf-imap-voice@imc.org In-Reply-To: <200011212208.eALM8o803996@gollum.esys.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 21 Nov 2000 15:08:50 -0700, Lyndon Nerenberg wrote: > > However, I object strongly to the "BODY[x.y.BINARY]" syntax. > I'll agree with that. I'm not particularly happy with that syntax either. > I needed something as a starting point OK, good. I'm happy with a stipulation that we're going to fix that. I don't want to stand in the way of the functionality, but that particular syntax has got to go. > And this is something VPIM originally requested (general conversions). I > don't like overloading (or combining, I guess) BINARY with data conversion. Isn't converting QP and BASE64 to BINARY a form of data conversion? > I hadn't realized that you and Steve had been discussing this, otherwise > I would have held off with BINARY for a bit. That's why I was a bit surprised to see your document! :-) > I like the XFETCH architecture, > however I'm not convinced (yet) that a server should have to implement > external channel support just to get BINARY. At this point I think the > two are really distinct issues, and should be separate extensions. OK with me. My guiding principle (consider XLIST) is that if it's trivial to bundle two things together and less work than having them separate, then bundle them; but if there's a reason why someone may want one and not the other, then keep them separate. If you feel that BINARY vs. external channel support is the latter, I won't squawk. [I'd appreciate the return favor when we talk about XLIST vs. subscriptions........] > > XFETCH that would output on the IMAP channel, so the client can > > distinguish a literal8 from an ordinary literal. > This shouldn't be necessary. The server will only send a literal8 at > the specific request of the client, and they will never show up in > an unsolicited response. It's not a big deal, though. If concensus is > for a unique syntax for literal8 that's an easy change to make. Mr. IMAP Architecture says that it's presumptious to say that "they will never show up in an unsolicited responses." The presumption may be valid for literal8 (and certainly right now it is), but it isn't for literal; and that's what creates the ambiguity. We don't want the situation where a client gets a literal and thinks that it's a literal8. I suggest some added little token in literal8, perhaps {###}~ instead of {###} to indicate its special nature. Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA13870 for ietf-imapext-bks; Tue, 21 Nov 2000 14:20:33 -0800 (PST) Received: from gollum.esys.ca (dhcp198-59.esys.ca [198.161.92.59]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA13866 for ; Tue, 21 Nov 2000 14:20:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gollum.esys.ca (8.11.1/8.11.1) with ESMTP id eALMLA804133 for ; Tue, 21 Nov 2000 15:21:10 -0700 (MST) (envelope-from lyndon@gollum.esys.ca) Message-Id: <200011212221.eALMLA804133@gollum.esys.ca> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Lyndon Nerenberg To: ietf-imapext@imc.org Subject: (resend) Re; BINARY X-URL: http://www.messagingdirect.com/ Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Nov 2000 15:21:10 -0700 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [Sorry folks, this bounced first time around. >> == Mark, > == me.] >> The subject draft attempts to fufill a needed requirement for the >>VPIM folks. > >Initially that was the case, although I certainly think this extension has >a use outside of that context. > >> However, I object strongly to the "BODY[x.y.BINARY]" syntax. Unlike other >> section specifiers, this one would stipulate a transformation of a section >> rather than identify a unique section. It also adds complexity >>(the "terminal >> MIME body part" rule) as a side effect of overloading location syntax (the >> section specifier) with transformation instructions ("BINARY"). > >I'll agree with that. I'm not particularly happy with that syntax either. >I needed something as a starting point (and was under the gun to meet >the submission deadline, so I didn't have a chance to work out anything >better), so I went with the syntax in the original VPIM proposal. > >> Furthermore, this extension does not really address the complete need, which >> is a general ability to transform/deliver message data in extended >>forms. For >> example, a streaming application may wish to specify a separate >>host/port for >> delivery of the data. It may be desireable to request the server >>to transform >> text data to UTF-8. > >And this is something VPIM originally requested (general conversions). I >don't like overloading (or combining, I guess) BINARY with data conversion. >BINARY provides a single piece of functionality: undoing of content >transfer encodings. This is neutral to the actual content. If there is >a need to do actual conversion of the underlying data, that should be >handled separately. Character set conversions (such as your UTF8 example) >are a bit fuzzy, sitting in between BINARY and general data conversions. >I'm not sure where that actually fits in, but again I think that's a >separate issue from BINARY itself. > >> I believe therefore that this functionality belongs in a new command, e.g. >> something like >> tag XFETCH (BINARY) 1 BODY[x.y] >> tag XFETCH (CHARSET=UTF-8) 1 BODY[x.y] >> tag XFETCH (BINARY CHANNEL=[1.2.3.4]:432) 1 BODY[x.y] >> etc. These examples are to demonstrate the concept; the exact syntax to be >> determined. > >I hadn't realized that you and Steve had been discussing this, otherwise >I would have held off with BINARY for a bit. I like the XFETCH architecture, >however I'm not convinced (yet) that a server should have to implement >external channel support just to get BINARY. At this point I think the >two are really distinct issues, and should be separate extensions. I don't >think implementing channel necessarily requires the BINARY extensions >be present. The external channel may already be 8bit clean, and the >specification for that profile of the channel target mechanism could >explicitly state that the channel is 8bit clean, therefore there's >no need for the server to also implement BINARY if the implementer doesn't >feel it adds significant value. It's still very early in the game, though, >so I don't consider any of this cast in stone. I'm looking forward to >seeing a more complete specification for XFETCH. > >> We should also have a syntax for literal8s that are output in the case of an >> XFETCH that would output on the IMAP channel, so the client can >>distinguish a >> literal8 from an ordinary literal. Otherwise there would be an >>ambiguity due >> to the unsolicited data model of IMAP, and the client would have to depend >> upon a command modality that IMAP espressly forbids. > >This shouldn't be necessary. The server will only send a literal8 at >the specific request of the client, and they will never show up in >an unsolicited response. It's not a big deal, though. If concensus is >for a unique syntax for literal8 that's an easy change to make. > >--lyndon Received: by ns.secondary.com (8.9.3/8.9.3) id NAA13007 for ietf-imapext-bks; Tue, 21 Nov 2000 13:51:49 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13003 for ; Tue, 21 Nov 2000 13:51:45 -0800 (PST) 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 QAA00064 for ; Tue, 21 Nov 2000 16:51:31 -0500 (EST) Date: Tue, 21 Nov 2000 16:52:33 -0500 From: Cyrus Daboo To: IMAP Extensions WG Subject: View draft for San Diego Message-ID: <1435577.3183814353@sardis.cyrusoft.com> X-Mailer: Mulberry/2.0.5 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'd like to get an update to the VIEW draft out before the deadline (and before the current one expires, though I could just re-sub,it it as it is with a change of expiry date). The debate on VIEW was left somewhat open-ended after the last round of discussions on the list (a couple of months ago now). I think the issues wrt SORT & THREAD working with VIEW may best be left for the meeting, but a couple of issues for VIEW did come out of that round of discussions: 1) VIEW responses are too chatty. The proposal I had to solve this (Message-ID: <3223946.3175613932@socrates.cyrusoft.com>) was to collapse all the VIEW 'position changed' responses into a single * VIEW response with three parts to it: > Right now we have a * VIEW for each change. We could compress this down > to a single * VIEW for all changes during the command in progress. > Something along the lines off: > > * VIEW (1:3,5) (10 11 15 16) (1:2,20) > > The three groups represent: > > 1) View positions of messages removed from the view > 2) Pairs of view positions for messages moving in the view > 3) View positions of new messages added to the view > > This removes both UIDs and sequence numbers from the original * VIEW > response. 2) Clients need a way to get the VIEW-UID map so that they can utilise existing cached data when changing from one view to another. There was a proposal to add a new VIEW WINDOW command that would allow this to work: tag VIEW WINDOW ... This would return a list of message UIDs corresponding to the range of view position ids requested. There are some issues about how to make this work with threads where the positions may represent different levels of hierarchy. Are there any objections to these changes? Should we just wait until San Diego before deciding on ANY changes to VIEW, to allow the issues with SORT etc to be resolved first? -- Cyrus Daboo Received: by ns.secondary.com (8.9.3/8.9.3) id NAA12944 for ietf-imapext-bks; Tue, 21 Nov 2000 13:45:19 -0800 (PST) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA12939 for ; Tue, 21 Nov 2000 13:45:18 -0800 (PST) Received: from messagingdirect.com (gagarin.esys.ca [198.161.92.84]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id eALLk9022779; Tue, 21 Nov 2000 14:46:09 -0700 Message-ID: <3A1AED20.68CE1CC@messagingdirect.com> Date: Tue, 21 Nov 2000 14:46:09 -0700 From: Alexey Melnikov X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Crispin , IMAP Extensions WG Subject: Re: draft-nerenberg-imap-binary-00.txt References: <3A1AEBFC.9198A541@messagingdirect.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Oops. Hit Send button too fast. Sorry :-(. To the best of my knowledge Lyndon will be writing another draft (superset of the current) that will address VPIM stuff (general ability to transform/deliver message in a different format or over a different channel). The draft that Lyndon submitted is generally useful for conserving bandwidth. It is possible that in the future there will be only a single extension. Alexey Received: by ns.secondary.com (8.9.3/8.9.3) id NAA12862 for ietf-imapext-bks; Tue, 21 Nov 2000 13:40:32 -0800 (PST) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA12858 for ; Tue, 21 Nov 2000 13:40:31 -0800 (PST) Received: from messagingdirect.com (gagarin.esys.ca [198.161.92.84]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id eALLfH022703; Tue, 21 Nov 2000 14:41:17 -0700 Message-ID: <3A1AEBFC.9198A541@messagingdirect.com> Date: Tue, 21 Nov 2000 14:41:16 -0700 From: Alexey Melnikov X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Crispin CC: IMAP Extensions WG Subject: Re: draft-nerenberg-imap-binary-00.txt References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > The subject draft attempts to fufill a needed requirement for the VPIM folks. > > However, I object strongly to the "BODY[x.y.BINARY]" syntax. Unlike other > section specifiers, this one would stipulate a transformation of a section > rather than identify a unique section. It also adds complexity (the "terminal > MIME body part" rule) as a side effect of overloading location syntax (the > section specifier) with transformation instructions ("BINARY"). > > Furthermore, this extension does not really address the complete need, which > is a general ability to transform/deliver message data in extended forms. For > example, a streaming application may wish to specify a separate host/port for > delivery of the data. It may be desireable to request the server to transform > text data to UTF-8. > > I believe therefore that this functionality belongs in a new command, e.g. > something like > tag XFETCH (BINARY) 1 BODY[x.y] > tag XFETCH (CHARSET=UTF-8) 1 BODY[x.y] > tag XFETCH (BINARY CHANNEL=[1.2.3.4]:432) 1 BODY[x.y] > etc. These examples are to demonstrate the concept; the exact syntax to be > determined. > > We should also have a syntax for literal8s that are output in the case of an > XFETCH that would output on the IMAP channel, so the client can distinguish a > literal8 from an ordinary literal. Otherwise there would be an ambiguity due > to the unsolicited data model of IMAP, and the client would have to depend > upon a command modality that IMAP espressly forbids. Received: by ns.secondary.com (8.9.3/8.9.3) id NAA12494 for ietf-imapext-bks; Tue, 21 Nov 2000 13:11:32 -0800 (PST) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA12490 for ; Tue, 21 Nov 2000 13:11:30 -0800 (PST) Received: from mailhost1.u.washington.edu (mailhost1.u.washington.edu [140.142.32.2]) by mxout2.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW99.09) with ESMTP id NAA18608 for ; Tue, 21 Nov 2000 13:12:21 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tpb@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost1.u.washington.edu (8.9.3+UW00.02/8.9.3+UW00.01) with ESMTP id NAA00361 for ; Tue, 21 Nov 2000 13:12:21 -0800 Date: Tue, 21 Nov 2000 12:58:19 -0800 (PST) From: Mark Crispin Subject: draft-nerenberg-imap-binary-00.txt To: IMAP Extensions WG Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The subject draft attempts to fufill a needed requirement for the VPIM folks. However, I object strongly to the "BODY[x.y.BINARY]" syntax. Unlike other section specifiers, this one would stipulate a transformation of a section rather than identify a unique section. It also adds complexity (the "terminal MIME body part" rule) as a side effect of overloading location syntax (the section specifier) with transformation instructions ("BINARY"). Furthermore, this extension does not really address the complete need, which is a general ability to transform/deliver message data in extended forms. For example, a streaming application may wish to specify a separate host/port for delivery of the data. It may be desireable to request the server to transform text data to UTF-8. I believe therefore that this functionality belongs in a new command, e.g. something like tag XFETCH (BINARY) 1 BODY[x.y] tag XFETCH (CHARSET=UTF-8) 1 BODY[x.y] tag XFETCH (BINARY CHANNEL=[1.2.3.4]:432) 1 BODY[x.y] etc. These examples are to demonstrate the concept; the exact syntax to be determined. We should also have a syntax for literal8s that are output in the case of an XFETCH that would output on the IMAP channel, so the client can distinguish a literal8 from an ordinary literal. Otherwise there would be an ambiguity due to the unsolicited data model of IMAP, and the client would have to depend upon a command modality that IMAP espressly forbids. Received: by ns.secondary.com (8.9.3/8.9.3) id NAA17361 for ietf-imapext-bks; Fri, 17 Nov 2000 13:48:52 -0800 (PST) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA17355 for ; Fri, 17 Nov 2000 13:48:50 -0800 (PST) Received: from messagingdirect.com (gagarin.esys.ca [198.161.92.84]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id eAHLuKC22447; Fri, 17 Nov 2000 14:56:20 -0700 Message-ID: <3A15A983.2A13E6C0@messagingdirect.com> Date: Fri, 17 Nov 2000 14:56:19 -0700 From: Alexey Melnikov X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Chris Newman CC: Steve Hole , IMAP Extensions WG Subject: Re: LIST Extensions Requirements References: <4412999.3183452300@nifty-jr.west.sun.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > One thing I would ask. Can you keep track of the individual requirements > > that progress through the discussion? > > I'm too busy to do a good job keeping track of such a list (I only get to > IMAPEXT every couple weeks). Furthermore, someone who is more neutral than > I on some of the controversial issues would be better. The WG chair or > document editor would be a better choice, IMHO. I can try to compile the list if there are no objections. Alexey Received: by ns.secondary.com (8.9.3/8.9.3) id MAA21622 for ietf-imapext-bks; Fri, 17 Nov 2000 12:11:08 -0800 (PST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA21611 for ; Fri, 17 Nov 2000 12:11:06 -0800 (PST) Received: from westmail2.West.Sun.COM ([129.153.100.30]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA19886; Fri, 17 Nov 2000 12:18:45 -0800 (PST) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA28599; Fri, 17 Nov 2000 12:18:43 -0800 (PST) Date: Fri, 17 Nov 2000 12:18:20 -0800 From: Chris Newman To: Steve Hole cc: IMAP Extensions WG Subject: Re: LIST Extensions Requirements Message-ID: <4412999.3183452300@nifty-jr.west.sun.com> In-Reply-To: X-Mailer: Mulberry/2.0.5 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Thursday, November 16, 2000 9:46 -0700 Steve Hole wrote: > One thing I would ask. Can you keep track of the individual requirements > that progress through the discussion? I'm too busy to do a good job keeping track of such a list (I only get to IMAPEXT every couple weeks). Furthermore, someone who is more neutral than I on some of the controversial issues would be better. The WG chair or document editor would be a better choice, IMHO. - Chris Received: by ns.secondary.com (8.9.3/8.9.3) id JAA27511 for ietf-imapext-bks; Thu, 16 Nov 2000 09:47:09 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (tonyb@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA27504 for ; Thu, 16 Nov 2000 09:47:07 -0800 (PST) Date: Thu, 16 Nov 2000 09:47:23 -0800 (PST) From: Mark Crispin Subject: re: RFC 2193 & RFC 2221 To: Cynthia_Mamacos@lotus.com cc: ietf-imapext@imc.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 16 Nov 2000 12:40:04 -0500, Cynthia_Mamacos@lotus.com wrote: > Interested in RFC 2193 IMAP4 Mailbox Referrals & RFC 2221IMAP4 Login > Referrals. How well adopted are these ? What's happening in this area ? Pine and most other good-quality client implementations fully implement referrals at the client level. I am aware of at least two servers which support referrals, either with a full implementation or with hooks to a local management facility. Received: by ns.secondary.com (8.9.3/8.9.3) id JAA23482 for ietf-imapext-bks; Thu, 16 Nov 2000 09:33:28 -0800 (PST) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA23471 for ; Thu, 16 Nov 2000 09:33:25 -0800 (PST) From: Cynthia_Mamacos@lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id MAA21045 for ; Thu, 16 Nov 2000 12:44:07 -0500 (EST) Received: from ismail.lotus.com (ISMAIL.lotus.com [9.95.4.115]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id MAA23189 for ; Thu, 16 Nov 2000 12:40:29 -0500 (EST) To: ietf-imapext@imc.org Subject: RFC 2193 & RFC 2221 X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: Date: Thu, 16 Nov 2000 12:40:04 -0500 X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Build V506_11132000 |November 13, 2000) at 11/16/2000 12:40:06 PM, Serialize complete at 11/16/2000 12:40:06 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0060C73E85256999_=" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0060C73E85256999_= Content-Type: text/plain; charset="us-ascii" All, Interested in RFC 2193 IMAP4 Mailbox Referrals & RFC 2221IMAP4 Login Referrals. How well adopted are these ? What's happening in this area ? Any assistance would be greatly appreciated. Cynthia Mamacos Lotus Development Corp. --=_alternative 0060C73E85256999_= Content-Type: text/html; charset="us-ascii"
All,  
Interested in RFC 2193 IMAP4 Mailbox Referrals & RFC 2221IMAP4 Login Referrals.  How well adopted are these ?  What's happening in this area ?
Any assistance would be greatly appreciated.

Cynthia Mamacos
Lotus Development Corp.
 --=_alternative 0060C73E85256999_=-- Received: by ns.secondary.com (8.9.3/8.9.3) id IAA07766 for ietf-imapext-bks; Thu, 16 Nov 2000 08:39:36 -0800 (PST) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA07757 for ; Thu, 16 Nov 2000 08:39:35 -0800 (PST) Received: from kepler (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id eAGGlAC05201; Thu, 16 Nov 2000 09:47:10 -0700 From: Steve Hole Date: Thu, 16 Nov 2000 09:46:01 -0700 To: Chris Newman Subject: Re: LIST Extensions Requirements Cc: IMAP Extensions WG Message-ID: X-Mailer: Execmail for Win32 5.1.1 Build (10) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 15 Nov 2000 12:04:59 -0800 Chris Newman wrote: > Here's a first shot at requirements for the "XLIST" command. This is a > brainstorm of ideas I recall being mentioned or have thought about, so > please don't assume you know my position just because an item showed up > in the list. Looks good Chris. There are things that I would like to discuss about the namespace issues and reference arguments, but that should wait for a face-to-face. One thing I would ask. Can you keep track of the individual requirements that progress through the discussion? I think that we want to collect a requirements table that lists all the requirements that people propose, along with a state that is one of: Accepted - concensus to include as a requirement Rejected - concensus to reject as a requirement Discussion - further discussion required to reach accept or reject Proposed - proposed requirement but no discussion had yet There are probably other states, but that should do for a starter. If you can't, then can someone else do this? It will greatly improve our ability to have a rational design discussion if we avoid rehashing things that we have already reached concensus on. Good work Chris. Cheers. --- Steve Hole Chief Technical Officer Messaging Direct Mailto:Steve.Hole@MessagingDirect.com Phone: 780-424-4922 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA27298 for ietf-imapext-bks; Thu, 16 Nov 2000 03:20:47 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA27270 for ; Thu, 16 Nov 2000 03:20:37 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09130; Thu, 16 Nov 2000 06:28:10 -0500 (EST) Message-Id: <200011161128.GAA09130@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-thread-05.txt Date: Thu, 16 Nov 2000 06:28:09 -0500 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF. Title : INTERNET MESSAGE ACCESS PROTOCOL - THREAD EXTENSION Author(s) : M. Crispin, K. Murchison Filename : draft-ietf-imapext-thread-05.txt Pages : 13 Date : 15-Nov-00 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-ietf-imapext-thread-05.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-ietf-imapext-thread-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imapext-thread-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001115091746.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-thread-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-thread-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001115091746.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: by ns.secondary.com (8.9.3/8.9.3) id OAA17808 for ietf-imapext-bks; Wed, 15 Nov 2000 14:47:56 -0800 (PST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA17798 for ; Wed, 15 Nov 2000 14:47:55 -0800 (PST) Received: from westmail2.West.Sun.COM ([129.153.100.30]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA24329; Wed, 15 Nov 2000 14:55:18 -0800 (PST) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA06142; Wed, 15 Nov 2000 14:55:17 -0800 (PST) Date: Wed, 15 Nov 2000 14:54:58 -0800 From: Chris Newman To: Simon Josefsson cc: IMAP Extensions WG Subject: Re: LIST Extensions Requirements Message-ID: <840379.3183288898@nifty-jr.west.sun.com> In-Reply-To: X-Mailer: Mulberry/2.0.5 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Wednesday, November 15, 2000 23:21 +0100 Simon Josefsson wrote: > * It must not break old mailbox names -- if `/' is the new delimiter > there must be a way to escape `/' within a mailbox name. That's not a requirement for XLIST, IMHO. If you want to use "/" as a character in a mailbox names, then don't implement XLIST. > * Because escaping might be ugly, I suggest that we could consider a > delimiter agnostic solution -- * XLIST ... "INBOX" "whatever" > "whatother" I'd rather not. That's too much work to parse, manage and map to URL semantics (which use "/" as the one true delimiter). > * I feel the "display delimiter" might be as complicated as the > current delimiter situation, is it really worth having? I'd prefer to do without it, but it's certainly simpler than the status quo where a client has to support all delimiters (including NIL) and translate mailbox names accordingly. With a "display delimiter", the majority of clients which use hierarchy don't care, only those which display full paths to mailboxes need to worry about it. > * Permit a facility to discover mailboxes with newly arrived mail How do you define "newly arrived mail"? Mailboxes with unseen messages? Or Mailboxes with \Recent messages (meaning messages have arrived since the last time you or perhaps someone else selected the mailbox). >> * Layered facility for virtual scrollbars in very large mailbox list >> (e.g. #news/alt/%) >> >> * Limit on number of returned mailboxes (with limit exceeded notice) > > IMHO these should be optional and only used upon client request. For the former I'd agree. For the later, I'd actually be tempted to force clients to always specify the maximum number of returned mailboxes they can deal with. I'm sick and tired of clients that crash or hang my machine when I point them at a server with too many mailboxes. - Chris Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA15704 for ietf-imapext-bks; Wed, 15 Nov 2000 14:39:15 -0800 (PST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA15700 for ; Wed, 15 Nov 2000 14:39:14 -0800 (PST) Received: from westmail2.West.Sun.COM ([129.153.100.30]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA10110 for ; Wed, 15 Nov 2000 14:46:38 -0800 (PST) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA03786 for ; Wed, 15 Nov 2000 14:29:19 -0800 (PST) Date: Wed, 15 Nov 2000 14:28:59 -0800 From: Chris Newman To: IMAP Extensions WG Subject: re: LIST Extensions Requirements Message-ID: <746635.3183287339@nifty-jr.west.sun.com> In-Reply-To: X-Mailer: Mulberry/2.0.5 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Wednesday, November 15, 2000 12:14 -0800 Mark Crispin wrote: > Server MUST be able to refuse LSUB or STATUS functionality. Consequently > extended LIST will never deprecate LSUB or STATUS, and clients MUST be > able to use LSUB and STATUS. That point is controversial and I doubt further debate on the list would be productive. I _suggest_ resolving face to face. > This has the potential to be a major rathole. Suggest that debate on > this be deferred to the end and/or be time-limited ahead of time. > > I believe that "generic extensible command" is a solution in search of a > problem. I concur. I don't mind people structuring the command using some sort of extensible command model, as long as it isn't a separate document and doesn't waste a lot of time. >> * Only permit "/" as delimiter in new list command. > > How does this interact with newsgroups? > > How did URLs solve the problem? Did they make the newsgroup namespace > flat? I don't think that #news/comp/mail/misc will please the users, but > maybe #news/comp.mail.misc is OK. This would make % equivalent to *, but > as a practical matter this seems to be how many clients treat news anyway. The newsgroup namespace is flat in URLs (news:). I suspect that's the right answer. >> * Always use UTF-8 in new list command. > > Yes, definitely. That was my thought at first, but now I'm unsure. If UTF-8 shows up in mailbox names from extended list, then SELECT, CREATE, DELETE, etc. all have to support UTF-8. Should the presence of the extended LIST modify the behavior of other commands? I'd like to see more discussion. Perhaps use of UTF-8 is inherently orthogonal to extended list and thus has to be a separate independent extension (unfortunately)? >> * Permit a facility to discover newly created mailboxes. >> * Permit a facility to discover newly deleted mailboxes. >> * Permit a facility to discover mailboxes which have changed >> since last disconnected synchronization. >> * Layered facility for virtual scrollbars in very large mailbox list >> (e.g. #news/alt/%) > > ...Umm...as long as it is server-optional. That's the direction I lean as well. But IMAP's lack of the ability to get a list of newly created newsgroups is the major protocol reason people won't migrate from NNTP to IMAP for client access, so I hope most servers will choose to implement that facility. > ... due to the incorrect implementation in Cyrus; The Cyrus implementation was done in good faith and complied with RFC 2060. John and I had a long discussion of what is a "breakout" character in a news-style namespace. The conclusion we came to was that when a user types "comp.sys.mac" they are always referring to a top-level news folder. News didn't have a way to refer to relative namespaces, but the obvious choice was to use a "." prefix for relative names, since names lacking a prefix "." were absolute. We were trying our best to interpret the reference argument reasonably given the namespace semantics we were using. When URLs came along and made Unix path semantics the standard path semantics for the Internet, our interpretation (and choice of path delimiter) became inappropriate. When Pine came along and used the reference argument in a way we didn't expect, it failed to interoperate with Cyrus. The best fix at that point was to change Cyrus (and derivative servers) to match the URL path semantics which Pine assumed. - Chris Received: by ns.secondary.com (8.9.3/8.9.3) id OAA15480 for ietf-imapext-bks; Wed, 15 Nov 2000 14:26:41 -0800 (PST) Received: from dolk.extundo.com (dolk.extundo.com [195.42.214.242]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA15476 for ; Wed, 15 Nov 2000 14:26:38 -0800 (PST) Received: from barbar.josefsson.org (localhost.localdomain [127.0.0.1]) (authenticated) by dolk.extundo.com (8.11.1/8.11.1) with ESMTP id eAFMY9q28827 for ; Wed, 15 Nov 2000 23:34:10 +0100 To: Chris Newman Cc: IMAP Extensions WG Subject: Re: LIST Extensions Requirements References: <226931.3183278699@nifty-jr.west.sun.com> From: Simon Josefsson In-Reply-To: <226931.3183278699@nifty-jr.west.sun.com> Date: 15 Nov 2000 23:21:41 +0100 Message-ID: Lines: 35 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Some random thoughts about some of the issues... > * Only permit "/" as delimiter in new list command. > (Possibly have "display delimiter" attribute for clients that display > full mailbox names). * It must not break old mailbox names -- if `/' is the new delimiter there must be a way to escape `/' within a mailbox name. * Because escaping might be ugly, I suggest that we could consider a delimiter agnostic solution -- * XLIST ... "INBOX" "whatever" "whatother" * I feel the "display delimiter" might be as complicated as the current delimiter situation, is it really worth having? > * Permit a facility to discover newly created mailboxes. > > * Permit a facility to discover newly deleted mailboxes. > > * Permit a facility to discover mailboxes which have changed > since last disconnected synchronization. I'll add another idea: * Permit a facility to discover mailboxes with newly arrived mail > * Layered facility for virtual scrollbars in very large mailbox list > (e.g. #news/alt/%) > > * Limit on number of returned mailboxes (with limit exceeded notice) IMHO these should be optional and only used upon client request. Thanks Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA08110 for ietf-imapext-bks; Wed, 15 Nov 2000 13:09:13 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (icz@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA08093 for ; Wed, 15 Nov 2000 13:09:08 -0800 (PST) Date: Wed, 15 Nov 2000 12:14:45 -0800 (PST) From: Mark Crispin Subject: re: LIST Extensions Requirements To: Chris Newman cc: IMAP Extensions WG In-Reply-To: <226931.3183278699@nifty-jr.west.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 15 Nov 2000 12:04:59 -0800, Chris Newman wrote: > * The command should be structured so that clients only request the > information they really need and will actually use. Yes, definitely > * New list command subsumes functionality of LIST, LSUB, RLIST, RLSUB and > STATUS commands. Server MUST be able to refuse LSUB or STATUS functionality. Consequently extended LIST will never deprecate LSUB or STATUS, and clients MUST be able to use LSUB and STATUS. > * New list command subsumes child mailbox functionality. > * The command should have the option of returning ACL and myrights > information for mailboxes. > * The command should support mailbox annotations > * Avoid silly states. Use tri-state or multi-state variables instead of > interrelated flags to avoid them. All these are fine. > * Design around a "generic extensible command" model This has the potential to be a major rathole. Suggest that debate on this be deferred to the end and/or be time-limited ahead of time. I believe that "generic extensible command" is a solution in search of a problem. > * Only permit "/" as delimiter in new list command. How does this interact with newsgroups? How did URLs solve the problem? Did they make the newsgroup namespace flat? I don't think that #news/comp/mail/misc will please the users, but maybe #news/comp.mail.misc is OK. This would make % equivalent to *, but as a practical matter this seems to be how many clients treat news anyway. > * Always use UTF-8 in new list command. Yes, definitely. > * Permit a facility to discover newly created mailboxes. > * Permit a facility to discover newly deleted mailboxes. > * Permit a facility to discover mailboxes which have changed > since last disconnected synchronization. > * Layered facility for virtual scrollbars in very large mailbox list > (e.g. #news/alt/%) ...Umm...as long as it is server-optional. > * Limit on number of returned mailboxes (with limit exceeded notice) Yes. > * Way to request Quota information? Need review/overhaul of existing QUOTA specification. > * Don't include the reference argument in the replacement list command > (only using the "/" delimiter is the prerequisite for this). No. The only way to avoid the reference argument is to have a CWD command in IMAP. The last time this issue came up it wasted at least a year of everybody's time several years ago. It wasted time again a few years later due to the incorrect implementation in Cyrus; fortunately that is now fixed, and we had to leave a monument in RFC 2683 as to why the old Cyrus implementation was incorrect. However, in the meantime many users of Cyrus IMAP servers were inconvenienced. Reviving this dead issue will waste everybody's time all over again, and with many people this time the potential time wasted is worse than a year. > Explicitly note for clients that permit users to type a mailbox > name in context that if a user refers to ~/... or ~user/..., that > is likely shorthand for the Personal or Other Users namespaces > respectively. That proposal would create a UNIX-centric kludge. The need for context is wider than UNIX, and as such these kludges would need to be specified for every operating system (and future operating systems). The reference argument solves the problem, in a far simpler and cleaner way than such kludges. The reference argument also has the advantage of being in the IMAP base today. Let's leave it alone. > * What should be required for the base list replacement command If it is a "LIST replacement", then it must NOT replace LSUB or STATUS. Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA28839 for ietf-imapext-bks; Wed, 15 Nov 2000 11:57:56 -0800 (PST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA28814 for ; Wed, 15 Nov 2000 11:57:51 -0800 (PST) Received: from westmail2.West.Sun.COM ([129.153.100.30]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA13354 for ; Wed, 15 Nov 2000 12:05:21 -0800 (PST) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA16678 for ; Wed, 15 Nov 2000 12:05:16 -0800 (PST) Date: Wed, 15 Nov 2000 12:04:59 -0800 From: Chris Newman To: IMAP Extensions WG Subject: LIST Extensions Requirements Message-ID: <226931.3183278699@nifty-jr.west.sun.com> X-Mailer: Mulberry/2.0.5 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Here's a first shot at requirements for the "XLIST" command. This is a brainstorm of ideas I recall being mentioned or have thought about, so please don't assume you know my position just because an item showed up in the list. Believed Non-Controversial Requirements: ---------------------------------------- * The command should be structured so that clients only request the information they really need and will actually use. * Clients which don't need subscription flag won't ask for it. * Clients which care about remote mailboxes, but don't need referrals until select time can request that. * New list command subsumes functionality of LIST, LSUB, RLIST, RLSUB and STATUS commands. CAVEAT: Controversy exists as to what set of these should be required as part of the XLIST base spec and which ones should be layered XLIST extensions with their own capability string. * New list command subsumes child mailbox functionality. * The command should have the option of returning ACL and myrights information for mailboxes. * The command should support mailbox annotations CAVEAT: per-user and shared issue will rear its ugly head. As will annotation namespace issue. * Avoid silly states. Use tri-state or multi-state variables instead of interrelated flags to avoid them. * Design around a "generic extensible command" model that could be applied to other IMAP command extension situtations. CAVEAT: Controversy over whether "generic extensible command" model should be a separate standard. Ideas for requirements which need debate: ----------------------------------------- * Only permit "/" as delimiter in new list command. (Possibly have "display delimiter" attribute for clients that display full mailbox names). * Always use UTF-8 in new list command. * Permit a facility to discover newly created mailboxes. * Permit a facility to discover newly deleted mailboxes. * Permit a facility to discover mailboxes which have changed since last disconnected synchronization. * Layered facility for virtual scrollbars in very large mailbox list (e.g. #news/alt/%) * Limit on number of returned mailboxes (with limit exceeded notice) * Way to request Quota information? * Don't include the reference argument in the replacement list command (only using the "/" delimiter is the prerequisite for this). Explicitly note for clients that permit users to type a mailbox name in context that if a user refers to ~/... or ~user/..., that is likely shorthand for the Personal or Other Users namespaces respectively. Controversial requirement ideas: -------------------------------- * What should be required for the base list replacement command, as opposed to extensions to the list replacement command? Proposed litmus test: If it is common practice for IMAP clients to kludge around a deficiency in the LIST/LSUB/etc suite, then that facility should be part of the base XLIST command. For example, many clients currently do "LIST "" %" and "LIST "" %/%" when \HasChildren information isn't available. When XLIST is implemented this kludge should never be necessary. Additional litmus test: If there's a reasonable trivial implemention to comply, then include it in the XLIST base spec. For example, a non-referral IMAP server can support clients that request referrals simply by never returning any. Anything not meeting one of these litmus tests should be an XLIST extension. * Have "generic extensible command" model as a separate standard. - Chris Received: by ns.secondary.com (8.9.3/8.9.3) id MAA04858 for ietf-imapext-bks; Sat, 4 Nov 2000 12:21:13 -0800 (PST) Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA04854 for ; Sat, 4 Nov 2000 12:21:12 -0800 (PST) Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14]) by ogma.cisco.com (Postfix) with ESMTP id A8A8E569; Sat, 4 Nov 2000 21:27:17 +0100 (MET) Received: from [192.168.1.129] (ssh-sj1.cisco.com [171.68.225.134]) by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id VAA02905; Sat, 4 Nov 2000 21:27:13 +0100 (MET) Mime-Version: 1.0 X-Sender: pfaltstr@192.168.1.129 Message-Id: Date: Sat, 4 Nov 2000 15:26:43 -0500 To: "RL 'Bob' Morgan" From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: moderate or restrict IMAPEXT Cc: IMAP Extensions WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10.17 -0800 00-11-04, RL 'Bob' Morgan wrote: >Having seen this issue go by on several mailing lists, and seen more or >less the same answer be suggested, I wonder whether this wisdom is >captured anywhere official? http://www.ietf.org/IESG/STATEMENTS/moderated-lists.txt paf > > - RL "Bob" > >> As an IESG member which _IS_ subscribed to the list, let me explain >> what we normally say in these cases: >> >> This is the algorithm which we think is ok: >> >> IF the sender address is subscribed to the mailing list, OR >> on a special list for "approved subscribers" THEN >> Send the mail to the mailing list >> ELSE >> forward the mail to a human >> IF the mail is spam THEN >> >/dev/null >> FI >> IF the mail is not according to list policy THEN >> return message to sender, informing of what happened >> FI >> forward the mail to the mailing list >> FI >> >> I.e. filtering is ok, but you need a human which manually takes care >> of rejected messages. Received: by ns.secondary.com (8.9.3/8.9.3) id MAA04744 for ietf-imapext-bks; Sat, 4 Nov 2000 12:10:30 -0800 (PST) Received: from episteme-software.com (presnick-fw.flexabit.net [64.198.230.34]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA04739 for ; Sat, 4 Nov 2000 12:10:28 -0800 (PST) Received: from presnick-35.flexabit.net (64.198.230.35) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.0.2a2) for ; Sat, 4 Nov 2000 12:49:58 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: X-Mailer: Eudora [Macintosh version 5.1a1-12.00] Date: Sat, 4 Nov 2000 12:49:56 -0600 To: IMAP Extensions WG From: "RL 'Bob' Morgan" () Subject: RE: moderate or restrict IMAPEXT Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Having seen this issue go by on several mailing lists, and seen more or less the same answer be suggested, I wonder whether this wisdom is captured anywhere official? - RL "Bob" > As an IESG member which _IS_ subscribed to the list, let me explain > what we normally say in these cases: > > This is the algorithm which we think is ok: > > IF the sender address is subscribed to the mailing list, OR > on a special list for "approved subscribers" THEN > Send the mail to the mailing list > ELSE > forward the mail to a human > IF the mail is spam THEN > >/dev/null > FI > IF the mail is not according to list policy THEN > return message to sender, informing of what happened > FI > forward the mail to the mailing list > FI > > I.e. filtering is ok, but you need a human which manually takes care > of rejected messages. Received: by ns.secondary.com (8.9.3/8.9.3) id MAA04743 for ietf-imapext-bks; Sat, 4 Nov 2000 12:10:30 -0800 (PST) Received: from episteme-software.com (presnick-fw.flexabit.net [64.198.230.34]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA04734 for ; Sat, 4 Nov 2000 12:10:28 -0800 (PST) Received: from presnick-35.flexabit.net (64.198.230.35) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.0.2a2) for ; Sat, 4 Nov 2000 12:48:43 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: X-Mailer: Eudora [Macintosh version 5.1a1-12.00] Date: Sat, 4 Nov 2000 12:48:41 -0600 To: ietf-imapext@imc.org From: Lawrence Greenfield () Subject: Re: comments on LIST extensions Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From: "Mike Gahrns" Cc: Date: Fri, 3 Nov 2000 16:18:33 -0800 [...] How about something like the following? 3a) tag LIST "" % (REMOTE) includes in the LIST response folders that are remote and somehow marked as such in the LIST response 3b)tag LIST "" % (REFERRAL) include in the LIST response folders that are remote along with their remote URL referral data However, I am somewhat unsure as to the scenario where it would be desirable for the client to request to have the folder's referral URL returned to it in the LIST command, rather than obtaining this info on demand when needed during the SELECT command. I really want advisory referrals---I have a server that will silently proxy for non-referral aware clients and handout referrals to clients that execute an RLIST or RLSUB (yes, it's a mode, and yes, it's an ugly hack). So I'd like the way that referrals are discovered to happen before a SELECT---even an advisory referral on SELECT will require my proxy server to open a connection to the backend server, to give the rest of the data on SELECT. Larry Received: by ns.secondary.com (8.9.3/8.9.3) id LAA03643 for ietf-imapext-bks; Sat, 4 Nov 2000 11:54:21 -0800 (PST) Received: from smtp5.andrew.cmu.edu (SMTP5.ANDREW.CMU.EDU [128.2.10.85]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA03638 for ; Sat, 4 Nov 2000 11:54:19 -0800 (PST) Received: from PENGUIN.ANDREW.CMU.EDU (PENGUIN.ANDREW.CMU.EDU [128.2.122.2]) (authenticated as leg with KERBEROS_V4 (56 bits)) by smtp5.andrew.cmu.edu (8.11.1/8.11.1) with ESMTP id eA4K0sK15409 for ; Sat, 4 Nov 2000 15:00:54 -0500 X-Sieve: cmu-sieve 2.0 Received: from mail1.andrew.cmu.edu (MAIL1.ANDREW.CMU.EDU [128.2.10.131]) by mail3.andrew.cmu.edu (8.11.0/8.11.0) with ESMTP id eA4HP7B16535 for ; Sat, 4 Nov 2000 12:25:07 -0500 (EST) Received: (from root@localhost) by mail1.andrew.cmu.edu (8.9.3/8.9.3) id MAA23899 for leg@mail3.andrew.cmu.edu; Sat, 4 Nov 2000 12:25:07 -0500 (EST) X-Sieve: cmu-sieve 2.0 Received: from smtp4.andrew.cmu.edu (SMTP4.ANDREW.CMU.EDU [128.2.10.84]) by mail1.andrew.cmu.edu (8.9.3/8.9.3) with ESMTP id MAA23892 for ; Sat, 4 Nov 2000 12:25:06 -0500 (EST) Received: from PENGUIN.ANDREW.CMU.EDU (PENGUIN.ANDREW.CMU.EDU [128.2.122.2]) (authenticated as leg with KERBEROS_V4 (56 bits)) by smtp4.andrew.cmu.edu (8.11.1/8.11.0) with ESMTP id eA4HP6V17033; Sat, 4 Nov 2000 12:25:06 -0500 Date: Sat, 4 Nov 2000 12:25:06 -0500 Message-Id: <200011041725.eA4HP6V17033@smtp4.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.2 To: Mike Gahrns Cc: ietf-imapext@imc.org In-reply-to: <000401c045f4$c8950500$8dfc3b9d@redmond.corp.microsoft.com> Subject: Re: comments on LIST extensions References: <000401c045f4$c8950500$8dfc3b9d@redmond.corp.microsoft.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From: "Mike Gahrns" Cc: Date: Fri, 3 Nov 2000 16:18:33 -0800 [...] How about something like the following? 3a) tag LIST "" % (REMOTE) includes in the LIST response folders that are remote and somehow marked as such in the LIST response 3b)tag LIST "" % (REFERRAL) include in the LIST response folders that are remote along with their remote URL referral data However, I am somewhat unsure as to the scenario where it would be desirable for the client to request to have the folder's referral URL returned to it in the LIST command, rather than obtaining this info on demand when needed during the SELECT command. I really want advisory referrals---I have a server that will silently proxy for non-referral aware clients and handout referrals to clients that execute an RLIST or RLSUB (yes, it's a mode, and yes, it's an ugly hack). So I'd like the way that referrals are discovered to happen before a SELECT---even an advisory referral on SELECT will require my proxy server to open a connection to the backend server, to give the rest of the data on SELECT. Larry Received: by ns.secondary.com (8.9.3/8.9.3) id JAA27735 for ietf-imapext-bks; Sat, 4 Nov 2000 09:17:44 -0800 (PST) Received: from episteme-software.com (presnick-fw.flexabit.net [64.198.230.34]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA27731 for ; Sat, 4 Nov 2000 09:17:43 -0800 (PST) Received: from presnick-35.flexabit.net (64.198.230.35) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.0.2a2); Sat, 4 Nov 2000 11:23:48 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: References: X-Mailer: Eudora [Macintosh version 5.1a1-12.00] Date: Sat, 4 Nov 2000 11:23:44 -0600 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= From: Pete Resnick Subject: RE: moderate or restrict IMAPEXT Cc: "Eric Burger" , "Mark Crispin" , "IMAP Extensions WG" Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 11/4/00 at 12:19 PM -0500, Patrik Fδltstrφm wrote: >I.e. filtering is ok, but you need a human which manually takes care >of rejected messages. Yes, I got e-mail from Paul (our list manager), and what you describe is exactly what we will do. pr -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA27638 for ietf-imapext-bks; Sat, 4 Nov 2000 09:15:38 -0800 (PST) Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA27634 for ; Sat, 4 Nov 2000 09:15:36 -0800 (PST) Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14]) by ogma.cisco.com (Postfix) with ESMTP id 71F9AF8; Sat, 4 Nov 2000 18:21:41 +0100 (MET) Received: from [192.168.1.129] (ssh-sj1.cisco.com [171.68.225.134]) by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id SAA22151; Sat, 4 Nov 2000 18:21:24 +0100 (MET) Mime-Version: 1.0 X-Sender: pfaltstr@192.168.1.129 Message-Id: In-Reply-To: References: Date: Sat, 4 Nov 2000 12:19:21 -0500 To: Pete Resnick , "Eric Burger" From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: moderate or restrict IMAPEXT Cc: "Mark Crispin" , "IMAP Extensions WG" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 16.54 -0600 00-11-03, Pete Resnick wrote: >On 11/3/00 at 5:38 PM -0500, Eric Burger wrote: > >>What if we just limit posting to subscribers? That reduces the chance of an >>amature spammer succeeding, without the pain for the moderator. > >And it would proceed to disallow people like IESG members and others >who don't subscribe to the list from posting. I heavily object to >that. I'll moderate if we can work that out. As an IESG member which _IS_ subscribed to the list, let me explain what we normally say in these cases: This is the algorithm which we think is ok: IF the sender address is subscribed to the mailing list, OR on a special list for "approved subscribers" THEN Send the mail to the mailing list ELSE forward the mail to a human IF the mail is spam THEN >/dev/null FI IF the mail is not according to list policy THEN return message to sender, informing of what happened FI forward the mail to the mailing list FI I.e. filtering is ok, but you need a human which manually takes care of rejected messages. Patrik Received: by ns.secondary.com (8.9.3/8.9.3) id QAA21992 for ietf-imapext-bks; Fri, 3 Nov 2000 16:17:44 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA21988 for ; Fri, 3 Nov 2000 16:17:42 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 3 Nov 2000 16:18:00 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 03 Nov 2000 16:18:41 -0800 (Pacific Standard Time) Received: from mikega10 ([157.59.252.141]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 3 Nov 2000 16:18:40 -0800 Message-ID: <000401c045f4$c8950500$8dfc3b9d@redmond.corp.microsoft.com> From: "Mike Gahrns" To: "Mark Crispin" Cc: References: Subject: Re: comments on LIST extensions Date: Fri, 3 Nov 2000 16:18:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-OriginalArrivalTime: 04 Nov 2000 00:18:40.0543 (UTC) FILETIME=[C88D8AF0:01C045F4] Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: >So, would it work for you that: > > 1) tag LIST "" % > does not include referral mailboxes > > 2) tag RLIST "" % > tag LIST "" % () > include referral mailboxes, but do not return referal data > > 3) tag LIST "" % (REFERRAL) > include referral mailboxes and return referral data *** If we went the LIST extension route, I think I would like to see RLIST eventually deprecated. As such, I think there would need to be a way to get just the list of remote mailboxes, and not their remote url location for the perf reasons I mentioned in my previous post. The remote url location for can be easily obtained via SELECT, and saves having the server need to supply the info on a potentially large number of folders that may never be accessed during the session. (Hopefully clients smart enough to use this extension would not be blindly getting a whole public folder tree, but none-the-less it would still be common to have potentially hundreds of folders in a single level of hierarchy.) How about something like the following? 3a) tag LIST "" % (REMOTE) includes in the LIST response folders that are remote and somehow marked as such in the LIST response 3b)tag LIST "" % (REFERRAL) include in the LIST response folders that are remote along with their remote URL referral data However, I am somewhat unsure as to the scenario where it would be desirable for the client to request to have the folder's referral URL returned to it in the LIST command, rather than obtaining this info on demand when needed during the SELECT command. Received: by ns.secondary.com (8.9.3/8.9.3) id PAA21176 for ietf-imapext-bks; Fri, 3 Nov 2000 15:44:02 -0800 (PST) Received: from mail15a.boca15-verio.com (mail15a.boca15-verio.com [208.55.91.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA21172 for ; Fri, 3 Nov 2000 15:44:01 -0800 (PST) Received: from www.snowshore.com (128.241.144.247) by mail15a.boca15-verio.com (RS ver 1.0.57s) with SMTP id 02562983; Fri, 3 Nov 2000 18:50:23 -0500 (EST) From: "Eric Burger" To: "Pete Resnick" , "Mark Crispin" Cc: "IMAP Extensions WG" Subject: RE: moderate or restrict IMAPEXT Date: Fri, 3 Nov 2000 18:49:53 -0500 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: X-Loop-Detect: 1 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: What if we just limit posting to subscribers? That reduces the chance of an amature spammer succeeding, without the pain for the moderator. -- - Eric -----Original Message----- From: owner-ietf-imapext@mail.imc.org [mailto:owner-ietf-imapext@mail.imc.org]On Behalf Of Pete Resnick Sent: Friday, November 03, 2000 1:24 PM To: Mark Crispin Cc: IMAP Extensions WG Subject: Re: moderate or restrict IMAPEXT On 11/3/00 at 9:48 AM -0800, Mark Crispin wrote: >Please establish moderation on IMAPEXT Paul, I'm perfectly willing to do this if you have a method. If we can use IMAP mailboxes to do this (perhaps an incoming IMAP mailbox on your server that I moderate and transfer to another mailbox on your server that you send out to the list), it would be perfectly easy for me. pr -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA20652 for ietf-imapext-bks; Fri, 3 Nov 2000 15:11:47 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (jeff@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA20648 for ; Fri, 3 Nov 2000 15:11:46 -0800 (PST) Date: Fri, 3 Nov 2000 15:16:34 -0800 (PST) From: Mark Crispin Subject: Re: comments on LIST extensions To: Mike Gahrns cc: Barry Leiba , ietf-imapext@imc.org In-Reply-To: <000401c045e6$d545a600$8dfc3b9d@redmond.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 3 Nov 2000 14:38:42 -0800, Mike Gahrns wrote: > *** For Exchange, there will be some hit in getting the referral data. > Probably not devasting, but likely noticeable in the time it takes the LIST > response to come back. From a general design point of view, it is probably > best to not include the referral details in a response. Why generate this > info until it is needed? Not to mention sending the extra info across the > wire, (which if there are multiple replicas could get large). So, would it work for you that: 1) tag LIST "" % does not include referral mailboxes 2) tag RLIST "" % tag LIST "" % () include referral mailboxes, but do not return referal data 3) tag LIST "" % (REFERRAL) include referral mailboxes and return referral data Received: by ns.secondary.com (8.9.3/8.9.3) id PAA20591 for ietf-imapext-bks; Fri, 3 Nov 2000 15:08:49 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (dchap@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA20586 for ; Fri, 3 Nov 2000 15:08:48 -0800 (PST) Date: Fri, 3 Nov 2000 15:10:20 -0800 (PST) From: Mark Crispin Subject: Re: comments on LIST extensions To: Mike Gahrns cc: ietf-imapext@imc.org In-Reply-To: <000f01c045e1$af45a8b0$8dfc3b9d@redmond.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 3 Nov 2000 14:01:57 -0800, Mike Gahrns wrote: > How did you envision your suggestion working? Assuming that the LIST command is extended with a third argument, containing a parenthesized list of additional attributes desired, then: A two-argument LIST command will work as now; it may have expansion attributes in the response but will never return additional data. A three-argument LIST command will result in responses that include referral messages and possibly also referral data. The replacement for RLIST is a three-argument LIST with zero members in the additional attribute list. Received: by ns.secondary.com (8.9.3/8.9.3) id PAA20489 for ietf-imapext-bks; Fri, 3 Nov 2000 15:02:22 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA20485 for ; Fri, 3 Nov 2000 15:02:21 -0800 (PST) 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 SAA12194; Fri, 3 Nov 2000 18:07:36 -0500 (EST) Date: Fri, 03 Nov 2000 18:08:37 -0500 From: Cyrus Daboo To: Pete Resnick , Eric Burger cc: Mark Crispin , IMAP Extensions WG Subject: RE: moderate or restrict IMAPEXT Message-ID: <1583220.3182263717@sardis.cyrusoft.com> In-Reply-To: X-Mailer: Mulberry/2.0.5 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Friday, November 3, 2000 4:54 PM -0600 Pete Resnick wrote: >> What if we just limit posting to subscribers? That reduces the chance >> of an amature spammer succeeding, without the pain for the moderator. > > And it would proceed to disallow people like IESG members and others who > don't subscribe to the list from posting. I heavily object to that. I'll > moderate if we can work that out. Also a number of us don't subscribe directly but instead pipe the list into a shared imap mailbox via a specific email address - one of the many useful features of IMAP! -- Cyrus Daboo Received: by ns.secondary.com (8.9.3/8.9.3) id PAA20462 for ietf-imapext-bks; Fri, 3 Nov 2000 15:01:26 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA20458 for ; Fri, 3 Nov 2000 15:01:25 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 3 Nov 2000 14:38:10 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 03 Nov 2000 14:38:51 -0800 (Pacific Standard Time) Received: from mikega10 ([157.59.252.141]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 3 Nov 2000 14:38:48 -0800 Message-ID: <000401c045e6$d545a600$8dfc3b9d@redmond.corp.microsoft.com> From: "Mike Gahrns" To: "Barry Leiba" , References: <2579962729.973242571@mars.trees.watson.ibm.com> Subject: Re: comments on LIST extensions Date: Fri, 3 Nov 2000 14:38:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-OriginalArrivalTime: 03 Nov 2000 22:38:48.0988 (UTC) FILETIME=[D54ECDC0:01C045E6] Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Barry Leiba writes: > The only concern I have here is that a referral-capable server might > know quickly that a mailbox is remote, but might have a slower time > actually retrieving the referral information. So there *might* be some use > in letting the server tell you "this mailbox exists somewhere else", but > not actually tell you *where* until you try to do something with it (if, > for example, there are 50 remote mailboxes and it takes 1 second to > retrieve the referral data for each, adding 50 seconds to the LIST > (REFERRALS) command would be bad, and it might be better to make you try > a SELECT when you actually want to use one of them). Do any servers > besides Exchange support mailbox referrals now? How fast is it for Exchange (or > other servers) to retrieve the referral details? *** For Exchange, there will be some hit in getting the referral data. Probably not devasting, but likely noticeable in the time it takes the LIST response to come back. From a general design point of view, it is probably best to not include the referral details in a response. Why generate this info until it is needed? Not to mention sending the extra info across the wire, (which if there are multiple replicas could get large). Received: by ns.secondary.com (8.9.3/8.9.3) id OAA20217 for ietf-imapext-bks; Fri, 3 Nov 2000 14:48:05 -0800 (PST) Received: from episteme-software.com (presnick-fw.flexabit.net [64.198.230.34]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA20213 for ; Fri, 3 Nov 2000 14:48:04 -0800 (PST) Received: from presnick-35.flexabit.net (64.198.230.35) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.0.2a2); Fri, 3 Nov 2000 16:54:06 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: References: X-Mailer: Eudora [Macintosh version 5.1a1-12.00] Date: Fri, 3 Nov 2000 16:54:04 -0600 To: "Eric Burger" From: Pete Resnick Subject: RE: moderate or restrict IMAPEXT Cc: "Mark Crispin" , "IMAP Extensions WG" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 11/3/00 at 5:38 PM -0500, Eric Burger wrote: >What if we just limit posting to subscribers? That reduces the chance of an >amature spammer succeeding, without the pain for the moderator. And it would proceed to disallow people like IESG members and others who don't subscribe to the list from posting. I heavily object to that. I'll moderate if we can work that out. pr -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA19767 for ietf-imapext-bks; Fri, 3 Nov 2000 14:33:31 -0800 (PST) Received: from mail15a.boca15-verio.com (mail15a.boca15-verio.com [208.55.91.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA19762 for ; Fri, 3 Nov 2000 14:33:30 -0800 (PST) Received: from www.snowshore.com (128.241.144.247) by mail15a.boca15-verio.com (RS ver 1.0.57s) with SMTP id 02549864; Fri, 3 Nov 2000 17:39:29 -0500 (EST) From: "Eric Burger" To: "Pete Resnick" , "Mark Crispin" Cc: "IMAP Extensions WG" Subject: RE: moderate or restrict IMAPEXT Date: Fri, 3 Nov 2000 17:38:58 -0500 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: X-Loop-Detect: 1 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: What if we just limit posting to subscribers? That reduces the chance of an amature spammer succeeding, without the pain for the moderator. -- - Eric -----Original Message----- From: owner-ietf-imapext@mail.imc.org [mailto:owner-ietf-imapext@mail.imc.org]On Behalf Of Pete Resnick Sent: Friday, November 03, 2000 1:24 PM To: Mark Crispin Cc: IMAP Extensions WG Subject: Re: moderate or restrict IMAPEXT On 11/3/00 at 9:48 AM -0800, Mark Crispin wrote: >Please establish moderation on IMAPEXT Paul, I'm perfectly willing to do this if you have a method. If we can use IMAP mailboxes to do this (perhaps an incoming IMAP mailbox on your server that I moderate and transfer to another mailbox on your server that you send out to the list), it would be perfectly easy for me. pr -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA19089 for ietf-imapext-bks; Fri, 3 Nov 2000 14:01:35 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA19085 for ; Fri, 3 Nov 2000 14:01:34 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 3 Nov 2000 14:01:17 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 03 Nov 2000 14:01:59 -0800 (Pacific Standard Time) Received: from mikega10 ([157.59.252.141]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 3 Nov 2000 14:01:58 -0800 Message-ID: <000f01c045e1$af45a8b0$8dfc3b9d@redmond.corp.microsoft.com> From: "Mike Gahrns" To: "Mark Crispin" Cc: References: Subject: Re: comments on LIST extensions Date: Fri, 3 Nov 2000 14:01:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-OriginalArrivalTime: 03 Nov 2000 22:01:58.0143 (UTC) FILETIME=[AF8AA0F0:01C045E1] Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: > My idea was that you would not show referrals unless you asked for referral > information in the extended LIST. This could work. My assumptions were that the extended LIST info would be always coming back. How did you envision your suggestion working? Are you proposing a command to turn on extend LIST responses, or a command to include referral info in an extended LIST response? This seems like it would be adding "modes" to IMAP, which I thought there were strong objections to in the past... With a command like XLIST, it was explicit that the client was requesting this additional info and had to be prepared to handle it. Received: by ns.secondary.com (8.9.3/8.9.3) id NAA18729 for ietf-imapext-bks; Fri, 3 Nov 2000 13:48:16 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (warner@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA18724 for ; Fri, 3 Nov 2000 13:48:15 -0800 (PST) Date: Fri, 3 Nov 2000 13:53:07 -0800 (PST) From: Mark Crispin Subject: Re: comments on LIST extensions To: Mike Gahrns cc: Steve Hole , Tony Hansen , Barry Leiba , ietf-imapext@imc.org In-Reply-To: <000a01c045e0$2e125c80$8dfc3b9d@redmond.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 3 Nov 2000 13:51:06 -0800, Mike Gahrns wrote: > *** One drawback of extending LIST through upwards-compatible syntax instead > of creating a new command like XLIST, is that it will create problems in > the referral case. My idea was that you would not show referrals unless you asked for referral information in the extended LIST. Received: by ns.secondary.com (8.9.3/8.9.3) id NAA18667 for ietf-imapext-bks; Fri, 3 Nov 2000 13:46:02 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA18663 for ; Fri, 3 Nov 2000 13:46:00 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 3 Nov 2000 13:50:31 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 03 Nov 2000 13:51:12 -0800 (Pacific Standard Time) Received: from mikega10 ([157.59.252.141]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 3 Nov 2000 13:51:11 -0800 Message-ID: <000a01c045e0$2e125c80$8dfc3b9d@redmond.corp.microsoft.com> From: "Mike Gahrns" To: "Mark Crispin" , "Steve Hole" Cc: "Tony Hansen" , "Barry Leiba" , References: Subject: Re: comments on LIST extensions Date: Fri, 3 Nov 2000 13:51:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-OriginalArrivalTime: 03 Nov 2000 21:51:11.0865 (UTC) FILETIME=[2E546E90:01C045E0] Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: > I am not yet convinced that we can not extend LIST through upwards-compatible > syntax. Shouldn't we proceed as if we can do so, with the understanding that > XLIST is not out of the question if we hit an otherwise insurmountable > obstacle? *** One drawback of extending LIST through upwards-compatible syntax instead of creating a new command like XLIST, is that it will create problems in the referral case. Even if we add referral info in a LIST response that presumably would be ignored by non-referral enabled clients, these non-referral enabled clients would still likely show these remote folders to their users. This was deemed undesirable during the initial referral discussions. e.g. The user experience would be bad in that users would try to select these remote folders, and have the SELECT command fail when accessed. Received: by ns.secondary.com (8.9.3/8.9.3) id MAA16921 for ietf-imapext-bks; Fri, 3 Nov 2000 12:26:25 -0800 (PST) Received: from episteme-software.com (presnick-fw.flexabit.net [64.198.230.34]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA16915 for ; Fri, 3 Nov 2000 12:26:22 -0800 (PST) Received: from presnick-35.flexabit.net (64.198.230.35) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.0.2a2); Fri, 3 Nov 2000 13:44:00 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: <2598967901.973261576@mars.trees.watson.ibm.com> References: <2598967901.973261576@mars.trees.watson.ibm.com> X-Mailer: Eudora [Macintosh version 5.1a1-12.00] Date: Fri, 3 Nov 2000 13:43:57 -0600 To: Barry Leiba From: Pete Resnick Subject: Re: comments on LIST extensions Cc: ietf-imapext@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 11/3/00 at 2:26 PM -0500, Barry Leiba wrote: >OK, then... since all the discussions about what XLIST might be have >so far been ad hoc discussion among a few of us, why don't we get >some time on the agenda at San Diego and have a proper discussion of >it. I'll take that discussion and come up with a first pass at the >requirements, and then we can discuss it further on the mailing list. > >If that's the way everyone wants to go, then I'll not make any >updates to the LIST Extensions draft now, and the next revision will >just be the first draft of the new XLIST command. Shall we do it >that way? Barry, I am more inclined to have you write *something* before the meeting if you can, even if it is just a straw man to bat around. We've still got two weeks to discuss this a bit on the list and maybe get Barry enough stuff to throw into an I-D before the November 17 deadline. If we can't, such is life, but let's see what we can do. In either case, this will still be an important item on the agenda. pr -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA16918 for ietf-imapext-bks; Fri, 3 Nov 2000 12:26:24 -0800 (PST) Received: from episteme-software.com (presnick-fw.flexabit.net [64.198.230.34]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA16911 for ; Fri, 3 Nov 2000 12:26:22 -0800 (PST) Received: from presnick-35.flexabit.net (64.198.230.35) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.0.2a2); Fri, 3 Nov 2000 12:24:14 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: References: X-Mailer: Eudora [Macintosh version 5.1a1-12.00] Date: Fri, 3 Nov 2000 12:24:02 -0600 To: Mark Crispin From: Pete Resnick Subject: Re: moderate or restrict IMAPEXT Cc: IMAP Extensions WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 11/3/00 at 9:48 AM -0800, Mark Crispin wrote: >Please establish moderation on IMAPEXT Paul, I'm perfectly willing to do this if you have a method. If we can use IMAP mailboxes to do this (perhaps an incoming IMAP mailbox on your server that I moderate and transfer to another mailbox on your server that you send out to the list), it would be perfectly easy for me. pr -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA14247 for ietf-imapext-bks; Fri, 3 Nov 2000 11:19:49 -0800 (PST) Received: from igw8.watson.ibm.com (igw8.watson.ibm.com [198.81.209.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA14243 for ; Fri, 3 Nov 2000 11:19:47 -0800 (PST) Received: from sp1n190at0.watson.ibm.com (sp1n190at0.watson.ibm.com [9.2.104.63]) by igw8.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id OAA20376 for ; Fri, 3 Nov 2000 14:26:17 -0500 Received: from mars.trees.watson.ibm.com (mars.watson.ibm.com [9.2.40.64]) by sp1n190at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id OAA26526 for ; Fri, 3 Nov 2000 14:26:17 -0500 Date: Fri, 03 Nov 2000 14:26:16 -0500 From: Barry Leiba To: ietf-imapext@imc.org Subject: Re: comments on LIST extensions Message-ID: <2598967901.973261576@mars.trees.watson.ibm.com> In-Reply-To: X-Mailer: Mulberry/2.0.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Mark is right, we need a set of requirements that we can get concensus on. > From there we can design the thing we want. OK, then... since all the discussions about what XLIST might be have so far been ad hoc discussion among a few of us, why don't we get some time on the agenda at San Diego and have a proper discussion of it. I'll take that discussion and come up with a first pass at the requirements, and then we can discuss it further on the mailing list. If that's the way everyone wants to go, then I'll not make any updates to the LIST Extensions draft now, and the next revision will just be the first draft of the new XLIST command. Shall we do it that way? Barry Leiba, Living Lab Services (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba Received: by ns.secondary.com (8.9.3/8.9.3) id LAA13955 for ietf-imapext-bks; Fri, 3 Nov 2000 11:17:07 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (rodriguez@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA13949 for ; Fri, 3 Nov 2000 11:17:06 -0800 (PST) Date: Fri, 3 Nov 2000 10:46:54 -0800 (PST) From: Mark Crispin Subject: Re: comments on LIST extensions To: Steve Hole cc: Tony Hansen , Barry Leiba , ietf-imapext@imc.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Obviously, base LIST and LSUB have to be left alone. However, base LIST and LSUB does have an extension mechanism for attributes, so the server can utter extraneous attributes to a base client. I am not yet convinced that we can not extend LIST through upwards-compatible syntax. Shouldn't we proceed as if we can do so, with the understanding that XLIST is not out of the question if we hit an otherwise insurmountable obstacle? Unless I'm completely off-base, there are three things that need to be done: 1) Add additional attributes. Completely compatible with base spec. 2) Add additional arguments to LIST command. Must be governed by capability. 3) Add additional return values to LIST response. Must be governed by use of an extended LIST command from (2). Whether or not we also do XLIST, I think that we should do these steps to LIST. Received: by ns.secondary.com (8.9.3/8.9.3) id KAA11560 for ietf-imapext-bks; Fri, 3 Nov 2000 10:49:37 -0800 (PST) Received: from demo.esys.ca (IDENT:root@demo.esys.ca [207.167.22.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA11553 for ; Fri, 3 Nov 2000 10:49:35 -0800 (PST) Received: from kepler.esys.ca (kepler.esys.ca [198.161.92.108]) by demo.esys.ca (8.9.3 (MessagingDirect 1.0.4)/8.9.3) with ESMTP id LAA21311; Fri, 3 Nov 2000 11:42:25 -0700 From: Steve Hole Date: Fri, 3 Nov 2000 11:41:48 -0700 To: Mark Crispin Subject: Re: comments on LIST extensions Cc: Tony Hansen , Barry Leiba , ietf-imapext@imc.org In-Reply-To: References: Message-ID: X-Mailer: Execmail for Linux 5.3 b1 Build (1) -- Evaluation Copy MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 3 Nov 2000 10:12:18 -0800 (PST) Mark Crispin wrote: > Leaving aside the issue of LIST vs. XLIST, I recommend that there be a > statement or position paper about these "actual requirements." > > This is to ensure that we are all on the same wavelength. What you feel that > "we have learned" may be very different from what people here that "we have > learned." > > Having created and agreed to such a list, we should use that list in the > resulting design. We get into trouble when we don't have a fixed (and mutual) > statement of requirements. Sounds good to me. > This statement scares me. Backward compatibility is a good thing, and should > be abandoned only with a great deal of reluctance. > > The current LIST architecture definitely has problems, but those problems > happened for a reason. Ya ... it sounds worse than it was meant to. I think my point is that LIST did happen for a reason and it was successful in providing a bridge from pre-IMAP4 functionality to IMAP4. That is why I would like to leave LIST and LSUB alone. It is part of the base spec and mandatory to implement. With XLIST we have an opportunity to take the good stuff from LIST (like the basic mailbox metaphor) and create a new command that has all of that, plus all of the good stuff from the other extensions to LIST (like referrals etc.) and unify it all together. I think we can do that because everyone has to implement LIST and LSUB no matter what and we can make sure that everyone interoperates. The risk is that we try to build something that is mutually incompatible from a basic principles point of view and that makes implementation on the server (and possibly in the client) completely impractical. We just shouldn't do that. Of course, it is exactly this issue that has gotten us into trouble before -- where is the line for impractical implementation. Mark is right, we need a set of requirements that we can get concensus on. >From there we can design the thing we want. Cheers. --- Steve Hole Chief Technology Officer MessagingDirect Ltd. Phone: 780-424-4922 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA11149 for ietf-imapext-bks; Fri, 3 Nov 2000 10:40:13 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (guest@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA11141 for ; Fri, 3 Nov 2000 10:40:11 -0800 (PST) Date: Fri, 3 Nov 2000 10:34:31 -0800 (PST) From: Mark Crispin Subject: Re: comments on LIST extensions To: Barry Leiba cc: ietf-imapext@imc.org In-Reply-To: <2595573948.973258182@mars.trees.watson.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 03 Nov 2000 13:29:42 -0500, Barry Leiba wrote: > Right, but I think that what Steve means is that we should leave LIST and > LSUB alone, and that provides the backward compatibility... and then we can > make a new XLIST command that's unencumbered by those issues. That's OK as far as it goes. However, the underlying reasons for why those issues came to be can't be ignored. For example, although I understand the desire for greater client control over server behavior, nonetheless you can't forbid the server from making decisions that overrule client desires. Servers have a right (some would say obligation) to protect themselves. LIST * is the obvious example of this. A possible solution may be to expand responses so that it is clear when the server is declining to give information (or otherwise do something). Suppose, for example, there was a \Select and an \Inferiors attribute in LIST; in that case () would mean "server declines to say" rather than ambiguous between that and (\Select \Inferiors). However, this brings us to the "silly state" argument whenever we have a three way state such as this represented by binary flags; there's a fourth, silly, state. I abhor such silly states as bad architecture. Plus, sooner or later, some clown will do it, and software has to figure out what to do. So, when designing this facility, we should use mechanisms that avoid silly states. In other words, if it's a three-way state, then use a three-way protocol mechanism instead of a pair of binary mechanisms. Received: by ns.secondary.com (8.9.3/8.9.3) id KAA10432 for ietf-imapext-bks; Fri, 3 Nov 2000 10:26:14 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA10428 for ; Fri, 3 Nov 2000 10:26:13 -0800 (PST) Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [206.31.218.216]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id NAA11326; Fri, 3 Nov 2000 13:27:49 -0500 (EST) Date: Fri, 03 Nov 2000 13:28:48 -0500 From: Cyrus Daboo To: Steve Hole , Tony Hansen cc: Barry Leiba , ietf-imapext@imc.org Subject: Re: comments on LIST extensions Message-ID: <1189319.973258128@socrates.cyrusoft.com> In-Reply-To: X-Mailer: Mulberry/2.1.0d1 (MacOS-PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Friday, November 3, 2000 10:52 AM -0700 Steve Hole wrote: >> I think the charter has us, among other things, working on >> augmenting/fixing LIST. I don't think the charter constrains us to the >> form those augmentations or fixes must take. > > Exactly. Even if the charter did constrain, I would suggest cutting > LIST extension out of imapext and proceeding with an XLIST outside of > imapext. Mark is exactly right that messing with LIST and LSUB has two > major problems: > > 1. It constrains the final solution unacceptibly because we have a > learned a great deal about the actual requirements for managing mailbox > namespaces. We will be forced to tradeoffs for backward compatibility > that we don't want to make. > > 2. It will confuse new developers tremendously. The interoperability > with LIST and LSUB will get worse than it already is. I think your XLIST is really covered under the auspices of the mailbox annotations extension, which I believe we did agree to cover in the WG, once the message annotation issues were worked out. Note that mailbox annotations can encompose a lot of other extensions through unification. It would naturally include all the existing LIST flags, and include CHILDREN and RLIST. But it can go further and include STATUS, access control and quota information, in addition to arbitrary attribute-value data, thus giving a single command syntax to cover nearly all mailbox specific operations. -- Cyrus Daboo Received: by ns.secondary.com (8.9.3/8.9.3) id KAA10376 for ietf-imapext-bks; Fri, 3 Nov 2000 10:23:16 -0800 (PST) Received: from igw8.watson.ibm.com (igw8.watson.ibm.com [198.81.209.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA10372 for ; Fri, 3 Nov 2000 10:23:14 -0800 (PST) Received: from sp1n190at0.watson.ibm.com (sp1n190at0.watson.ibm.com [9.2.104.63]) by igw8.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id NAA19938 for ; Fri, 3 Nov 2000 13:29:43 -0500 Received: from mars.trees.watson.ibm.com (mars.watson.ibm.com [9.2.40.64]) by sp1n190at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id NAA46546 for ; Fri, 3 Nov 2000 13:29:43 -0500 Date: Fri, 03 Nov 2000 13:29:42 -0500 From: Barry Leiba To: ietf-imapext@imc.org Subject: Re: comments on LIST extensions Message-ID: <2595573948.973258182@mars.trees.watson.ibm.com> In-Reply-To: X-Mailer: Mulberry/2.0.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> We will be forced to tradeoffs for backward compatibility >> that we don't want to make. > > This statement scares me. Backward compatibility is a good thing, and > should be abandoned only with a great deal of reluctance. Right, but I think that what Steve means is that we should leave LIST and LSUB alone, and that provides the backward compatibility... and then we can make a new XLIST command that's unencumbered by those issues. Barry Received: by ns.secondary.com (8.9.3/8.9.3) id KAA10281 for ietf-imapext-bks; Fri, 3 Nov 2000 10:17:18 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (v92ti@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA10276 for ; Fri, 3 Nov 2000 10:17:17 -0800 (PST) Date: Fri, 3 Nov 2000 10:12:18 -0800 (PST) From: Mark Crispin Subject: Re: comments on LIST extensions To: Steve Hole cc: Tony Hansen , Barry Leiba , ietf-imapext@imc.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 3 Nov 2000 10:52:38 -0700, Steve Hole wrote: > 1. It constrains the final solution unacceptibly because we have a > learned a great deal about the actual requirements for managing mailbox > namespaces. Leaving aside the issue of LIST vs. XLIST, I recommend that there be a statement or position paper about these "actual requirements." This is to ensure that we are all on the same wavelength. What you feel that "we have learned" may be very different from what people here that "we have learned." Having created and agreed to such a list, we should use that list in the resulting design. We get into trouble when we don't have a fixed (and mutual) statement of requirements. > We will be forced to tradeoffs for backward compatibility > that we don't want to make. This statement scares me. Backward compatibility is a good thing, and should be abandoned only with a great deal of reluctance. The current LIST architecture definitely has problems, but those problems happened for a reason. Received: by ns.secondary.com (8.9.3/8.9.3) id KAA10175 for ietf-imapext-bks; Fri, 3 Nov 2000 10:13:39 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA10169 for ; Fri, 3 Nov 2000 10:13:38 -0800 (PST) Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [206.31.218.216]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id NAA11282; Fri, 3 Nov 2000 13:18:54 -0500 (EST) Date: Fri, 03 Nov 2000 13:19:53 -0500 From: Cyrus Daboo To: Mark Crispin , IMAP Extensions WG Subject: Re: moderate or restrict IMAPEXT Message-ID: <1157111.973257593@socrates.cyrusoft.com> In-Reply-To: X-Mailer: Mulberry/2.1.0d1 (MacOS-PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Friday, November 3, 2000 9:48 AM -0800 Mark Crispin wrote: > It happened again today. IMAPEXT polluted my mailbox with a spam for a > fake love potion. > > No, I do not want to hear offers for quack medicines, dirty pictures, > pyramid schemes, et nauseum. > > Please establish moderation on IMAPEXT; or at least restrict posting > privileges to list members. > > -- Mark -- > > http://staff.washington.edu/mrc > Science does not emerge from voting, party politics, or public debate. > >From what I can see the 'spam' arriving on this list has not included imapext in To, CC addresses. There were two messages in that category that were not spam, but I think its reasonable to expect posts to this list to contain the imapext address in either the To or CC headers. Thus a simple SIEVE script like the following would work as a reasonable filter for the time being: # SIEVE Script # Name: imapext spam discard # Date: Fri, 03 Nov 2000 13:18:32 -0500 # User-Agent : Mulberry 2.1.0d1 # Rule 1: imapext spam discard # Generated from GUI if not address :contains ["To", "CC"] "ietf-imapext@imc.org" { discard; } # SIEVE Script ends here -- Cyrus Daboo Received: by ns.secondary.com (8.9.3/8.9.3) id KAA09870 for ietf-imapext-bks; Fri, 3 Nov 2000 10:00:25 -0800 (PST) Received: from demo.esys.ca (IDENT:root@demo.esys.ca [207.167.22.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA09865 for ; Fri, 3 Nov 2000 10:00:23 -0800 (PST) Received: from kepler.esys.ca (kepler.esys.ca [198.161.92.108]) by demo.esys.ca (8.9.3 (MessagingDirect 1.0.4)/8.9.3) with ESMTP id KAA21191; Fri, 3 Nov 2000 10:53:14 -0700 From: Steve Hole Date: Fri, 3 Nov 2000 10:52:38 -0700 To: Tony Hansen Subject: Re: comments on LIST extensions Cc: Barry Leiba , ietf-imapext@imc.org In-Reply-To: <3A02D36E.A3A891F3@att.com> References: <3A02D36E.A3A891F3@att.com> <2578869589.973241478@mars.trees.watson.ibm.com> Message-ID: X-Mailer: Execmail for Linux 5.3 b1 Build (1) -- Evaluation Copy MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 03 Nov 2000 10:02:06 -0500 Tony Hansen wrote: > I think the charter has us, among other things, working on > augmenting/fixing LIST. I don't think the charter constrains us to the > form those augmentations or fixes must take. Exactly. Even if the charter did constrain, I would suggest cutting LIST extension out of imapext and proceeding with an XLIST outside of imapext. Mark is exactly right that messing with LIST and LSUB has two major problems: 1. It constrains the final solution unacceptibly because we have a learned a great deal about the actual requirements for managing mailbox namespaces. We will be forced to tradeoffs for backward compatibility that we don't want to make. 2. It will confuse new developers tremendously. The interoperability with LIST and LSUB will get worse than it already is. Cheers. --- Steve Hole Chief Technology Officer MessagingDirect Ltd. Phone: 780-424-4922 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA08895 for ietf-imapext-bks; Fri, 3 Nov 2000 09:41:49 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (koma@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA08891 for ; Fri, 3 Nov 2000 09:41:47 -0800 (PST) Date: Fri, 3 Nov 2000 09:48:16 -0800 (PST) From: Mark Crispin To: IMAP Extensions WG Subject: moderate or restrict IMAPEXT Message-ID: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It happened again today. IMAPEXT polluted my mailbox with a spam for a fake love potion. No, I do not want to hear offers for quack medicines, dirty pictures, pyramid schemes, et nauseum. Please establish moderation on IMAPEXT; or at least restrict posting privileges to list members. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: by ns.secondary.com (8.9.3/8.9.3) id HAA29830 for ietf-imapext-bks; Fri, 3 Nov 2000 07:00:36 -0800 (PST) Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA29823 for ; Fri, 3 Nov 2000 07:00:34 -0800 (PST) Received: from dns.maillennium.att.com ([135.25.114.99]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.3) with ESMTP id KAA02306 for ; Fri, 3 Nov 2000 10:06:33 -0500 (EST) Received: from att.com ([135.197.86.244]) by maillennium.att.com (labmail) with SMTP id <20001103150631099005qh39e> (Authid: tony@maillennium.att.com); Fri, 3 Nov 2000 15:06:32 +0000 Message-ID: <3A02D36E.A3A891F3@att.com> Date: Fri, 03 Nov 2000 10:02:06 -0500 From: Tony Hansen Organization: AT&T Laboratories X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Barry Leiba CC: ietf-imapext@imc.org Subject: Re: comments on LIST extensions References: <2578869589.973241478@mars.trees.watson.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think the charter has us, among other things, working on augmenting/fixing LIST. I don't think the charter constrains us to the form those augmentations or fixes must take. Tony Barry Leiba wrote: > > > Actually Barry, while I applaud the extensible LIST argument attempt, what > > I am most interested in is an entirely new, all consuming LIST command. > > Call it XLIST for the purpose of discussion. > > Yes, we've talked about this, and I agree, and I want to work on that. It > was my understanding, though, that doing that was beyond the scope of the > IMAPExt WG, and that the LIST extensions that the WG decided to work on > were of the sort described in this draft. Pete R., can you clarify? I'll > be happy to shift this draft toward a complete revision of the LIST > command, if the WG considers it to be within its scope. Otherwise I'll > continue with this as the interim answer, and work on the "XLIST" (or > whatever) afterward. Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA24692 for ietf-imapext-bks; Fri, 3 Nov 2000 06:03:06 -0800 (PST) Received: from igw8.watson.ibm.com (igw8.watson.ibm.com [198.81.209.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA24688 for ; Fri, 3 Nov 2000 06:03:04 -0800 (PST) Received: from sp1n190at0.watson.ibm.com (sp1n190at0.watson.ibm.com [9.2.104.63]) by igw8.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id JAA09662 for ; Fri, 3 Nov 2000 09:09:32 -0500 Received: from mars.trees.watson.ibm.com (mars.watson.ibm.com [9.2.40.64]) by sp1n190at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id JAA31058 for ; Fri, 3 Nov 2000 09:09:31 -0500 Date: Fri, 03 Nov 2000 09:09:31 -0500 From: Barry Leiba To: ietf-imapext@imc.org Subject: Re: comments on LIST extensions Message-ID: <2579962729.973242571@mars.trees.watson.ibm.com> In-Reply-To: X-Mailer: Mulberry/2.0.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Remember, subscriptions were defined specifically to support a > pre-existing functionality, and that this functionality is in use. > Compatibility with this functionality must be retained. > > If I understand your proposal correctly, you're doing this. Yes, by keeping LSUB as is and recommending its continued use. >> 2. Maybe add wording to clarify that flags returned by LSUB may not be >> accurate. This should probably be in the base spec, actually. > > It isn't that the flags are inaccurate; they are different. For example, > \NoSelect means something different in LSUB. The list of flags may also not include flags that would be included in a LIST. I don't mean to say that flags would appear spuriously, so it's probably more accurate to say that "the flags returned by LSUB may be incomplete, and some may have different meanings." The point is that a client can't know whether "()" means there are no flags set or that this server can't return the list of flags in LSUB. In fact, there's nothing stopping a server from returning, say, "(\Marked)" in response to LSUB and "(\Marked \NoInferiors)" in response to LIST (or some other similar example). > I'll be happy to consider suggested changes to the base spec wording for > this. Please review what's in the current draft, not RFC 2060. I'll do that and post something separately about it; thanks. > OK, so by omitting LIST-SUBSCRIBED, I can implement the other options > (and use them), correct? > > Put another way, there is no requirement to implement LIST-SUBSCRIBED in > order to implement any other piece of this technology, correct? Exactly; that's the intent here. I'm recommending that you implement LIST-SUBSCRIBED, because clients can and will get that information anyway if they really want it, at greater cost... but its implementation is entirely optional. > "\NonExistant" => "\NonExistent" Glrf. Thanks. I hate when I misspel things. :-) >> 6. Add a new mailbox flag, "\PlaceHolder" (alternative name?), intended >> to indicate, when necessary, that "this mailbox does not meet your >> selection criteria, but it has a child that might (or, stronger, does?)". > > How will this work with LSUB, given the need to maintain compatibility? I > suggest that it be allowed in LSUB, but *with* the overloaded \NoSelect, > e.g. * LSUB (\NoSelect \PlaceHolder) "/" foo > to make it unambiguous that the \NoSelect is the overloaded form. Yes, that was also the intent, and I didn't mention that. To be general: LSUB MUST behave as it always has, but MAY also include the new flags. Clients MAY use the new flags for the information they convey, but MUST NOT assume that their absence means anything. Side issue here: if a client sees "\NonExistent" or "\PlaceHolder" in one LSUB response line, can it now assume that their absence in other response lines is meaningful? Maybe it's best not to address this. > I think that we should do it. I've been convinced that we should have > another value in the LIST response, containing a parenthesized list of > property/value pairs. > * LIST () "/" foo (REFERRAL "..." BLOOP soop) > > The purpose of the parentheses is to enable to addition of another value > in the response in the future if it turns out that attribute or > property/value aren't enough. Absolutely, on the parentheses; I think it's valuable to group things that way for extensibility. OK, since everyone who's chimed in agrees that the referral data should be presented(*), I'll work that in. Should that go in this spec, or into a revision of the MAILBOX-REFERRALS spec? (*) The only concern I have here is that a referral-capable server might know quickly that a mailbox is remote, but might have a slower time actually retrieving the referral information. So there *might* be some use in letting the server tell you "this mailbox exists somewhere else", but not actually tell you *where* until you try to do something with it (if, for example, there are 50 remote mailboxes and it takes 1 second to retrieve the referral data for each, adding 50 seconds to the LIST (REFERRALS) command would be bad, and it might be better to make you try a SELECT when you actually want to use one of them). Do any servers besides Exchange support mailbox referrals now? How fast is it for Exchange (or other servers) to retrieve the referral details? Barry Leiba, Living Lab Services (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba Received: by ns.secondary.com (8.9.3/8.9.3) id FAA23708 for ietf-imapext-bks; Fri, 3 Nov 2000 05:44:52 -0800 (PST) Received: from igw8.watson.ibm.com (igw8.watson.ibm.com [198.81.209.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA23704 for ; Fri, 3 Nov 2000 05:44:51 -0800 (PST) Received: from sp1n190at0.watson.ibm.com (sp1n190at0.watson.ibm.com [9.2.104.63]) by igw8.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id IAA09552 for ; Fri, 3 Nov 2000 08:51:19 -0500 Received: from mars.trees.watson.ibm.com (mars.watson.ibm.com [9.2.40.64]) by sp1n190at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id IAA30302 for ; Fri, 3 Nov 2000 08:51:18 -0500 Date: Fri, 03 Nov 2000 08:51:18 -0500 From: Barry Leiba To: ietf-imapext@imc.org Subject: Re: comments on LIST extensions Message-ID: <2578869589.973241478@mars.trees.watson.ibm.com> In-Reply-To: X-Mailer: Mulberry/2.0.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Actually Barry, while I applaud the extensible LIST argument attempt, what > I am most interested in is an entirely new, all consuming LIST command. > Call it XLIST for the purpose of discussion. Yes, we've talked about this, and I agree, and I want to work on that. It was my understanding, though, that doing that was beyond the scope of the IMAPExt WG, and that the LIST extensions that the WG decided to work on were of the sort described in this draft. Pete R., can you clarify? I'll be happy to shift this draft toward a complete revision of the LIST command, if the WG considers it to be within its scope. Otherwise I'll continue with this as the interim answer, and work on the "XLIST" (or whatever) afterward. > 1. I would like to see the orginal extension framework draft revived, > Included the restriction on applicable command set if people still feel > it is necessary. I agree, and I think that I asked for comments on this resurrection a while ago and got insufficient support, considering the objections from Mark and Chris. If there's enough support for it to try to get past their objections, I'm certainly eager to pursue it, and I think Cyrus is too. I'd rather discuss it here, unless Pete objects, rather than on the IMAP list, but I think it's outside the scope of the IMAPExt WG. Barry Leiba, Living Lab Services (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA18426 for ietf-imapext-bks; Fri, 3 Nov 2000 03:59:13 -0800 (PST) Received: from dns.wsbx.com ([202.99.11.67]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA18417 for ; Fri, 3 Nov 2000 03:59:09 -0800 (PST) Date: Fri, 3 Nov 2000 03:59:09 -0800 (PST) From: hv@of-hachetal.de Message-Id: <200011031159.DAA18417@ns.secondary.com> Received: from h809 (1cust188.tnt3.mia5.da.uu.net [63.30.200.188]) by dns.wsbx.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id V8F2G3HT; Fri, 3 Nov 2000 20:08:30 +0800 To: hv@of-hachetal.de Subject: At last, Herbal V, the all natural alternative to V----A! Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Herbal V: An Incredible All-Natural Healthy Alternative Herbal V is the All Natural Approach to Male Virility, Vitality and Pleasure. Available N o w ! Welcome to the New Sexual Revolution. It's the all natural male potency and pleasure pill that men everywhere are buzzing about. Herbal V is safe, natural and specifically formulated to help support male sexual function and pleasure. You just take two easy-to-swallow tablets one hour before sex. And there's more great news - you can get Herbal V for less than $1 a pill. Amazing word of mouth praise on Herbal V has been spreading like wildfire-already over 1,500,000 men have chosen Herbal V. Since it is 100% natural you will never have to worry about safety. Try doctor-recommended Herbal V today and have the greatest night of your life! Herbal V... Bringing Back the Magic! 1,585,000 men can't be wrong. To date over 1 million men have tried the super supplement Herbal V. Here is why: No Doctor Visit Required Available Over the Counter Not a Drug 100% Natural Safe, No Worries Highest Quality Pharmaceutical-Grade Pure Nutriceuticals Guaranteed Potency & Purity Be a Real Man Again! Questions and Answers What is Herbal V? Herbal V is a proprietary blend that was specifically developed as a safe alternative for men who prefer an all-natural approach to address impotence and boost sexual performance. This amazing formula first became popular with Hollywood insiders and the wealthy elite. They were maximizing their sex lives, long before it was available to the general public. How does Herbal V work? Developed by a team whose goal was to create the perfect all-natural aphrodisiac. Herbal V is the result of that remarkable effort. The Herbal V formula contains a precise blend of cutting edge pro-sexual nutrients from around the world that provide nutritional support, making it possible for a man to have a pleasurable sexual experience. What can Herbal V do for me? Herbal V helps support male sexual function and pleasure in a safe and natural manner. Simply put, it can make your sex life incredible. Is Herbal V Safe? One of the great things about Herbal V is that it is not a drug. It is an incredible herbal dietary supplement that provides nutritional support for male sexual function and pleasure. One of the most comforting features of Herbal V is that you never have to worry about safety. Herbal V: Safe - Natural - Exciting Many have speculated that because Herbal V is so popular with men, it must contain prescription drugs or chemical components. Herbal V does not contain any elements or traces of any prescription drug. Herbal V is made using the world's most technologically advanced state-of-the-art cold processing equipment to ensure maximum purity. Herbal V has been independently analyzed by the nation's premier testing facility to ensure purity, quality and to end the rumors that, because it is so popular, it must somehow be chemical. It is not. Herbal V is natural - just as it says on the label. Herbal V is simply fantastic! Herbal V: Ingredients Yohimbe, saw palmetto, avena sativa, androstenedione, guarana, taurine, siberian ginseng, tribulus terrestris. Tribulus Terrestis is certified to enhanced testosterone levels by increasing Luteinzing hormone (LH) levels. Androstenedione which is a precursor to testosterone unlocks bound testosterone and makes it biologically active again quickly. This means a dramatic surge in desire. Avena Sativa Stimulates the neurotransmitter pleasure centers to maximum capacity. This greatly intensifies pleasure. Just listen to what Herbal V has done for the sex lives of people like you! “On a scale of 1 to 10, it's a 15. Electrifying. It's like a wonder pill!” — Justin Q B., New Haven, Texas “I haven't had sexual relations in 11 years. Then with Herbal V it was... wow! It works again!” — Sid R., Lakeland, Florida “I had sex four times in one night. It made me feel like a 19-year-old again.” — Chip S, Beech Mountain, North Carolina “Herbal V has turned my husband into a Sexual Superman! I like the fact that it's all natural and has no side effects. It's bringing back the good old days.” — Jennifer B, Beverly Hills, California The above testimonials are from product literature, and we have not independently verified them. However, the following testimonial is from a "senior" gentleman who has purchased his second bottle of Herbal V. When we heard his words with our own ears, we asked his permission to print them here. “Man! I'm wild as I can be! I feel like I'm 25 years old again! I'm not believing this!” — Mr. Murphy, age 64, Lampart, IL. Risk Free: Double Your Money Back Guarantee If Herbal V does not give the desired results as stated above, simply return the unused portion for a double-your money back refund. No questions asked ! Order Now: Safe, Fast, Secure, Private Herbal V with its DOUBLE YOUR MONEY BACK GUARANTEE is available only through this special promotional offer. Herbal V arrives in plain packaging for your privacy. Any and all information is kept strictly confidential. Payment Methods You may FAX or Postal Mail Checks, MasterCard, Visa, & American Express.payments. Money Orders are accepted only by Postal Mail. Each bottle of Herbal V contains 30 tablets, approximately a 1 month supply. Step 1: Place a check by your desired quanity. ______ 1 Bottle of Herbal V $28 ______ 2 Bottles of Herbal V $48 ______ 3 Bottles of Herbal V $59 Please add $6 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$34, 2 bottles=$54, 3 bottles=$65 ] International Orders Please add $16 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$40, 2 bottles=$60, 3 bottles=$75 ] We cannot accept foreign checks. International money orders or credit cards only. Step 2: Place a check by your desired payment method and complete fields if necessary. _____Check or CHECK-BY-FAX [details below] _____Money Order _____American Express Account Number__________________ Exp____/____ _____Visa Account Number__________________ Exp____/____ _____MasterCard Account Number__________________ Exp____/____ Please make your check or money order payable to "Lion Sciences National". Step 3: Please complete and print the following fields clearly. Name ___________________________________________________ Address _________________________________________________ City ____________________________________________________ State ___________________________________________________ Zip _____________________________________________________ E-mail __________________________________________________ Signature _________________________________________________ [ required for check and credit card orders] Toll Free FAX Order Line: 1-800-940-6590 If faxing in your order, please state whether you require a fax, email, or no confirmation at all. Allow up to one day for confirmation, if requested. FAX orders are processed immediately. Or, print & mail to: LSN 3502 N. Powerline Rd. #525 Pompano Beach, FL 33069 ______________________________________________________ *CHECK BY FAX ORDERS: Complete the check as normal. Tape the check in the area below. Below the check, clearly write the check number, all numbers at the bottom of the check, & your name. Tape the check below and fax the check to the toll free FAX number above. Void the check. Our merchant will electronically debit your account for the amount of the check; your reference number for this transaction will be your check number. Nothing could be safer & easier ! TAPE CHECK BELOW _____________________________________________________________ This is a one time mailing: Removal is automatic and no further contact is necessary. Please Note: Herbal V is not intended to diagnose, treat, cure or prevent any disease. As individuals differ, so will results. Herbal V helps provide herbal and nutritional support for male sexual performance. The FDA has not evaluated these statements. For details about our double your money back guarantee, please write to the above address, attention consumer affairs department; enclose a self addressed stamped envelope for this and any requested contact information. Thank You. Received: by ns.secondary.com (8.9.3/8.9.3) id NAA13079 for ietf-imapext-bks; Thu, 2 Nov 2000 13:54:00 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13075 for ; Thu, 2 Nov 2000 13:53:59 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 2 Nov 2000 13:56:34 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 02 Nov 2000 13:57:10 -0800 (Pacific Standard Time) Received: from mikega10 ([157.59.252.141]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 2 Nov 2000 13:57:10 -0800 Message-ID: <000901c04517$e6f564a0$8dfc3b9d@redmond.corp.microsoft.com> From: "Mike Gahrns" To: "Barry Leiba" , References: <2513123103.973175731@mars.trees.watson.ibm.com> Subject: Re: comments on LIST extensions Date: Thu, 2 Nov 2000 13:57:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-OriginalArrivalTime: 02 Nov 2000 21:57:10.0043 (UTC) FILETIME=[D9684EB0:01C04517] Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Barry Leiba writes: > We also have to do something with the REMOTE (or REFERRALS) option. I > agree with those who think that we should add referral information to the > LIST response, but I'd really like to hear from Mike Gahrns or Raymond > Cheng about it. Yes, including referral information in a "general LIST response type extension" is a good idea, and something that many of us discussed at various events like the IMC interops and IETF meetings. Assuming we went with the approach Steve Hole suggested with a new command like XLIST (insted of a general LIST response extension) this type of mechanism could simplify referrals in removing the need for the RLIST command. Recall, RLIST was added to referrals since in general one would not want a non-referral enabled client displaying remote mailboxes that would not be accessible to a user. If a mailbox was flagged as \remote (or whatever was agreed upon), it would need to be explicitly stated in the XLIST extension that the mailbox should not be displayed to the user unless the client was a referral enabled client. Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA13073 for ietf-imapext-bks; Thu, 2 Nov 2000 13:53:53 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (bruce@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13069 for ; Thu, 2 Nov 2000 13:53:51 -0800 (PST) Date: Thu, 2 Nov 2000 13:37:33 -0800 (PST) From: Mark Crispin Subject: Re: comments on LIST extensions To: Barry Leiba cc: ietf-imapext@imc.org In-Reply-To: <2513123103.973175731@mars.trees.watson.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Barry - I think that your latest message on this topic is good, and we can move forward with it. I figured that I should get *that* data point said before going into the long response. On Thu, 02 Nov 2000 14:35:31 -0500, Barry Leiba wrote: > It seems that Mark's got the main complaint, and that complaint involves > the interaction between subscriptions and other options. Specifically, in > Mark's model of how subscriptions work, it doesn't generally make sense to > combine SUBSCRIBED with other options. Remember, subscriptions were defined specifically to support a pre-existing functionality, and that this functionality is in use. Compatibility with this functionality must be retained. If I understand your proposal correctly, you're doing this. > That said, many servers *do* implement "subscribed to" as a mailbox > attribute, and in those servers it *does* make sense to have SUBSCRIBED be > an option, and to allow its combination with other options. I agree that it is alright as an option that does not break or otherwise restrict existing software. This implies that it should be permissible to implement other options without implementing this one. > 1. Change wording so it doesn't suggest deprecating LSUB. Add wording to > indicate that LSUB will remain *unchanged*, and that clients that don't > need more function than is provided by LSUB should continue to use LSUB. OK > 2. Maybe add wording to clarify that flags returned by LSUB may not be > accurate. This should probably be in the base spec, actually. It isn't that the flags are inaccurate; they are different. For example, \NoSelect means something different in LSUB. I'll be happy to consider suggested changes to the base spec wording for this. Please review what's in the current draft, not RFC 2060. > 3. The LISTEXT capability will announce support for the general method of > specifying LIST options and for the CHILDREN option. OK. > 4. The LIST-SUBSCRIBED capability will announce support for the SUBSCRIBED > option. OK, so by omitting LIST-SUBSCRIBED, I can implement the other options (and use them), correct? Put another way, there is no requirement to implement LIST-SUBSCRIBED in order to implement any other piece of this technology, correct? If the answer to both of these is "yes", you may consider my objections as having been satisfied and consequently are dropped. > Note that this means (and I will make it clear) that "LSUB" and "LIST > (SUBSCRIBED)" are *not* the same, and that clients that do not need the > extra function provided by the latter SHOULD NOT use it. OK > 5. Add a new mailbox flag, "\NonExistant", intended to be applied to a > mailbox that's subscribed to but that doesn't actually exist. "\NonExistant" => "\NonExistent" > 6. Add a new mailbox flag, "\PlaceHolder" (alternative name?), intended to > indicate, when necessary, that "this mailbox does not meet your selection > criteria, but it has a child that might (or, stronger, does?)". How will this work with LSUB, given the need to maintain compatibility? I suggest that it be allowed in LSUB, but *with* the overloaded \NoSelect, e.g. * LSUB (\NoSelect \PlaceHolder) "/" foo to make it unambiguous that the \NoSelect is the overloaded form. LIST-SUBSCRIBED, on the other hand, won't have \NoSelect. > We also have to do something with the REMOTE (or REFERRALS) option. I > agree with those who think that we should add referral information to the > LIST response, but I'd really like to hear from Mike Gahrns or Raymond > Cheng about it. I think that we should do it. I've been convinced that we should have another value in the LIST response, containing a parenthesized list of property/value pairs. * LIST () "/" foo (REFERRAL "..." BLOOP soop) The purpose of the parentheses is to enable to addition of another value in the response in the future if it turns out that attribute or property/value aren't enough. Received: by ns.secondary.com (8.9.3/8.9.3) id NAA11900 for ietf-imapext-bks; Thu, 2 Nov 2000 13:09:18 -0800 (PST) Received: from demo.esys.ca (IDENT:root@demo.esys.ca [207.167.22.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA11896 for ; Thu, 2 Nov 2000 13:09:17 -0800 (PST) Received: from kepler.esys.ca (kepler.esys.ca [198.161.92.108]) by demo.esys.ca (8.9.3 (MessagingDirect 1.0.4)/8.9.3) with ESMTP id OAA19993; Thu, 2 Nov 2000 14:01:56 -0700 From: Steve Hole Date: Thu, 2 Nov 2000 14:01:20 -0700 To: Barry Leiba Subject: Re: comments on LIST extensions Cc: ietf-imapext@imc.org In-Reply-To: <2513123103.973175731@mars.trees.watson.ibm.com> References: <2513123103.973175731@mars.trees.watson.ibm.com> <39E685D1.15CEB9A0@messagingdirect.com> Message-ID: X-Mailer: Execmail for Linux 5.3 b1 Build (1) -- Evaluation Copy MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Actually Barry, while I applaud the extensible LIST argument attempt, what I am most interested in is an entirely new, all consuming LIST command. Call it XLIST for the purpose of discussion. All of the things that you put in your message, modulo the bits that define interaction between LIST and LSUB, would go into the XLIST extension command. In XLIST, mailboxes can express a number of different attributes, including user/application defined ones (annotations) and they can all be searched/retrieved using the XLIST and related commands. Great. People will either implement or not in the true spirit of the IMAP world -- if it is useful lots of people will do it. Leave LIST and LSUB alone. Their semantics are defined and implemented in a number of products, and messing with them is just going to cause confusion. It will certainly cause lots of disagreement -- as it already has. ... I also think that your original draft that provided a general IMAP command argument extension framework was a damned good idea. Certainly, the new XLIST command could employ it straight off. Some people didn't like the possibility of command extension for the commands available in the non-authenticated state. Fine. Stipulate that that set of commands cannot be extended in this way. Otherwise, if you want to extend the arguments for a base command, this is the way to do it. Personally, I don't understand what the issue is for the commands available in the non-authenticated state. And yes, I have heard the arguments -- please don't send them again. I just don't agree with them. In my opinion, they are not sound arguments and the examples provided are very much contrived. ... To summarize: 1. I would like to see the orginal extension framework draft revived, Included the restriction on applicable command set if people still feel it is necessary. 2. I would like to see a draft for a brand new command that can be used as an alternative to the existing LIST and LSUB commands that has the unified semantics of the various LIST extensions, plus an explicit extension mechanism for folder metadata. Cheers. --- Steve Hole Chief Technology Officer MessagingDirect Ltd. Phone: 780-424-4922 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA07108 for ietf-imapext-bks; Thu, 2 Nov 2000 11:29:10 -0800 (PST) Received: from igw8.watson.ibm.com (igw8.watson.ibm.com [198.81.209.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA07101 for ; Thu, 2 Nov 2000 11:29:08 -0800 (PST) Received: from sp1n190at0.watson.ibm.com (sp1n190at0.watson.ibm.com [9.2.104.63]) by igw8.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id OAA11286 for ; Thu, 2 Nov 2000 14:35:33 -0500 Received: from mars.trees.watson.ibm.com (mars.watson.ibm.com [9.2.40.64]) by sp1n190at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id OAA36402 for ; Thu, 2 Nov 2000 14:35:32 -0500 Date: Thu, 02 Nov 2000 14:35:31 -0500 From: Barry Leiba To: ietf-imapext@imc.org Subject: Re: comments on LIST extensions Message-ID: <2513123103.973175731@mars.trees.watson.ibm.com> In-Reply-To: <39E685D1.15CEB9A0@messagingdirect.com> X-Mailer: Mulberry/2.0.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: OK, it seems that the discussion has settled down -- nothing for a couple of weeks -- so I'll do a little summary and a proposal. It seems that Mark's got the main complaint, and that complaint involves the interaction between subscriptions and other options. Specifically, in Mark's model of how subscriptions work, it doesn't generally make sense to combine SUBSCRIBED with other options. Further, the idea that SUBSCRIBED is an option on the LIST command implies that "being subscribed to" is an attribute of a mailbox, and that wasn't Mark's intent. He strongly wants to keep the LSUB command separate, and that's partly to make it clear that the list of subscriptions is a completely separate list. That said, many servers *do* implement "subscribed to" as a mailbox attribute, and in those servers it *does* make sense to have SUBSCRIBED be an option, and to allow its combination with other options. Further, a client that wants to have an accurate list of mailbox flags on subscribed mailboxes (for instance) *will* get that information, and as it stands it has to do it by combinations of LSUB and multiple LIST commands. OK, so here's what I propose as a change to the current LIST extensions draft: 1. Change wording so it doesn't suggest deprecating LSUB. Add wording to indicate that LSUB will remain *unchanged*, and that clients that don't need more function than is provided by LSUB should continue to use LSUB. 2. Maybe add wording to clarify that flags returned by LSUB may not be accurate. This should probably be in the base spec, actually. 3. The LISTEXT capability will announce support for the general method of specifying LIST options and for the CHILDREN option. 4. The LIST-SUBSCRIBED capability will announce support for the SUBSCRIBED option. This option may be combined with other options, guarantees accurate flags, and so forth (I'll put in appropriate wording). Note that this means (and I will make it clear) that "LSUB" and "LIST (SUBSCRIBED)" are *not* the same, and that clients that do not need the extra function provided by the latter SHOULD NOT use it. Servers, such as Mark's, which have to do extra work to, for example, get accurate flags for subscribed mailboxes, MUST do so if they implement LIST-SUBSCRIBED. I think such servers would do well to do so, since, as noted above, a client that wants the information will get it anyway, and at greater cost to both client and server. 5. Add a new mailbox flag, "\NonExistant", intended to be applied to a mailbox that's subscribed to but that doesn't actually exist. This will distingush between * LIST () "/" "Banana" and * LIST (\NonExistant) "/" "Banana" The LSUB command MAY use the \NonExistant flag as a hint, but the "LIST (SUBSCRIBED)" MUST use it. 6. Add a new mailbox flag, "\PlaceHolder" (alternative name?), intended to indicate, when necessary, that "this mailbox does not meet your selection criteria, but it has a child that might (or, stronger, does?)". This will eliminate the overloading of \NoSelect for this purpose, which, once we implement the SUBSCRIBED option, has to be done. Example: A1 LIST (SUBSCRIBED CHILDREN) "" "%" * LIST (\NoInferiors) "/" "inbox" * LIST (\NoSelect \HasChildren) "/" "xyz" * LIST (\NonExistant) "/" "abc" * LIST (\PlaceHolder \HasChildren) "/" "def" * LIST (\HasChildren) "/" "ghi" A1 OK done A2 LIST (SUBSCRIBED CHILDREN) "" "%/%" * LIST (\HasChildren) "/" "def/xxx" * LIST (\HasNoChildren) "/" "ghi/yyy" * LIST (\HasNoChildren) "/" "ghi/zzz" A2 OK done Here, note that "inbox" and "abc" do not have CHILDREN flags, because the \NoInferiors and \NonExistant flags make them unnecessary. Mailbox "xyz" is subscribed to, but is not selectable; it has children, and, as it turns out, none of those children are subscribed to. "abc" is subscribed to, but doesn't actually exist. "def" is not subscribed to, but it has children that are. "ghi" is subscribed to and has children; we don't know whether any of its children are subscribed to -- the second LIST shows us that they are. Does this all make sense? Mark, does it satisfy your concerns? Others, does it meet your needs too? We also have to do something with the REMOTE (or REFERRALS) option. I agree with those who think that we should add referral information to the LIST response, but I'd really like to hear from Mike Gahrns or Raymond Cheng about it. Barry Leiba, Living Lab Services (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba