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

Timestamp:

06/05/14 12:37:38 (9 years ago)

Author:

julian.reschke@…

Message:

punctuation (#553)

File:

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

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

@@ -207 +207 @@
    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.
+   intentions were carried out, and determine 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"/>.
@@ -650 +650 @@
    separated by a hyphen character ("-", %x2D).  In most cases, a language tag
    consists of a primary language subtag that identifies a broad family of
-   related languages (e.g., "en" = English) which is optionally followed by a
+   related languages (e.g., "en" = English), which is optionally followed by a
    series of subtags that refine or narrow that language's range (e.g.,
    "en-CA" = the variety of English as communicated in Canada).
@@ -1274 +1274 @@
    &caching;. In general, safe methods that do not depend on a current or
    authoritative response are defined as cacheable; this specification defines
-   GET, HEAD and POST as cacheable, although the overwhelming majority of 
+   GET, HEAD, and POST as cacheable, although the overwhelming majority of 
    cache implementations only support GET and HEAD.
 </t>
@@ -1297 +1297 @@
 <t>
    It is tempting to think of resource identifiers as remote file system
-   pathnames, and of representations as being a copy of the contents of such
+   pathnames and of representations as being a copy of the contents of such
    files. In fact, that is how many resources are implemented (see
    <xref target="attack.pathname"/> for related security considerations).
@@ -1305 +1305 @@
    other information systems. Even when the URI mapping mechanism is tied to a
    file system, an origin server might be configured to execute the files with
-   the request as input and send the output as the representation, rather than
+   the request as input and send the output as the representation rather than
    transfer the files directly. Regardless, only the origin server needs to
-   know how each of its resource identifiers corresponds to an implementation,
+   know how each of its resource identifiers corresponds to an implementation
    and how each implementation manages to select and send a current
    representation of the target resource in a response to GET.
@@ -1561 +1561 @@
    between the <x:ref>target resource</x:ref> and its current functionality.
    In effect, this method is similar to the rm command in UNIX: it expresses a
-   deletion operation on the URI mapping of the origin server, rather than an
+   deletion operation on the URI mapping of the origin server rather than an
    expectation that the previously associated information be deleted.
 </t>
@@ -1991 +1991 @@
    the final recipient. If the received Max-Forwards value is greater than
    zero, the intermediary &MUST; generate an updated Max-Forwards field in the
-   forwarded message with a field-value that is the lesser of: a) the received
-   value decremented by one (1), or b) the recipient's maximum supported value
+   forwarded message with a field-value that is the lesser of a) the received
+   value decremented by one (1) or b) the recipient's maximum supported value
    for Max-Forwards.
 </t>
@@ -2356 +2356 @@
    a matching language tag, the origin server can either disregard the header
    field by treating the response as if it is not subject to content
-   negotiation, or honor the header field by sending a <x:ref>406 (Not Acceptable)</x:ref>
+   negotiation or honor the header field by sending a <x:ref>406 (Not Acceptable)</x:ref>
    response. However, the latter is not encouraged, as doing so can prevent
    users from accessing content that they might be able to use (with
@@ -2387 +2387 @@
    Since intelligibility is highly dependent on the individual user, user
    agents need to allow user control over the linguistic preference (either
-   through configuration of the user agent itself, or by defaulting to a user
+   through configuration of the user agent itself or by defaulting to a user
    controllable system setting).
    A user agent that does not provide such control to the user &MUST-NOT;
@@ -2730 +2730 @@
    prior to completing the requested action and sending a final response.
    All 1xx responses consist of only the status-line and optional header
-   fields, and thus are terminated by the empty line at the end of the header
+   fields and, thus, are terminated by the empty line at the end of the header
    section.
    Since HTTP/1.0 did not define any 1xx status codes, a server &MUST-NOT; send
@@ -3195 +3195 @@
    the user agent to a selected resource, since doing so provides the
    information corresponding to the POST response in a form that
-   can be separately identified, bookmarked, and cached independent
+   can be separately identified, bookmarked, and cached, independent
    of the original request.
 </t>
@@ -3488 +3488 @@
    information, when the client has descended into a "black hole" of
    redirection (e.g., a redirected URI prefix that points to a suffix of
-   itself), or when the server is under attack by a client attempting to
+   itself) or when the server is under attack by a client attempting to
    exploit potential security holes.
 </t>
@@ -4257 +4257 @@
    when the condition is false.
    Likewise, if the new method might have some use for partial response
-   semantics (<xref target="RFC7233"/>), it ought to document this too.
+   semantics (<xref target="RFC7233"/>), it ought to document this, too.
 </t>
 <x:note>
@@ -4676 +4676 @@
   <list style="symbols">
     <x:lt>
-      <t>Whether the field is a single value, or whether it can be a list
+      <t>Whether the field is a single value or whether it can be a list
       (delimited by commas; see &header-fields;).</t>
       <t>If it does not use the list syntax, document how to treat messages
@@ -4930 +4930 @@
    mapping from effective request URI to resource representations.
    Implementers need to be aware that most file systems are not designed to
-   protect against malicious file or path names, and thus depend on the
+   protect against malicious file or path names and, thus, depend on the
    origin server to avoid mapping to file names, folders, or directories that
    have special significance to the system.