Synchronization Operations for Disconnected IMAP4 Clients
draft-melnikov-imap-disc-06

[Ballot comment]
Reviewed by John Loughney, Gen-ART. Editing pass suggested.

His review:

Summary: The document is ready, there are some small issues to clarify or
clean-up.  I'd suggest an editorial pass on the document before submitting,
but I don't think a DISCUSS is in order. 

In general, the document is readable, but a bit converstation, so a tightening
up of the language would make sense.  Other issues are listed below.

Issues:

1) Draft header says:
IMAPEXT Working Group                                        A. Melnikov
Internet Draft: IMAP4 Disconnected Access                        Editor
Document: draft-melnikov-imap-disc-06.txt                  October 2004

But its an individual submission, so I think the IMAPEXT Working Group tag
should be removed.

2) Editorial comments with comments/questions marked by << and >> should be
  removed.

3) Missing IANA considerations section

Nits:
1) ToC would be nice.

2) The following text is too conversational, I suggest improving it.

  Let's call an IMAP command idempotent, if the result of executing the
  command twice sequentially is the same as the result of executing the
  command just once.

[Ballot comment]
$ idnits draft-melnikov-imap-disc-06.txt
idnits 1.57

draft-melnikov-imap-disc-06.txt:

  Checking nits according to http://www.ietf.org/ID-Checklist.html :

  * The document seems to lack an IANA Considerations section.
    Checking conformance with RFC 3667/3668 boilerplate...
    the boilerplate looks good.
  * The document is more than 15 pages and seems to lack a Table of Contents.
  * There are 319 instances of too long lines in the document, the longest one being 23
    characters in excess of 72.


Further I notice examples (in sects 4.2.2.3 and 4.2.2.5 for example)
that do not follow the rules/guidelines for example domain names.
There are other places with same problem.

[Note]: 'RFC Editor Note: In Section 3: OLD:   The special mailbox "INBOX" SHOULD always
        be considered "interesting". NEW: The special mailbox "INBOX" SHOULD be in the default set of mailboxes
    that the client considers interesting.  However providing the ability
    to ignore INBOX for a particular session or client may be valuable for
    some mail filtering strategies. In Section 1.1 OLD:   Editorial comments/questions or missing paragraphs are marked in the
  text with << and >>. NEW: In Section 5: OLD: <> NEW' added by Michelle Cotton

[Note]: 'RFC Editor Note:

In Section 3:

OLD:

   The special mailbox "INBOX" SHOULD always
         be considered "interesting".

NEW:

The special mailbox "INBOX" SHOULD be in the default set of mailboxes
    that the client considers interesting.  However providing the ability
    to ignore INBOX for a particular session or client may be valuable for
    some mail filtering strategies.

In Section 1.1

OLD:

  Editorial comments/questions or missing paragraphs are marked in the
  text with << and >>.

NEW:


In Section 5:

OLD:

<>

NEW' added by Ted Hardie

[Ballot discuss]
This spec requires that INBOX "Should always be considered interesting."

I think that is too strong of a requirement.  It's fairly easy,
especially with sieve, for inbox to end up being the place where all
mail that cannot be classified ends up.  This seems like a reasonable
use of sieve and imap to me, but in that case you may well not want to
look at inbox from a low-bandwith client.

I'd propose something along the lines of

The special mailbox "INBOX" SHOULD be in the default set of mailboxes
that the client considers interesting.  However providing the ability
to ignore INBOX for a particular session or client may be valuable for
some mail filtering strategies.

I'm not tied to any particular text; I just want the requirement
weakened.

[Ballot comment]
The text in section 1.1 describing the editorial comment convention (Editorial comments/questions or missing paragraphs are marked in the text with << and >>.) and the question in section 5 (<>) should be removed.

The definition of idempotency in section 1.1 could also be improved.

"Let's call an IMAP command idempotent, if the result of executing the command twice sequentially is the same as the result of executing the command just once."

sounds pretty wishy-washy.  This could be used instead:

"An IMAP command is idempotent if the effect of executing the command more than once sequentially is the same as the result of executing the command just once."

I've changed "result" to "effect" because it's possible for an idempotent operation to return a different response if it's executed multiple times.  What's important is the effect of the operation.

Missing IANA Considerations.