On Wed, 25 Sep 2002 08:34:10 -0700 (PDT)
Mark Crispin <[EMAIL PROTECTED]> wrote:
> On Wed, 25 Sep 2002 07:39:40 -0700, Vladimir A. Butenko wrote:
> > If FETCH 2:2 is legal for a mailbox that contains one message, I do not
> > understand why Fetch 1:1 is illegal in an empty mailbox, or why FETCH 1:*
> >is
>
> > illegal in an empty mailbox.
>
> FETCH 2:2 is *NOT* legal for a mailbox that contains one message. So your
> argument falls apart:
> x select foo
> * 1 EXISTS
> * 1 RECENT
> * OK [UIDVALIDITY 1032968134] UID validity status
> * OK [UIDNEXT 2] Predicted next UID
> * FLAGS (\Answered \Flagged \Deleted \Draft \Seen)
> * OK [PERMANENTFLAGS ()] Permanent flags
> * OK [UNSEEN 1] first unseen message in /u/mrc/foo
> x OK [READ-ONLY] SELECT completed
> y fetch 2:2 flags
> y BAD Bogus sequence in FETCH
>
> FETCH 2:2 is legal for a message that contains two messages. It is
> equivalent
> to FETCH 2.
>
> On the other hand...
>
> UID FETCH 2:2 is legal for all mailboxes.
> UID FETCH 1:1 is legal for all mailboxes.
> UID FETCH 1:* is legal for all mailboxes.
>
> Do you see the pattern?
I see the pattern in your letter. I do not see anything resenbling this
pattern in the RFC2060.
Note: the phrase
; Identifies a set of messages. For message
; sequence numbers, these are consecutive
; numbers from 1 to the number of messages in
; the mailbox
specifies what the sequence numbers are (hint: the word "consecutive"). It
has NOTING to do with specification of:
set = sequence-num / (sequence-num ":" sequence-num) /
(set "," set)
and this:
; Comma delimits individual numbers, colon
; delimits between two numbers inclusive. Note
; that n:m and m:n are equivalent.
; Example: 2,4:7,9,12:* is 2,4,5,6,7,9,12,13,
; 14,15 for a mailbox with 15 messages.
is not a proper declaration either:
a) it means that the comma cannot delimit to "ranges" (the note about this
was sent to you separately and I see that you are addressing this now)
b) it does not specify what all those numbers are.
You either assume that the reader of this document knows at least the
elementary school mathematics, and knows the STRICT meaning of the words
"set", "sequence", etc., or - as your letters imply - you assume that the
reader is a CS graduate who has already forgotten even the basics, and in
this case you need to explain that:
a) "1,1,1,1,1" is not an error and is the same as "1"
b) "1,3,2" is not an error and is the same as "1,2,3"
c) "1:5,2:6" is not an error and is the same as "1:6"
Finally, if your interpretation of the RFC2060 leads to the statement that
FETCH 2 in a mailbox that has less than 2 messages is an error, the standard
should specify that explicitly - as I cannot get it from the current RFC -
the "from 1 to the number of messages" clause specifies what the sequence
numbers IN THE MAILBOX are, not what a client can specify in the request.
The standard says: sequence-num = nz-number / "*", i.e. one can specify
any nz-number as the sequence-num
Suggestion:
seq_number := number
;; a number in the [1..N] range where N is the current
;; number of messages in the mailbox
seq_spec_number: = seq_number / "*"
;; "*" is equvalent to number N, where
;; N is the current number of messages in the mailbox.
;; "*" cannot be used in an empty mailbox
seq_subset_elem: = seq_spec_number / (seq_spec_number ":" seq_spec_number)
;; if M <= N, then the M:N is a set of all numbers
;; not smaller than M and not greater than N
;; if M > N, the M:N is equivalent to N:M
seq_subset: = seq_subset_elem / (seq_subset_elem "," seq_subset)
;; seq_subset includes all numbers
;; from all seq_subset_elem separated with the "," sign.
;; seq_subset_elems are not required to be ordered and
;; several seq_subset_elems can include the same
number(s)
The "UID_seq_subset" should be specified in the same way, with all "implied"
things clearly and explictily formulated.
Currently, all we have is the phrase "Unique identifiers used instead of
message sequence numbers", but then if it is not an error to specify
[UID] 2:2 in a mailboxe where the largest UID is 1, then it's inexplicable
why 2:2 specified as a sequence number subset has to produce an error.
Note: the word "subset" used here. It is not "met all over the document",
and it clearly specifies what all those 1,2:3,4:100 things do - they specify
a SUBset of the set of messages in the mailbox.
About BAD:
There are
three possible server completion responses: OK (indicating success),
NO (indicating failure), or BAD (indicating protocol error such as
unrecognized command or command syntax error).
If FETCH 2:2 cannot be used right now, becase we have only one message in
that mailbox, it is a failure, not an "unrecognized command" or "command
syntax error" (even if we say in the syntax rules that seq_numbers used in
the seq_subset should be not greater than the # of messages in the mailbox -
it's not a syntax rule).
Compare to other portions of that same standard: If we do not have a mailbox
ZZZ, then the SELECT ZZZ command should return the "NO" response -
NO - select failure, now in authenticated state: no
such mailbox, can't access mailbox
because the ZZZ mailbox can be created at any moment, and that command would
succeed that time. In the same way, the message #2 can appear in our mailbox
at any time, and the FETCH 2:2 command will succeed at that time.
This (the definition of NO and BAD responses) should also be improved.
Suggestion:
If a received command can NEVER be accepted by the server (because it
contains an unrecognized command or the command syntax is incorrect), the
server should respond with the "BAD" response. If the failure is caused by
the current state of the session (SELECT in unauthenticated state, etc.) or
by the current state of the mailbox store (no such mailbox, no such
message), the server should respond with the "NO" response.
> IMAP has not done so for 17 years. This has been a useful debugging
> feature.
> It would declare current servers to be non-compliant.
>
> I see no benefit in doing this.
Our servers allow FETCH 2:2 in a mailbox that has zero or 1 message, and I
will say that they are compliant with the current version of the RFC. It
does not mean that we refuse to change this, but in order to justify such a
change, the standard should CLEARLY say what a "message subset" is and how
it can be composed. The same applies to the clause saying that M:N range and
N:M ranges are the same - in spite of the fact that we have changed our code
by your request, the current RFC standard has NO such requirement.
> > C: .....
> > S: 1 EXISTS
> > S: aaaa OK
> > C: bbbb FETCH * (FLAGS BODY[HEADER.FIELDS ({4}+
> > * 1 EXPUNGE
> > + proceed
> > DATE
> > FROM)])
>
> This scenario is prohibited in section 7.4.1.
Yes, my fault. It is prohibited. Then change it to:
C: .....
S: 1 EXISTS
S: aaaa OK
C: bbbb FETCH * (FLAGS BODY[HEADER.FIELDS ({4}+
* 2 EXISTS
+ proceed
DATE
FROM)])
Which message will the client get? It is bad to say that it is
implementation-dependant, because it does affect many clients - it's just
not a situation that happens too often, but still. If this is specified,
then that specification will provide the answer to the following Q - what's
the server response in this case? -
C: .....
S: 1 EXISTS
S: aaaa OK
C: bbbb FETCH 2 (FLAGS BODY[HEADER.FIELDS ({4}+
* 2 EXISTS
+ proceed
DATE
FROM)])
> > I seriously doubt that many clients do process untagged responses that
> >are
> > send together with continuation requests. Because of the troubles this
> > "feature" provides, I'd suggest its removal from the IMAP standard (i.e.
> >no
> > untagged responses can be sent with continuation requests).
>
> Every application built with c-client handles this.
Sorry, I have not seen many applications built on that "c-client". And the
fact is that the standard should be STANDARD, not a brief description of
some software package functionality.
> That's a lot of clients (don't forget that PHP uses c-client).
I saw very many clients - commercial and custom-built, and none of them used
that c-client, but it's not the point: the point is that the purpose of the
standard is to specify the way how the things should work, and the protocols
specs should either avoid situations that are traps (like this one), or
explicitly specify how to deal with those situations.
> Among other things, this facility is used by IDLE.
No, it is not:
It is also possible for the server to send a completion
response for some other command (if multiple commands are
in progress), or untagged data. In either case, the
command continuation request is still pending; the client
takes the appropriate action for the response, and reads
another response from the server. In all cases, the client
MUST send a complete command (including receiving all
command continuation request responses and command
continuations for the command) before initiating a new
command.
This implies ("command continuation request is still pending") that untagged
data can only be sent BEFORE the continuation request line (the + line).
BTW, it means that the word "before" must be used here, not the word "with".
When the IDLE command is in progress, the continuation request is sent
immediately, and untagged data is sent AFTER that request. It's a completely
different case:
The IDLE command is sent from the client to the server when the
client is ready to accept unsolicited mailbox update messages. The
server requests a response to the IDLE command using the continuation
("+") response. The IDLE command remains active until the client
responds to the continuation, and as long as an IDLE command is
active, the server is now free to send untagged EXISTS, EXPUNGE, and
other messages at any time.
Sincerely,
Vladimir
