Re: IMAP REPLACE extension

Pete -

Thanks for your response. My comments are inline.

On 5/5/15 2:35 PM, Pete Maclean wrote:
> Stu,
>
> This is a good start indeed but I find a few things to mention.
>
> Is UID REPLACE valid in the authenticated state?  My assumption would be
> that it is but it might be good for the text to make that explicit.

I was hoping that section 3.5 would have covered that. Specifically my 
statement of...

  "Unlike the APPEND command which is valid in the authenticated state,
    the REPLACE command MUST only be valid in the selected state. "

...was intended to answer your question. In my proposal, I'm intending 
to say it's valid ONLY in SELECTED state.  Does that wording cover it 
for you or can you help detail the ambiguity in the wording?

>
> Can REPLACE be used to replace a message in a mailbox other than the one
> the client has selected?  Surely it should not be.  Which perhaps
> suggests that REPLACE should not have a mailbox-name argument.

Yeah, I spent a lot of time going back and forth on this question.
Ultimately where I ended up is that since the problems that REPLACE 
solves (specified in section 2) exist regardless of whether the new 
message ends up in the same mailbox or a different one, I chose not to 
restrict the new message to the selected mailbox.

As an aside, there is at least 1 common use case I can think of where 
I'd want to replace a message in one mailbox with a message in an 
entirely different mailbox; replacing the final version of a message in 
Drafts with a message in Sent following a successful send. Together with 
CATENATE, REPLACE as written could be quite useful in this case.

>
> The penultimate paragraph in section 3.4 strikes me as awkward and unclear.

It's trying to provide more details around what a server might need to 
do in order to be truly atomic in implementing REPLACE. Things like 
don't fail REPLACE but then show the original message with the /Deleted 
flag. Or don't fail REPLACE *after* you've already sent an untagged 
EXPUNGE. Or don't fail REPLACE but then change MODSEQ and NEXTUID in a 
way that would make the client think it missed some kind of change. Or 
don't fail REPLACE after having sent untagged EXISTS to other clients in 
IDLE. This list goes on, but basically:
1) Don't leave selected mailbox in an altered state if it fails
2) Don't send untagged responses if it fails
3) Don't leave the target mailbox in an altered state if it fails

Does that make sense?


>
> There is a typo ("replacment") in the first paragraph of the Abstract.

Thank you. It'll be corrected in next version.

>
> Pete Maclean
>

_______________________________________________
imapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imapext