Subject: Re: CONDSTORE plus UID EXPUNGE undefined?
From: Arnt Gulbrandsen <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>
Cc: Bron Gondwana <[email-masked]>, [email-masked]
Date: Thu, 29 Mar 2012 12:45:00 +0200
List-Id: <ietf-imapext.imc.org>

On 03/29/2012 12:40 PM, Adrien W. de Croy wrote:
> it's just that looking in my code I have 2 options.
>  
> 1. nest locks in the case of non UID MOVE.
> 2. reply to non-UID MOVE with BAD.
>  
> Since this is still a draft, we could solve that problem right now :)

The draft as it stands only defines UID MOVE, not an MSN-based command,
so you're good.

Arnt

From: "Adrien W. de Croy" <[email-masked]>
To: "Arnt Gulbrandsen" <[email-masked]>
Subject: Re: CONDSTORE plus UID EXPUNGE undefined?
Cc: "Bron Gondwana" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 29 Mar 2012 10:40:56 +0000
Reply-To: "Adrien W. de Croy" <[email-masked]>
Sender: [email-masked]

------ Original Message ------
From: "Arnt Gulbrandsen" <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>
Cc: "Bron Gondwana" <[email-masked]>;"[email-masked]" 
<[email-masked]>
Sent: 29/03/2012 11:36:09 p.m.
Subject: Re: CONDSTORE plus UID EXPUNGE undefined?
>On 03/29/2012 12:28 PM, Adrien W. de Croy wrote:
>
>>
>>it probably means though that only UID MOVE is safe.
>>
>
>
>Depends on the server and on how much time the server maintainer wants
>to spend on move.
>
>
>>
>>do we really need a non-UID MOVE?
>>
>
>
>You can restate that question as "how many clients prefer MSN-based
>commands and offer move in their UI" and my answer is "none that I know of".
>
  
it's just that looking in my code I have 2 options.
  
1. nest locks in the case of non UID MOVE.
2. reply to non-UID MOVE with BAD.
  
Since this is still a draft, we could solve that problem right now :)
  
Adrien

>
>
>Arnt
>
>
>

Date: Thu, 29 Mar 2012 12:36:09 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>
Cc: Bron Gondwana <[email-masked]>, [email-masked]
Subject: Re: CONDSTORE plus UID EXPUNGE undefined?
Sender: [email-masked]

On 03/29/2012 12:28 PM, Adrien W. de Croy wrote:
> it probably means though that only UID MOVE is safe.

Depends on the server and on how much time the server maintainer wants
to spend on move.

> do we really need a non-UID MOVE?

You can restate that question as "how many clients prefer MSN-based
commands and offer move in their UI" and my answer is "none that I know of".

Arnt

From: "Adrien W. de Croy" <[email-masked]>
To: "Arnt Gulbrandsen" <[email-masked]>
Subject: Re: CONDSTORE plus UID EXPUNGE undefined?
Cc: "Bron Gondwana" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 29 Mar 2012 10:28:34 +0000
Reply-To: "Adrien W. de Croy" <[email-masked]>
Sender: [email-masked]

it probably means though that only UID MOVE is safe.
  
do we really need a non-UID MOVE?

------ Original Message ------
From: "Arnt Gulbrandsen" <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>
Cc: "Bron Gondwana" <[email-masked]>;"[email-masked]" 
<[email-masked]>
Sent: 29/03/2012 11:16:09 p.m.
Subject: Re: CONDSTORE plus UID EXPUNGE undefined?
>Bron is right, at least for some architectures. But his argument is
>really the same as I've heard umpteen times for move: Carrying out the
>copy/store/expunge sequence without the lock COPY can drop early has too
>many failure modes and handling them requires too much clientside code.
>
>Having a lock gives you the advantages of the lock at the cost of the lock.
>
>Arnt
>
>

From: "Adrien W. de Croy" <[email-masked]>
To: "Arnt Gulbrandsen" <[email-masked]>
Subject: Re: CONDSTORE plus UID EXPUNGE undefined?
Cc: "Bron Gondwana" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 29 Mar 2012 10:25:49 +0000
Reply-To: "Adrien W. de Croy" <[email-masked]>
Sender: [email-masked]

actually we don't nest locks in our implementation of move for this 
very reason.  
  
but for a DB-based index, move can be as simple as an update query on 
the folder field for a message.
  
Adrien

------ Original Message ------
From: "Arnt Gulbrandsen" <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>
Cc: "Bron Gondwana" <[email-masked]>;"[email-masked]" 
<[email-masked]>
Sent: 29/03/2012 11:16:09 p.m.
Subject: Re: CONDSTORE plus UID EXPUNGE undefined?
>Bron is right, at least for some architectures. But his argument is
>really the same as I've heard umpteen times for move: Carrying out the
>copy/store/expunge sequence without the lock COPY can drop early has too
>many failure modes and handling them requires too much clientside code.
>
>Having a lock gives you the advantages of the lock at the cost of the lock.
>
>Arnt
>
>

Date: Thu, 29 Mar 2012 12:16:09 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>
Cc: Bron Gondwana <[email-masked]>, [email-masked]
Subject: Re: CONDSTORE plus UID EXPUNGE undefined?
Sender: [email-masked]

Bron is right, at least for some architectures. But his argument is
really the same as I've heard umpteen times for move: Carrying out the
copy/store/expunge sequence without the lock COPY can drop early has too
many failure modes and handling them requires too much clientside code.

Having a lock gives you the advantages of the lock at the cost of the lock.

Arnt

From: Robert Mueller <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>, Bron Gondwana <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: CONDSTORE plus UID EXPUNGE undefined?
Date: Thu, 29 Mar 2012 08:04:32 +1100
Sender: [email-masked]

> >With MOVE, you need to hold the lock on the first mailbox until
> >after the APPEND has succeeded, then come back and EXPUNGE them.
>   
> it can be optimised for MOVE.  Since you don't need to do a deep file 
> copy, but a file system move, as long as the dest folder is in the same 
> volume as the source, it's usually a very quick operation - much 
> quicker than copy.  Worst case it takes the same time if different 
> volumes.

Assuming you're using a "1 file = 1 email" model, then most filesystems
that support move, also support hardlinks, so a copy is actually
*cheaper* than a move, because you're just adding an extra link, and
adding links is usually a lot cheaper than unlinking.

In fact unlinks are usually sufficiently poorly optimised in
filesystems, that we explicitly added a "delayed expunge" mode to cyrus,
that allows us to push the unlink actions off into the future (eg
weekends) because they completely dominate the time on large expunges
otherwise.

> So the 2 locks are held a short time only.

It's not that they're short time only, it's that it can cause deadlocks
because for a move to be atomic, you have to have both locks at the same
time, while with copy you can get/drop them sequentially.

Rob

From: "Adrien W. de Croy" <[email-masked]>
To: "Bron Gondwana" <[email-masked]>, "Arnt Gulbrandsen" <[email-masked]>
Subject: Re: CONDSTORE plus UID EXPUNGE undefined?
Cc: "[email-masked]" <[email-masked]>
Date: Wed, 28 Mar 2012 18:09:23 +0000
Reply-To: "Adrien W. de Croy" <[email-masked]>
Sender: [email-masked]

------ Original Message ------
From: "Bron Gondwana" <[email-masked]>
To: "Arnt Gulbrandsen" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: 29/03/2012 1:54:43 a.m.
Subject: Re: CONDSTORE plus UID EXPUNGE undefined?
>On Wed, Mar 28, 2012 at 02:21:54PM +0200, Arnt Gulbrandsen wrote:
>
>>
>>
>>On 03/27/2012 02:44 AM, Adrien W. de Croy wrote:
>>> This I guess belongs in the MOVE I-D in terms of reference to CONDSTORE.
>>>
>>> Are there any plans to progress that draft?  It's quite worthwhile IMO.
>>
>>There have been many. I uploaded one now, with text from Witold, Alexey
>>and myself.
>>
>>http://tools.ietf.org/html/draft-gulbrandsen-imap-move
>>
>

great, thanks!
>
>
>  Servers may want to avoid implementing this because atomicity
>  requires holding one or more locks on several mailboxes at the same
>  time.  (This sounds just wrong. COPY requires the same.)
>
>No, COPY doesn't.  You can release the lock on the first mailbox
>after taking all the data required, then obtain the lock on the
>second mailbox.  At this point, it doesn't matter if someone else
>does something to your source messages.
>
>With MOVE, you need to hold the lock on the first mailbox until
>after the APPEND has succeeded, then come back and EXPUNGE them.
>
>

  
it can be optimised for MOVE.  Since you don't need to do a deep file 
copy, but a file system move, as long as the dest folder is in the same 
volume as the source, it's usually a very quick operation - much 
quicker than copy.  Worst case it takes the same time if different 
volumes.
  
So the 2 locks are held a short time only.

>
>Bron.
>
>
>

Date: Wed, 28 Mar 2012 23:54:43 +1100
From: Bron Gondwana <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked]
Subject: Re: CONDSTORE plus UID EXPUNGE undefined?
Organization: brong.net
Sender: [email-masked]

On Wed, Mar 28, 2012 at 02:21:54PM +0200, Arnt Gulbrandsen wrote:
> 
> On 03/27/2012 02:44 AM, Adrien W. de Croy wrote:
> > This I guess belongs in the MOVE I-D in terms of reference to CONDSTORE.
> >  
> > Are there any plans to progress that draft?  It's quite worthwhile IMO.
> 
> There have been many. I uploaded one now, with text from Witold, Alexey
> and myself.
> 
> http://tools.ietf.org/html/draft-gulbrandsen-imap-move

   Servers may want to avoid implementing this because atomicity
   requires holding one or more locks on several mailboxes at the same
   time.  (This sounds just wrong. COPY requires the same.)

No, COPY doesn't.  You can release the lock on the first mailbox
after taking all the data required, then obtain the lock on the
second mailbox.  At this point, it doesn't matter if someone else
does something to your source messages.

With MOVE, you need to hold the lock on the first mailbox until
after the APPEND has succeeded, then come back and EXPUNGE them.

Bron.

Date: Wed, 28 Mar 2012 14:21:54 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: CONDSTORE plus UID EXPUNGE undefined?
Sender: [email-masked]

On 03/27/2012 02:44 AM, Adrien W. de Croy wrote:
> This I guess belongs in the MOVE I-D in terms of reference to CONDSTORE.
>  
> Are there any plans to progress that draft?  It's quite worthwhile IMO.

There have been many. I uploaded one now, with text from Witold, Alexey
and myself.

http://tools.ietf.org/html/draft-gulbrandsen-imap-move

Arnt

Date: Tue, 27 Mar 2012 13:42:30 +1100
From: Bron Gondwana <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>
Cc: Bron Gondwana <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Re[2]: CONDSTORE plus UID EXPUNGE undefined?
Organization: brong.net
Sender: [email-masked]

On Tue, Mar 27, 2012 at 12:44:35AM +0000, Adrien W. de Croy wrote:
> Looks like our issue related to MOVE + CONDSTORE.
> 
> Since MOVE doesn't do an untagged FETCH response advertising \Deleted
> on the source, but instead only sends untagged EXPUNGE responses, it's
> not clear about incrementing HMS.
> 
> The obvious behaviour is to increment HMS.
> 
> This I guess belongs in the MOVE I-D in terms of reference to CONDSTORE.
> 
> Are there any plans to progress that draft?  It's quite worthwhile IMO.

Agree that it's worthwhile.  We're already using it internally for our
web interface talking to the Cyrus backends.

My attitude to HMS is - if anything user-visible changes, the HMS must
be bumped such that a client connection can never see two different
responses with exactly the same HMS.  Idempotency is good.

Bron.

From: "Adrien W. de Croy" <[email-masked]>
To: "Bron Gondwana" <[email-masked]>
Subject: Re[2]: CONDSTORE plus UID EXPUNGE undefined?
Cc: "[email-masked]" <[email-masked]>
Date: Tue, 27 Mar 2012 00:44:35 +0000
Reply-To: "Adrien W. de Croy" <[email-masked]>
Sender: [email-masked]

Looks like our issue related to MOVE + CONDSTORE.
  
Since MOVE doesn't do an untagged FETCH response advertising \Deleted 
on the source, but instead only sends untagged EXPUNGE responses, it's 
not clear about incrementing HMS.
  
The obvious behaviour is to increment HMS.
  
This I guess belongs in the MOVE I-D in terms of reference to CONDSTORE.
  
Are there any plans to progress that draft?  It's quite worthwhile IMO.
  
Adrien

------ Original Message ------
From: "Bron Gondwana" <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: 27/03/2012 1:30:27 p.m.
Subject: Re: CONDSTORE plus UID EXPUNGE undefined?
>On Tue, Mar 27, 2012 at 12:13:00AM +0000, Adrien W. de Croy wrote:
>
>>
>>Hi all
>>
>>Apologies if this is covered somewhere and I missed it.
>>
>>I've been reviewing behaviour of HIGHESTMODSEQ wrt UID EXPUNGE.
>>
>>My gut feel is that the intent of CONDSTORE would be that the
>>HIGHESTMODSEQ be incremented if a UID EXPUNGE results in any messages
>>being removed from a mailbox.
>>
>
>
>Absolutely.  In fact, if you look at QRESYNC, it not only needs to
>increment the HIGHESTMODSEQ, it has to increment the MODSEQ of the
>message being expunged so that you can give a VANISHED response.
>
>
>>
>>If we shouldn't increment HMS on UID EXPUNGE, then the HIGHESTMODSEQ
>>becomes unreliable as an indication that anything changed on a
>>mailbox, since a UID EXPUNGE may have removed messages. I'd like
>>clients to be
>>able to rely on HMS as an indication that ANY work is required or not
>>to resynch.
>>
>
>
>You can increment HMS by however much you like, whenever you want, and
>still be compatible... it could be that something has changed which the
>client just didn't ask for.
>
>Bron ( until you run out of 64 bits anyway )
>
>
>

Date: Tue, 27 Mar 2012 11:30:27 +1100
From: Bron Gondwana <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: CONDSTORE plus UID EXPUNGE undefined?
Organization: brong.net
Sender: [email-masked]

On Tue, Mar 27, 2012 at 12:13:00AM +0000, Adrien W. de Croy wrote:
> Hi all
> 
> Apologies if this is covered somewhere and I missed it.
> 
> I've been reviewing behaviour of HIGHESTMODSEQ wrt UID EXPUNGE.
> 
> My gut feel is that the intent of CONDSTORE would be that the
> HIGHESTMODSEQ be incremented if a UID EXPUNGE results in any messages
> being removed from a mailbox.

Absolutely.  In fact, if you look at QRESYNC, it not only needs to
increment the HIGHESTMODSEQ, it has to increment the MODSEQ of the
message being expunged so that you can give a VANISHED response.

> If we shouldn't increment HMS on UID EXPUNGE, then the HIGHESTMODSEQ
> becomes unreliable as an indication that anything changed on a
> mailbox, since a UID EXPUNGE may have removed messages. I'd like
> clients to be
> able to rely on HMS as an indication that ANY work is required or not
> to resynch.

You can increment HMS by however much you like, whenever you want, and
still be compatible... it could be that something has changed which the
client just didn't ask for.

Bron ( until you run out of 64 bits anyway )

From: "Adrien W. de Croy" <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: CONDSTORE plus UID EXPUNGE undefined?
Date: Tue, 27 Mar 2012 00:22:56 +0000
Reply-To: "Adrien W. de Croy" <[email-masked]>
Sender: [email-masked]

--------=_MB0BC11C23-792B-4534-8D89-DCAF7E9638FF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; format=flowed; charset=utf-8

sorry, looks like it's covered in UIDPLUS, since UID EXPUNGE must only 
affect messages with \Deleted.
  
therefore setting \Deleted will already affect HMS
  
Adrien

------ Original Message ------
From: "Adrien W. de Croy" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: 27/03/2012 1:13:00 p.m.
Subject: CONDSTORE plus UID EXPUNGE undefined?
>Hi all
> 
>Apologies if this is covered somewhere and I missed it.
> 
>I've been reviewing behaviour of HIGHESTMODSEQ wrt UID EXPUNGE.
> 
>My gut feel is that the intent of CONDSTORE would be that the 
>HIGHESTMODSEQ be incremented if a UID EXPUNGE results in any messages 
>being removed from a mailbox.
> 
>However in RFC4551 I can find no mention of what to do upon UID 
>EXPUNGE. Since there is no STORE beforehand, we can't rely on 
>processing associated with that.
> 
>If we shouldn't increment HMS on UID EXPUNGE, then the HIGHESTMODSEQ 
>becomes unreliable as an indication that anything changed on a 
>mailbox, since a UID EXPUNGE may have removed messages. I'd like 
>clients to be able to rely on HMS as an indication that ANY work is 
>required or not to resynch.
> 
>Or is there another proposed way to do this?
>
>Regards
> 
>Adrien

--------=_MB0BC11C23-792B-4534-8D89-DCAF7E9638FF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=utf-8

<HTML><HEAD>
<STYLE id=3DeMClientCss>blockquote.cite { margin-left: 5px; margin-right: 0=
px; padding-left: 10px; padding-right:0px; border-left: 1px solid #000000 }=

.plain pre { font-family: monospace; font-size: 100%; font-weight: normal; =
font-style: normal; }
body {font-family: Tahoma;font-size: 12pt;}
.plain pre {font-family: Tahoma;font-size: 12pt;}

#44c5894d81234174a65b849bb07ddccb BLOCKQUOTE.cite
{BORDER-LEFT: #000000 1px solid; PADDING-LEFT: 10px; PADDING-RIGHT: 0px; MA=
RGIN-LEFT: 5px; MARGIN-RIGHT: 0px}
#44c5894d81234174a65b849bb07ddccb .plain PRE
{FONT-STYLE: normal; FONT-FAMILY: monospace; FONT-SIZE: 100%; FONT-WEIGHT: =
normal}
#44c5894d81234174a65b849bb07ddccb 
{FONT-FAMILY: Tahoma; FONT-SIZE: 12pt}
#44c5894d81234174a65b849bb07ddccb .plain PRE
{FONT-FAMILY: Tahoma; FONT-SIZE: 12pt}</STYLE>
</HEAD>
<BODY background=3D"" scroll=3Dauto class>
<DIV>&nbsp;</DIV>
<DIV>sorry, looks like it's covered in UIDPLUS, since UID EXPUNGE must only=
 affect messages with \Deleted.</DIV>
<DIV>&nbsp;</DIV>
<DIV>therefore setting \Deleted will already affect HMS</DIV>
<DIV>&nbsp;</DIV>
<DIV>Adrien</DIV>
<DIV><BR>------ Original Message ------<BR>From: "Adrien W. de Croy" &lt;ad=
[email-masked]&gt;<BR>To: "[email-masked]" &lt;[email-masked]&gt=
;<BR>Sent: 27/03/2012 1:13:00 p.m.<BR>Subject: CONDSTORE plus UID EXPUNGE u=
ndefined?<BR></DIV>
<BLOCKQUOTE class=3Dcite cite=3Deme5a21663-7eac-4f7b-ba02-75ce572f2448@BOMB=
ED type=3D"cite">
<DIV id=3D44c5894d81234174a65b849bb07ddccb>
<DIV>Hi all</DIV>
<DIV>&nbsp;</DIV>
<DIV>Apologies if this is covered somewhere and I missed it.</DIV>
<DIV>&nbsp;</DIV>
<DIV>I've been reviewing behaviour of HIGHESTMODSEQ wrt UID EXPUNGE.</DIV>=

<DIV>&nbsp;</DIV>
<DIV>My gut feel is that the intent of CONDSTORE would be that the HIGHESTM=
ODSEQ be incremented if a UID EXPUNGE results in any messages being removed=
 from a mailbox.</DIV>
<DIV>&nbsp;</DIV>
<DIV>However in RFC4551 I can find no mention of what to do upon UID EXPUNG=
E. Since there is no STORE beforehand, we can't rely on processing associat=
ed with that.</DIV>
<DIV>&nbsp;</DIV>
<DIV>If we shouldn't increment HMS on UID EXPUNGE, then the HIGHESTMODSEQ b=
ecomes unreliable as an indication that anything changed on a mailbox, sinc=
e a UID EXPUNGE may have removed messages. I'd like clients to be able to r=
ely on HMS as an indication that ANY work is required or not to resynch.</D=
IV>
<DIV>&nbsp;</DIV>
<DIV>Or is there another proposed way to do this?</DIV>
<DIV><BR>Regards</DIV>
<DIV>&nbsp;</DIV>
<DIV>Adrien</DIV></DIV></BLOCKQUOTE></BODY></HTML>
--------=_MB0BC11C23-792B-4534-8D89-DCAF7E9638FF--

From: "Adrien W. de Croy" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: CONDSTORE plus UID EXPUNGE undefined?
Date: Tue, 27 Mar 2012 00:13:00 +0000
Reply-To: "Adrien W. de Croy" <[email-masked]>
Sender: [email-masked]

--------=_MBE3DB4DAD-D74B-4CF4-8D33-1BF0507BE9C8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; format=flowed; charset=utf-8

Hi all
  
Apologies if this is covered somewhere and I missed it.
  
I've been reviewing behaviour of HIGHESTMODSEQ wrt UID EXPUNGE.
  
My gut feel is that the intent of CONDSTORE would be that the 
HIGHESTMODSEQ be incremented if a UID EXPUNGE results in any messages 
being removed from a mailbox.
  
However in RFC4551 I can find no mention of what to do upon UID 
EXPUNGE. Since there is no STORE beforehand, we can't rely on 
processing associated with that.
  
If we shouldn't increment HMS on UID EXPUNGE, then the HIGHESTMODSEQ 
becomes unreliable as an indication that anything changed on a mailbox, =

since a UID EXPUNGE may have removed messages. I'd like clients to be 
able to rely on HMS as an indication that ANY work is required or not 
to resynch.
  
Or is there another proposed way to do this?

Regards
  
Adrien

--------=_MBE3DB4DAD-D74B-4CF4-8D33-1BF0507BE9C8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=utf-8

<HTML><HEAD>
<STYLE id=3DeMClientCss>
blockquote.cite { margin-left: 5px; margin-right: 0px; padding-left: 10px; =
padding-right:0px; border-left: 1px solid #000000 }
.plain pre { font-family: monospace; font-size: 100%; font-weight: normal; =
font-style: normal; }
body {font-family: Tahoma;font-size: 12pt;}
.plain pre {font-family: Tahoma;font-size: 12pt;}</STYLE>
</HEAD>
<BODY background=3D""><!--StartFragment-->
<DIV>Hi all</DIV>
<DIV>&nbsp;</DIV>
<DIV>Apologies if this is covered somewhere and I missed it.</DIV>
<DIV>&nbsp;</DIV>
<DIV>I've been reviewing behaviour of HIGHESTMODSEQ wrt UID EXPUNGE.</DIV>=

<DIV>&nbsp;</DIV>
<DIV>My gut feel is that the intent of CONDSTORE would be that the HIGHESTM=
ODSEQ be incremented if a UID EXPUNGE results in any messages being removed=
 from a mailbox.</DIV>
<DIV>&nbsp;</DIV>
<DIV>However in RFC4551 I can find no mention of what to do upon UID EXPUNG=
E. Since there is no STORE beforehand, we can't rely on processing associat=
ed with that.</DIV>
<DIV>&nbsp;</DIV>
<DIV>If we shouldn't increment HMS on UID EXPUNGE, then the HIGHESTMODSEQ b=
ecomes unreliable as an indication that anything changed on a mailbox, sinc=
e a UID EXPUNGE may have removed messages. I'd like clients to be able to r=
ely on HMS as an indication that ANY work is required or not to resynch.</D=
IV>
<DIV>&nbsp;</DIV>
<DIV>Or is there another proposed way to do this?</DIV>
<DIV><BR>Regards</DIV>
<DIV>&nbsp;</DIV>
<DIV>Adrien</DIV><!--EndFragment--></BODY></HTML>
--------=_MBE3DB4DAD-D74B-4CF4-8D33-1BF0507BE9C8--

Date: Thu, 29 Mar 2012 13:52:01 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: CONDSTORE plus UID EXPUNGE undefined?
Sender: [email-masked]

I fixed some typoes.

http://tools.ietf.org/html/draft-gulbrandsen-imap-move

Date: Thu, 29 Mar 2012 12:45:00 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>
Cc: Bron Gondwana <[email-masked]>, [email-masked]
Subject: Re: CONDSTORE plus UID EXPUNGE undefined?
Sender: [email-masked]

On 03/29/2012 12:40 PM, Adrien W. de Croy wrote:
> it's just that looking in my code I have 2 options.
>  
> 1. nest locks in the case of non UID MOVE.
> 2. reply to non-UID MOVE with BAD.
>  
> Since this is still a draft, we could solve that problem right now :)

The draft as it stands only defines UID MOVE, not an MSN-based command,
so you're good.

Arnt

From: "Adrien W. de Croy" <[email-masked]>
To: "Arnt Gulbrandsen" <[email-masked]>
Subject: Re: CONDSTORE plus UID EXPUNGE undefined?
Cc: "Bron Gondwana" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 29 Mar 2012 10:40:56 +0000
Reply-To: "Adrien W. de Croy" <[email-masked]>
Sender: [email-masked]

------ Original Message ------
From: "Arnt Gulbrandsen" <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>
Cc: "Bron Gondwana" <[email-masked]>;"[email-masked]" 
<[email-masked]>
Sent: 29/03/2012 11:36:09 p.m.
Subject: Re: CONDSTORE plus UID EXPUNGE undefined?
>On 03/29/2012 12:28 PM, Adrien W. de Croy wrote:
>
>>
>>it probably means though that only UID MOVE is safe.
>>
>
>
>Depends on the server and on how much time the server maintainer wants
>to spend on move.
>
>
>>
>>do we really need a non-UID MOVE?
>>
>
>
>You can restate that question as "how many clients prefer MSN-based
>commands and offer move in their UI" and my answer is "none that I know of".
>
  
it's just that looking in my code I have 2 options.
  
1. nest locks in the case of non UID MOVE.
2. reply to non-UID MOVE with BAD.
  
Since this is still a draft, we could solve that problem right now :)
  
Adrien

>
>
>Arnt
>
>
>

Date: Thu, 29 Mar 2012 12:36:09 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>
Cc: Bron Gondwana <[email-masked]>, [email-masked]
Subject: Re: CONDSTORE plus UID EXPUNGE undefined?
Sender: [email-masked]

On 03/29/2012 12:28 PM, Adrien W. de Croy wrote:
> it probably means though that only UID MOVE is safe.

Depends on the server and on how much time the server maintainer wants
to spend on move.

> do we really need a non-UID MOVE?

You can restate that question as "how many clients prefer MSN-based
commands and offer move in their UI" and my answer is "none that I know of".

Arnt

From: "Adrien W. de Croy" <[email-masked]>
To: "Arnt Gulbrandsen" <[email-masked]>
Subject: Re: CONDSTORE plus UID EXPUNGE undefined?
Cc: "Bron Gondwana" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 29 Mar 2012 10:28:34 +0000
Reply-To: "Adrien W. de Croy" <[email-masked]>
Sender: [email-masked]

it probably means though that only UID MOVE is safe.
  
do we really need a non-UID MOVE?

------ Original Message ------
From: "Arnt Gulbrandsen" <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>
Cc: "Bron Gondwana" <[email-masked]>;"[email-masked]" 
<[email-masked]>
Sent: 29/03/2012 11:16:09 p.m.
Subject: Re: CONDSTORE plus UID EXPUNGE undefined?
>Bron is right, at least for some architectures. But his argument is
>really the same as I've heard umpteen times for move: Carrying out the
>copy/store/expunge sequence without the lock COPY can drop early has too
>many failure modes and handling them requires too much clientside code.
>
>Having a lock gives you the advantages of the lock at the cost of the lock.
>
>Arnt
>
>

From: "Adrien W. de Croy" <[email-masked]>
To: "Arnt Gulbrandsen" <[email-masked]>
Subject: Re: CONDSTORE plus UID EXPUNGE undefined?
Cc: "Bron Gondwana" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 29 Mar 2012 10:25:49 +0000
Reply-To: "Adrien W. de Croy" <[email-masked]>
Sender: [email-masked]

actually we don't nest locks in our implementation of move for this 
very reason.  
  
but for a DB-based index, move can be as simple as an update query on 
the folder field for a message.
  
Adrien

------ Original Message ------
From: "Arnt Gulbrandsen" <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>
Cc: "Bron Gondwana" <[email-masked]>;"[email-masked]" 
<[email-masked]>
Sent: 29/03/2012 11:16:09 p.m.
Subject: Re: CONDSTORE plus UID EXPUNGE undefined?
>Bron is right, at least for some architectures. But his argument is
>really the same as I've heard umpteen times for move: Carrying out the
>copy/store/expunge sequence without the lock COPY can drop early has too
>many failure modes and handling them requires too much clientside code.
>
>Having a lock gives you the advantages of the lock at the cost of the lock.
>
>Arnt
>
>

Date: Thu, 29 Mar 2012 12:16:09 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>
Cc: Bron Gondwana <[email-masked]>, [email-masked]
Subject: Re: CONDSTORE plus UID EXPUNGE undefined?
Sender: [email-masked]

Bron is right, at least for some architectures. But his argument is
really the same as I've heard umpteen times for move: Carrying out the
copy/store/expunge sequence without the lock COPY can drop early has too
many failure modes and handling them requires too much clientside code.

Having a lock gives you the advantages of the lock at the cost of the lock.

Arnt

From: Robert Mueller <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>, Bron Gondwana <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: CONDSTORE plus UID EXPUNGE undefined?
Date: Thu, 29 Mar 2012 08:04:32 +1100
Sender: [email-masked]

> >With MOVE, you need to hold the lock on the first mailbox until
> >after the APPEND has succeeded, then come back and EXPUNGE them.
>   
> it can be optimised for MOVE.  Since you don't need to do a deep file 
> copy, but a file system move, as long as the dest folder is in the same 
> volume as the source, it's usually a very quick operation - much 
> quicker than copy.  Worst case it takes the same time if different 
> volumes.

