[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Behaviour of fetch annotation

To: Arnt Gulbrandsen <arnt@xxxxxxxxxxxxxxxxxxx>
Subject: Re: Behaviour of fetch annotation
From: Mark Crispin <mrc@xxxxxxxxxxxxxxxxxx>
Date: Sat, 8 Oct 2005 09:03:29 -0700 (PDT)
Cc: ietf-imapext@xxxxxxx, Peter Coates <peter.coates@xxxxxxx>
In-reply-to: <>
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>
References: <> <> <>
Sender: owner-ietf-imapext@xxxxxxxxxxxx

On Sat, 8 Oct 2005, Arnt Gulbrandsen wrote:

This is, as I see it, the IMAP way.

The IMAP way would be to return a NIL for the messages where the requested FETCH message data is irrelevant, not return a tagged BAD.

A tagged BAD response is for invalid protocol, not for "data not set". The reason why fetching no such message returns BAD is that the client knows in advance that the message is bad; it does not do so for no such UID.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Follow-Ups:
- RE: Behaviour of fetch annotation
  - From: Peter Coates

References:
- Behaviour of fetch annotation
  - From: Peter Coates
- Re: Behaviour of fetch annotation
  - From: Arnt Gulbrandsen
- Re: Behaviour of fetch annotation
  - From: Arnt Gulbrandsen

Prev by Date: Re: Behaviour of fetch annotation
Next by Date: value of /flag/* entries
Previous by thread: Re: Behaviour of fetch annotation
Next by thread: RE: Behaviour of fetch annotation
Index(es):
- Date
- Thread