Hi Barry, Sure and sorry to have left off a few people, it was unintentional!
I'll explain where I was confused and think I am looking for a lot less than how you may have interpreted my comments, so this should be fairly easy to resolve. I added my new comments with [KMM] at the start of each line. Thanks, Kathleen ________________________________________ From: [email protected] [[email protected]] On Behalf Of Barry Leiba [[email protected]] Sent: Tuesday, November 20, 2012 4:26 PM To: Moriarty, Kathleen Cc: [email protected]; [email protected]; [email protected]; [email protected]; Alexey Melnikov Subject: Re: Gen-art review of draft-ietf-imapmove-command-02 Hi, Kathleen, and thanks for the review. You left the document shepherd and one of the editors off of the distribution list, so I'm adding them in here. Because of that, I'm not doing the trimming that I'd normally do in my inline reply. On Tue, Nov 20, 2012 at 3:01 PM, Moriarty, Kathleen <[email protected]> wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-imapmove-command-02 > Reviewer: Kathleen Moriarty > Review Date: > IETF LC End Date: > IESG Telechat date: (if known) > > Summary: The document needs a little more work before it is ready and should > address what happens when the series of commands fails to execute (logging, > revert, etc.). This should just result in either an incomplete copy (so > maybe a > garbled message or extra messages being left behind (expunge operations did > not occur). This document does not cover that case and does not point to > another > standard that covers that question. This appears to be a repetition of the "minor issues" below, so I'm responding to it there. > Minor issues: The security consideration section and the main body of the > document do not explain what happens when the series of commands fails to > execute or any associated risks. It should not result in mail being deleted, > but > rather being left in too many places or possible errors if the copy operation > did > not complete (unless that is handled and just needs a refernce)? What "series of commands" are you referring to? The point here is that there's *one* command, MOVE (or UID MOVE), which makes atomic a function that is otherwise done with three separate commands (that cause the problems you're noting, which is why we're creating a single command to do it). Is that really not explained sufficiently? I should think that the Introduction makes this clear. As to what state the single MOVE command leaves things in, this paragraph from Section 3 answers the questions you appear to have: Each message SHOULD either be moved or unaffected. The server MUST NOT leave a message in neither mailbox, and SHOULD NOT leave a message in both mailboxes afterwards, even if the server returns a tagged NO response. Note that these restrictions only apply to individual messages and not to the command as a whole, which can fail partway through. [KMM]: It was the last part of the last sentence that raised the confusion, "which can fail part way through." What happens if it fails partway through? If this is answered in another RFC, can there be a pointer added to the RFC and section? Or do you clarify this to say that a failure partway through is not acceptable? I was reading this last sentence as the MOVE command as a whole contained several operations and one of those operations could fail. See below for more discussion of that. > Nits/editorial comments: > Section 3.3 third paragraph: NOT and neither form a double negative, the > phrase should use either instead of neither: > The server MUST NOT leave a message in either mailbox Absolutely not! The double negative is quite necessary and intentional. One possible outcome if the MOVE of a single message should fail internally would be that the message would be in *neither* mailbox... perhaps the server removed it from the source mailbox before putting it into the target, and there was some internal error, server crash, or power failure at that point. This is saying that such a thing MUST NOT happen. [KMM]: I think the correct grammar is to say either instead of neither and it has the same meaning that you intended. The message would not be in either mailbox. > In the last sentence of this same paragraph, is there a reference to what > happens in the very last clause if the command fails? > "Note that these restrictions only apply to > individual messages and not to the command as a whole, which can fail > partway through." I don't understand what you're asking here either. The MOVE command can operate on a set of messages in one command. The paragraph is saying that it has to operate successfully (that is, as described in the earlier part of the paragraph) on each message, but that the command can fail in the middle, having moved some of the messages but not others. It doesn't have to roll back successful moves if it can't finish the rest. Maybe this would be clearer to you?: These restrictions apply to each message in the set to be moved. If the command fails partway through, some messages might be moved, while others will not have been. [KMM]: Okay, now I am a bit more confused. Can the set of operations fail? Earlier in your response, you say it can't fail. Then here, it says one of the operations can fail. I am fine with either, I just want to make sure it is clear to the reader. Is there any logging required when it fails? If this is specified in another IMAP document, maybe a quick reference would be helpful? > Section 3.3 paragraph 5, can you add more context or clean up the paragraph > to make it easier to follow: > "Note that the server may send EXPUNGEs for other messages as well, if > any happen to have been expunged at the same time; this is normal > IMAP operation." No further context is needed for anyone familiar with IMAP. The IMAP protocol allows the server to send EXPUNGE responses for any message at any time, and this is just a reminder of that. It could be removed, and it would change nothing. But it would be a bad idea to repeat what's explained at length in RFC 3501. [KMM]: By context, I only meant on the wording, not references to other RFCs. Reading through this sentence, it would be helpful to know that you are talking about unrelated expunge operations, at least I think that is what was intended and think it would be helpful to clarify that point with a few extra words. > Section 3.3, paragraph 6: remove duplicate "is allowed": > Change from: > "Note that moving a message to the currently selected mailbox (that > is, where the source and target mailboxes are the same) is allowed > when copying the message to the currently selected mailbox is > allowed." > TO: > "Note that moving a message to the currently selected mailbox (that > is, where the source and target mailboxes are the same) is allowed > when copying the message to the currently selected mailbox." Yes, that probably got left there as the sentence was rephrased. Thanks. > Section 4.3, last sentence: > Replace 'that' with whatever it is referring to as it is not clear to the > reader. > "It can be unnecessarily difficult to process that usefully.)" Would "that sequence" make it clearer for you? [KMM]: Yes, "the sequence" works once you add the word sequence. At the start of the parens, replacing 'it' would be helpful as well. > Section 6, Security Considerations, second paragraph, last sentence (change > with to when): > Change from: > "Scanning with updated rules may > also be required when messages are moved even with the underlying > policy has not changed. > To: > "Scanning with updated rules may > also be required when messages are moved even when the underlying > policy has not changed." Yep; thanks. Barry _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
