Internet Message Access Protocol version 4 - LIST Command Extensions
draft-ietf-imapext-list-extensions-18

INTRODUCTION, paragraph 15:

>    A revised version of this draft document will be submitted to the RFC
>    editor as a Proposed Standard for the Internet Community.  Discussion
>    and suggestions for improvement are requested, and should be sent to
>    ietf-imapext@imc.org.

  I guess this note should be removed upon publication.


Section 1., paragraph 0:

>    1.  Exactly one LIST response should be returned for each mailbox
>        name which matches the canonical LIST pattern.  Server
>        implementors must not assume that clients will be able to
>        assemble mailbox attributes and other information returned in
>        multiple LIST responses.

  Shouldn't the "should" and "must not" be RFC2119 terms here?


Section 3., paragraph 0:

>    3.  Attributes returned in the same LIST response must be treated
>        additively.  For example the following response

  Shouldn't the "must" be a RFC2119 term here?


Section 11, paragraph 4:

>    The following table summarizes interaction between the "\NonExistent"
>    attribute and CHILDINFO (the first collumn describes if the parent

  Nit: s/collumn/column/


Section 4., paragraph 5:

>         This
>         might happen, for example, due to children mailboxes beig

  Nit: s/beig/being/


Section 4., paragraph 9:

>    It is an error for the server to return both a \HasChildren and a
>    \HasNoChildren attribute in the same LIST response.

  s/It is an error for the server to/The server MUST NOT/


Section 6., paragraph 0:

 6.  Formal Syntax

  Check line wrapping and blank lines in the ABNF; it needed some
  tweaking after a copy&paste before it would validate.


Section 6., paragraph 2:

>    "vendor-token" is defined in [ACAP].  Note that this normative
>    reference to ACAP will be an issue in moving this spec forward, since
>    it introduces a dependency on ACAP.  The definitions of "vendor-
>    token" and of the IANA registry must eventually go somewhere else, in
>    a document that can be moved forward on the standards track
>    independently of ACAP.

  I lack the background to understand this comment about ACAP - can
  someone comment on how serious this issue is?