Re: IMAP REPLACE extension

Stu Brandt <[email protected]>
Newsgroups gmane.ietf.imapext
Message-ID <[email protected]>
Comments inline.

On 5/5/15 6:31 PM, Adrien de Croy wrote:
>
> Ok
>
> do you think many / any people would even want to use this with seq
> numbers, or should it be UID REPLACE only?

I'll flip the question back to you...do you think this draft is the 
right place to stop supporting sequence numbers when referring to a 
message in the store?

For a client looking to implement REPLACE, they're likely already in 
Selected mode since their current code needs to do a STORE. Closing the 
door on the use of sequence numbers seemed to be forging an unnecessary 
new path.

So much as I dislike sequence numbers, I did not think this was the 
right vehicle to pursue it.

>
> I don't have a problem with it being in selected state only.  Was just
> trying to explain the rationale.
>
> I guess it is quite different to an APPEND, since that generates a new
> MSGNO and UID, which is not what happens for REPLACE.

Sorry, but that's not the case either. Message bodies are immutable 
things, so not changing UID or MSGNO would break the basic client-server 
model where clients fetch body once, store it locally, and never need to 
ask for body ever again.

I was being somewhat literal when I wrote:

"In its simplest form, the REPLACE command is an atomic encapsulation of 
STORE + UID EXPUNGE + APPEND" in section 2.

The examples in section 3 also show APPENDUID responses to cover the 
factthat the new revision is considered its own message with its own UID.

I suppose I should clarify the examples a bit more with untagged EXISTS 
as well per recommendation of 6.3.11 in rfc3501.

>
> Adrien
>
>

_______________________________________________
imapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imapext
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.