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)
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

Yes ()

                            

(Bill Fenner; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Cullen Jennings; former steering group member) No Objection

No Objection ()

                            

(David Kessens; former steering group member) No Objection

No Objection ()

                            

(Jari Arkko; former steering group member) No Objection

No Objection ()

                            

(Jon Peterson; former steering group member) No Objection

No Objection ()

                            

(Mark Townsley; former steering group member) No Objection

No Objection ()

                            

(Ross Callon; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) No Objection

No Objection ()

                            

(Sam Hartman; former steering group member) No Objection

No Objection ()

                            

(Ted Hardie; former steering group member) No Objection

No Objection ()