Subject: [imapext] Last Call: <draft-ietf-imapmove-command-02.txt> (The IMAP Move Extension) to Proposed Standard

From: The IESG <[email-masked]>
Date: Wed, 07 Nov 2012 15:05:47 -0800

The IESG has received a request from the IMAP MOVE extension WG
(imapmove) to consider the following document:
- 'The IMAP Move Extension'
  <draft-ietf-imapmove-command-02.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2012-11-21. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

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 file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-imapmove-command/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-imapmove-command/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Jan Kundrát <[email-masked]>
Date: Thu, 08 Nov 2012 13:59:05 +0100

Hi, section 4.1 still says that "This may be user-visible, but should not be MUA-visible." which is a sentence whose meaning I cannot decipher. People on this ML have also said that it should probably be removed.

So, what has to be done to get rid of it? (I suspect that is is not a "substantive comment" that the IETF seeks, which is why I'm sending this just to the imapext).

With kind regards,
Jan

---

From: Ned Freed <[email-masked]>
Date: Thu, 08 Nov 2012 07:37:23 -0800 (PST)

> Hi, section 4.1 still says that "This may be user-visible, but should not be
> MUA-visible." which is a sentence whose meaning I cannot decipher. People on
> this ML have also said that it should probably be removed.

It will be removed the next time an updated draft is posted.

				Ned

---

From: Christian Ketterer <[email-masked]>
Date: Fri, 09 Nov 2012 18:30:01 +0100

Hi,

I have a couple of remarks on the draft.

1. In section 3.1 the argument "mailbox name" isn't indented correctly.

2. In section 6 mailboxes are referred to as "folders".

3. English is not my first language, but the end of this sentence in
section 6 sounds wrong: "Scanning with updated rules may also be
required when messages are moved even with the underlying policy has not
changed."

4. The document doesn't explicitly state that a server announces support
for this extension by returning the capability "MOVE" in the response to
the CAPABILITY command.

5. The document doesn't explicitly state what responses look like in
case of a partial failure. I believe adding this would be helpful to
readers not intimately familiar with IMAP.

Best,
Chris

---

From: Ned Freed <[email-masked]>
Date: Fri, 09 Nov 2012 09:53:32 -0800 (PST)

> 1. In section 3.1 the argument "mailbox name" isn't indented correctly.

Not sure how that happened. Fixed.

> 2. In section 6 mailboxes are referred to as "folders".

An error on my part. Fixed.

> required when messages are moved even with the underlying policy has not

"with" should be "when". Fixed.

> for this extension by returning the capability "MOVE" in the response to

Yes, this seems to be essentially boilerplate for IMAP extension documents.
I'll add the appropriate text.

> readers not intimately familiar with IMAP.

I'm not really sure that's true. The problem I've seen fairly often with
examples of how errors get reported is that implementors then assume that's
the only sort of error that can happen. This is compounded when you're talking
about partial failures.

Anyway, if you want a change in this area, someone needs to suggest text.

Thanks for the feedback.

				Ned