re: FETCH command behavior
Mark Crispin <MRC@cac.washington.edu> Tue, 26 August 1997 23:18 UTC
Received: from cnri by ietf.org id aa19185; 26 Aug 97 19:18 EDT
Received: from lists.u.washington.edu (root@lists.u.washington.edu [140.142.56.13]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid TAA08443 for <ietf-archive@CNRI.Reston.VA.US>; Tue, 26 Aug 1997 19:21:46 -0400 (EDT)
Received: from host (server@lists.u.washington.edu [140.142.56.13]) by lists.u.washington.edu (8.8.4+UW97.07/8.8.4+UW97.05) with SMTP id QAA33534; Tue, 26 Aug 1997 16:13:40 -0700
Received: from mx5.u.washington.edu (mx5.u.washington.edu [140.142.32.6]) by lists.u.washington.edu (8.8.4+UW97.07/8.8.4+UW97.05) with ESMTP id QAA16816 for <imap@lists.u.washington.edu>; Tue, 26 Aug 1997 16:12:41 -0700
Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx5.u.washington.edu (8.8.4+UW97.07/8.8.4+UW97.04) with ESMTP id QAA06561 for <imap@u.washington.edu>; Tue, 26 Aug 1997 16:12:38 -0700
Received: from mailhost2.cac.washington.edu (mailhost2.cac.washington.edu [140.142.33.2]) by mx1.cac.washington.edu (8.8.4+UW97.07/8.8.4+UW97.04) with ESMTP id QAA01098 for <imap@CAC.Washington.EDU>; Tue, 26 Aug 1997 16:12:37 -0700
Received: from Tomobiki-Cho.CAC.Washington.EDU (nark@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost2.cac.washington.edu (8.8.4+UW97.07/8.8.4+UW97.07) with SMTP id QAA05621; Tue, 26 Aug 1997 16:12:33 -0700
Message-Id: <MailManager.872636774.19274.mrc@Tomobiki-Cho.CAC.Washington.EDU>
Date: Tue, 26 Aug 1997 16:06:14 -0700
Sender: IMAP-owner@u.washington.edu
Precedence: bulk
From: Mark Crispin <MRC@cac.washington.edu>
To: "Larry Osterman (Exchange)" <larryo@exchange.microsoft.com>
Cc: 'IMAP List' <imap@cac.washington.edu>
Subject: re: FETCH command behavior
In-Reply-To: <2FBF98FC7852CF11912A0000000000010581D29B@DINO>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET="US-ASCII"
X-Sender: Mark Crispin <mrc@tomobiki-cho.cac.washington.edu>
X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN
On Tue, 26 Aug 1997 15:57:38 -0700, Larry Osterman (Exchange) wrote: > The corollary of this statement is that a unique identifier OUTSIDE a > message set range SHOULD generate a message. Thus the first example > will fail if any of the messages specified doesn't exist, while after > our canonicalization logic, the example would fail only if all of the > messages specified don't exist. I consider that to be a rather extreme position. I think that unknown UIDs should be just ignored, and if a UID sequence doesn't match any messages the command would then be a no-op. I could imagine clients taking advantage of that characteristic. > Do we need to change our canonicalization logic to not collapse > individual sequence values (not a big deal, but we need to know). > And are there clients that will choke if we DO canonicalize the output? Code which collapses 1:5,3,7,8 to 1:8 is fine as-is.
- FETCH command behavior Larry Osterman (Exchange)
- re: FETCH command behavior Mark Crispin
- re: FETCH command behavior Larry Osterman
- Re: re: FETCH command behavior Mark Crispin
- RE: FETCH command behavior Mark Crispin