MBOX-Line: From daboo at isamet.com  Thu Sep  8 09:47:04 2005
To: imap-protocol@u.washington.edu
From: Cyrus Daboo <daboo@isamet.com>
Date: Fri Jun  8 12:34:36 2018
Subject: [Imap-protocol] SELECT of same mailbox
In-Reply-To: <Pine.WNT.4.64.0509071235060.3496@Shimo-Tomobiki.panda.com>
References: <8613FB1A1827570EC6B5150F@ninevah.cyrusoft.com>
	<Pine.OSX.4.63.0509071108110.28350@pangtzu.panda.com>
	<DC4E58A90D144DDA3A10024D@ninevah.cyrusoft.com>
	<Pine.WNT.4.64.0509071235060.3496@Shimo-Tomobiki.panda.com>
Message-ID: <14D6F6402750309B537A989C@ninevah.local>

Hi Mark,

--On September 7, 2005 12:50:36 PM -0700 Mark Crispin 
<MRC@CAC.Washington.EDU> wrote:

>> a SELECT INBOX foobar
>
> That is not a SELECT command, any more than
>  	{ select } choose your option
> or
>  	to select the best candidate for the job
> are.

In many Sections in rfc3501:

>                BAD - command unknown or arguments invalid

To me this implies a difference between an unknown command 'verb' and a 
known command 'verb' but with invalid arguments. Yet you say that a command 
with invalid arguments is an unknown command or at least not the same as 
the command that uses the 'verb'.

rfc3501, Section 2.2.2:

> BAD (indicating a protocol error such as
>    unrecognized command or command syntax error)

Again a distinction is being made between an unrecognised command and a 
command with syntax errors, contrary to your statements.

So, I still believe that:

a SELECT INBOX foobar

is a SELECT command with a syntax error. I wonder how many others also see 
it that way?


>> I guess all I am asking for is a change to that sentence, something like:
>>       Consequently, if a mailbox is selected and an attempted SELECT
>>       command fails with a NO response, no mailbox is selected.
>
> I think that this is a terrible idea.  It implies that there are other
> cases where there is "failure" involving a BAD.  Thus, every single point
> where command failure is mentioned would have to add such wording, now
> and forever.

The problem is you are using the work 'failure' to mean a 'NO' response is 
returned. My dictionary defines failure as 'lack of success' - i.e. any 
response other than 'OK' as far as IMAP is concerned. Form a client 
implementer perspective both 'NO' and 'BAD' represent errors (and that to 
me means failure). The term 'failure' is used in 3501 in many several 
different contexts. So lets look at 3501:

Section 2.2.2:

>    The server completion result response indicates the success or
>    failure of the operation.

To me that means 'BAD' is considered a 'failure' since its a completion 
response and clearly does not indicate 'success'. Later on in that same 
paragraph it says 'OK' is 'success', 'NO' is 'failure' and 'BAD' is 
'error'. So there is a lack of consistency at least there.

Section 7.1.5:

>       The difference between a BYE that occurs as part of a normal
>       LOGOUT sequence (the first case) and a BYE that occurs because of
>       a failure (the other three cases) is that the connection closes
>       immediately in the failure case.

This is clearly talking about a 'generic' failure as opposed to a 'NO' 
failure.

Section 6:

>    The state of a connection is only changed by successful commands
>    which are documented as changing state.  A rejected command (BAD
>    response) never changes the state of the connection or of the
>    selected mailbox.  A failed command (NO response) generally does not
>    change the state of the connection or of the selected mailbox; the
>    exception being the SELECT and EXAMINE commands.

This is a very clear statement of the SELECT problem, but in terms of a 
'generic' state change.

Section 6.2.2:

>       If an AUTHENTICATE command fails with a NO response, the client
>       MAY try another authentication mechanism by issuing another
>       AUTHENTICATE command.

Here the specific case of 'NO' vs 'BAD' is described to avoid confusion. 
That is really all I am asking for for the SELECT issue. Perhaps a 
reference back to that paragraph at the top of Section 6 is really all that 
is needed.

Alternatively, if you are going to redefine the terms 'failure' and 'fails' 
to mean a 'NO' response (as opposed to their usual dictionary meaning) then 
they should be explicitly described in the 'Conventions' section and 
perhaps even be quoted whenever that explicit meaning is used as opposed to 
the regular dictionary meaning.

-- 
Cyrus Daboo

