clarify who owns what version specifiers

Author: ewdurbin

peps/pep-0694.rst

@@ -171,11 +171,19 @@ these steps:
 Versioning
 ----------
 
-This PEP uses the same ``MAJOR.MINOR`` versioning system as used in :pep:`691`, but it is otherwise
-independently versioned. The legacy API is considered by this PEP to be version ``1.0``, but this
-PEP does not modify the legacy API in any way.
+This PEP uses the same ``MAJOR.MINOR`` versioning system as used in :pep:`691`,
+but it is otherwise independently versioned.
+The legacy API is considered by this PEP to be version ``1.0``,
+but this PEP does not modify the legacy API in any way.
 
-The API proposed in this PEP therefor has the version number ``2.0``.
+The API proposed in this PEP therefore has the version number ``2.0``.
+
+Both major and minor version numbers of the Upload API
+**MUST** only be changed through the PEP process.
+Index operators and implementers **MUST NOT** advertise or implement
+new API versions without an approved PEP.
+This ensures consistency across all implementations
+and prevents fragmentation of the ecosystem.
 
 Content Types
 -------------
@@ -209,14 +217,19 @@ defined in this PEP **MUST** include a ``Content-Type`` header value of:
 - ``application/vnd.pypi.upload.v2+json``.
 
 Similar to :pep:`691`, this PEP also standardizes on using server-driven content negotiation to
-allow clients to request different versions or serialization formats, which includes the ``format``
-part of the content type.  However, since this PEP expects the existing legacy ``1.0`` upload API
-to exist at a different endpoint, and this PEP currently only provides for JSON serialization, this
-mechanism is not particularly useful.
+allow clients to request different versions or serialization formats,
+which includes the ``format`` part of the content type.
+However, since this PEP expects the existing legacy ``1.0`` upload API
+to exist at a different endpoint,
+and this PEP currently only provides for JSON serialization,
+this mechanism is not particularly useful.
 Clients only have a single version and serialization they can request.
 However clients **SHOULD** be prepared to handle content negotiation gracefully
 in the case that additional formats or versions are added in the future.
 
+Servers **MUST NOT** advertise support for API versions beyond those defined in approved PEPs.
+Any new versions or formats require standardization through a new PEP.
+
 Unless otherwise specified, all HTTP requests and responses in this document are assumed to include
 the HTTP header:
 
@@ -876,7 +889,9 @@ Each major version of the Upload API **MUST** specify at least one required File
 
 New required mechanisms **MUST NOT** be added
 and existing required mechanisms **MUST NOT** be removed
-without an update to the :ref:`major version <versioning>`.  Any server-specific or experimental mechanisms added or removed **MUST NOT** change the major or minor version number of this specification.
+without an update to the :ref:`major version <versioning>`.
+Any server-specific or experimental mechanisms added or removed
+**MUST NOT** change the major or minor version number of this specification.
 
 .. _required-file-upload-mechanisms:
 
@@ -936,15 +951,25 @@ and contain only alphanumeric characters ``[a-z0-9]``.
 The ``implementation identifier`` **SHOULD** concisely describe the underlying implementation
 and contain only alphanumeric characters ``[a-z0-9]`` and ``-``.
 
+When server operators need to make breaking changes to their upload mechanisms,
+they **SHOULD** create a new mechanism identifier rather than modifying the existing one.
+The recommended pattern is to append a version suffix like ``-v1``, ``-v2``, etc.
+to the implementation identifier.
+This allows clients to explicitly opt into new versions while maintaining
+backward compatibility with existing clients.
+
 For example:
 
 ====================================== ================  =========================================================================
 File Upload Mechanism string           Server Operator   Mechanism description
 ====================================== ================  =========================================================================
 ``vnd-pypi-s3multipart-presigned``     PyPI              S3 multipart upload via pre-signed URL
+``vnd-pypi-s3multipart-presigned-v2``  PyPI              S3 multipart upload via pre-signed URL version 2
 ``vnd-pypi-http-fetch``                PyPI              File delivered by instructing server to fetch from a URL via HTTP request
 ``vnd-acmecorp-http-fetch``            Acme Corp         File delivered by instructing server to fetch from a URL via HTTP request
 ``vnd-acmecorp-postal``                Acme Corp         File delivered via postal mail
+``vnd-widgetinc-stream-v1``            Widget Inc.       Streaming upload protocol version 1
+``vnd-widgetinc-stream-v2``            Widget Inc.       Streaming upload protocol version 2
 ``vnd-madscience-quantumentanglement`` Mad Science Labs  Upload via quantum entanglement
 ====================================== ================  =========================================================================