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