Respond to more feedback from Adam

Author: emmatyping

peps/pep-0819.rst

@@ -42,7 +42,7 @@ spaces and a pipe ('``|``') character. While ``Description`` may now be encoded
 the message body, similar escaping issues occur for the ``Author`` and
 ``Maintainer`` fields. Improperly escaped newlines can lead to missing,
 partial, or invalid core metadata. Second, as discussed in the
-`core metadata specifications <https://packaging.python.org/specifications/core-metadata/>`__:
+:ref:`core metadata specifications <packaging:core-metadata>`:
 
 .. epigraph::
 
@@ -61,25 +61,26 @@ However, the core metadata specifications also requires that core metadata is
 encoded using UTF-8 when written to a file. This de-facto makes the core
 metadata follow :rfc:`6532`, which specifies internationalization of email
 headers. This has practical interoperability concerns. Until a few years ago,
-it was unspecified how to handle non-ASCII encoded content in core metadata,
-causing confusion about how to properly encode non-ASCII emails in core
-metadata. Third, the current format is difficult to properly validate and
-parse. Many tools do not check for issues with the output of the :mod:`!email`
-parser. If a document is malformed, it may still parse without error by the
-:mod:`!email` module as a valid email message. Furthermore, due to limitations
-in the email format, fields like ``Project-Url`` must create custom encodings
-of nested key-value items, further complicating parsing.  Finally, the lack of
-a schema makes it difficult to validate the contents of email message encoded
-metadata. While introducing a specification for the current format has been
-`discussed previously <https://discuss.python.org/t/7550>`__,
-no progress had been made, and converting to JSON was a suggested resolution
-to the issues raised.
+it was unspecified how to properly encode non-ASCII emails in core
+metadata, making parsing ambiguous. Third, the current format is difficult to
+properly validate and parse. Many tools do not check for issues with the output
+of the :mod:`!email` parser. If a document is malformed, it may still parse
+without error by the :mod:`!email` module as a valid email message. Furthermore,
+due to limitations in the email format, fields like ``Project-Url`` must create
+custom encodings of nested key-value items, further complicating parsing and
+validation. Finally, the lack of a schema makes it difficult to validate the
+contents of email message encoded metadata. While introducing a specification
+for the current format has been
+`discussed previously <https://discuss.python.org/t/7550>`__, no progress had
+been made, and converting to JSON was a suggested resolution to the issues
+raised.
 
 The ``WHEEL`` file format is currently encoded in a custom key-value format.
 While this format is easy to parse and write, it requires manual parsing and
 validation to ensure that the contents are valid. Moving to a JSON encoded
 format will allow for easier parsing and validation of the contents, and
-simplify packaging tools and services.
+simplify packaging tools and services by using a consistent format for
+distribution metadata.
 
 
 Rationale
@@ -123,19 +124,22 @@ MUST be placed in the same directory as the current email formatted
 ``METADATA`` or ``PKG-INFO`` file.
 
 For wheels, this means that ``METADATA.json`` MUST be located in the
-``.dist-info`` directory. The wheel format minor version will be incremented to
-indicate the change in the format.
+``.dist-info`` directory.
 
-For source distribution packages, the ``METADATA.json`` file MUST be located
-in the root directory of the project sources. Tools that prefer the JSON
-formatted metadata file MUST check for the existence of a ``METADATA.json``
-in the source distribution before reading the file.
+If present, the ``METADATA.json`` file MUST be located in the root directory of
+the project sources in a source distribution package. Tools that prefer the
+JSON formatted metadata file MUST NOT assume the presence of the
+``METADATA.json`` file in the source distribution before reading the file.
 
 The semantic contents of the ``METADATA`` and ``METADATA.json`` files MUST be
 equivalent if ``METADATA.json`` is present. Installers MAY verify this
 information. Public package indexes SHOULD verify the files are semantically
 equivalent.
 
+The new ``METADATA.json`` file MUST be included in the
+:ref:`installed project metadata <packaging:recording-installed-packages>`,
+if present in the distribution metadata.
+
 Conversion of ``METADATA`` to JSON Encoding
 -------------------------------------------
 
@@ -200,7 +204,9 @@ A new optional but recommended file ``WHEEL.json`` shall be introduced as a
 JSON encoded version of the ``WHEEL`` file. If generated, the ``WHEEL.json``
 file MUST be placed in the same directory as the current key-value formatted
 ``WHEEL`` file, i.e. the ``.dist-info`` directory. The semantic contents of
-the ``WHEEL`` and ``WHEEL.json`` files MUST be equivalent.
+the ``WHEEL`` and ``WHEEL.json`` files MUST be equivalent. The wheel file
+format version will be incremented to ``1.1`` to reflect the introduction
+of ``WHEEL.json``.
 
 The ``WHEEL.json`` file SHOULD be preferred over the ``WHEEL`` file when both
 are present.