Subject: [imapext] I-D Action: draft-ietf-imapmove-command-05.txt

From: [email-masked]
Date: Thu, 29 Nov 2012 08:26:37 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IMAP MOVE extension Working Group of the IETF.

	Title           : Internet Message Access Protocol (IMAP) - MOVE Extension
	Author(s)       : Arnt Gulbrandsen
                          Ned Freed
	Filename        : draft-ietf-imapmove-command-05.txt
	Pages           : 11
	Date            : 2012-11-29

Abstract:
   This document defines an IMAP extension consisting of two new
   commands, MOVE and UID MOVE, that are used to move messages from one
   mailbox to another.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-imapmove-command

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-imapmove-command-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-imapmove-command-05

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Timo Sirainen <[email-masked]>
Date: Thu, 29 Nov 2012 23:04:35 +0200

I guess I should have read this more closely earlier:

>    When a message is moved to a target mailbox, if the server is capable	
>  	   of storing modification sequences for the mailbox, the server MUST	
>  	   generate a new modification sequence that is higher than the highest	
>  	   modification sequence of all messages in the mailbox and assign it to	
>  	   the moved message.

This seems to mean each moved message MUST have a new different modification sequence. My server gives the same new modseq for all of them.

In general, maybe there shouldn't be any MUSTs at all in section 4? They may unintentionally add extra restrictions that aren't in the base documents. I now see another problem:

> 4.3.  RFC 4315, UIDPLUS
> 
>    Servers supporting UIDPLUS [RFC4315] MUST send COPYUID in response to
>    a UID MOVE command.

This shouldn't be a MUST, since it adds a restriction not present in RFC 4315:

   [RFC2359] implied that a server must always return COPYUID/APPENDUID
   data; thus suggesting that in such cases the server should return
   arbitrary data if the destination mailbox did not support persistent
   UIDs.  This document adds the UIDNOTSTICKY response code to indicate
   that a mailbox does not support persistent UIDs, and stipulates that
   a UIDPLUS server does not return COPYUID/APPENDUID data when the COPY
   (or APPEND) destination mailbox has UIDNOTSTICKY status.

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Thu, 29 Nov 2012 21:47:18 +0000

------ Original Message ------
From: "Timo Sirainen" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: 30/11/2012 10:04:35 a.m.
Subject: Re: [imapext] I-D Action: draft-ietf-imapmove-command-05.txt
>In general, maybe there shouldn't be any MUSTs at all in section 4? They may unintentionally add extra restrictions that aren't in the base documents. I now see another problem:
maybe "a message" should be generalised to cover all the messages being 
moved.  E.g.

When message(s) are moved to a target mailbox, if the server is capable 
of storing modification sequences for the mailbox, the server MUST 
generate a new modification sequence that is higher than the highest 
modification sequence of all messages in the mailbox and assign it to 
the moved message(s).

>  (or APPEND) destination mailbox has UIDNOTSTICKY status.

persistence of UIDs is independent of allocation of them surely?  a 
message must have a UID, whether that's sticky or not.  At the time of 
the move, there must therefore be a UID?

Adrien
>
>
>
>_______________________________________________
>imapext mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/imapext
>
>

---

From: Timo Sirainen <[email-masked]>
Date: Fri, 30 Nov 2012 01:50:43 +0200

On 29.11.2012, at 23.47, Adrien W. de Croy wrote:

> maybe "a message" should be generalised to cover all the messages being moved.  E.g.
> 
> When message(s) are moved to a target mailbox, if the server is capable of storing modification sequences for the mailbox, the server MUST generate a new modification sequence that is higher than the highest modification sequence of all messages in the mailbox and assign it to the moved message(s).

That then reads more like all of the messages have the same modseq. That's not necessarily true either.

> persistence of UIDs is independent of allocation of them surely?  a message must have a UID, whether that's sticky or not.  At the time of the move, there must therefore be a UID?

RFC 4315 clearly says that COPYUID doesn't need to be returned for such mailboxes, so MOVE RFC shouldn't require it either.

---

From: Ned Freed <[email-masked]>
Date: Thu, 29 Nov 2012 15:40:53 -0800 (PST)

> modification sequence of all messages in the mailbox and assign it to

That's my thought as well. (It's also how I read the original text.)

This can be fixed in AUTH48.

> the move, there must therefore be a UID?

I confess to having very little sympathy with this one. I'm completely
comfortable with keeping this requirement, and BTW there's nothing that
says we can't impose additional requirements.

That said, we could add "to any destintion that doesn't have UIDNOTSTICKY
status" to the end.

I'm also strongly opposed to removing compliance language. The point of having
this section is to eliminate the need for readers to have to figure out
requirements that arise from the interaction of this extension with other
extensions.

				Ned

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Thu, 29 Nov 2012 23:55:25 +0000

------ Original Message ------
>That then reads more like all of the messages have the same modseq. That's not necessarily true either.
fair enough

>RFC 4315 clearly says that COPYUID doesn't need to be returned for such mailboxes, so MOVE RFC shouldn't require it either.

