Fix wording and clarify that the IDNA codec operates on full domain names.

Before reading the code to check, I wasn't sure if it operated on
full domain names or just individual labels.

1 files changed, 8 insertions, 2 deletions

diff --git a/Doc/library/codecs.rst b/Doc/library/codecs.rst
index 8a93f3a..d07dafa 100644
--- a/Doc/library/codecs.rst
+++ b/Doc/library/codecs.rst
@@ -1185,8 +1185,12 @@ the user: The application should transparently convert Unicode domain labels to
 IDNA on the wire, and convert back ACE labels to Unicode before presenting them
 to the user.
 
-Python supports this conversion in several ways: The ``idna`` codec allows to
-convert between Unicode and the ACE. Furthermore, the :mod:`socket` module
+Python supports this conversion in several ways:  the ``idna`` codec performs
+conversion between Unicode and ACE, separating an input string into labels
+based on the separator characters defined in `section 3.1`_ (1) of :rfc:`3490`
+and converting each label to ACE as required, and conversely separating an input
+byte string into labels based on the ``.`` separator and converting any ACE
+labels found into unicode.  Furthermore, the :mod:`socket` module
 transparently converts Unicode host names to ACE, so that applications need not
 be concerned about converting host names themselves when they pass them to the
 socket module. On top of that, modules that have host names as function
@@ -1194,6 +1198,8 @@ parameters, such as :mod:`http.client` and :mod:`ftplib`, accept Unicode host
 names (:mod:`http.client` then also transparently sends an IDNA hostname in the
 :mailheader:`Host` field if it sends that field at all).
 
+.. _section 3.1: http://tools.ietf.org/html/rfc3490#section-3.1
+
 When receiving host names from the wire (such as in reverse name lookup), no
 automatic conversion to Unicode is performed: Applications wishing to present
 such host names to the user should decode them to Unicode.