Internet Message Access Protocol version 4 - LIST Command Extensions
RFC 5258

[Ballot discuss]
The ABNF for childinfo-extended-item has comments wrapped, making parts of them not comments and therefore syntax errors.

It's more appropriate to use DQUOTE from the base grammar or %x22 than <">.  You use DQUOTE elsewhere so that's probably most appropriate.

Strictly speaking, the double-spaced entries for tagged-ext-comp and tagged-ext-val are syntax errors, because they have blank lines that are trying to be used for continuation lines, and continuation lines have to have whitespace.  It'd probably be easiest to just not double-space them.

There may be more - this was what I got from a quick pass, and I'm on vacation this week.

IANA Last Call Comment:

Upon approval of this document, the IANA understands that two new registries need to be created. The IANA will create a new Internet Message Access Protocol (IMAP) 4 LIST-EXTENDED registry. In this registry will be two new subregistries: the LIST-EXTENDED options subregistry and the LIST-EXTENDED response subregistry.

The new LIST-EXTENDED options subregistry will be populated with the following initial entries:

LIST-EXTENDED option name: SUBSCRIBED
LIST-EXTENDED option type: SELECTION
Implied return options(s): SUBSCRIBED
LIST-EXTENDED option description: Causes the LIST command to list
subscribed mailboxes, rather than the actual mailboxes.
Published specification : XXXX, Section 3.
Security considerations: XXXX, Section 8.
Intended usage: COMMON
Person and email address to contact for further information: Alexey
Melnikov
Owner/Change controller: iesg@ietf.org

LIST-EXTENDED option name: REMOTE
LIST-EXTENDED option type: SELECTION
Implied return options(s): (none)
LIST-EXTENDED option description: causes the LIST command to return remote
mailboxes as well as local ones, as described in RFC 2193.
Published specification : XXXX, Section 3.
Security considerations: XXXX, Section 8.
Intended usage: COMMON
Person and email address to contact for further information: Alexey
Melnikov
Owner/Change controller: iesg@ietf.org

LIST-EXTENDED option name: SUBSCRIBED
LIST-EXTENDED option type: RETURN
LIST-EXTENDED option description: Causes the LIST command to return
subscription state.
Published specification : XXXX, Section 3.
Security considerations: XXXX, Section 8.
Intended usage: COMMON
Person and email address to contact for further information: Alexey
Melnikov
Owner/Change controller: iesg@ietf.org

LIST-EXTENDED option name: RECURSIVEMATCH
LIST-EXTENDED option type: SELECTION
Implied return options(s): (none)
LIST-EXTENDED option description: Requests that CHILDINFO extended data
item (childinfo-extended-item) is to be returned.
Published specification : XXXX, Section 3.
Security considerations: XXXX, Section 8.
Intended usage: COMMON
Person and email address to contact for further information: Alexey
Melnikov
Owner/Change controller: iesg@ietf.org

LIST-EXTENDED option name: CHILDREN
LIST-EXTENDED option type: RETURN
LIST-EXTENDED option description: Requests mailbox child information.
Published specification : XXXX, Section 3 and Section 4.
Security considerations: XXXX, Section 8.
Intended usage: COMMON
Person and email address to contact for further information: Alexey
Melnikov
Owner/Change controller: iesg@ietf.org

The new LIST-EXTENDED response subregistry will be populated with the following
initial entry:

LIST-EXTENDED extended data item tag: CHILDINFO
LIST-EXTENDED extended data item description: The CHILDINFO extended data
item describes the selection criteria that has caused it to be returned and indicates that the mailbox has one or more child mailbox that match the selection criteria.
Which LIST-EXTENDED option(s) (and their types) causes this extended data
item to be returned (if any): RECURSIVEMATCH selection option
Published specification : XXXX, Section 3.5.
Security considerations: XXXX, Section 8.
Intended usage: COMMON
Person and email address to contact for further information: Alexey
Melnikov
Owner/Change controller: iesg@ietf.org

The IANA understands these to be the only IANA Actions needed upon approval of the document.

[Ballot comment]
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?