MBOX-Line: From mrc at CAC.Washington.EDU  Thu Sep  8 11:56:38 2005
To: imap-protocol@u.washington.edu
From: Mark Crispin <mrc@CAC.Washington.EDU>
Date: Fri Jun  8 12:34:36 2018
Subject: [Imap-protocol] SELECT of same mailbox
In-Reply-To: <14D6F6402750309B537A989C@ninevah.local>
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>
	<14D6F6402750309B537A989C@ninevah.local>
Message-ID: <Pine.OSX.4.63.0509081101540.28350@pangtzu.panda.com>

Hi Cyrus,

Your confusion seems to be that you infer the existance of a protocol 
element (and thus its semantics) from natural-language text, even though 
there is nothing in the formal syntax to justify belief that this protocol 
element exists.

Natural language is ambiguous (especially given the myriad of dialects!); 
that is why we have formal syntax.  We are lost the moment we turn to 
dictionaries to justify an interpretation of natural language as being 
normative even though that interpretation has no basis in the formal 
syntax.

This is especially true when the dictionary definition is itself 
ambiguous.  You say that your dictionary defines "failure" as "lack of 
success".  What is "success" or "failure" in the context of a "I don't 
understand you" response?

If you utter "blah blie boh bah" and I respond "I don't understand you", 
that constitutes "success" if you wanted to confuse me by uttering 
nonsense, and "failure" if you speak Blahish and want to know where the 
post office is.  In other words, "success" and "failure" in the dictionary 
context is based entirely on the perspective of the initiator.  It's not a 
protocol element.

In order to apply semantics to a protocol element, we must have a 
normative definition of that protocol element.  In this case, we are 
looking for a normative definition of "a SELECT command with invalid 
arguments."

In the formal syntax on page 90, we find the definition of a SELECT 
command:

select          = "SELECT" SP mailbox

This is the one, and *only*, definition, of a SELECT command.  Now, if the 
definition was something like

select          = "SELECT" [arguments]

that would allow there to be "a SELECT command with invalid arguments" 
protocol element.

Put another way; IMAP does not have a protocol element of "a SELECT 
command with invalid arguments."  Nor is there any syntax that could be 
used to define such a protocol element.

More importantly, such a concept is tied to a particular style of parsing 
algorithm.  Not all parsers work this way.

We humans may recognize such a concept.  For our benefit we may have text 
such as "command unknown or arguments invalid".  But such text is not 
normative to the definition of a command in the protocol.

We humans may think that the syntax for "a SELECT command with invalid 
arguments" is "obvious".  As I demonstrated in my previous message, it 
isn't obvious.  There is no razor, anywhere in the IMAP specification, 
that can differentiate between "a SELECT command with invalid arguments" 
and random garbage.

Consider (as I showed in my previous message) a tag with a non-atom 
character.  A parser which separates "words" as space-delimited tokens 
might not discover that the tag is invalid until after it has recognized 
the SELECT verb.  A parser which does strict left-to-right processing 
would choke on the invalid character in the tag and never see the verb.

Nothing in the IMAP specification dictates that either way of parsing is 
superior to the other; either way ultimately results in a BAD.

The problem only comes in if you assume that there are semantics 
associated with a protocol element of "a SELECT command with invalid 
arguments".  Such an assumption is invalidated by absence of that protocol 
element in the formal syntax, and by the absurd conclusion that *any* BAD 
could trigger those sematics (because there is no defined protocol element 
and any implied definition is ambiguous because your implied definition 
differs from mine).

>>    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.

Interesting that you point that out, since it completely demolishes your 
argument that there is an ambiguity.

It defines, by example, "rejected" and "failed" commands.

It clearly states that a BAD response "never changes the state of the 
connection or of the selected mailbox".

>>       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.

I see it differently.  "fails with a NO response" is a tautology; "fails" 
or "responds with NO" suffice.

I interpret your argument as saying that this tautology conveys meaning, 
and a lack of the same tautology elsewhere is similarly meaningful.

The right thing to do is to delete tautologies, not add new ones.

-- 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.

