IETF Logo Mail Archive

Re: draft-melnikov-imap-search-res

Alexey Melnikov <Alexey.Melnikov@isode.com> Tue, 19 October 2004 16:38 UTC

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JGcALJ098420; Tue, 19 Oct 2004 09:38:10 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9JGcAnw098419; Tue, 19 Oct 2004 09:38:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JGc99H098411 for <ietf-imapext@imc.org>; Tue, 19 Oct 2004 09:38:09 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com)
Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 19 Oct 2004 17:37:59 +0100
Message-ID: <417542E6.50902@isode.com>
Date: Tue, 19 Oct 2004 17:37:58 +0100
From: Alexey Melnikov <Alexey.Melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Timo Sirainen <tss@iki.fi>
CC: IMAP Extensions WG <ietf-imapext@imc.org>
Subject: Re: draft-melnikov-imap-search-res
References: <7yoPjUFDAsyLma6mHUEDow.md5@libertango.oryx.com> <4174F9C2.40304@isode.com> <A988B56A-21EB-11D9-8450-000393CC2E90@iki.fi>
In-Reply-To: <A988B56A-21EB-11D9-8450-000393CC2E90@iki.fi>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Timo Sirainen wrote:

> On 19.10.2004, at 14:25, Alexey Melnikov wrote:
>
>> My guess is (at least from the times I was an IMAP client developer) 
>> that the result of a SEARCH command is usually used as input to a 
>> subsequent FETCH/COPY/STORE command. With the base IMAP protocol one 
>> has to wait for the result of SEARCH to feed it into the subsequent 
>> command.
>
> If client sends SEARCH + FETCH << pipelined, nothing prevents server 
> from giving all the FETCH replies before the SEARCH reply, right?

The server shouldn't reorder the commands if there are any data 
dependencies. "<<" is a very explicit indication that there are.

Is there any particular reason why you think that a server should return 
FETCH responses before the SEARCH response?

Alexey

v2.23.0 | Report a Bug | By Email