Spencer Dawkins wrote:
Hi, Alexey,
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Thanks, and Happy New Year,
Hi Spencer,
Thank you for the review. I am on holidays at the moment, so in this
reply I will mostly answer to your comments/questions marked as "protocol".
Upon successful completion of a SELECT or an EXAMINE command (after
the tagged OK response), the current search result variable is reset
to the empty sequence.
Spencer (protocol) - I'd like to better understand why this design choice
was made. This statement seems to conflict with text in the next
paragraph, so I'm not exactly sure what's going on here.
A successful SEARCH command with the SAVE result option sets the
value of the search result variable to the list of messages found in
the SEARCH command. For example, if no messages were found, the
search result variable will contain the empty list. A SEARCH command
that caused the server to return BAD tagged response, a SEARCH
command with no SAVE result option that caused the server to return
NO tagged response, or a successful SEARCH command with no SAVE
result option MUST NOT change the search result variable. A SEARCH
Spencer (protocol) - I'm now confused. The previous paragraph says
"reset to
the empty sequence" upon successful completion of a SELECT command,
but this
is saying that "a successful SEARCH command with no SAVE result option
MUST
NOT change the search result variable" - what am I missing?
I am not sure what is the cause of your confusion. Let me try to explain
the extension in more details, maybe this will help.
IMAP is a stateful protocol: before a client can perform any message
operation (such as SEARCH or FETCH), a mailbox must be selected with a
SELECT or an EXAMINE command.
The standard SEARCH command is not affected by this extension. A SEARCH
(SAVE) is a variant of a standard SEARCH command that tells the server
that it should remember the result of the search. The two variants exist
so that a client that doesn't care about using results of a SEARCH in
another command doesn't make the server do extra work.
Once a mailbox is closed (explicitly or implicitly, when another mailbox
is selected), the list of saved messages is no longer valid, because
different mailboxes have different messages.
I chose to invalidate the list on SELECT/EXAMINE (as opposed to on CLOSE
which is a command to close the currently selected mailbox), because no
SEARCH command can be executed before a SELECT/EXAMINE.
(I'm actually OK
with the "no messages" and "BAD tagged response" exceptions, but the
successful case seems to contradict the previous paragraph)
[...]
2.1. Examples
The client can also pipeline the two commands:
Example 2:
C: A282 SEARCH RETURN (SAVE) FLAGGED SINCE 1-Feb-1994
NOT FROM "Smith"
C: A283 FETCH $ (UID INTERNALDATE FLAGS RFC822.HEADER)
S: A282 OK SEARCH completed
S: * 2 FETCH (UID 14 ...
S: * 84 FETCH (UID 100 ...
S: * 882 FETCH (UID 1115 ...
S: A283 OK completed
Spencer (protocol) - I'm not seeing any description of how pipelined
commands deal with first-command failure - is this relevant?
A failed SEARCH (SAVE) command doesn't change the list of saved messages.
(does the server execute the second command if the first command
generates a
BAD-tagged response?
Yes.
However, in general in IMAP the server doesn't return BAD response
unless the client does something wrong, i.e. uses invalid syntax or
unrecognized extension. So a well written client should never see a BAD
response.
The server can return NO response, which means any other type of
failure. This response is quite rare and is almost never returned in
response to a SEARCH command.
Handling of pipelining errors is a general issue in IMAP, not specific
to this extension. For example, a client can pipeline SELECT with a
SEARCH, if SELECT fails, the SEARCH would fail as well, as no mailbox
would be selected at this point.
etc)
2) The following example demonstrates that the result of one SEARCH
command can be used to subset the result of another SEARCH
command:
Example 3:
C: A300 SEARCH RETURN (SAVE) SINCE 1-Jan-2004
NOT FROM "Smith"
S: A300 OK SEARCH completed
C: A301 UID SEARCH UID $ SMALLER 4096
S: * SEARCH 17 900 901
S: A301 OK completed
Note that the second command in Example 3 can be replaced with:
C: A301 UID SEARCH $ SMALLER 4096
and the result of the command would be the same.
Spencer (readability) - I didn't quite follow this. I think what
confused me
is the introductory text - isn't this example demonstrating "that the
result
of one SEARCH command can be used as input to a second SEARCH command"?
"Subset" as written seemed to say that the first result was taking an
action
("subset"), but it's just input to the second SEARCH...
Correct. This is what I called subsetting. I agree that this might be
confusing.
2.2. Multiple Commands in Progress
Spencer (readability) - could you insert a sentence that introduces
Example
7 and explains what you illustrate in this example? (Is it only what the
//comment says?
Yes.
) (same for Example 8)
[...]
4. Security Considerations
This extension requires the server to keep additional state, that may
be used to simplify Deny of Service attacks. In order to minimize
damage from such attacks server implementations MAY limit the number
of saved searches they allow across all connections at any given time
and return the tagged NO response to a SEARCH RETURN (SAVE) command
when this limit is exceeded.
Spencer (readability) - I'm guessing there is no way for a client to
discover this is the reason for the tagged NO response?
This is not entirely true. Various commands can return addition
information with NO response (such information is called "response code").
I can define a new response code for this case.
but it might be nice
to say so explicitly. Just curious - is this what an IMAP server would do
today, when it detects a DoS attack (by an attacker who's just working
harder)? If so, it might be nice to point that out, too.
I am not sure what you are suggesting here.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf