Last bit of cleanup before post: clarify behavior for not-enough-content

case, and improved punctuation of Graham's acknowledgement.

pep-3333.txt

@@ -915,9 +915,10 @@ If the application supplies a ``Content-Length`` header, the server
 **should not** transmit more bytes to the client than the header
 allows, and **should** stop iterating over the response when enough
 data has been sent, or raise an error if the application tries to
-``write()`` past that point.
-
-XXX What if the application doesn't provide *enough* data?
+``write()`` past that point.  (Of course, if the application does
+not provide *enough* data to meet its stated ``Content-Length``,
+the server **should** close the connection and log or otherwise
+report the error.)
 
 If the application does not supply a ``Content-Length`` header, a
 server or gateway may choose one of several approaches to handling
@@ -1737,9 +1738,9 @@ thoughtful feedback made this revised draft possible.  Especially:
   HTTP RFC compliance, especially with regard to HTTP/1.1 features that
   I didn't even know existed until he pointed them out.
 
-* Graham Dumpleton, who worked tirelessly in the face of my laziness
-  and stupidity to get some sort of Python 3 version out, who proposed
-  the "native strings" vs. "byte strings" concept, and thoughtfully
+* Graham Dumpleton, who worked tirelessly (even in the face of my laziness
+  and stupidity) to get some sort of Python 3 version of WSGI out, who
+  proposed the "native strings" vs. "byte strings" concept, and thoughtfully
   wrestled through a great many HTTP, ``wsgi.input``, and other
   amendments.  Most, if not all, of the credit for this new PEP
   belongs to him.