Internet Message Access Protocol version 4 - LIST Command Extensions
RFC 5258
Yes
No Objection
Note: This ballot was opened for revision 18 and is now closed.
Lars Eggert No Objection
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?
(Lisa Dusseault; former steering group member) Yes
(Bill Fenner; former steering group member) (was Discuss) No Objection
(Cullen Jennings; former steering group member) No Objection
(David Kessens; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Jon Peterson; former steering group member) No Objection
(Mark Townsley; former steering group member) No Objection
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Sam Hartman; former steering group member) No Objection
(Ted Hardie; former steering group member) No Objection