cmd with "bad" sequence number (or uid seq.)
Greg
Hi all,
as often, I found the rfc not clear at all for those (simple?) cases:
let's say a mailbox (folder), contains 10 messages, 1->10 (and say uid
1001 to 1010).
what are the must/should/could/.. response of a server if a client send a :
"tag store 11 +flags (\Seen)" (or whatever valid flags attribute and values)
"tag uid store 1 +flags (\Seen)"
"uid store 1030 '...'" (always a valid flag attribute and values)
and what about the same msg nbr (or uid), but with doing a fetch (and
uid fetch also so) (with ofcourse valid fetch item(s)).
but now, always with 10 msgs within the box, always uid 1001->1010, the
same question but for partially "bad" seq. numbers:
"tag store 1,2,3,20 ..."
"uid store 1001,1005,9000 ..."
or
"uid store 5,1001,1002 ..."
and also for the fetch.
Many thanks in advance for your advices.
Greg.
Mark Crispin
> as often, I found the rfc not clear at all for those (simple?) cases:
A sequence number is a value between 1 and the current EXISTS value;
consequently client use of an invalid sequence is always a protocol error
and always results in a BAD. A command can not be partially BAD;
therefore even if some sequences are bad the presence of a single invalid
sequence causes the entire command to be rejected.
There is no reason why any debugged client should ever issue a command
with an invalid sequence.
Client use of unknown UIDs is ignored. A command which only uses unknown
UIDs is effectively a NOOP. A command which uses some known UIDs and some
unknown UIDs operates on the known UIDs and ignores the unknown UIDs.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
Greg
> On Fri, 18 Feb 2005, Greg wrote:
>
>> as often, I found the rfc not clear at all for those (simple?) cases:
>
>
> A sequence number is a value between 1 and the current EXISTS value;
> consequently client use of an invalid sequence is always a protocol
> error and always results in a BAD. A command can not be partially BAD;
> therefore even if some sequences are bad the presence of a single
> invalid sequence causes the entire command to be rejected.
So the server should check the validity of each sequence number it get
from a client in a set BEFORE doing any operation for the associated
command.. rejecting with bad whenever 1 (or more) sequence number within
the gived set is .. greater than the last EXISTS value (or <= 0 but that
"should" be even less the case than a greater than last EXISTS.. who
knows) ...
Ok that's what I guessed.. Hmm, not that I want to be insistant, but
giving a NO response is also ok no ??
> There is no reason why any debugged client should ever issue a command
> with an invalid sequence.
Indeed, or maybe ;-) In a perfect world I would have totaly agreed, but
I think we are not there..
> Client use of unknown UIDs is ignored. A command which only uses
> unknown UIDs is effectively a NOOP. A command which uses some known
> UIDs and some unknown UIDs operates on the known UIDs and ignores the
> unknown UIDs.
Ok, that's also what I was expecting, but but but .. ;-)
"from wich point" can we explain the difference with the non-UID
corresponding command ?? Or there isn't a such way to explain it and we
could say that this is a "definition" case ?
Anyway, thank you for your comments.
Greg.
Mark Crispin
> So the server should check the validity of each sequence number it get from a
> client in a set BEFORE doing any operation for the associated command..
Yes
> rejecting with bad whenever 1 (or more) sequence number within the gived set
> is .. greater than the last EXISTS value (or <= 0 but that "should" be even
> less the case than a greater than last EXISTS.. who knows) ...
Sequence numbers are unsigned non-zero values. 0 is syntactically
invalid.
> Ok that's what I guessed.. Hmm, not that I want to be insistant, but giving a
> NO response is also ok no ??
Incorrect. A NO response is a problem in the execution of a valid
command. A command with bad sequence numbers is an invalid command and
must get a BAD.
The whole point is that NO means "server condition error" whereas BAD
means "client bug".
>> There is no reason why any debugged client should ever issue a command with
>> an invalid sequence.
> Indeed, or maybe ;-) In a perfect world I would have totaly agreed, but I
> think we are not there..
I said a "debugged client". A client which issues invalid sequences is
not debugged by definition.
>> Client use of unknown UIDs is ignored. A command which only uses unknown
>> UIDs is effectively a NOOP. A command which uses some known UIDs and some
>> unknown UIDs operates on the known UIDs and ignores the unknown UIDs.
> Ok, that's also what I was expecting, but but but .. ;-)
> "from wich point" can we explain the difference with the non-UID
> corresponding command ?? Or there isn't a such way to explain it and we could
> say that this is a "definition" case ?
I don't understand what you are saying here.
Sequences are mathematically calculable values.
UIDs, on the other hand, are values which can only be obtained through
fetching. The entire purpose of allowing non-existant UIDs is to allow a
client to synchronize with a server without having to fetch the entire
UID/sequence map (which you are forced to do with POP3).
Greg
>
> Incorrect. A NO response is a problem in the execution of a valid
> command. A command with bad sequence numbers is an invalid command and
> must get a BAD.
>
> The whole point is that NO means "server condition error" whereas BAD
> means "client bug".
Fine, this is the most "simple" and logical explanation I've never
heard/readed for NO/BAD difference. :-)
>> Ok, that's also what I was expecting, but but but .. ;-)
>> "from wich point" can we explain the difference with the non-UID
>> corresponding command ?? Or there isn't a such way to explain it and
>> we could say that this is a "definition" case ?
>
>
> I don't understand what you are saying here.
indeed I'm not very clear, I would have liked to have an explanation as
simple as the one you just gived for the difference between NO and BAD,
but here for the difference of a (negative or not) response with a UID
and non-UID command type in the case of bad sequence number (or UID)
(even more with "partialy" bad sequence number (or uid) set) used. But,
I've have already understood all (suffisiently I mean ;-)), so let's say
this is all clear.
Again thank you.
Greg.
Mark Crispin
>> The whole point is that NO means "server condition error" whereas BAD means
>> "client bug".
> Fine, this is the most "simple" and logical explanation I've never
> heard/readed for NO/BAD difference. :-)
I'm glad that it makes sense to you now.
It was a lot more obvious before UIDs came into existence.
Here's a way to think about UID commands (UID FETCH, UID STORE, UID COPY);
think of them as being equivalent to a SEARCH for the given UIDs, followed
by a FETCH/STORE/COPY of the sequences in the SEARCH, e.g.
tag UID FETCH 13,56 FLAGS
is like
tag1 SEARCH UID 13,56
* SEARCH 3 5
tag1 OK done!
tag2 FETCH 3,5 FLAGS
UID SEARCH, on the other hand, is an ill-conceived and broken command,
because it returns the same response as SEARCH with no way of knowing
whether the data are sequences or UIDs. UID SEARCH should have been fixed
in RFC 2060 when the other broken commands of RFC 1730 were fixed, but it
was not.