Last Call Review of draft-ietf-eai-imap-utf8-
review-ietf-eai-imap-utf8-secdir-lc-hoffman-2009-09-03-00

Request Review of draft-ietf-eai-imap-utf8
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-09-08
Requested 2009-08-17
Authors Chris Newman, Pete Resnick
Draft last updated 2009-09-03
Completed reviews Secdir Last Call review of -?? by Paul Hoffman
Assignment Reviewer Paul Hoffman 
State Completed
Review review-ietf-eai-imap-utf8-secdir-lc-hoffman-2009-09-03
Review completed: 2009-09-03

Review
review-ietf-eai-imap-utf8-secdir-lc-hoffman-2009-09-03

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

The security sections of this document are fine. The Security Considerations section says, in full:
   The security considerations of UTF-8 [RFC3629] and SASLprep [RFC4013]
   apply to this specification, particularly with respect to use of
   UTF-8 in user names and passwords.  Otherwise, this is not believed
   to alter the security considerations of IMAP4rev1.
That should actually sufficient for implementers of this document. The new uses of UTF-8 described here should not cause an additional security problems beyond what IMAP implementers already face.

The language used in the document is probably appropriate for an IMAP developer who has read lots of other IMAP extensions, but is quite rough for people reading this from an i18n or EAI perspective.

The document *is not ready* for IESG review, however. In fact, it should not have been placed in IETF Last Call in its current state. Did anyone even read the Abstract, for crying out loud? Further, the I-D Nits checker finds two hard errors: a line the is obviously too long, and an obsolete normative reference.

Even though this document hasn't garnered any other IETF Last Call comments, it really needs a careful review from the authors and the document shepherd. (The I-D tracker does not say who the document shepherd is, so I have Cc'd the two WG chairs on this note, assuming one of the two of them was the shepherd but that did not get reported to the tracker.)

--Paul Hoffman, Director
--VPN Consortium