Changeset 2197 for draft-ietf-httpbis/latest

Timestamp:

03/03/13 19:06:21 (10 years ago)

Author:

julian.reschke@…

Message:

minor grammar fixes

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.html (modified) (5 diffs)
• p1-messaging.xml (modified) (1 diff)
• p2-semantics.html (modified) (2 diffs)
• p2-semantics.xml (modified) (2 diffs)

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

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires September 2, 2013"; 
+       content: "Expires September 4, 2013"; 
   } 
   @bottom-right {
@@ -491 +491 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2013-03-01">
+      <meta name="dct.issued" scheme="ISO8601" content="2013-03-03">
       <meta name="dct.replaces" content="urn:ietf:rfc:2145">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
@@ -520 +520 @@
             <tr>
                <td class="left">Intended status: Standards Track</td>
-               <td class="right">March 1, 2013</td>
+               <td class="right">March 3, 2013</td>
             </tr>
             <tr>
-               <td class="left">Expires: September 2, 2013</td>
+               <td class="left">Expires: September 4, 2013</td>
                <td class="right"></td>
             </tr>
@@ -551 +551 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on September 2, 2013.</p>
+      <p>This Internet-Draft will expire on September 4, 2013.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -1209 +1209 @@
          the protocol version if their defined semantics allow them to be safely ignored by recipients that do not recognize them.
       </p>
-      <p id="rfc.section.3.2.1.p.2">New HTTP header fields ought to be be registered with IANA in the Message Header Field Registry, as described in <a href="p2-semantics.html#header.field.registry" title="Header Field Registry">Section 8.3</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>. A proxy <em class="bcp14">MUST</em> forward unrecognized header fields unless the field-name is listed in the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section&nbsp;6.1</a>) or the proxy is specifically configured to block, or otherwise transform, such fields. Other recipients <em class="bcp14">SHOULD</em> ignore unrecognized header fields.
+      <p id="rfc.section.3.2.1.p.2">New HTTP header fields ought to be registered with IANA in the Message Header Field Registry, as described in <a href="p2-semantics.html#header.field.registry" title="Header Field Registry">Section 8.3</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>. A proxy <em class="bcp14">MUST</em> forward unrecognized header fields unless the field-name is listed in the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section&nbsp;6.1</a>) or the proxy is specifically configured to block, or otherwise transform, such fields. Other recipients <em class="bcp14">SHOULD</em> ignore unrecognized header fields.
       </p>
       <h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a>&nbsp;<a id="field.order" href="#field.order">Field Order</a></h3>

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

@@ -1199 +1199 @@
 </t>
 <t>
-   New HTTP header fields ought to be be registered with IANA in the
+   New HTTP header fields ought to be registered with IANA in the
    Message Header Field Registry, as described in &iana-header-registry;.
    A proxy &MUST; forward unrecognized header fields unless the

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

@@ -1388 +1388 @@
          is just as likely to be implemented as a tree of content objects, a programmatic view on various database records, or a gateway
          to other information systems. Even when the URI mapping mechanism is tied to a filesystem, an origin server might be configured
-         to execute the files with the request as input and send the output as the representation, rather then transfer the files directly.
-         Regardless, only the origin server needs to know how each of its resource identifiers correspond to an implementation, and
+         to execute the files with 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, and
          how each implementation manages to select and send a current representation of the target resource in a response to GET.
       </p>
@@ -1852 +1852 @@
          all subtypes of that type. The media-range can include media type parameters that are applicable to that range.
       </p>
-      <p id="rfc.section.5.3.2.p.4">Each media-range might be followed by zero or more applicable media type parameters (e.g., <a href="#charset" class="smpl">charset</a>), an optional "q" parameter for indicating a relative weight (<a href="#quality.values" title="Quality Values">Section&nbsp;5.3.1</a>), and then zero or more extension parameters. The "q" parameter is necessary if any accept-ext are present, since it acts
-         as a separator between the two parameter sets.
+      <p id="rfc.section.5.3.2.p.4">Each media-range might be followed by zero or more applicable media type parameters (e.g., <a href="#charset" class="smpl">charset</a>), an optional "q" parameter for indicating a relative weight (<a href="#quality.values" title="Quality Values">Section&nbsp;5.3.1</a>), and then zero or more extension parameters. The "q" parameter is necessary if any extensions (accept-ext) are present,
+         since it acts as a separator between the two parameter sets.
       </p>
       <div class="note" id="rfc.section.5.3.2.p.5"> 

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

@@ -1268 +1268 @@
    other information systems. Even when the URI mapping mechanism is tied to a
    filesystem, an origin server might be configured to execute the files with
-   the request as input and send the output as the representation, rather then
+   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 correspond 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.
@@ -2093 +2093 @@
    parameters (e.g., <x:ref>charset</x:ref>), an optional "q" parameter for
    indicating a relative weight (&qvalue;), and then zero or more extension
-   parameters. The "q" parameter is necessary if any accept-ext are present,
+   parameters. The "q" parameter is necessary if any extensions (accept-ext) are present,
    since it acts as a separator between the two parameter sets.
 </t>