maybe 4315 shouldn't have made that optional.  Does it make any and all 
use of UID undefined for such folders?  Seems like a major breakage of 
IMAP to me.

But in any case, this is a new command - MOVE, and UID MOVE.

With a new RFC.

So rather than re-use COPYUID and make it optional (therefore useless, 
since you can't rely on it), why not define something that is 
mandatory, and we could maybe call it MOVEUID

As for sticky or not UIDs, I'm not convinced these hens teeth should 
have such a sharp bite.  

Adrien

---

From: Timo Sirainen <[email-masked]>
Date: Fri, 30 Nov 2012 02:12:53 +0200

On 30.11.2012, at 1.55, Adrien W. de Croy wrote:

> maybe 4315 shouldn't have made that optional.  Does it make any and all use of UID undefined for such folders?  Seems like a major breakage of IMAP to me.
> 
> So rather than re-use COPYUID and make it optional (therefore useless, since you can't rely on it), why not define something that is mandatory, and we could maybe call it MOVEUID
> 
> As for sticky or not UIDs, I'm not convinced these hens teeth should have such a sharp bite.  

Well, my server advertises UIDPLUS, because it works pretty much everywhere. But there are some backends where returning COPYUID/APPENDUID would be very complex/expensive (e.g. proxying to another IMAP server without UIDPLUS support), so it just doesn't return it. I guess that's already on the grey area with UIDPLUS, but I'd rather not make it completely wrong when MOVE is advertised. :)

---

From: Ned Freed <[email-masked]>
Date: Thu, 29 Nov 2012 17:58:16 -0800 (PST)

> Well, my server advertises UIDPLUS, because it works pretty much everywhere.
> But there are some backends where returning COPYUID/APPENDUID would be very
> complex/expensive (e.g. proxying to another IMAP server without UIDPLUS
> support), so it just doesn't return it. I guess that's already on the grey area
> with UIDPLUS, but I'd rather not make it completely wrong when MOVE is
> advertised. :)

I read this as saying that your server never returns COPYUID/APPENDUID even
when the backend you're using supports it If that's the case, then I'm afraid
your server isn't really compliant with RFC 4315. RFC 4315 relaxes the COPYUID
requirement, but only to a SHOULD (section 3), and specifies two
exceptions:

(1) When the mailbox is protected from reads but allows writes (SHOULD NOT
    return)

(2) When UIDNOTSTICKY is set (MAY omit).

This gives sufficient grounds for not returning it when the back end can't
provide the necessary information, but does not justify not returning it in
cases where the backend is capable of doing so.

Getting back to the specification at hand, given that RFC 4315 only says
SHOULD, not MUST, that's a case for changing the MUST to a SHOULD in section
4.3. But as I pointed out previously, I'm also OK with keeping the MUST
if people think that's what needs to be there.

As for process issues, I think if we get agrement on the list and Barry agrees
we can make this change during AUTH48.

				Ned

---

From: Timo Sirainen <[email-masked]>
Date: Fri, 30 Nov 2012 04:40:29 +0200

On 30.11.2012, at 3.58, Ned Freed wrote:

> your server isn't really compliant with RFC 4315.

Only with some very rarely used backends/configurations.

> RFC 4315 relaxes the COPYUID

Oh, this is actually a good point that I hadn't noticed / thought of before. If mailbox ACLs prevent read access, the COPY command shouldn't expose how many messages it contains or when it gets new messages by sending COPYUID. This would be important for MOVE as well.

---

From: Ned Freed <[email-masked]>
Date: Thu, 29 Nov 2012 21:48:05 -0800 (PST)

> Oh, this is actually a good point that I hadn't noticed / thought of before.
> If mailbox ACLs prevent read access, the COPY command shouldn't expose how many
> messages it contains or when it gets new messages by sending COPYUID. This
> would be important for MOVE as well.

And when you put it that way, it's an information exposure issue that IMO
requires us to use SHOULD. I'm therefore changing the paragraph to read:

  Servers supporting UIDPLUS [RFC4315] SHOULD send COPYUID in response to a UID
  MOVE command. For additional information see Section 3 of [RFC4315].

Does this address the issue?

				Ned

---

From: Timo Sirainen <[email-masked]>
Date: Fri, 30 Nov 2012 08:54:47 +0200

> Does this address the issue?

Works for me.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 30 Nov 2012 16:30:02 +0000

On 29/11/2012 23:40, Ned Freed wrote:
>> >This seems to mean each moved message MUST have a new different 
>> modification sequence. My server gives the same new modseq for all of 
>> them.
>> >
>> >In general, maybe there shouldn't be any MUSTs at all in section 4? 
>> They may unintentionally add extra restrictions that aren't in the 
>> base documents. I now see another problem:
>> >
That was the intent. The server can assign different modseqs or the same 
modseqs to multiple messages being moved.
> This can be fixed in AUTH48.
Agreed.
> That said, we could add "to any destintion that doesn't have UIDNOTSTICKY

Agreed.

> requirements that arise from the interaction of this extension with other

Exactly.