Address more review comments

peps/pep-0770.rst

@@ -29,9 +29,6 @@ frameworks.
 This PEP proposes using SBOM documents included in Python packages as a
 means to improve automated software measurability for Python packages.
 
-The changes will update the
-`Core Metadata specification <coremetadataspec_>`__ to version 2.5.
-
 Motivation
 ==========
 
@@ -155,13 +152,19 @@ begin emitting the new metadata version, again wait for releases, and only then
 can projects begin using the new features. Even with this careful approach it's
 not guaranteed that tools won't break on new metadata versions and fields.
 
-To avoid this delay, this PEP proposes a new mechanism ``[additional-files]``
-to safely add data to a Python package through a registry of reserved names that
+To avoid this delay, simplify overall how to include SBOMs, and to give
+flexibility to build backends and tools, this PEP proposes a new top-level table
+in ``pyproject.toml``, ``[additional-files]``, to safely add data to a Python
+package through a registry of reserved names that
 avoids the need for new metadata fields and versions.  This mechanism allows
 build backends and tools to begin using the features described in this PEP
 immediately after acceptance without the head-of-line blocking on other
 projects adopting the PEP.
 
+A new top-level table was chosen over using the ``[project]`` table because,
+as described in :pep:`621`, the ``[project]`` table is used for storing core
+metadata and this mechanism doesn't use core metadata.
+
 What are the differences between PEP 770 and PEP 725?
 -----------------------------------------------------
 
@@ -172,8 +175,8 @@ software within Python packaging metadata. This section aims to show how these
 two PEPs are tracking different information and serving different use-cases:
 
 * PEP 725 describes **abstract dependencies**, such as requiring "a C compiler"
-  as a build-time dependency (``virtual:compiler/c``) or an "OpenSSL-like
-  library" (``pkg:generic/openssl``). PEP 770 describes
+  as a build-time dependency (``virtual:compiler/c``) or needing to link "the
+  OpenSSL library" at build time (``pkg:generic/openssl``). PEP 770 describes
   **concrete dependencies**, more akin to dependencies in a "lock file", such as
   an exact name, version, architecture, and
   hash of a software library distributed through AlmaLinux distribution
@@ -241,14 +244,17 @@ the ``.dist-info`` directory for the :term:`distribution archive`
 and :term:`installed project` s project types. Future additions to this registry
 will be made through the PEP process. The initial values in this registry are:
 
-================= ==========
-Subdirectory name    PEP
-================= ==========
+================= ==============
+Subdirectory name PEP / Standard
+================= ==============
 ``licenses``      :pep:`639`
-``license_files`` N/A (See :ref:`770-backwards-compat`)
-``LICENSES``      N/A (See :ref:`770-backwards-compat`)
+``license_files`` :pep:`639` (draft-only)
+``LICENSES``      `REUSE licensing framework <https://reuse.software>`__
 ``sboms``         :pep:`770`
-================= ==========
+================= ==============
+
+See :ref:`770-backwards-compat` for a complete methodology for
+creating this initial set of values to avoid backwards incompatibility issues.
 
 .. _770-spec-project-source-metadata: