diff --git a/pep-0425.txt b/pep-0425.txt
index edf8157d9..fb482a5cb 100644
--- a/pep-0425.txt
+++ b/pep-0425.txt
@@ -64,6 +64,14 @@ platform tag
 For example, the tag py27-none-any indicates compatible with Python 2.7
 (any Python 2.7 implementation) with no abi requirement, on any platform.
 
+Use
+===
+
+The `wheel` built package format includes these tags in its filenames,
+of the form ``{distribution}-{version}(-{build tag})?-{python tag}-{abi
+tag}-{platform tag}.whl``.  Other package formats may have their own
+conventions.
+
 Details
 =======
 
@@ -103,8 +111,7 @@ extension modules.  For implementation-specific ABIs, the implementation
 is abbreviated in the same way as the Python Tag, e.g. `cp33d` would be
 the CPython 3.3 ABI with debugging.
 
-The CPython stable ABI is `abi3` as in the shared library suffix, and
-is available starting with Python 3.2.
+The CPython stable ABI is `abi3` as in the shared library suffix.
 
 Implementations with a very unstable ABI may use the first 6 bytes (as
 8 base64-encoded characters) of the SHA-256 hash of ther source code
@@ -135,19 +142,30 @@ For example, an installer running under CPython 3.3 on a linux_x86_64
 system might support::
 
  1. cp33-cp33m-linux_x86_64
- 2. cp33-none-linux_x86_64
- 3. cp3-abi3-linux_x86_64
+ 2. cp33-abi3-linux_x86_64
+ 3. cp33-none-linux_x86_64
  4. cp33-none-any
  5. cp3-none-any
- 6. py33-none-any
- 7. py3-none-any
+ 6. cp32-none-any
+ 7. cp31-none-any
+ 8. cp30-none-any
+ 9. py33-none-any
+ 10. py3-none-any
+ 11. py32-none-any
+ 12. py31-none-any
+ 13. py30-none-any
 
-A user could instruct their installer to fall back to building from an
-sdist more or less often by configuring this list of tags.
+The list is in order from most-preferred (a distribution with a
+compiled extension module, built for the current version of Python)
+to least-preferred (a pure-Python distribution built with an older
+version of Python).  A user could instruct their installer to fall back
+to building from an sdist more or less often by configuring this list of
+tags; for example, a user could include only the `*-none-any` tags to only
+download built packages that advertise themselves as being pure Python.
 
 Rarely there will be more than one supported built distribution for a
 particular version of a package.  For example, a packager could release
-a package tagged `cp3-abi3-linux_x86_64` that contains an optional C
+a package tagged `cp33-abi3-linux_x86_64` that contains an optional C
 extension and the same distribution tagged `py3-none-any` that does not.
 The index of the tag in the supported tags list breaks the tie, and the
 package with the C extension is installed in preference to the package
@@ -176,6 +194,13 @@ by no Python implementation e.g. "cp33-cp31u-win64", so use it sparingly.
 FAQ
 ===
 
+What tags are used by default?
+    Tools should use the most-preferred architecture dependent tag
+    e.g. `cp33-cp33m-win32` or the most-preferred pure python tag
+    e.g. `py33-none-any` by default.  If the packager overrides the
+    default it indicates that they intended to provide cross-Python
+    compatibility.
+
 Can I have a tag `py32+` to indicate a minimum Python minor release?
     No.  Inspect the Trove classifiers to determine this level of
     cross-release compatibility.  Similar to the announcements "beaglevote