Skip to main content

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 revision 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
I-D last updated 2009-09-03
Completed reviews Secdir Last Call review of -?? by Paul E. Hoffman
Assignment Reviewer Paul E. Hoffman
State Completed
Request Last Call review on draft-ietf-eai-imap-utf8 by Security Area Directorate Assigned
Completed 2009-09-03
review-ietf-eai-imap-utf8-secdir-lc-hoffman-2009-09-03-00
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