Thank you, Barry! I appreciate your patience on this and suggestions. I am in the middle of some developers working on RFCs in MILE and the comments are leading me to be very specific... and I think they are obvious too.
I like all of your suggestions below. For the second to last one, another alternate option closer to the original text for the editors to consider would be: OLD 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. NEW Note that the server may send unrelated EXPUNGE messages as well, if any happen to have been expunged at the same time; this is normal IMAP operation. Thanks, Kathleen BTW, I can configure a sendmail.cf by hand, but have never programmed IMAP server code. :-) ________________________________________ From: [email protected] [[email protected]] On Behalf Of Barry Leiba [[email protected]] Sent: Tuesday, November 20, 2012 5:40 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 > 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. Got it. Then this is really overlapping with this discussion, moved up from below: > 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? I don't think we ever refer to "operations", so I'm still not sure what you're confused about, but I am sure that you're confused. So let's try to sort that out. The MOVE command can move a set of messages. If the client sends "MOVE 1:50 Banana", that's asking the server to move the first 50 messages from the currently selected mailbox into the mailbox called "Banana". Let's suppose that the currently selected mailbox is called "Apple". The paragraph in question, so we have the context here, says this: 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. What that paragraph is *trying* to tell you is this: The MOVE command has to leave each message in a reasonable state. That means that for each message in the message set ("1:50"), either the message should be moved, or the message should be unaffected (sentence 1). For each message in the message set, the server MUST NOT make it disappear from both Apple and Banana, and SHOULD NOT leave it in *both* Apple and Banana (sentence 2). This stuff applies to each message individually... it's allowable for the server to fail to move all 50 messages, as long as the previous two sentences apply. Do you (think you) understand *that*? I'll propose a reformulation of that paragraph in a moment, but first... >> 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. I think you're wrong. "MUST NOT be in either mailbox" would mean that it's not in Apple and it's also not in Banana. Which is what you say in your last comment, but it's not what we're trying to say. There's nothing grammatically or semantically wrong with the sentence as written, and it says exactly what it's meant to say: that you MUST NOT have the message be not in Apple and also not in Banana -- you have to make sure it remains in one or the other. Notwithstanding that it's correct, if a native English speaker can't understand it, then it needs to be re-written (though we thought it was nice and elegant as it is; sigh -- elegance has to give way to understanding). If I re-write the whole paragraph like this, is the whole thing clearer to you?: Because a MOVE applies to a set of messages, it might fail partway through the set. Regardless of whether the command is successful in moving the entire set, each individual message SHOULD either be moved or unaffected. The server MUST leave each message in a state where it is in at least one of the source or target mailboxes (no message can be lost or orphaned). The server SHOULD NOT leave any message in both mailboxes (it would be bad for a partial failure to result in a bunch of duplicate messages). This is true even if the server returns a tagged NO response to the command. >> 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. Hm. I'm still thinking that this is entirely unnecessary, because, really, anyone familiar enough with IMAP to consider implementing this will know exactly what this means. I'll propose something, and we'll see if the editors think it's useful to change: OLD 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. NEW It is always the case in normal IMAP operation that the server might also send EXPUNGE responses that are not related to the MOVE, such as for other messages that happen to have been expunged at the same time. >> 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. NEW (Sending COPYUID in the tagged OK, as described in the UIDPLUS specification, means that clients first receive an EXPUNGE for a message and afterwards COPYUID for the same message. It can be unnecessarily difficult to process that sequence usefully.) Barry _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
