RE: FETCH command behavior
Mark Crispin <MRC@cac.washington.edu> Thu, 28 August 1997 20:35 UTC
Received: from cnri by ietf.org id aa15427; 28 Aug 97 16:35 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 QAA14571 for <ietf-archive@CNRI.Reston.VA.US>; Thu, 28 Aug 1997 16:38:29 -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 NAA49556; Thu, 28 Aug 1997 13:28:31 -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 NAA17558 for <imap@lists.u.washington.edu>; Thu, 28 Aug 1997 13:25:59 -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 NAA02048 for <imap@u.washington.edu>; Thu, 28 Aug 1997 13:25:55 -0700
Received: from Tomobiki-Cho.CAC.Washington.EDU (stein@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mx1.cac.washington.edu (8.8.4+UW97.07/8.8.4+UW97.04) with ESMTP id NAA15592 for <IMAP@CAC.Washington.EDU>; Thu, 28 Aug 1997 13:25:52 -0700
Message-Id: <MailManager.872799216.5592.mrc@Ikkoku-Kan.Panda.COM>
Date: Thu, 28 Aug 1997 13:13:36 -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 Interest List <IMAP@cac.washington.edu>
Subject: RE: FETCH command behavior
In-Reply-To: <2FBF98FC7852CF11912A000000000001065E3EFE@DINO>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET="US-ASCII"
X-Sender: Mark Crispin <mrc@Ikkoku-Kan.Panda.COM>
X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN
With regard to Larry Osterman's messages about references to non-existant UIDs, I have considered the matter carefully, and I propose to change the text in 6.4.8 from: ... A non-existent unique identifier within a message set range is ignored without any error message generated. to: ... A non-existent unique identifier is ignored without any error message generated. or to (just to make it clear): ... A non-existent unique identifier is ignored without any error message generated. Thus, it is possible for a UID FETCH command to return OK without any data. My implementation already conforms to this behavior. I believe that this behavior is more useful and easier to program than requiring that errors be issued. This is based on the belief that non-existant UIDs can be issued based upon reasonable mathematical calculations for a client to use, e.g. "123:*" (when 122 was the highest known UID from a previous session) to get data on new UIDs. This is a perfectly normal situation, which shouldn't cause any error. In the case of message numbers, a client never issues an unknown message number for any reason other than a bug, so reporting an error is alright here. I very strongly feel that errors should not happen in the course of normal operation. An error should mean "something is wrong", not "empty data". If anybody has objections to this proposed change, please speak up now.
- 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