From barryleiba@gmail.com Tue Jul 7 06:45:28 2009 Return-Path: X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFC163A689B for ; Tue, 7 Jul 2009 06:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwfM0qh3RwBN for ; Tue, 7 Jul 2009 06:45:27 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 631803A6899 for ; Tue, 7 Jul 2009 06:45:27 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so1052418eye.65 for ; Tue, 07 Jul 2009 06:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=o7lzBh9a2epitwLd25yzVMovrycBqjn0eM/wk9tYQKw=; b=CX+6ABzGvtmxAfJkpzIKof8qJre5dXaUnfT9gQ9VF0TV+z4KFl0J3gTXy3LHTnDRJF LHKXR2T2FfkxpECqZ3+z8c1qp5P/SPpDOn20pQ/sfZR99usIDazqGkWvXMIf8Da3fIaX Hf7s0cFRHOD7FlBTnMuVpomqwhCsPGhD+JJL0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=pCRnCqYYMBHiYJj7obhGtxAxStRxwluN24QKhbXR+fAmenHFlwlWkOQKwEpHBwSVRe TSjFEatk2mg49+saf1HL9IXmOqZ5ff5nFFxk5XevPnhMrSH1pWU2VvMBO3m80Ksumv7l eo1MRIgRRFMe57vcxMFqD1Xoi2WwJL8RbWTTA= MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.210.61.8 with SMTP id j8mr2174844eba.16.1246974302266; Tue, 07 Jul 2009 06:45:02 -0700 (PDT) In-Reply-To: <9abf48a60907061213v6692c3f2lc5e6f134aca66d25@mail.gmail.com> References: <9abf48a60907061213v6692c3f2lc5e6f134aca66d25@mail.gmail.com> Date: Tue, 7 Jul 2009 09:45:02 -0400 X-Google-Sender-Auth: cbe63685315c2c70 Message-ID: <9abf48a60907070645uc59a7f3kf48c3bf7ab87f5bb@mail.gmail.com> From: Barry Leiba To: morg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [MORG] New I-D proposing a "message recall" protocol X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 13:45:28 -0000 [I posted this yesterday, but the mailing list wasn't accepting posts from this address. Posting again; please excuse me if it winds up showing up twice.] The subject of "message recall" (the "Damn! I got the date wrong," or "I really shouldn't have said that to my boss," feature) has once again come up -- those who've been around for a while know how often the subject is raised. This time, I've spent some time writing up a proposal, got some feedback from Ned and Nathaniel, and the result is now in an I-D (see below). I've taken the liberty of suggesting that it might be discussed on the morg mailing list (hey, we need some activity here, right?), in the hope that the WG might decide to adopt it as a WG document. It vaguely relates to the idea of organizing messages, if you stretch the thought a bit. And I think this idea is one that will have to be done in a WG, not as an individual submission. So, this message is a request for three things: 1. To all of you, please review the proposal and comment on it. (If you reply to this message, please reply only to the mailing list.) 2. To the chairs, Timo and Randy, I'm asking for a bit of time on the Stockholm agenda to discuss it, if you can spare the time. 3. To the ADs, Alexey and Lisa, I'm asking for a few minutes on the Apparea agenda on Monday, to introduce the idea. How much discussion you want to have there is up to you... if the Apparea meeting is a little shy of topics, this can suck up some spare time. :-) Thanks, all. Barry -- Barry Leiba (barryleiba@computer.org) http://internetmessagingtechnology.org/ ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: Mon, Jul 6, 2009 at 2:37 PM Subject: New Version Notification for draft-leiba-morg-message-recall-00 To: barryleiba@computer.org A new version of I-D, draft-leiba-morg-message-recall-00.txt has been successfuly submitted by Barry Leiba and posted to the IETF repository. Filename: draft-leiba-morg-message-recall Revision: 00 Title: SMTP Service Extension for Message Recall Creation_date: 2009-07-06 WG ID: Independent Submission Number_of_pages: 17 Abstract: End users occasionally send email messages that they later want to recall, perhaps because they sent incorrect information, or had second thoughts about what they said in the message. Proprietary email systems often provide such a recall function. This document specifies a standard mechanism for providing it with Internet email. Note A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested, and should be sent to morg@ietf.org. The IETF Secretariat. From root@core3.amsl.com Tue Jul 7 09:15:04 2009 Return-Path: X-Original-To: morg@ietf.org Delivered-To: morg@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 279903A6EA3; Tue, 7 Jul 2009 09:15:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090707161503.279903A6EA3@core3.amsl.com> Date: Tue, 7 Jul 2009 09:15:02 -0700 (PDT) Cc: morg@ietf.org Subject: [MORG] I-D Action:draft-ietf-morg-multimailbox-search-01.txt X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 16:15:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Message Organization Working Group of the IETF. Title : IMAP4 Multimailbox SEARCH Extension Author(s) : B. Leiba, A. Melnikov Filename : draft-ietf-morg-multimailbox-search-01.txt Pages : 8 Date : 2009-07-07 The IMAP4 specification allows the searching only of the selected mailbox. A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT and SEARCH commands, waiting for each to complete before moving on to the next. This extension allows a client to search multiple mailboxes with one command, limiting the round-trips and waiting for various searches to complete, and not requiring disruption of the currently selected mailbox. This also uses MAILBOX and TAG fields in ESEARCH responses, allowing a client to pipeline the searches if it chooses. Note A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested, and should be sent to morg@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-morg-multimailbox-search-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-morg-multimailbox-search-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-07090059.I-D@ietf.org> --NextPart-- From barryleiba.mailing.lists@gmail.com Tue Jul 7 11:03:42 2009 Return-Path: X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEFA03A6EC8 for ; Tue, 7 Jul 2009 11:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mto6C4muQKXN for ; Tue, 7 Jul 2009 11:03:42 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 90D0A3A6EC5 for ; Tue, 7 Jul 2009 11:03:41 -0700 (PDT) Received: by fxm18 with SMTP id 18so5100483fxm.37 for ; Tue, 07 Jul 2009 11:03:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=RJUoxvOg5kpgls/B7aqvb1jKT83DebronH0SRuhXjt8=; b=s55WILN9JVbUqsnyb6455oJFIZI43IYyY4e2hP9o/pJRSt6X/PMauJYP41bqRCB/Bv fn045BenuTM7G/Ln7YippzFs2vu6lrGG2E8eTMWRa3xhewdYQd6nKJsfp4K1/Zlb94dh rTHDFlUatqLLiw6Mpc4uqiuFGfQdBJOCdl4xw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=mFioFWLwOE0hsB+S6SL3UX5xWKJw8UVx90BQwGBuHD58Er3a4MFSUkE50INHcTlOp9 AphQAeMVnsvZCYyI9UMRWCrRB91TvX1CEZ2VaUKqg3a58PCNAvLaEMN7oZQGuW++lEMC 8YBcDVsI1cPd1e+ss+mz4kZxwMbePrauMWMfQ= MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.239.149.195 with SMTP id k3mr518676hbb.108.1246989833424; Tue, 07 Jul 2009 11:03:53 -0700 (PDT) In-Reply-To: <20090707161503.279903A6EA3@core3.amsl.com> References: <20090707161503.279903A6EA3@core3.amsl.com> Date: Tue, 7 Jul 2009 14:03:53 -0400 X-Google-Sender-Auth: c5656cd1b8ea7567 Message-ID: <6c9fcc2a0907071103k1a129a14i4b86365442c4a7fd@mail.gmail.com> From: Barry Leiba To: morg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [MORG] I-D Action:draft-ietf-morg-multimailbox-search-01.txt X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 18:03:43 -0000 This version switches to the NOTIFY mailbox specification syntax, as we decided at IETF 74, and it cleans up the ABNF and some other wording. Apart from having to write up the Security Considerations section properly, I think it's done, but for one issue. So I'd like folks to review it and see if it's what we want. The one issue: As noted in the sketched-out Security Considerations section, at IETF 74 we had a discussion about possible using metadata to refine the list of mailboxes. Do we want to do that? If so, we can do it by adding a scope-option, but I'd like someone to take a stab at some text for how it should go. I'm thinking maybe we'd want "include" and "exclude" scope options, which can refine the list that results from the NOTIFY selectors. And one of the things the parameters to those options can specify is metadata matching. Would there be anything else? Comments? -- Barry On Tue, Jul 7, 2009 at 12:15 PM, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Message Organization Working Group of th= e IETF. > > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : IMAP4 Multimailbox SEARCH Exte= nsion > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : B. Leiba, A. Melnikov > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-morg-multimailbox-sea= rch-01.txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 8 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2009-07-07 > > The IMAP4 specification allows the searching only of the selected > mailbox. =A0A user often wants to search multiple mailboxes, and a > client that wishes to support this must issue a series of SELECT and > SEARCH commands, waiting for each to complete before moving on to the > next. =A0This extension allows a client to search multiple mailboxes > with one command, limiting the round-trips and waiting for various > searches to complete, and not requiring disruption of the currently > selected mailbox. =A0This also uses MAILBOX and TAG fields in ESEARCH > responses, allowing a client to pipeline the searches if it chooses. > > Note > > A revised version of this draft document will be submitted to the RFC > editor as a Proposed Standard for the Internet Community. =A0Discussion > and suggestions for improvement are requested, and should be sent to > morg@ietf.org. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-morg-multimailbox-search-0= 1.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > From alexey.melnikov@isode.com Tue Jul 7 14:20:28 2009 Return-Path: X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10F653A694A for ; Tue, 7 Jul 2009 14:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.817 X-Spam-Level: X-Spam-Status: No, score=-2.817 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXTdqpks4ogi for ; Tue, 7 Jul 2009 14:20:27 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id B292228C542 for ; Tue, 7 Jul 2009 14:19:21 -0700 (PDT) Received: from [94.197.216.96] (94.197.216.96.threembb.co.uk [94.197.216.96]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 7 Jul 2009 22:17:25 +0100 Message-ID: <4A53BB0B.8050202@isode.com> Date: Tue, 07 Jul 2009 22:15:55 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Barry Leiba References: <20090707161503.279903A6EA3@core3.amsl.com> <6c9fcc2a0907071103k1a129a14i4b86365442c4a7fd@mail.gmail.com> In-Reply-To: <6c9fcc2a0907071103k1a129a14i4b86365442c4a7fd@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: morg@ietf.org Subject: Re: [MORG] I-D Action:draft-ietf-morg-multimailbox-search-01.txt X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 21:20:28 -0000 Barry, this looks good. Note that I still need to review the new ABNF in more details, so I might have some comments later. One quick comment about the capability: I think you should keep the "X-DRAFT-" prefix ("X-DRAFT-W01-MSEARCH"), until the document is stable. I am not convinced that it will not change syntactically, so I would rather not let people deploy a non final version while advertising the MSEARCH capability. From tss@iki.fi Thu Jul 16 11:12:57 2009 Return-Path: X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3801528C20F for ; Thu, 16 Jul 2009 11:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04OcSHHZWMQe for ; Thu, 16 Jul 2009 11:12:56 -0700 (PDT) Received: from dovecot.org (dovecot.org [82.118.211.50]) by core3.amsl.com (Postfix) with ESMTP id 58D4528C1FE for ; Thu, 16 Jul 2009 11:12:56 -0700 (PDT) Received: from [10.4.192.51] (unknown [74.205.24.229]) by dovecot.org (Postfix) with ESMTP id 0934116471E9 for ; Thu, 16 Jul 2009 21:13:26 +0300 (EEST) From: Timo Sirainen To: morg@ietf.org In-Reply-To: <20090525003002.071743A6993@core3.amsl.com> References: <20090525003002.071743A6993@core3.amsl.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Rlz6HEPbAtmYOaLlEih2" Date: Thu, 16 Jul 2009 14:13:25 -0400 Message-Id: <1247768005.4435.238.camel@timo-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Subject: Re: [MORG] I-D Action:draft-ietf-morg-fuzzy-search-01.txt X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 18:12:57 -0000 --=-Rlz6HEPbAtmYOaLlEih2 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable This should describe pretty much what we talked about in last IETF: Server can do pretty much anything it wants for search keys inside FUZZY. One TODO item though: > UIDs, sequences, modification sequences: [[anchor6: TODO: There is > probably not much point in matching these fuzzily. Could it be a > MUST NOT for clients to use them inside FUZZY?]] I don't really have any thoughts on this. Seems pointless, but then again maybe it might make something easier to allow them to be matched (exactly?) --=-Rlz6HEPbAtmYOaLlEih2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkpfbcUACgkQyUhSUUBVislZsgCfaHJBEO94+6aaYWLESVarf0Wt BtUAnjiz75FI4fNxdZTZTzOhB3namEOs =7h+B -----END PGP SIGNATURE----- --=-Rlz6HEPbAtmYOaLlEih2-- From tss@iki.fi Thu Jul 16 11:35:06 2009 Return-Path: X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE0D13A6DCA for ; Thu, 16 Jul 2009 11:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bc+y46vU+is for ; Thu, 16 Jul 2009 11:35:06 -0700 (PDT) Received: from dovecot.org (dovecot.org [82.118.211.50]) by core3.amsl.com (Postfix) with ESMTP id CC2C43A6DC4 for ; Thu, 16 Jul 2009 11:35:05 -0700 (PDT) Received: from [10.4.192.51] (unknown [74.205.24.229]) by dovecot.org (Postfix) with ESMTP id 0B649FA8B72 for ; Thu, 16 Jul 2009 21:35:37 +0300 (EEST) From: Timo Sirainen To: morg@ietf.org In-Reply-To: <9abf48a60907070645uc59a7f3kf48c3bf7ab87f5bb@mail.gmail.com> References: <9abf48a60907061213v6692c3f2lc5e6f134aca66d25@mail.gmail.com> <9abf48a60907070645uc59a7f3kf48c3bf7ab87f5bb@mail.gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-ekZA+8tdgrmrl/SmUJdE" Date: Thu, 16 Jul 2009 14:35:36 -0400 Message-Id: <1247769336.4435.247.camel@timo-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Subject: Re: [MORG] New I-D proposing a "message recall" protocol X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 18:35:06 -0000 --=-ekZA+8tdgrmrl/SmUJdE Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2009-07-07 at 09:45 -0400, Barry Leiba wrote: > 1. To all of you, please review the proposal and comment on it. (If > you reply to this message, please reply only to the mailing list.) It should probably talk a bit what it means that a message is "seen by the recipient". For example: 1. IMAP client is IDLEing and downloads the message headers immediately. Can it be recalled? (yes?) 2. IMAP client downloads one (or more) MIME parts of the message and sets \Seen flag. Can it be recalled? (no?) 3. IMAP client downloads one (or more) MIME part of the message but doesn't change flags. Can it be recalled? (no?) 4. IMAP client downloads message headers and sets \Seen flag. Can it be recalled? (yes?) 5. POP3 client downloads the message but doesn't delete it. Can it be recalled? (no?) Also there's a security/privacy issue that's not mentioned: I don't want anyone to know when I've read an email they sent. This could be used by whatever spies to find out when exactly I'm reading my email by looping: send message, recall message, send the message again, recall again, etc. > 2. To the chairs, Timo and Randy, I'm asking for a bit of time on the > Stockholm agenda to discuss it, if you can spare the time. Should be ok. --=-ekZA+8tdgrmrl/SmUJdE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkpfcvgACgkQyUhSUUBVismTmACdEh7T5kpUtfbzBWQkllDNce/p 3sQAnjQ0CYbPLCwUxPD36/G7eYK+4qP2 =K5Ci -----END PGP SIGNATURE----- --=-ekZA+8tdgrmrl/SmUJdE-- From Anil.Srivastava@Sun.COM Thu Jul 16 12:53:39 2009 Return-Path: X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A46B73A6DAE for ; Thu, 16 Jul 2009 12:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.446 X-Spam-Level: X-Spam-Status: No, score=-5.446 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmr95y9EWUKj for ; Thu, 16 Jul 2009 12:53:38 -0700 (PDT) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by core3.amsl.com (Postfix) with ESMTP id BFD573A6D55 for ; Thu, 16 Jul 2009 12:53:38 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6GJs7pn002738 for ; Thu, 16 Jul 2009 12:54:11 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; delsp=yes; format=flowed Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KMW00B00486FV00@fe-sfbay-09.sun.com> for morg@ietf.org; Thu, 16 Jul 2009 12:54:07 -0700 (PDT) Received: from [10.90.234.81] ([unknown] [32.157.33.88]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KMW00G6R4M0URG0@fe-sfbay-09.sun.com>; Thu, 16 Jul 2009 12:54:05 -0700 (PDT) Date: Thu, 16 Jul 2009 12:53:53 -0700 From: "Anil SRIVASTAVA [mobile]" In-reply-to: <1247769336.4435.247.camel@timo-desktop> Sender: Anil.Srivastava@Sun.COM To: Timo Sirainen Message-id: <4512F876-B41C-4D6A-B0FF-AE739E543488@Sun.COM> X-Mailer: iPhone Mail (7A341) References: <9abf48a60907061213v6692c3f2lc5e6f134aca66d25@mail.gmail.com> <9abf48a60907070645uc59a7f3kf48c3bf7ab87f5bb@mail.gmail.com> <1247769336.4435.247.camel@timo-desktop> Cc: "morg@ietf.org" Subject: Re: [MORG] New I-D proposing a "message recall" protocol X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 19:53:39 -0000 ~ Anil (tapped out on a iPhone) On Jul 16, 2009, at 11:35, Timo Sirainen wrote: > On Tue, 2009-07-07 at 09:45 -0400, Barry Leiba wrote: >> 1. To all of you, please review the proposal and comment on it. (If >> you reply to this message, please reply only to the mailing list.) > > It should probably talk a bit what it means that a message is "seen by > the recipient". For example: > > 1. IMAP client is IDLEing and downloads the message headers > immediately. > Can it be recalled? (yes?) > Increasingly more and more clients are behaving like (3) below to ease searching of message content. Mail.app, Postbox, Xobni plugin for Outlook are examples of such clients. Are we saying here that the server needs to track the client interaction for a particular message in order to determine if a message can be recalled? > 2. IMAP client downloads one (or more) MIME parts of the message and > sets \Seen flag. Can it be recalled? (no?) > > 3. IMAP client downloads one (or more) MIME part of the message but > doesn't change flags. Can it be recalled? (no?) > > 4. IMAP client downloads message headers and sets \Seen flag. Can it > be > recalled? (yes?) > > 5. POP3 client downloads the message but doesn't delete it. Can it be > recalled? (no?) > > Also there's a security/privacy issue that's not mentioned: I don't > want > anyone to know when I've read an email they sent. This could be used > by > whatever spies to find out when exactly I'm reading my email by > looping: > send message, recall message, send the message again, recall again, > etc. > >> 2. To the chairs, Timo and Randy, I'm asking for a bit of time on the >> Stockholm agenda to discuss it, if you can spare the time. > > Should be ok. > _______________________________________________ > MORG mailing list > MORG@ietf.org > https://www.ietf.org/mailman/listinfo/morg > Note Well: http://www.ietf.org/maillist.html From barryleiba.mailing.lists@gmail.com Fri Jul 17 11:17:54 2009 Return-Path: X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 500B53A6A55 for ; Fri, 17 Jul 2009 11:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHSdGgNW2MB4 for ; Fri, 17 Jul 2009 11:17:53 -0700 (PDT) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by core3.amsl.com (Postfix) with ESMTP id 42AD63A680A for ; Fri, 17 Jul 2009 11:17:53 -0700 (PDT) Received: by bwz28 with SMTP id 28so893821bwz.37 for ; Fri, 17 Jul 2009 11:18:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=gphBWYreHm93xSrxQRfYZmH3T4P/AVKoVNuPIlTnEdw=; b=Zc/sdoPRvySDrsULPG+Ug9GAV731niE/JMB0xHZg71PaOq9Yn1rijmJ1HN+5aW4H7b 9s8X59FAN+VXxCHk4jRsI58relrrmj0fPrhQRpgAxexLdSrZCEs2gwxDOET53Yl0sxTw egHJtSRUMCuxaSZAhme0tegY9wnpnF3iuAlc8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=Gw9NDr0Ept8TnCDCieGuVQvXmhkkPdGdhJ4gzPq4rS5Q0VpkPSk7IRhLEMIrtVeHzZ Hlciz9JCQapKPSo+Vy8BzR4QL/01sN0p7ETihiu8ewgemqeOiE7o8/T9RWSxCTBawO4z tEmjxv5cbjdxLPW++ROB96M3wW9lPpz9Y8v6Y= MIME-Version: 1.0 Received: by 10.239.157.140 with SMTP id q12mr125291hbc.80.1247854704284; Fri, 17 Jul 2009 11:18:24 -0700 (PDT) In-Reply-To: <1247768005.4435.238.camel@timo-desktop> References: <20090525003002.071743A6993@core3.amsl.com> <1247768005.4435.238.camel@timo-desktop> Date: Fri, 17 Jul 2009 14:18:24 -0400 Message-ID: <6c9fcc2a0907171118v3c8a306dg755b2c0d79e13bf9@mail.gmail.com> From: Barry Leiba To: Timo Sirainen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: morg@ietf.org Subject: Re: [MORG] I-D Action:draft-ietf-morg-fuzzy-search-01.txt X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: barryleiba@computer.org List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 18:17:54 -0000 >> UIDs, sequences, modification sequences: [[anchor6: TODO: There is >> =A0 =A0probably not much point in matching these fuzzily. =A0Could it be= a >> =A0 =A0MUST NOT for clients to use them inside FUZZY?]] > > I don't really have any thoughts on this. Seems pointless, but then > again maybe it might make something easier to allow them to be matched > (exactly?) I think the point is that the server decides what "fuzzy" means, and that the decision may vary from search key to search key -- including doing an exact match because it thinks that "fuzzy" isn't meaningful for that particular key. I would never want a client to be unable to say something like this: SEARCH FUZZY (FROM "siranan" UID 123:217) ...even though the client could put the UID item outside the FUZZY scope. It's up to the server how to handle it; I don't want the client to be trying to second-guess what the server will do. Maybe a change to the text will help. How about this?: OLD Fuzzy matching is not limited to just string matching. All search keys SHOULD be matched fuzzily, although what exactly that means for different search keys is left up to implementations to decide. Some suggestions are given below. NEW Fuzzy matching is not limited to just string matching. All search keys SHOULD be matched fuzzily, although what exactly that means for different search keys is left up to server implementations to decide -- including deciding that fuzzy matching is meaningless for a particular key, and falling back to exact matching). Some suggestions are given below. And then maybe: NEW UIDs, sequences, modification sequences: These are examples of keys for which exact matching is probably what makes sense. Alternatively, a server might choose, for instance, to expand a UID range by 5% on each side. --- What do you think? Barry From barryleiba.mailing.lists@gmail.com Fri Jul 17 11:22:26 2009 Return-Path: X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FDB428C309 for ; Fri, 17 Jul 2009 11:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDhD56eSfECx for ; Fri, 17 Jul 2009 11:22:25 -0700 (PDT) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by core3.amsl.com (Postfix) with ESMTP id 0935F3A6E8D for ; Fri, 17 Jul 2009 11:22:24 -0700 (PDT) Received: by bwz28 with SMTP id 28so896057bwz.37 for ; Fri, 17 Jul 2009 11:22:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=iA5Ak5LkseHK42ro4x23vJ8KO7uKpIQmYtp6PVRg7H4=; b=ok7CGxftM2AFGePtIlo2LjFdDlGRhBEXpbVkEcPm+k1yfbbDmuw7bn71bofUs4hckz K57STVm9KvsHnVS6T4BJKiluxJDYdkgqO6x+i3dXkTvfgWSOe+MYGDKNGrGu3TPhP0kz BHWLtRyoEZlqKKr7gty6Wrf7bD1T67k+elVYw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=cM3TDbl0bB4jwPnBGOyRrVY1dNf+/0FtGL7rO+yUfJNWpTUlrdsrww+xkDoCTzhiwG qWNjGyYLfZCddP43hdm0ZRyGXEJKOs6m0owzOHQJrsjPH6MoWUVTVUMN3GPod+OnN2px lK2nDufm+cx5Zl8iyCaAmBRvPp7CzvPtMzuBI= MIME-Version: 1.0 Received: by 10.239.134.3 with SMTP id 3mr121941hbx.73.1247854975911; Fri, 17 Jul 2009 11:22:55 -0700 (PDT) In-Reply-To: <1247769336.4435.247.camel@timo-desktop> References: <9abf48a60907061213v6692c3f2lc5e6f134aca66d25@mail.gmail.com> <9abf48a60907070645uc59a7f3kf48c3bf7ab87f5bb@mail.gmail.com> <1247769336.4435.247.camel@timo-desktop> Date: Fri, 17 Jul 2009 14:22:55 -0400 Message-ID: <6c9fcc2a0907171122m3b838aafwc9f92c0010edc1ca@mail.gmail.com> From: Barry Leiba To: Timo Sirainen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: morg@ietf.org Subject: Re: [MORG] New I-D proposing a "message recall" protocol X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: barryleiba@computer.org List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 18:22:26 -0000 > It should probably talk a bit what it means that a message is "seen by > the recipient". I was intentionally vague there; perhaps I should say it differently. My thinking is that it's basically a "policy" decision. We can certainly give examples, much as you have, and then either make recommendations or not. My inclination is not to make recommendations, but to just put the examples out there for implementers to think about. > Also there's a security/privacy issue that's not mentioned: I don't want > anyone to know when I've read an email they sent. This could be used by > whatever spies to find out when exactly I'm reading my email by looping: > send message, recall message, send the message again, recall again, etc. Excellent; thanks. Yes, or, less intrusively, do a sequence of HOLD-RELEASE, waiting for HOLD to say NO. This definitely needs to be in there. Barry From tss@iki.fi Mon Jul 20 16:23:03 2009 Return-Path: X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D6BF3A6AB1 for ; Mon, 20 Jul 2009 16:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.469 X-Spam-Level: X-Spam-Status: No, score=-5.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAhmM3naLC5u for ; Mon, 20 Jul 2009 16:23:02 -0700 (PDT) Received: from dovecot.org (dovecot.org [82.118.211.50]) by core3.amsl.com (Postfix) with ESMTP id 5B00E3A6781 for ; Mon, 20 Jul 2009 16:23:02 -0700 (PDT) Received: from [10.4.192.51] (unknown [74.205.24.229]) by dovecot.org (Postfix) with ESMTP id A64BC16471E2; Tue, 21 Jul 2009 02:22:23 +0300 (EEST) From: Timo Sirainen To: barryleiba@computer.org In-Reply-To: <6c9fcc2a0907171118v3c8a306dg755b2c0d79e13bf9@mail.gmail.com> References: <20090525003002.071743A6993@core3.amsl.com> <1247768005.4435.238.camel@timo-desktop> <6c9fcc2a0907171118v3c8a306dg755b2c0d79e13bf9@mail.gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-XQA9OGez9DeX9vJpH9+/" Date: Mon, 20 Jul 2009 19:22:21 -0400 Message-Id: <1248132141.4435.590.camel@timo-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Cc: morg@ietf.org Subject: Re: [MORG] I-D Action:draft-ietf-morg-fuzzy-search-01.txt X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 23:23:03 -0000 --=-XQA9OGez9DeX9vJpH9+/ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2009-07-17 at 14:18 -0400, Barry Leiba wrote: > NEW > Fuzzy matching is not limited to just string matching. All search > keys SHOULD be matched fuzzily, although what exactly that means for > different search keys is left up to server implementations to decide > -- including deciding that fuzzy matching is meaningless for a > particular key, and falling back to exact matching). Some suggestions > are given below. >=20 >=20 > And then maybe: > NEW > UIDs, sequences, modification sequences: These are examples of keys > for which exact matching is probably what makes sense. Alternatively, > a server might choose, for instance, to expand a UID range by 5% on > each side. >=20 > --- > What do you think? Yes, looks good. I added those changes to my copy (minus the extra ")"). --=-XQA9OGez9DeX9vJpH9+/ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkpk/C0ACgkQyUhSUUBVislDygCgnIAEcQIn67UIjfHi5bBCMDxz tPgAn0JElNY2FI8ilmNhmDugTemGat3S =ZffL -----END PGP SIGNATURE----- --=-XQA9OGez9DeX9vJpH9+/-- From tss@iki.fi Tue Jul 21 10:51:20 2009 Return-Path: X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 653C13A6A1F for ; Tue, 21 Jul 2009 10:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.169 X-Spam-Level: X-Spam-Status: No, score=-5.169 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARu9G10UlGjZ for ; Tue, 21 Jul 2009 10:51:19 -0700 (PDT) Received: from dovecot.org (dovecot.org [82.118.211.50]) by core3.amsl.com (Postfix) with ESMTP id 987673A69F4 for ; Tue, 21 Jul 2009 10:51:19 -0700 (PDT) Received: from [10.4.192.51] (unknown [74.205.24.229]) by dovecot.org (Postfix) with ESMTP id 722C916471E2 for ; Tue, 21 Jul 2009 20:51:17 +0300 (EEST) From: Timo Sirainen To: morg@ietf.org In-Reply-To: <20090525003002.071743A6993@core3.amsl.com> References: <20090525003002.071743A6993@core3.amsl.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-YSlH7esU5cfKfwz0V4Gp" Date: Tue, 21 Jul 2009 13:51:15 -0400 Message-Id: <1248198675.29737.5.camel@timo-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Subject: Re: [MORG] I-D Action:draft-ietf-morg-fuzzy-search-01.txt X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 17:51:20 -0000 --=-YSlH7esU5cfKfwz0V4Gp Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Pretty minor thing, but would FUZZY capability be better than SEARCH=3DFUZZY? Somehow I thought there were more SEARCH=3D capabilities, but I can't seem to find any. And FUZZY isn't really SEARCH-specific anyway, since it works with SORT, THREAD, etc. And that reminds me, should it be possible to return relevancy values also for THREAD? I guess that would require ESORT-like ETHREAD extension. --=-YSlH7esU5cfKfwz0V4Gp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkpmAA0ACgkQyUhSUUBVism6CgCgpRNKXG83Idr7sYtP+wcTfiRk kkEAoJjTFH/puURjKw+OcSDpicLPr93K =chpU -----END PGP SIGNATURE----- --=-YSlH7esU5cfKfwz0V4Gp-- From barryleiba.mailing.lists@gmail.com Wed Jul 29 05:33:56 2009 Return-Path: X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22E003A6884; Wed, 29 Jul 2009 05:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.962 X-Spam-Level: X-Spam-Status: No, score=-1.962 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VH03wK4sN6bv; Wed, 29 Jul 2009 05:33:55 -0700 (PDT) Received: from mail-pz0-f204.google.com (mail-pz0-f204.google.com [209.85.222.204]) by core3.amsl.com (Postfix) with ESMTP id 2198D3A6971; Wed, 29 Jul 2009 05:33:52 -0700 (PDT) Received: by pzk42 with SMTP id 42so553554pzk.29 for ; Wed, 29 Jul 2009 05:33:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=EOb+oYZ8KhCkjSo1khF/aLBdQ7t3H84eVvgpjrMdwJk=; b=Ch69Fp5FOttWTYYTfze1V2RnAgK3pMrFnTLhXctms7LuN6UKJstU2cwpckZYx1abkN guPYrau8Z3W3z3BVB4kIl4PivFB1UHcGjaCjLvhZdI3rb+y5tmVyveH1tui8ZFeVGAxW 9woLzgqt40hJHVdHhcMkIx1d3d1CQsavMwdSE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=QYnPEzlBzxd86fMtQD8awGZGDv6Fg13zdZ5A3+1no6c0ZeHK8Ix4kTWtH/prI2Ckbp QHuvLa7LVjjb/y0n/GIWvjVqsMHYYr7p5uXMjFr8HfLn2n5Jkx56bM1ccZnbgM96FKVJ D2/XsYA8yB899i0MIKGHBUx6kVbcYCuK+N2WA= MIME-Version: 1.0 Received: by 10.114.180.16 with SMTP id c16mr13654081waf.57.1248870831894; Wed, 29 Jul 2009 05:33:51 -0700 (PDT) Date: Wed, 29 Jul 2009 08:33:51 -0400 Message-ID: <6c9fcc2a0907290533v4b96ea0co76e4cb6b0b24ca34@mail.gmail.com> From: Barry Leiba To: morg@ietf.org, IMAP Extensions WG , ima@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [MORG] "Friends of IMAP" dinner in Stockholm on IETF Friday X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: barryleiba@computer.org List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 12:33:56 -0000 We'll be gathering for the traditional "Friends of IMAP" dinner, after the IETF meeting, in Stockholm. Because the only time we can get most of the people together is Friday, we'll do it on Friday evening, 31 July. We'll meet in the entrance lobby of the Clarion Sign Hotel at 19:00. No plan, yet, about where to do. Barry From randy@qualcomm.com Wed Jul 29 12:49:17 2009 Return-Path: X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2949B3A6F11 for ; Wed, 29 Jul 2009 12:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.66 X-Spam-Level: X-Spam-Status: No, score=-104.66 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3YT8hTL1O-w for ; Wed, 29 Jul 2009 12:49:15 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 5AD9E3A6DB6 for ; Wed, 29 Jul 2009 12:49:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1248896957; x=1280432957; h=message-id:x-mailer:x-message-note:date:to:from:subject: mime-version:content-type:x-random-sig-tag:x-ironport-av; z=Message-ID:=20 |X-Mailer:=20Eudora=20for=20Mac=20OS=20X|X-message-Note: =20Warning:=20Outlook=20in=20use.=20=20Upgrade=20to=20Eud ora:=20|Date:=20Wed,=2029=20Jul=20 2009=2006:13:33=20-0700|To:=20|From:=20Ran dall=20Gellens=20|Subject:=20notes=20 from=20morg=20@=20IETF75|MIME-Version:=201.0 |Content-Type:=20text/plain=3B=20charset=3D"us-ascii"=3B =20format=3Dflowed|X-Random-Sig-Tag:=201.0b28 |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5692"=3B=20 a=3D"21400690"; bh=WhuyML3JGQ1uqNKeswEwsnGXn50HCKW1y5M8UllV0Ug=; b=dCMRoNYQmBqZrAtRGXsOXSWL5rXd2wKYtBcvQM7wmba+fi13RxpUGJYC 8sW/3Zk3U6UDZrIc8SAhOaOyGzavVsMVbGVYQhtJfRVZkm4s4n1Uyq5Ti rX3jAyx/fsOQ3E9M/KeWUc0WmFW5k9WRBZBMhrkpJKo3UiJ5cDJCwzhLI o=; X-IronPort-AV: E=McAfee;i="5300,2777,5692"; a="21400690" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Jul 2009 12:49:01 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6TJn16p022553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 29 Jul 2009 12:49:01 -0700 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6TJn1DV001417 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 29 Jul 2009 12:49:01 -0700 Received: from nasanexmsp02.na.qualcomm.com (10.45.56.203) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.1.358.0; Wed, 29 Jul 2009 12:49:00 -0700 Received: from [78.64.88.186] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.203) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 29 Jul 2009 12:48:58 -0700 Message-ID: X-Mailer: Eudora for Mac OS X X-message-Note: Warning: Outlook in use. Upgrade to Eudora: Date: Wed, 29 Jul 2009 06:13:33 -0700 To: From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 Subject: [MORG] notes from morg @ IETF75 X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 19:49:17 -0000 Here are the notes from the MORG meeting at IETF75. Please review. Thanks to Cyrus and Pete for scribing. [11:08:00] Cyrus (me) will scribe in jabber. [11:10:44] Agenda: any changes? [11:11:05] On to drafts: [11:11:13] Status-in-list draft [11:11:29] Alexey will talk [11:11:51] More reviews needed. [11:12:02] Some discussion about paged LIST results. [11:12:21] Barry thinks it needs addressing in general - not in this document. [11:12:46] Idea: clients can do FETCH in batches, can't do the same with LIST. [11:13:19] Barry is happy to write the spec but will do a straw proposal to the list first. [11:13:36] Next draft: sort-display [11:14:07] One open issue: what to do about sorting on group email addresses. [11:14:18] Alexey thinks we should flip a coin on this one. [11:14:23] Otherwise it is done? [11:14:50] Sorry, how do groups impact the DISPLAYFROM? [11:15:21] Can groups occur in From? (I suppose they could, From can technically contain multiple). [11:15:27] From address can be a group address, right? [11:16:11] Oh, but -sortdisplay appears to only contain DISPLAYFROM. [11:17:01] Need an updated draft - it is about to expire. [11:17:27] There maybe support for sorting on TO. [11:17:34] As in, no DISPLAYTO/DISPLAYCC or whatever. So groups and multiple from are a real edge case we'll never really see in practise, so quite honestly, we could collate those "equal and after", like failed comparators. [11:18:07] Chris suggest just use the display name portion of the group. [11:18:26] I can also do a proper review... [11:19:05] Will do. [11:19:07] Dave tasked to do formal review. [11:19:35] Next draft: fuzzy search [11:20:18] Chris thinks it is reasonable. [11:20:30] Was it just decided to *not* deal with group names? [11:20:51] One issue: range is 1 to 100. Might want to allow more precision with 1 to 1000 or 10,000. [11:20:59] (Sorry, I'm not hearing the conversation, only looking at the jabber.) [11:21:27] Issue from list: should fuzzy be banned for things like UID? [11:21:50] Barry proposed text -- that seems OK. [11:22:12] Other issue: name of capability string. No one cares that much here! [11:22:17] Timo can choose. [11:22:35] After having skimmed this, should the FUZZY and RELEVANCY be split into distinct capabilities? [11:22:39] Next steps: one more revision and then done. [11:22:59] Use case for splitting? [11:23:07] Implement one but not the other. [11:23:18] Well, more likely fuzzy searches without relevancy, but yes. [11:24:09] Is there a real need for that? [11:24:11] Irrelevant fuzziness... I think it might not be easy to determine relevancy. [11:24:46] Server could always return "neutral" relevancy numbers. [11:25:19] So I could just implement such that everything has equal relevancy - yes, that works. [11:25:23] Randy: Having two capabilities introduces more client complexity. Would prefer to stick with one. [11:25:36] Agreeing with Randy as well about not having 2 separate capabilities [11:25:39] Conclusion: keep to one capability. [11:26:20] Next draft: multi-mailbox search. [11:27:05] Security considerations needs more detail. [11:27:20] Biggest change was to syntax to use extended LIST syntax. [11:28:19] No wildcards any more. Depth parameter changed. No specify on a per mailbox basis whether sub-tree is traversed. [11:29:22] Chris would like to see LDAP nomenclature used. Barry prefers notify syntax. [11:29:47] Reviews of draft are now needed. More suggestions needed for security considerations. [11:30:30] Anyone volunteer for a review? [11:31:07] Chairs will ask individuals, [11:31:12] Dave, can you volunteer to review? :-) [11:31:30] Next draft: message recall. [11:31:43] Two main questions: [11:31:55] 1) Should this be done on top of message tracking? [11:32:25] 2) Whether two-phase system makes sense, or is best effort good enough? [11:32:33] 3) Blow off completely? [11:33:26] Pete: no to (3). On (1): architectural question: can message track pull out of the mail store at the end? [11:33:29] resnick, And also there's the in-brain memory editing, of course. [11:33:49] Does message tracking have enough to deal with the "mail spool"? [11:34:22] Message tracking tags a message with an ID. Same as Barry's current proposal. [11:35:23] Message tracking won't help with POP. [11:35:35] Or with IMAP once message is cached. [11:36:09] MDNs could be used? [11:36:21] Presumably it could at least go through LMTP to the store, as well as just SMTP. [11:37:51] Recall is only about promising not to deliver to final recipient - could still archive the message or do other things to it. [11:39:55] Randy thinks temporary hold is overly complicated and probably not reliable. [11:40:44] Pete does not think hold is worth doing. [11:42:01] An ISP ought not to allow recall without user control. [11:42:29] I suspect a lot of this discussion could be avoided by s/recall/retract/ [11:42:41] (Obviously with a 'g' modifier to that.) [11:43:19] dave... 3 in queue. We'll get you soon. [11:44:14] Chris: on hold/release - IMAP cannot "hide" (hold) messages in its store - that represents a new state for messages which will increase admin complexity too much - would not implement it with hold. [11:44:34] Chris: supportive of the feature as a whole, preference for message tracking. [11:44:44] Dave Cridland hears Dr Seuss in Chris - "Not in the queue, not in the store, not in my view, not any more..." [11:45:00] Barry: enough people have said they are unhappy with hold, so it will go from the next draft. [11:45:31] Chris: per-user option to control probably would not be implemented first, but maybe if request. [11:46:08] Dave: hold/release is a distributed commit - solutions to that do exist elsewhere and we should look at those. [11:47:35] Dave: is this a paradigm shift in email? Does this not imply the need for an email "control plane". [11:48:49] (Isn't it the standard rule that the first person to call a Paradigm Shift gets to buy the beer?) [11:49:38] even for folks on jabber :) [11:49:40] This implies some kind of trust overlay. [11:51:20] Jacob: spec from 10 years ago defined a Replaces header that could be used in a new message to "hide" an existing one. [11:52:28] With Jacob's proposal everyone is always informed of the recall. Would like to see Barry's spec define a notification always sent to recipients so that they know a recall was done. [11:54:16] Barry: "Replaces" header deals OK with the "factual error fix" case, but not so well with the "angry message retract" case. [11:54:57] Chris: does not want to implement a per-user opt in option unless required by the spec. [11:56:29] Chris: message recall is not just an enterprise feature - used on AOL a lot. It saves a lot of time when fixing quickly found errors. [11:57:50] Pete: security considerations section will list a lot of possible abuses, but also needs to describe cases where it would be bad to allow recall (e.g. messages to lawyers etc). So per-mailbox on/off option for this is going to be needed. [11:58:28] Pete: "Replaces" is independently a good idea - could use Supercedes. [11:58:43] Barry Leiba, Incidentally, the reason I say that "retraction" is easier to talk about than "recall" is that "retraction" implies that it's an indication that the message has, at some specific point in time, been stated as withdrawn, rather than a message which is going to be actually deleted out of someone else's mailbox. [11:59:00] Barry Leiba, Not that this needs channelling. [11:59:21] Randy: would opt-in make implementors not do this if required? [11:59:48] Chris: not a huge overhead and would not block implementation. [12:00:39] Jacob: for important non-recallable message just don't include the message id. [12:00:55] Chris: if there is a legal requirement, archiving system can take care of it. [12:01:48] Chris: spec should explicitly say that the new feature does not affect archiving systems. [12:02:09] Jacob: what about mailing lists? [12:03:37] Chris: add an iteration count to message track and use HMAC. [12:05:45] ANNOTATE? [12:05:58] (As in for Cyrus's token storage) [12:10:09] Barry: summary -- change to use message tracking. [12:10:32] Cyrus: want a way for client to easily manage and get status for the recall process. [12:10:53] Should there be a header or annotation on sent-mail message that can be used for this? [12:11:06] Chris: private key in header in sent-mail would be bad. [12:11:23] Pete: MDN can come back with "recall" status. [12:11:59] ? [12:12:20] Pete: Does this require a re-charter? [12:12:27] Alexey: Probably. [12:12:36] Chris: Should probably be done in WG. [12:13:22] Chris: Message tracking architecture: Runs on a different port. The security properties of that are good. (Outbound 25 is blocked, but not the recall; sites can reject packets on the port.) [12:13:43] Chris: Consequence is that you are not piggybacking on SMTP. [12:13:57] Barry: Side effect: Must implement message tracking to get recall. [12:14:30] Chris: Could structure protocol to reduce tracking requirements. But probably not necessary. [12:14:41] Chris: You'll want the tracking data anyway. [12:14:54] Barry: Objections to making this a WG document? [12:14:59] (None in the room) [12:15:35] Randy: You'd want the recall/query to follow the same path as the message. [12:16:11] Barry: For sending the message, you might need to use local infrastrucutre. [12:16:59] Chris: Recall path is a different path from the normal SMTP mechanisms. It must follow the original path, even if that path has changed. [12:17:12] Barry: What if the path has changed and you still want to recall? [12:17:35] Randy: If you don't follow the same path, you might hit a server that hasn't seen the message. [12:17:53] Tony: Tracking uses an SRV record. Well known issues. [12:18:42] Tony: Only the MTA knows how to track down the message. [12:19:27] Klensin: This was experimented with. Should have explicit warning that the recall might arrive before the message. [12:20:07] Klensin: It might want to cache these things. [12:20:29] Chris: With the separate protocol, you can offload the functionality on a different server. [12:20:37] Chris: Lowers impact on mail service. [12:20:51] Barry: I will make it message tracking, and remove hold/release. [12:22:01] Barry: Will confirm on the list. [12:22:59] Alexey: Draft related to messaging: Using SRV records for messaging (draft-daboo....) [12:23:02] Please review. [12:23:15] Randy: Declares done-ness. [12:23:22] Or done-itute. [12:23:23] B'bye, all. [12:25:58] Lemonade clients? [12:26:05] Thunderbird is doing CONDSTORE. [12:26:20] I think that counts to some not insignificant degree. [12:26:52] the what? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- To die for an idea is unquestionably noble. But how much nobler it would be if men died for ideas that were true! --H.L. Mencken