PEP 621: Clarify points brought up from public consultation (#1465)

pep-0621.rst

@@ -93,7 +93,8 @@ Tools MUST specify fields defined by this PEP in a table named
 ``[project]``. No tools may add fields to this table which are not
 defined by this PEP. For tools wishing to store their own settings in
 ``pyproject.toml``, they may use the ``[tool]`` table as defined in
-:pep:`518`.
+:pep:`518`. The lack of a ``[project]`` table implicitly means the
+build tool will dynamically provide all fields.
 
 ``name``
 ''''''''
@@ -172,8 +173,9 @@ file path ends in a case-insensitive ``.md`` suffix, then tools MUST
 assume the content-type is ``text/markdown``. If the file path ends in
 a case-insensitive ``.rst``, then tools MUST assume the content-type
 is ``text/x-rst``. If a tool recognizes more extensions than this PEP,
-they MAY infer the content-type for the user. For all unrecognized
-suffixes, tools MUST raise an error.
+they MAY infer the content-type for the user without specifying this
+field as ``dynamic``. For all unrecognized suffixes when a
+content-type is not provided, tools MUST raise an error.
 
 The ``readme`` field may also take a table. The ``file`` key has a
 string value representing a relative path to a file containing the
@@ -186,7 +188,7 @@ specifying the content-type of the full description. A tool MUST raise
 an error if the metadata does not specify this field in the table. If
 the metadata does not specify the ``charset`` parameter, then it is
 assumed to be UTF-8. Tools MAY support other encodings if they choose
-to.  Tools MAY support alternative content-types which they can
+to. Tools MAY support alternative content-types which they can
 transform to a content-type as supported by the `core metadata`_.
 Otherwise tools MUST raise an error for unsupported content-types.
 
@@ -270,6 +272,14 @@ Using the data to fill in `core metadata`_ is as follows:
 3. If both ``email`` and ``name`` are provided, the value goes in
    ``Author-email``, with the format ``{name} <{email}>``.
 
+This use of the field is a slight deviation as the core metadata also
+supports a ``Maintainer`` field which goes unused by this PEP. The
+authors of this PEP felt this field was ambiguous and never clearly
+defined. Other ecosystems have selected "author" as the term to use.
+As such, it was decided it would be better to standardize on
+``Author`` in the core metadata as the place to list people
+maintaining a project.
+
 ``keywords``
 ''''''''''''
 - Format: array of strings