IMAP4 Extensions for Quick Mailbox Resynchronization
draft-ietf-lemonade-reconnect-client-06

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

Lars Eggert No Objection

(Chris Newman; former steering group member) Yes

Yes ()
No email
send info

(Cullen Jennings; former steering group member) No Objection

No Objection ()
No email
send info

(Dan Romascanu; former steering group member) No Objection

No Objection ()
No email
send info

(David Ward; former steering group member) No Objection

No Objection ()
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection ()
No email
send info

(Jon Peterson; former steering group member) No Objection

No Objection ()
No email
send info

(Lisa Dusseault; former steering group member) No Objection

No Objection ()
No email
send info

(Magnus Westerlund; former steering group member) No Objection

No Objection ()
No email
send info

(Mark Townsley; former steering group member) No Objection

No Objection ()
No email
send info

(Ron Bonica; former steering group member) No Objection

No Objection ()
No email
send info

(Ross Callon; former steering group member) No Objection

No Objection ()
No email
send info

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Sam Hartman; former steering group member) No Objection

No Objection (2007-10-18)
No email
send info
I did not completely review the interactions when multiple clients are
manipulating a mailbox at the same time.  It looks complicated.  I'm
assuming that it has been thoroughly checked; if that is true, this
spec looks good.

(Tim Polk; former steering group member) (was Discuss) No Objection

No Objection (2007-10-17)
No email
send info
As a general rule, I am comfortable with security considerations by reference.  No
one should have to cut and paste the material out of an RFC you already reference.
However, I do believe it is unfair to readers to provide iterative referrals.

The Security Considerations section in this document is basically two pointers to the
security considerations in [CONDSTORE] and [RFC3501].  [CONDSTORE] (now RFC 4551)
is mentioned twice, so I really expected to find some content in the Security Considerations
section.  However, [CONDSTORE]'s Security Considerations section is only two sentences,
and one is a pointer to the security considerations in [RFC3501].

It might be better to replicate the content of CONDSTORE's security considerations
section in this document.