Changeset 1964 for draft-ietf-httpbis/latest/p1-messaging.xml

Timestamp:

Nov 1, 2012, 11:46:15 AM (7 years ago)

Author:

julian.reschke@…

Message:

editorial improvements (ack Dan W.)

File:

• draft-ietf-httpbis/latest/p1-messaging.xml (modified) (4 diffs)

draft-ietf-httpbis/latest/p1-messaging.xml

@@ -547 +547 @@
    can be understood in isolation.  Many implementations depend on HTTP's
    stateless design in order to reuse proxied connections or dynamically
-   load balance requests across multiple servers.  Hence, servers &MUST-NOT;
+   load-balance requests across multiple servers.  Hence, servers &MUST-NOT;
    assume that two requests on the same connection are from the same user
    agent unless the connection is secured and specific to that agent.
@@ -758 +758 @@
    the minor version was not incremented for the changes introduced between
    <xref target="RFC2068"/> and <xref target="RFC2616"/>, and this revision
-   is specifically avoiding any such changes to the protocol.
+   has specifically avoiding any such changes to the protocol.
 </t>
 </section>
@@ -2997 +2997 @@
 <t>
    A server that receives a <x:ref>close</x:ref> connection option &MUST;
-   initiate a lingering close of the connection after it sends the final
-   response to the request that contained <x:ref>close</x:ref>.
+   initiate a lingering close (see below) of the connection after it sends the
+   final response to the request that contained <x:ref>close</x:ref>.
    The server &SHOULD; include a <x:ref>close</x:ref> connection option
    in its final response on that connection. The server &MUST-NOT; process
@@ -3593 +3593 @@
    HTTP clients rely heavily on the Domain Name Service (DNS), and are thus
    generally prone to security attacks based on the deliberate misassociation
-   of IP addresses and DNS names not protected by DNSSec. Clients need to be
+   of IP addresses and DNS names not protected by DNSSEC. Clients need to be
    cautious in assuming the validity of an IP number/DNS name association unless
-   the response is protected by DNSSec (<xref target="RFC4033"/>).
+   the response is protected by DNSSEC (<xref target="RFC4033"/>).
 </t>
 </section>