Re: IMAP REPLACE extension

------ Original Message ------
From: "Stu Brandt" <[email protected]>
To: "Adrien de Croy" <[email protected]>; "'[email protected]'" 
<[email protected]>
Sent: 6/05/2015 10:59:31 a.m.
Subject: Re: [imapext] IMAP REPLACE extension

>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?
fair enough.

But I think it could be justifiable at some stage to take a position 
that certain extensions are only available using UIDs.  It's optional 
after all.  In fact wasn't MOVE debated around this point, re safety 
thereof?  I guess MOVE is special in that potentially 2 mailboxes are 
involved.

>
>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.
commonly in drafts folder it will actually end up with the same MSGNO 
but I guess there will be an expunge notification in between.

>
>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.

OK.


>
>I suppose I should clarify the examples a bit more with untagged EXISTS 
>as well per recommendation of 6.3.11 in rfc3501.
Sorry I should do more than just glance over the draft before 
commenting.

Cheers

Adrien


>
>>
>>Adrien
>>
>>

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