Subject: [apps-discuss] AppsDir review of draft-ietf-imapmove-command

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 20 Nov 2012 18:39:13 -0800 (PST)

I have been selected as the Applications Area Directorate (appsdir) reviewer
for this draft.  (For background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments you
may receive.  Please wait for direction from your document shepherd or AD
before posting a new version of the draft.

Document: draft-ietf-imapmove-command
Title: The IMAP Move Extension
Reviewer: Murray Kucherawy
Review Date: November 20, 2012
IETF Last Call Date: (ends) November 21, 2012
IESG Telechat Date: November 29, 2012

SUMMARY:

This draft is almost ready for publication as a Standards Track RFC,
but has a few issues that should be considerered before it is advanced.

As a participant, I support the publication of this work.

MAJOR ISSUES:

1) Section 4: Shouldn't each of these referenced RFCs that define other
   IMAP extensions be officially updated by this one?  (This may not be
   "major" but it seems to be the one point I have that's most likely to
   draw a DISCUSS.)

MINOR ISSUES:

1) Section 3.2, suggest:

OLD:
  This extends the first form of the UID command (see [RFC3501],
  Section 6.4.8) to add ...

NEW:
  The first form of the UID command ([RFC3501], Section 6.4.8) is
  extended to add ...

2) Seciton 4.1:  Are we worried here about non-normative "may" and "should"?

3) I am not experienced at IMAP, but it might be helpful to include in
   Section 3.3 an example of what it might look like if a request to move
   a set of messages resulted in some messages moved and some left in place.

NITS:

1) Suggest mentioning that the intent of this work is to create an atomic
move operation, just to be explicit.  (I think what I'm suggesting is to
use the word "atomic" in your intro text.)

2) s/COPY affect MOVE/COPY also affect MOVE/

3) s/, however,/.  However,/

4) s/even with the/even when the/

---

From: Barry Leiba <[email-masked]>
Date: Tue, 20 Nov 2012 22:55:34 -0500

>    IMAP extensions be officially updated by this one?

Why?  This is an entirely optional extension, and the only reason to
be pointed at this document is if you want to implement this.  It
doesn't make any updates to the other protocols (including to the IMAP
base, so it doesn't update 3501 either).  There's absolutely no reason
for "updates".

>   The first form of the UID command ([RFC3501], Section 6.4.8) is

You suggest that we take a perfectly good active sentence and make it
passive?  Please explain why you *prefer* passive voice.  (Or,
perhaps, please explain why passive voice is preferred.)

> 2) Seciton 4.1:  Are we worried here about non-normative "may" and "should"?

I'm not.  I know Arnt is not.  I think Ned is not.  And no one in the
working group mentioned it.

I know there are those who are bothered by it, though.  I'll leave it
to the editors to decide whether they should be changed.

>    a set of messages resulted in some messages moved and some left in place.

Not a bad idea.  Also left to the editors to decide.  If we do that,
we'll have to change the existing example so that it lists all the
EXPUNGE messages, rather than saying "(more expunges)".  It's also a
little vague anyway, because the UID MOVE specifies a set of messages
by UID, and the EXPUNGE responses return them as sequence numbers, so
on reading the example it's not immediately obvious how they map.

> use the word "atomic" in your intro text.)

No.  That was discussed, and we specifically decided NOT to say that.
The phrase "appears to the client as a single action" was chosen
carefully; we didn't want to limit implementations to servers that
could actually make it atomic.  That's why there's SHOULD and SHOULD
NOT in Section 3.3, rather than MUST and MUST NOT.

> 2) s/COPY affect MOVE/COPY also affect MOVE/

I don't see this as a nit, and I don't personally prefer having "also"
in there ("in the same way" is clear enough).  But I don't care, so if
the editors want to change it... or leave it for the RFC Editor's
style.

> 3) s/, however,/.  However,/

Yes; either that or "; however,"... as it is, it's a comma splice.

> 4) s/even with the/even when the/

The Gen-ART review found that one as well.

Barry

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 20 Nov 2012 20:30:47 -0800

> base, so it doesn't update 3501 either).  There's absolutely no reason

Suppose I want to add one of those other extensions to a server or client
that already has MOVE.  It would be nice to know that, say, UIDPLUS has
implications that relate to MOVE.

I had thought that's the sort of reason we use "Updates".  Terribly sorry
if I'd gotten the wrong impression.

> perhaps, please explain why passive voice is preferred.)

It's been done to my own documents by ADs in the past, so I thought that
was the preference.  Again, terribly sorry.

-MSK

---

From: Barry Leiba <[email-masked]>
Date: Wed, 21 Nov 2012 09:04:26 -0500

> I had thought that's the sort of reason we use "Updates".  Terribly sorry if
> I'd gotten the wrong impression.

No reason to be terrible.
The IESG is working on some guidance about using "updates", which
we're not done with yet.  I don't think this is going to fall into it.
 The basic reasons are (1) this document *actually* updates the other
one (changes something in it), and (2) more generally, if you're
implementing the old document, we absolutely want you to look at this
one when you do.

Your point is an interesting one.  We could say that, well, you've
implemented MOVE, so you know that you have to go check it again...
but that's clearly not on for a number of reasons, and doesn't scale.
On the other hand, if we used that logic for every combination of
extensions, we'd have an "updates" spaghetti bowl that's so
complicated that no one could sort it out.  We'll have to consider
that when we write the guidance.

> It's been done to my own documents by ADs in the past, so I thought that was
> the preference.  Again, terribly sorry.

Interesting.  What I've generally seen (and what I prefer) is a move
*away* from passive voice, to make it clearer who has to do what (this
specification says this, the server has to do that, the client is
responsible for the other).  Passive voice has its place, but it
generally obfuscates (or at least downplays) who takes the action.

Barry

---

From: Ned Freed <[email-masked]>
Date: Wed, 21 Nov 2012 11:18:35 -0800 (PST)

> base, so it doesn't update 3501 either).  There's absolutely no reason

The whole "let's repeat the Updates:/Obsoletes: lines in the Abstract" business
is more than enough for me; I'm not touching this one with a stick.

> perhaps, please explain why passive voice is preferred.)

I use passive voice too much as it is; I'm not inclined to use more.

> working group mentioned it.

I had a huge argument with Dave Crocker about this. Suffice it to say I'm not
on board with worrying about lower case "may" and "should".

> NOT in Section 3.3, rather than MUST and MUST NOT.

Agreed on all points.

> the editors want to change it... or leave it for the RFC Editor's

I think we can leave it to the RFC Editor. I actually don't know which way they
would go - I could just as easily see them removing an "also" we added.

> Yes; either that or "; however,"... as it is, it's a comma splice.

I slightly prefer the separate sentence, so that's the way I'll go.

				Ned