On Wed, 25 Sep 2002 22:18:02 +0200, Simon Josefsson wrote:
> Except possibly this new UIDNEXT thing. Cyrus IMAP for one doesn't do
> this.
Cyrus in your example is fine. It returned an error when using * to access a
message sequence number in an empty message:
> . FETCH * UID
> . NO No matchin
ispin; Pete Maclean; IMAP Interest List
Subject: Re: possible draft 19 changes for sequence
Mark Crispin <[EMAIL PROTECTED]> writes:
> On Wed, 25 Sep 2002 14:58:15 +0200, Simon Josefsson wrote:
>> Would it improve the standard to make this more obvious? The text
>> that the argu
Mark Crispin <[EMAIL PROTECTED]> writes:
> On Wed, 25 Sep 2002 14:58:15 +0200, Simon Josefsson wrote:
>> Would it improve the standard to make this more obvious? The text
>> that the argument is based on is located inside parentheses in a
>> comment inside the ABNF without saying how to handle t
-Original Message-
From: Mark Crispin [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 25, 2002 10:23 AM
To: Larry Osterman
Cc: Simon Josefsson; Pete Maclean; IMAP Interest List
Subject: RE: possible draft 19 changes for sequence
On Wed, 25 Sep 2002 10:20:56 -0700, Larry Osterman wrote
On Wed, 25 Sep 2002 10:20:56 -0700, Larry Osterman wrote:
> Nit: Should it be "should" or "SHOULD" in "The server should respond
> with a tagged BAD" below?
In general, I've avoided placing requirements on server handling of errors.
In my opinion, a compliant server could treat "FETCH *" of an em
02 9:55 AM
To: Simon Josefsson
Cc: Pete Maclean; IMAP Interest List
Subject: Re: possible draft 19 changes for sequence
On Wed, 25 Sep 2002 14:58:15 +0200, Simon Josefsson wrote:
> Would it improve the standard to make this more obvious? The text
> that the argument is based on is located insi
On Wed, 25 Sep 2002 14:58:15 +0200, Simon Josefsson wrote:
> Would it improve the standard to make this more obvious? The text
> that the argument is based on is located inside parentheses in a
> comment inside the ABNF without saying how to handle the error or why
> it is an error.
Well, sectio
Absolutely not. Messages in IMAP are immutable.
Larry Osterman
-Original Message-
From: Arnt Gulbrandsen [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 25, 2002 1:44 AM
To: IMAP Interest List
Subject: Re: possible draft 19 changes for sequence
Mark Crispin <[EM
Mark Crispin <[EMAIL PROTECTED]> writes:
> On Tue, 24 Sep 2002, Simon Josefsson wrote:
>> > That is also impossible in IMAP. Review sections 5.5 and 7.4.1.
>> The sections seem to only discuss multiple commands from one client.
>> I was thinking of server initiated emptying of mailboxes, or mult
On Wed, 25 Sep 2002 10:43:41 +0200, Arnt Gulbrandsen wrote:
> Hm. Is the server even allowed to give different responses to two FETCH
> commands for the same item?
>
> C: a FETCH 1 RFC822.SIZE
> S: * 1 FETCH (RFC822.SIZE 12345)
> S: a OK
> C: b IDLE
> S: +
> S:
Mark Crispin <[EMAIL PROTECTED]>
> The messages still exist, and will continue to exist until the untagged
> EXPUNGEs are transmitted. RFC 2180 offers NO as an option; however I
> contend (and empirical evidence has shown) that OK is what works best.
> RFC 2180 offers three ways that OK can happe
fsson; Pete Maclean; IMAP Interest List
Subject: RE: possible draft 19 changes for sequence
On Tue, 24 Sep 2002, Larry Osterman wrote:
> But what about this scenario:
> C: 1 NOOP
> S: * 5 EXISTS
> S: 1 OK NOOP Completed
> Client 2 now deletes all the messages in the mailbox. A
On Tue, 24 Sep 2002, Simon Josefsson wrote:
> > That is also impossible in IMAP. Review sections 5.5 and 7.4.1.
> The sections seem to only discuss multiple commands from one client.
> I was thinking of server initiated emptying of mailboxes, or multiple
> concurrent clients where one of them emp
On Tue, 24 Sep 2002, Larry Osterman wrote:
> But what about this scenario:
> C: 1 NOOP
> S: * 5 EXISTS
> S: 1 OK NOOP Completed
> Client 2 now deletes all the messages in the mailbox. At this point,
> the client thinks that there are 5 items in the mailbox while the server
> knows that there are
Mark Crispin <[EMAIL PROTECTED]> writes:
> On Tue, 24 Sep 2002 17:27:24 +0200, Simon Josefsson wrote:
>> I meant that the mailbox can become empty during the time it takes to
>> send the EXISTS to the client, and during that time window the client
>> can issue a command with the * message number.
September 24, 2002 8:09 AM
To: Simon Josefsson
Cc: Pete Maclean; IMAP Interest List
Subject: Re: possible draft 19 changes for sequence
On Tue, 24 Sep 2002 17:06:23 +0200, Simon Josefsson wrote:
> > By the way, even a UID only client could avoid the problem if it
> > paid attention to
: Mark Crispin; Pete Maclean; IMAP Interest List
Subject: Re: possible draft 19 changes for sequence
On Tue, 24 Sep 2002 14:00:38 +0200, Simon Josefsson wrote:
> I feel "an error" is a bit loose. Exactly what will happen?
The server would return either BAD or NO. I prefer BAD.
On Tue, 24 Sep 2002 17:27:24 +0200, Simon Josefsson wrote:
> I meant that the mailbox can become empty during the time it takes to
> send the EXISTS to the client, and during that time window the client
> can issue a command with the * message number. Not a likely scenario,
That is also impossib
Mark Crispin <[EMAIL PROTECTED]> writes:
> On Tue, 24 Sep 2002 17:06:23 +0200, Simon Josefsson wrote:
>> > By the way, even a UID only client could avoid the problem if it paid
>> > attention to the EXISTS value.
>> No, the mailbox can become empty before the client received the EXISTS
>> value.
On Tue, 24 Sep 2002 17:06:23 +0200, Simon Josefsson wrote:
> > By the way, even a UID only client could avoid the problem if it paid
> > attention to the EXISTS value.
> No, the mailbox can become empty before the client received the EXISTS
> value. Returning BAD in this case seems unwarranted.
On Tue, 24 Sep 2002 14:16:49 +0200, Simon Josefsson wrote:
> I also recall from a comp.mail.imap discussion that it was the word
> "sequence" that caused confusion, some people (me included) regard
> "sequences" to be ordered. It was suggested to use the word "set"
> throughout the specification
Mark Crispin <[EMAIL PROTECTED]> writes:
> By the way, even a UID only client could avoid the problem if it paid
> attention to the EXISTS value.
No, the mailbox can become empty before the client received the EXISTS
value. Returning BAD in this case seems unwarranted.
On Tue, 24 Sep 2002 14:00:38 +0200, Simon Josefsson wrote:
> I feel "an error" is a bit loose. Exactly what will happen?
The server would return either BAD or NO. I prefer BAD.
> It is
> not impossible for a client to send e.g. a UID SEARCH UID 1:* to a
> mailbox before it discover that the ma
Simon Josefsson <[EMAIL PROTECTED]> writes:
> Mark Crispin <[EMAIL PROTECTED]> writes:
>
>> to:
>>; * represents the largest number in use. In
>>; the case of message sequence numbers, it is
>>; the number of messages in a n
Mark Crispin <[EMAIL PROTECTED]> writes:
> to:
>; * represents the largest number in use. In
>; the case of message sequence numbers, it is
>; the number of messages in a non-empty mailbox
>; (it is a
To address Pete's nits, I've done the following. While I was at it, I saw
something else that needed a clarification: a message sequence number of * in
an empty mailbox is an error, but a UID-only client might do * in an empty
mailbox if it doesn't look at EXISTS and thus * needs a definition for
>Thus, a UID range of 559:* always
>indicates at least one message, unless the mailbox is
>empty.
It might be stronger and clearer to state that "any UID range involving *
indicates at least one message, unless the mailbox is empty."
>
27 matches
Mail list logo
