Minor updates

Author: warsaw

peps/pep-0694.rst

@@ -137,8 +137,12 @@ methods.
 Upload 2.0 API Specification
 ============================
 
-This PEP traces the root cause of most of the issues with the existing API to be
-roughly two things:
+This PEP draws inspiration from the `Resumable Uploads for HTTP <ietf-draft>`_ internet draft,
+however it has some significant differences.  This is largely due to the unique nature of Python
+package releases (i.e. metadata, multiple related artifacts, etc.), and the support for an upload
+session and release stages.  Where it makes sense to adopt details of the draft, this PEP does so.
+
+This PEP traces the root cause of most of the issues with the existing API to be roughly two things:
 
 - The metadata is submitted alongside the file, rather than being parsed from the
   file itself. [#fn-metadata]_
@@ -182,8 +186,8 @@ being tested, and will be blessed as permanent after sufficient testing with liv
 Create an Upload Session
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
-To create a new upload session, submit a ``POST`` request to ``/`` (i.e. the root URL), with a
-payload that looks like:
+To create a new upload session, submit a ``POST`` request to the root URL, with a payload that looks
+like:
 
 .. code-block:: json
 
@@ -230,7 +234,7 @@ requests.
 
 .. _session-response:
 
-Response body
+Response Body
 +++++++++++++
 
 The successful response includes the following JSON content:
@@ -402,8 +406,8 @@ Besides the standard ``meta`` key, the request JSON has the following additional
     If given, this is a string value containing the file's `core metadata
     <https://packaging.python.org/en/latest/specifications/core-metadata/>`_.
 
-Servers **MAY** use the data provided in this request to do some sanity checking prior to
-allowing the file to be uploaded.  These checks may include, but are not limited to:
+Servers **MAY** use the data provided in this request to do some sanity checking prior to allowing
+the file to be uploaded.  These checks may include, but are not limited to:
 
 - Checking if the ``filename`` already exists in a published release
 - Checking if the ``size`` would exceed any project or file quota
@@ -838,7 +842,7 @@ It's actually the protocol specified in an `active internet draft <ietf-draft>`_
 took what they learned implementing `tus <https://tus.io/>`_ to provide the idea of resumable
 uploads in a wholly generic, standards based way.
 
-.. _ietf-draft: https://datatracker.ietf.org/doc/draft-ietf-httpbis-resumable-upload/
+.. _ietf-draft: https://www.ietf.org/archive/id/draft-ietf-httpbis-resumable-upload-05.html
 
 The only deviation we've made from that spec is that we don't use the ``104 Upload Resumption
 Supported`` informational response in the first ``POST`` request. This decision was made for a few