Skip to main content

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

Yes

(Lisa Dusseault)

No Objection

(Bill Fenner)
(Cullen Jennings)
(David Kessens)
(Jari Arkko)
(Jon Peterson)
(Mark Townsley)
(Ross Callon)
(Russ Housley)
(Sam Hartman)
(Ted Hardie)

Note: This ballot was opened for revision 18 and is now closed.

Lars Eggert
No Objection
Comment (2006-08-15) Unknown
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 IESG member
Yes
Yes () Unknown

                            
Bill Fenner Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Cullen Jennings Former IESG member
No Objection
No Objection () Unknown

                            
David Kessens Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection () Unknown

                            
Jon Peterson Former IESG member
No Objection
No Objection () Unknown

                            
Mark Townsley Former IESG member
No Objection
No Objection () Unknown

                            
Ross Callon Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection () Unknown

                            
Sam Hartman Former IESG member
No Objection
No Objection () Unknown

                            
Ted Hardie Former IESG member
No Objection
No Objection () Unknown