POP3 Support for UTF-8
RFC 5721

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    eai mailing list <ima@ietf.org>, 
    eai chair <eai-chairs@tools.ietf.org>
Subject: Document Action: 'POP3 Support for UTF-8' to Experimental RFC

The IESG has approved the following document:

- 'POP3 Support for UTF-8 '
   <draft-ietf-eai-pop-09.txt> as an Experimental RFC


This document is the product of the Email Address Internationalization Working Group. 

The IESG contact persons are Alexey Melnikov and Lisa Dusseault.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-eai-pop-09.txt

Technical Summary 

  This specification extends the Post Office Protocol version 3 (POP3)
  to support un-encoded international characters in user names,
  passwords, mail addresses, message headers, and protocol-level
  textual error strings.

Working Group Summary 

  The WG explored a couple of different designs for this
  extension. The path chosen (a global switch to UTF-8 only mode)
  has the consensus of the WG.

Document Quality 

   At least one existing implementation of the document exists.

Personnel

   Harald Alvestrand is the document shepherd. Alexey Melnikov
   is the responsible AD.

RFC Editor Note

In Section 3.2, change the 4th paragraph to read:

OLD:
  When applying SASLprep [RFC4013], servers MUST reject UTF-8 user
  names or passwords which contain a Unicode character listed in
  section 2.3 of SASLprep [RFC4013].

NEW:
  When applying SASLprep [RFC4013], servers MUST reject UTF-8 user
  names or passwords which contain a Unicode character listed in
  section 2.3 of SASLprep [RFC4013].
  When applying SASLPrep to the USER argument, to the PASS argument
  or to the APOP username argument, a compliant server or client MUST
  treat them as a query string (i.e., unassigned Unicode codepoints are
  allowed). When applying SASLPrep to the APOP password argument, a
  compliant server or client MUST treat them as a stored string (i.e.,
  unassigned Unicode codepoints are prohibited).