Assuming you're using a "1 file = 1 email" model, then most filesystems
that support move, also support hardlinks, so a copy is actually
*cheaper* than a move, because you're just adding an extra link, and
adding links is usually a lot cheaper than unlinking.

In fact unlinks are usually sufficiently poorly optimised in
filesystems, that we explicitly added a "delayed expunge" mode to cyrus,
that allows us to push the unlink actions off into the future (eg
weekends) because they completely dominate the time on large expunges
otherwise.

> So the 2 locks are held a short time only.

It's not that they're short time only, it's that it can cause deadlocks
because for a move to be atomic, you have to have both locks at the same
time, while with copy you can get/drop them sequentially.

Rob

From: "Adrien W. de Croy" <[email-masked]>
To: "Bron Gondwana" <[email-masked]>, "Arnt Gulbrandsen" <[email-masked]>
Subject: Re: CONDSTORE plus UID EXPUNGE undefined?
Cc: "[email-masked]" <[email-masked]>
Date: Wed, 28 Mar 2012 18:09:23 +0000
Reply-To: "Adrien W. de Croy" <[email-masked]>
Sender: [email-masked]

------ Original Message ------
From: "Bron Gondwana" <[email-masked]>
To: "Arnt Gulbrandsen" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: 29/03/2012 1:54:43 a.m.
Subject: Re: CONDSTORE plus UID EXPUNGE undefined?
>On Wed, Mar 28, 2012 at 02:21:54PM +0200, Arnt Gulbrandsen wrote:
>
>>
>>
>>On 03/27/2012 02:44 AM, Adrien W. de Croy wrote:
>>> This I guess belongs in the MOVE I-D in terms of reference to CONDSTORE.
>>>
>>> Are there any plans to progress that draft?  It's quite worthwhile IMO.
>>
>>There have been many. I uploaded one now, with text from Witold, Alexey
>>and myself.
>>
>>http://tools.ietf.org/html/draft-gulbrandsen-imap-move
>>
>

great, thanks!
>
>
>  Servers may want to avoid implementing this because atomicity
>  requires holding one or more locks on several mailboxes at the same
>  time.  (This sounds just wrong. COPY requires the same.)
>
>No, COPY doesn't.  You can release the lock on the first mailbox
>after taking all the data required, then obtain the lock on the
>second mailbox.  At this point, it doesn't matter if someone else
>does something to your source messages.
>
>With MOVE, you need to hold the lock on the first mailbox until
>after the APPEND has succeeded, then come back and EXPUNGE them.
>
>

  
it can be optimised for MOVE.  Since you don't need to do a deep file 
copy, but a file system move, as long as the dest folder is in the same 
volume as the source, it's usually a very quick operation - much 
quicker than copy.  Worst case it takes the same time if different 
volumes.
  
So the 2 locks are held a short time only.

>
>Bron.
>
>
>

Date: Wed, 28 Mar 2012 23:54:43 +1100
From: Bron Gondwana <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked]
Subject: Re: CONDSTORE plus UID EXPUNGE undefined?
Organization: brong.net
Sender: [email-masked]

On Wed, Mar 28, 2012 at 02:21:54PM +0200, Arnt Gulbrandsen wrote:
> 
> On 03/27/2012 02:44 AM, Adrien W. de Croy wrote:
> > This I guess belongs in the MOVE I-D in terms of reference to CONDSTORE.
> >  
> > Are there any plans to progress that draft?  It's quite worthwhile IMO.
> 
> There have been many. I uploaded one now, with text from Witold, Alexey
> and myself.
> 
> http://tools.ietf.org/html/draft-gulbrandsen-imap-move

   Servers may want to avoid implementing this because atomicity
   requires holding one or more locks on several mailboxes at the same
   time.  (This sounds just wrong. COPY requires the same.)

No, COPY doesn't.  You can release the lock on the first mailbox
after taking all the data required, then obtain the lock on the
second mailbox.  At this point, it doesn't matter if someone else
does something to your source messages.

With MOVE, you need to hold the lock on the first mailbox until
after the APPEND has succeeded, then come back and EXPUNGE them.

Bron.

Date: Wed, 28 Mar 2012 14:21:54 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: CONDSTORE plus UID EXPUNGE undefined?
Sender: [email-masked]

On 03/27/2012 02:44 AM, Adrien W. de Croy wrote:
> This I guess belongs in the MOVE I-D in terms of reference to CONDSTORE.
>  
> Are there any plans to progress that draft?  It's quite worthwhile IMO.

There have been many. I uploaded one now, with text from Witold, Alexey
and myself.

http://tools.ietf.org/html/draft-gulbrandsen-imap-move

Arnt

Date: Tue, 27 Mar 2012 13:42:30 +1100
From: Bron Gondwana <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>
Cc: Bron Gondwana <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Re[2]: CONDSTORE plus UID EXPUNGE undefined?
Organization: brong.net
Sender: [email-masked]

On Tue, Mar 27, 2012 at 12:44:35AM +0000, Adrien W. de Croy wrote:
> Looks like our issue related to MOVE + CONDSTORE.
> 
> Since MOVE doesn't do an untagged FETCH response advertising \Deleted
> on the source, but instead only sends untagged EXPUNGE responses, it's
> not clear about incrementing HMS.
> 
> The obvious behaviour is to increment HMS.
> 
> This I guess belongs in the MOVE I-D in terms of reference to CONDSTORE.
> 
> Are there any plans to progress that draft?  It's quite worthwhile IMO.

Agree that it's worthwhile.  We're already using it internally for our
web interface talking to the Cyrus backends.

My attitude to HMS is - if anything user-visible changes, the HMS must
be bumped such that a client connection can never see two different
responses with exactly the same HMS.  Idempotency is good.

Bron.

From: "Adrien W. de Croy" <[email-masked]>
To: "Bron Gondwana" <[email-masked]>
Subject: Re[2]: CONDSTORE plus UID EXPUNGE undefined?
Cc: "[email-masked]" <[email-masked]>
Date: Tue, 27 Mar 2012 00:44:35 +0000
Reply-To: "Adrien W. de Croy" <[email-masked]>
Sender: [email-masked]

