Changeset 2647 for draft-ietf-httpbis/latest/p2-semantics.xml

Timestamp:

06/05/14 16:20:31 (9 years ago)

Author:

julian.reschke@…

Message:

mainly grammatical fixes (#553)

File:

• draft-ietf-httpbis/latest/p2-semantics.xml (modified) (13 diffs)

draft-ietf-httpbis/latest/p2-semantics.xml

@@ -206 +206 @@
    identified request target, and responds to that request with one or more
    response messages. A client constructs request messages to communicate
-   specific intentions, and examines received responses to see if the
-   intentions were carried out, and determine how to interpret the results.
+   specific intentions, examines received responses to see if the
+   intentions were carried out, and determines how to interpret the results.
    This document defines HTTP/1.1 request and response semantics in terms of
    the architecture defined in <xref target="RFC7230"/>.
@@ -317 +317 @@
 </t>
 <t>
-   An origin server might be provided with, or capable of generating, multiple
+   An origin server might be provided with, or be capable of generating, multiple
    representations that are each intended to reflect the current state of a
    <x:ref>target resource</x:ref>. In such cases, some algorithm is used by
@@ -388 +388 @@
 <t>
    A parameter value that matches the <x:ref>token</x:ref> production can be
-   transmitted as either a token or within a quoted-string. The quoted and
+   transmitted either as a token or within a quoted-string. The quoted and
    unquoted values are equivalent. For example, the following examples are
    all equivalent, but the first is preferred for consistency:
@@ -423 +423 @@
 </artwork></figure>
 <t>
-   Charset names ought to be registered in IANA Character Set registry
+   Charset names ought to be registered in the IANA Character Set registry
    (<eref target="http://www.iana.org/assignments/character-sets"/>)
    according to the procedures defined in <xref target="RFC2978"/>.
@@ -1495 +1495 @@
    This requirement allows a user agent to know when the representation body
    it has in memory remains current as a result of the PUT, thus not in need
-   of retrieving again from the origin server, and that the new validator(s)
+   of being retrieved again from the origin server, and that the new validator(s)
    received in the response can be used for future conditional requests in
    order to prevent accidental overwrites (<xref target="request.conditionals"/>).
@@ -1700 +1700 @@
 <t>
    The OPTIONS method requests information about the communication options
-   available for the target resource, either at the origin server or an
+   available for the target resource, at either the origin server or an
    intervening intermediary. This method allows a client to determine the
    options and/or requirements associated with a resource, or the capabilities
@@ -2571 +2571 @@
    A sender &SHOULD-NOT; generate information in <x:ref>product-version</x:ref>
    that is not a version identifier (i.e., successive versions of the same
-   product name ought to only differ in the product-version portion of the
+   product name ought only to differ in the product-version portion of the
    product identifier).
 </t>
@@ -3285 +3285 @@
 <t>
    The <x:dfn>400 (Bad Request)</x:dfn> status code indicates that the server
-   cannot or will not process the request due to something which is perceived
+   cannot or will not process the request due to something that is perceived
    to be a client error (e.g., malformed request syntax, invalid request
    message framing, or deceptive request routing).
@@ -3906 +3906 @@
 <t>
    If the Location value provided in a <x:ref>3xx (Redirection)</x:ref>
-   does not have a fragment component, a user agent &MUST; process the
+   response does not have a fragment component, a user agent &MUST; process the
    redirection as if the value inherits the fragment component of the URI
    reference used to generate the request target (i.e., the redirection
@@ -4340 +4340 @@
 </t>
 <t>
-   This Section replaces the registration procedure for HTTP Status Codes
+   This section replaces the registration procedure for HTTP Status Codes
    previously defined in <xref target="RFC2817" x:fmt="of" x:sec="7.1"/>.
 </t>
@@ -4620 +4620 @@
 <t>   
    Authors of specifications defining new fields are
-   advised to keep the name as short as practical and to not prefix the name
+   advised to keep the name as short as practical and not to prefix the name
    with "X-" unless the header field will never be used on the Internet.
-   (The "x-" prefix idiom has been extensively misused in practice; it was
+   (The "X-" prefix idiom has been extensively misused in practice; it was
    intended to only be used as a mechanism for avoiding name collisions inside
    proprietary software or intranet processing, since the prefix would ensure
    that private names never collide with a newly registered Internet name; see
-   <xref target="BCP178"/> for further information)
+   <xref target="BCP178"/> for further information).
 </t>
 <t>
@@ -4937 +4937 @@
    For example, UNIX, Microsoft Windows, and other operating systems use ".."
    as a path component to indicate a directory level above the current one,
-   and use specially named paths or file names to send data to system devices.
+   and they use specially named paths or file names to send data to system devices.
    Similar naming conventions might exist within other types of storage
    systems. Likewise, local storage systems have an annoying tendency to
@@ -5807 +5807 @@
    representations and with extensible header fields. However, RFC 2045
    is focused only on email; applications of HTTP have many characteristics
-   that differ from email, and hence HTTP has features that differ from MIME.
+   that differ from email; hence, HTTP has features that differ from MIME.
    These differences were carefully chosen to optimize performance over binary
    connections, to allow greater freedom in the use of new media types, to