[Gen-art] Re: Gen-ART Last Call Review of draft-melnikov-imap-search-res-06.txt

[Alexey Melnikov <[e-mail]>]

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.




_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art