Grammatical and minor content changes to PEP 546. (#274)

* Grammatical changes to PEP 546

* Address @alex's grammatical feedback.

pep-0546.txt

@@ -12,17 +12,18 @@ Created: 30-May-2017
 Abstract
 ========
 
-Backport ssl.MemoryBIO and ssl.SSLObject classes from Python 3 to Python
+Backport the ssl.MemoryBIO and ssl.SSLObject classes from Python 3 to Python
 2.7 to enhance the overall security of Python 2.7.
 
 
 Rationale
 =========
 
-While Python 2.7 is getting closer to its end-of-line (scheduled for
-2020), it is still used on production and the Python community is still
-responsible for its security. And to facilitate the future adoption of
-:pep:`543`, which will improve security for Python3 users.
+While Python 2.7 is getting closer to its end-of-support date (scheduled for
+2020), it is still used on production systems and the Python community is still
+responsible for its security. This PEP will help facilitate the future adoption
+of :pep:`543` across all supported Python versions, which will improve security
+for both Python 2 and Python 3 users.
 
 This PEP does NOT propose a general exception for backporting new
 features to Python 2.7 - every new feature proposed for backporting will
@@ -34,37 +35,32 @@ Python Package Index instead is not an acceptable solution.
 PEP 543
 -------
 
-The :pep:`543` defines a new TLS API for Python which would enhance the
-Python security: give access to the root certificate authorities on
-Windows and macOS by using native APIs, instead of OpenSSL. A side effect
-is that it gives access to certificates installed locally by system
-administrators, allowing to use "company certificates" without having to
-modify each Python application and so validate correctly TLS
-certificates (instead of having to ignore or bypass the TLS certificate
-validation).
+:pep:`543` defines a new TLS API for Python which would enhance Python
+security by giving Python applications access to the native TLS implementations
+on Windows and macOS, instead of using OpenSSL. A side effect is that it gives
+access to the system trust store and certificates installed
+locally by system administrators, enabling Python applications to use "company
+certificates" without having to modify each application and so to correctly
+validate TLS certificates (instead of having to ignore or bypass TLS
+certificate validation).
 
 For practical reasons, Cory Benfield would like to first implement an
-I/O-less class similar to ssl.MemoryBIO and ssl.SSLObject for the
-:pep:`543`, and provide a second class based on the first one to use
+I/O-less class similar to ssl.MemoryBIO and ssl.SSLObject for
+:pep:`543`, and to provide a second class based on the first one to use
 sockets or file descriptors.  This design would help to structure the code
-to support more backends and simplify testing and auditing. Later,
-optimized classes using directly sockets or file descriptors may be
-added for performance.
+to support more backends and simplify testing and auditing, as well as
+implementation. Later, optimized classes using directly sockets or file
+descriptors may be added for performance.
 
-While the :pep:`543` defines an API, the PEP would only make sense if it
+While :pep:`543` defines an API, the PEP would only make sense if it
 comes with at least one complete and good implementation. The first
-implementation will be based on the ``ssl`` module of the Python
-standard library.
+implementation would ideally be based on the ``ssl`` module of the Python
+standard library, as this is shipped to all users by default and can be used as
+a fallback implementation in the absence of anything more targetted.
 
-In a perfect world, all applications would already run on Python 3 since
-Python 3.0 was released. In practice, many applications still run on
-production on top of Python 2.7. To make the new TLS API more widely
-used, it should be usable on all Python versions currently supported:
-Python 2.7, 3.5, 3.6. Otherwise, some applications would have to wait
-until they drop Python 2 support to be able to use the new TLS API.
-
-Delaying adoption of the PEP 543 API means delaying the adoption for
-security improvements for Python 3 users as well.
+If this backport is not performed, the only baseline implementation that could
+be used would be pyOpenSSL. This is problematic, however, because of the
+interaction with pip, which is shipped with CPython on all supported versions.
 
 
 requests, pip and ensurepip
@@ -77,19 +73,19 @@ solution that Twisted currently does: namely, a mandatory dependency on
 `pyOpenSSL <https://pypi.python.org/pypi/pyOpenSSL>`_.
 
 The `pip <https://pip.pypa.io/>`_ program has to embed all its
-dependencies for pratical reason. Since pip depends on requests, it means
-that it would have to embed a copy of pyOpenSSL. That would imply
+dependencies for practical reasons: namely, that it cannot rely on any other
+installation method being present. Since pip depends on requests, it means
+that it would have to embed a copy of pyOpenSSL. That would imply substantial
 usability pain to install pip. Currently, pip doesn't support embedding
 C extensions which must be compiled on each platform and so require a C
 compiler.
 
 Since Python 2.7.9, Python embeds a copy of pip both for default
-installation and for use in virtual environments: the new ``ensurepip``
-module. If pip ends up bundling PyOpenSSL, then Python will end up
+installation and for use in virtual environments via the new ``ensurepip``
+module. If pip ends up bundling PyOpenSSL, then CPython will end up
 bundling PyOpenSSL. Only backporting ``ssl.MemoryBIO`` and
-``ssl.SSLObject`` would avoid to have to embed pyOpenSSL to only include
-the strict minimum features required by requests and fix the bootstrap
-issue (python -> ensurepip -> pip -> requests -> MemoryBIO).
+``ssl.SSLObject`` would avoid the need to embed pyOpenSSL, and would fix the
+bootstrap issue (python -> ensurepip -> pip -> requests -> MemoryBIO).
 
 
 Changes