Looks like our issue related to MOVE + CONDSTORE.
  
Since MOVE doesn't do an untagged FETCH response advertising \Deleted 
on the source, but instead only sends untagged EXPUNGE responses, it's 
not clear about incrementing HMS.
  
The obvious behaviour is to increment HMS.
  
This I guess belongs in the MOVE I-D in terms of reference to CONDSTORE.
  
Are there any plans to progress that draft?  It's quite worthwhile IMO.
  
Adrien

------ Original Message ------
From: "Bron Gondwana" <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: 27/03/2012 1:30:27 p.m.
Subject: Re: CONDSTORE plus UID EXPUNGE undefined?
>On Tue, Mar 27, 2012 at 12:13:00AM +0000, Adrien W. de Croy wrote:
>
>>
>>Hi all
>>
>>Apologies if this is covered somewhere and I missed it.
>>
>>I've been reviewing behaviour of HIGHESTMODSEQ wrt UID EXPUNGE.
>>
>>My gut feel is that the intent of CONDSTORE would be that the
>>HIGHESTMODSEQ be incremented if a UID EXPUNGE results in any messages
>>being removed from a mailbox.
>>
>
>
>Absolutely.  In fact, if you look at QRESYNC, it not only needs to
>increment the HIGHESTMODSEQ, it has to increment the MODSEQ of the
>message being expunged so that you can give a VANISHED response.
>
>
>>
>>If we shouldn't increment HMS on UID EXPUNGE, then the HIGHESTMODSEQ
>>becomes unreliable as an indication that anything changed on a
>>mailbox, since a UID EXPUNGE may have removed messages. I'd like
>>clients to be
>>able to rely on HMS as an indication that ANY work is required or not
>>to resynch.
>>
>
>
>You can increment HMS by however much you like, whenever you want, and
>still be compatible... it could be that something has changed which the
>client just didn't ask for.
>
>Bron ( until you run out of 64 bits anyway )
>
>
>

Date: Tue, 27 Mar 2012 11:30:27 +1100
From: Bron Gondwana <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: CONDSTORE plus UID EXPUNGE undefined?
Organization: brong.net
Sender: [email-masked]

On Tue, Mar 27, 2012 at 12:13:00AM +0000, Adrien W. de Croy wrote:
> Hi all
> 
> Apologies if this is covered somewhere and I missed it.
> 
> I've been reviewing behaviour of HIGHESTMODSEQ wrt UID EXPUNGE.
> 
> My gut feel is that the intent of CONDSTORE would be that the
> HIGHESTMODSEQ be incremented if a UID EXPUNGE results in any messages
> being removed from a mailbox.

Absolutely.  In fact, if you look at QRESYNC, it not only needs to
increment the HIGHESTMODSEQ, it has to increment the MODSEQ of the
message being expunged so that you can give a VANISHED response.

> If we shouldn't increment HMS on UID EXPUNGE, then the HIGHESTMODSEQ
> becomes unreliable as an indication that anything changed on a
> mailbox, since a UID EXPUNGE may have removed messages. I'd like
> clients to be
> able to rely on HMS as an indication that ANY work is required or not
> to resynch.

You can increment HMS by however much you like, whenever you want, and
still be compatible... it could be that something has changed which the
client just didn't ask for.

Bron ( until you run out of 64 bits anyway )

From: "Adrien W. de Croy" <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: CONDSTORE plus UID EXPUNGE undefined?
Date: Tue, 27 Mar 2012 00:22:56 +0000
Reply-To: "Adrien W. de Croy" <[email-masked]>
Sender: [email-masked]

--------=_MB0BC11C23-792B-4534-8D89-DCAF7E9638FF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; format=flowed; charset=utf-8

sorry, looks like it's covered in UIDPLUS, since UID EXPUNGE must only 
affect messages with \Deleted.
  
therefore setting \Deleted will already affect HMS
  
Adrien

------ Original Message ------
From: "Adrien W. de Croy" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: 27/03/2012 1:13:00 p.m.
Subject: CONDSTORE plus UID EXPUNGE undefined?
>Hi all
> 
>Apologies if this is covered somewhere and I missed it.
> 
>I've been reviewing behaviour of HIGHESTMODSEQ wrt UID EXPUNGE.
> 
>My gut feel is that the intent of CONDSTORE would be that the 
>HIGHESTMODSEQ be incremented if a UID EXPUNGE results in any messages 
>being removed from a mailbox.
> 
>However in RFC4551 I can find no mention of what to do upon UID 
>EXPUNGE. Since there is no STORE beforehand, we can't rely on 
>processing associated with that.
> 
>If we shouldn't increment HMS on UID EXPUNGE, then the HIGHESTMODSEQ 
>becomes unreliable as an indication that anything changed on a 
>mailbox, since a UID EXPUNGE may have removed messages. I'd like 
>clients to be able to rely on HMS as an indication that ANY work is 
>required or not to resynch.
> 
>Or is there another proposed way to do this?
>
>Regards
> 
>Adrien

--------=_MB0BC11C23-792B-4534-8D89-DCAF7E9638FF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=utf-8

<HTML><HEAD>
<STYLE id=3DeMClientCss>blockquote.cite { margin-left: 5px; margin-right: 0=
px; padding-left: 10px; padding-right:0px; border-left: 1px solid #000000 }=

.plain pre { font-family: monospace; font-size: 100%; font-weight: normal; =
font-style: normal; }
body {font-family: Tahoma;font-size: 12pt;}
.plain pre {font-family: Tahoma;font-size: 12pt;}

#44c5894d81234174a65b849bb07ddccb BLOCKQUOTE.cite
{BORDER-LEFT: #000000 1px solid; PADDING-LEFT: 10px; PADDING-RIGHT: 0px; MA=
RGIN-LEFT: 5px; MARGIN-RIGHT: 0px}
#44c5894d81234174a65b849bb07ddccb .plain PRE
{FONT-STYLE: normal; FONT-FAMILY: monospace; FONT-SIZE: 100%; FONT-WEIGHT: =
normal}
#44c5894d81234174a65b849bb07ddccb 
{FONT-FAMILY: Tahoma; FONT-SIZE: 12pt}
#44c5894d81234174a65b849bb07ddccb .plain PRE
{FONT-FAMILY: Tahoma; FONT-SIZE: 12pt}</STYLE>
</HEAD>
<BODY background=3D"" scroll=3Dauto class>
<DIV>&nbsp;</DIV>
<DIV>sorry, looks like it's covered in UIDPLUS, since UID EXPUNGE must only=
 affect messages with \Deleted.</DIV>
<DIV>&nbsp;</DIV>
<DIV>therefore setting \Deleted will already affect HMS</DIV>
<DIV>&nbsp;</DIV>
<DIV>Adrien</DIV>
<DIV><BR>------ Original Message ------<BR>From: "Adrien W. de Croy" &lt;ad=
[email-masked]&gt;<BR>To: "[email-masked]" &lt;[email-masked]&gt=
;<BR>Sent: 27/03/2012 1:13:00 p.m.<BR>Subject: CONDSTORE plus UID EXPUNGE u=
ndefined?<BR></DIV>
<BLOCKQUOTE class=3Dcite cite=3Deme5a21663-7eac-4f7b-ba02-75ce572f2448@BOMB=
ED type=3D"cite">
<DIV id=3D44c5894d81234174a65b849bb07ddccb>
<DIV>Hi all</DIV>
<DIV>&nbsp;</DIV>
<DIV>Apologies if this is covered somewhere and I missed it.</DIV>
<DIV>&nbsp;</DIV>
<DIV>I've been reviewing behaviour of HIGHESTMODSEQ wrt UID EXPUNGE.</DIV>=

<DIV>&nbsp;</DIV>
<DIV>My gut feel is that the intent of CONDSTORE would be that the HIGHESTM=
ODSEQ be incremented if a UID EXPUNGE results in any messages being removed=
 from a mailbox.</DIV>
<DIV>&nbsp;</DIV>
<DIV>However in RFC4551 I can find no mention of what to do upon UID EXPUNG=
E. Since there is no STORE beforehand, we can't rely on processing associat=
ed with that.</DIV>
<DIV>&nbsp;</DIV>
<DIV>If we shouldn't increment HMS on UID EXPUNGE, then the HIGHESTMODSEQ b=
ecomes unreliable as an indication that anything changed on a mailbox, sinc=
e a UID EXPUNGE may have removed messages. I'd like clients to be able to r=
ely on HMS as an indication that ANY work is required or not to resynch.</D=
IV>
<DIV>&nbsp;</DIV>
<DIV>Or is there another proposed way to do this?</DIV>
<DIV><BR>Regards</DIV>
<DIV>&nbsp;</DIV>
<DIV>Adrien</DIV></DIV></BLOCKQUOTE></BODY></HTML>
--------=_MB0BC11C23-792B-4534-8D89-DCAF7E9638FF--

From: "Adrien W. de Croy" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: CONDSTORE plus UID EXPUNGE undefined?
Date: Tue, 27 Mar 2012 00:13:00 +0000
Reply-To: "Adrien W. de Croy" <[email-masked]>
Sender: [email-masked]

--------=_MBE3DB4DAD-D74B-4CF4-8D33-1BF0507BE9C8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; format=flowed; charset=utf-8

Hi all
  
Apologies if this is covered somewhere and I missed it.
  
I've been reviewing behaviour of HIGHESTMODSEQ wrt UID EXPUNGE.
  
My gut feel is that the intent of CONDSTORE would be that the 
HIGHESTMODSEQ be incremented if a UID EXPUNGE results in any messages 
being removed from a mailbox.
  
However in RFC4551 I can find no mention of what to do upon UID 
EXPUNGE. Since there is no STORE beforehand, we can't rely on 
processing associated with that.
  
If we shouldn't increment HMS on UID EXPUNGE, then the HIGHESTMODSEQ 
becomes unreliable as an indication that anything changed on a mailbox, =

since a UID EXPUNGE may have removed messages. I'd like clients to be 
able to rely on HMS as an indication that ANY work is required or not 
to resynch.
  
Or is there another proposed way to do this?

Regards
  
Adrien

--------=_MBE3DB4DAD-D74B-4CF4-8D33-1BF0507BE9C8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=utf-8

<HTML><HEAD>
<STYLE id=3DeMClientCss>
blockquote.cite { margin-left: 5px; margin-right: 0px; padding-left: 10px; =
padding-right:0px; border-left: 1px solid #000000 }
.plain pre { font-family: monospace; font-size: 100%; font-weight: normal; =
font-style: normal; }
body {font-family: Tahoma;font-size: 12pt;}
.plain pre {font-family: Tahoma;font-size: 12pt;}</STYLE>
</HEAD>
<BODY background=3D""><!--StartFragment-->
<DIV>Hi all</DIV>
<DIV>&nbsp;</DIV>
<DIV>Apologies if this is covered somewhere and I missed it.</DIV>
<DIV>&nbsp;</DIV>
<DIV>I've been reviewing behaviour of HIGHESTMODSEQ wrt UID EXPUNGE.</DIV>=

<DIV>&nbsp;</DIV>
<DIV>My gut feel is that the intent of CONDSTORE would be that the HIGHESTM=
ODSEQ be incremented if a UID EXPUNGE results in any messages being removed=
 from a mailbox.</DIV>
<DIV>&nbsp;</DIV>
<DIV>However in RFC4551 I can find no mention of what to do upon UID EXPUNG=
E. Since there is no STORE beforehand, we can't rely on processing associat=
ed with that.</DIV>
<DIV>&nbsp;</DIV>
<DIV>If we shouldn't increment HMS on UID EXPUNGE, then the HIGHESTMODSEQ b=
ecomes unreliable as an indication that anything changed on a mailbox, sinc=
e a UID EXPUNGE may have removed messages. I'd like clients to be able to r=
ely on HMS as an indication that ANY work is required or not to resynch.</D=
IV>
<DIV>&nbsp;</DIV>
<DIV>Or is there another proposed way to do this?</DIV>
<DIV><BR>Regards</DIV>
<DIV>&nbsp;</DIV>
<DIV>Adrien</DIV><!--EndFragment--></BODY></HTML>
--------=_MBE3DB4DAD-D74B-4CF4-8D33-1BF0507BE9C8--