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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]