Changeset 746

Timestamp:

Jan 17, 2010, 6:33:08 AM (10 years ago)

Author:

julian.reschke@…

Message:

Editorial: use consistent quoting style (double quotes, in particular no back quotes)

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.html (modified) (6 diffs)
• p1-messaging.xml (modified) (2 diffs)
• p2-semantics.html (modified) (6 diffs)
• p2-semantics.xml (modified) (2 diffs)
• p3-payload.html (modified) (6 diffs)
• p3-payload.xml (modified) (2 diffs)
• p4-conditional.html (modified) (4 diffs)
• p5-range.html (modified) (5 diffs)
• p5-range.xml (modified) (1 diff)
• p7-auth.html (modified) (5 diffs)
• p7-auth.xml (modified) (1 diff)

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

@@ -404 +404 @@
       <meta name="DC.Creator" content="Reschke, J. F.">
       <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
-      <meta name="DC.Date.Issued" scheme="ISO8601" content="2010-01-08">
+      <meta name="DC.Date.Issued" scheme="ISO8601" content="2010-01-17">
       <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2616">
       <meta name="DC.Description.Abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 1 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 1 provides an overview of HTTP and its associated terminology, defines the &#34;http&#34; and &#34;https&#34; Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations.">
@@ -435 +435 @@
             </tr>
             <tr>
-               <td class="left">Expires: July 12, 2010</td>
+               <td class="left">Expires: July 21, 2010</td>
                <td class="right">HP</td>
             </tr>
@@ -488 +488 @@
             <tr>
                <td class="left"></td>
-               <td class="right">January 8, 2010</td>
+               <td class="right">January 17, 2010</td>
             </tr>
          </tbody>
@@ -520 +520 @@
       <p>The list of Internet-Draft Shadow Directories can be accessed at &lt;<a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>&gt;.
       </p>
-      <p>This Internet-Draft will expire in July 12, 2010.</p>
+      <p>This Internet-Draft will expire in July 21, 2010.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -1640 +1640 @@
       <p id="rfc.section.6.4.p.1">Both transfer codings (TE request header, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section&nbsp;9.5</a>) and content negotiation (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 4</a> of <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight
          is normalized to a real number in the range 0 through 1, where 0 is the minimum and 1 the maximum value. If a parameter has
-         a quality value of 0, then content with this parameter is `not acceptable' for the client. HTTP/1.1 applications <em class="bcp14">MUST NOT</em> generate more than three digits after the decimal point. User configuration of these values <em class="bcp14">SHOULD</em> also be limited in this fashion.
+         a quality value of 0, then content with this parameter is "not acceptable" for the client. HTTP/1.1 applications <em class="bcp14">MUST NOT</em> generate more than three digits after the decimal point. User configuration of these values <em class="bcp14">SHOULD</em> also be limited in this fashion.
       </p>
       <div id="rfc.figure.u.55"></div><pre class="inline"><span id="rfc.iref.g.92"></span>  <a href="#quality.values" class="smpl">qvalue</a>         = ( "0" [ "." 0*3<a href="#core.rules" class="smpl">DIGIT</a> ] )
@@ -1877 +1877 @@
       </p>
       <div id="rfc.figure.u.57"></div><pre class="text">  Connection: close
-</pre><p id="rfc.section.9.1.p.8">in either the request or the response header fields indicates that the connection <em class="bcp14">SHOULD NOT</em> be considered `persistent' (<a href="#persistent.connections" title="Persistent Connections">Section&nbsp;7.1</a>) after the current request/response is complete.
+</pre><p id="rfc.section.9.1.p.8">in either the request or the response header fields indicates that the connection <em class="bcp14">SHOULD NOT</em> be considered "persistent" (<a href="#persistent.connections" title="Persistent Connections">Section&nbsp;7.1</a>) after the current request/response is complete.
       </p>
       <p id="rfc.section.9.1.p.9">An HTTP/1.1 client that does not support persistent connections <em class="bcp14">MUST</em> include the "close" connection option in every request message.

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

@@ -2088 +2088 @@
    the range 0 through 1, where 0 is the minimum and 1 the maximum
    value. If a parameter has a quality value of 0, then content with
-   this parameter is `not acceptable' for the client. HTTP/1.1
+   this parameter is "not acceptable" for the client. HTTP/1.1
    applications &MUST-NOT; generate more than three digits after the
    decimal point. User configuration of these values &SHOULD; also be
@@ -2606 +2606 @@
 <t>
    in either the request or the response header fields indicates that
-   the connection &SHOULD-NOT;  be considered `persistent' (<xref target="persistent.connections"/>)
+   the connection &SHOULD-NOT;  be considered "persistent" (<xref target="persistent.connections"/>)
    after the current request/response is complete.
 </t>

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

@@ -403 +403 @@
       <meta name="DC.Creator" content="Reschke, J. F.">
       <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
-      <meta name="DC.Date.Issued" scheme="ISO8601" content="2010-01-01">
+      <meta name="DC.Date.Issued" scheme="ISO8601" content="2010-01-17">
       <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2616">
       <meta name="DC.Description.Abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request-header fields, response status codes, and response-header fields.">
@@ -434 +434 @@
             </tr>
             <tr>
-               <td class="left">Expires: July 5, 2010</td>
+               <td class="left">Expires: July 21, 2010</td>
                <td class="right">HP</td>
             </tr>
@@ -487 +487 @@
             <tr>
                <td class="left"></td>
-               <td class="right">January 1, 2010</td>
+               <td class="right">January 17, 2010</td>
             </tr>
          </tbody>
@@ -518 +518 @@
       <p>The list of Internet-Draft Shadow Directories can be accessed at &lt;<a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>&gt;.
       </p>
-      <p>This Internet-Draft will expire in July 5, 2010.</p>
+      <p>This Internet-Draft will expire in July 21, 2010.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -927 +927 @@
          <li>Otherwise, the response is a representation of an anonymous (i.e., unidentified) resource.</li>
       </ol>
-      <p id="rfc.section.6.1.p.5"> <span class="comment" id="TODO-req-uri">[<a href="#TODO-req-uri" class="smpl">TODO-req-uri</a>: Note that 'request-URI' is used here; however, we need to come up with a term to denote "the URI that can be inferred from
+      <p id="rfc.section.6.1.p.5"> <span class="comment" id="TODO-req-uri">[<a href="#TODO-req-uri" class="smpl">TODO-req-uri</a>: Note that "request-URI" is used here; however, we need to come up with a term to denote "the URI that can be inferred from
             examining the request-target and the Host header." (see &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/196">http://tools.ietf.org/wg/httpbis/trac/ticket/196</a>&gt;). Also, the comparison function is going to have to be defined somewhere, because we already need to compare URIs for things
             like cache invalidation.]</span> 
@@ -1050 +1050 @@
          the resource with that URI. If a new resource is created at the request-target, the origin server <em class="bcp14">MUST</em> inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No
          Content) response codes <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request. If the resource could not be created or modified with the request-target,
-         an appropriate error response <em class="bcp14">SHOULD</em> be given that reflects the nature of the problem. The recipient of the entity <em class="bcp14">MUST NOT</em> ignore any Content-* headers (headers starting with the prefix 'Content-') that it does not understand or implement and <em class="bcp14">MUST</em> return a 501 (Not Implemented) response in such cases.
+         an appropriate error response <em class="bcp14">SHOULD</em> be given that reflects the nature of the problem. The recipient of the entity <em class="bcp14">MUST NOT</em> ignore any Content-* headers (headers starting with the prefix "Content-") that it does not understand or implement and <em class="bcp14">MUST</em> return a 501 (Not Implemented) response in such cases.
       </p>
       <p id="rfc.section.7.6.p.2">If the request passes through a cache and the request-target identifies one or more currently cached entities, those entries <em class="bcp14">SHOULD</em> be treated as stale. Responses to this method are not cacheable.

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

@@ -691 +691 @@
 <t>
   <cref anchor="TODO-req-uri">
-   Note that 'request-URI' is used here; however, we need to come up with a
+   Note that "request-URI" is used here; however, we need to come up with a
    term to denote "the URI that can be inferred from examining the
    request-target and the Host header." (see <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/196" />).
@@ -956 +956 @@
    error response &SHOULD; be given that reflects the nature of the
    problem. The recipient of the entity &MUST-NOT; ignore any Content-*
-   headers (headers starting with the prefix 'Content-') that it does
+   headers (headers starting with the prefix "Content-") that it does
    not understand or implement
    and &MUST; return a 501 (Not Implemented) response in such cases.

draft-ietf-httpbis/latest/p3-payload.html

@@ -401 +401 @@
       <meta name="DC.Creator" content="Reschke, J. F.">
       <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest">
-      <meta name="DC.Date.Issued" scheme="ISO8601" content="2010-01-15">
+      <meta name="DC.Date.Issued" scheme="ISO8601" content="2010-01-17">
       <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2616">
       <meta name="DC.Description.Abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 3 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation.">
@@ -427 +427 @@
             </tr>
             <tr>
-               <td class="left">Expires: July 19, 2010</td>
+               <td class="left">Expires: July 21, 2010</td>
                <td class="right">J. Mogul</td>
             </tr>
@@ -484 +484 @@
             <tr>
                <td class="left"></td>
-               <td class="right">January 15, 2010</td>
+               <td class="right">January 17, 2010</td>
             </tr>
          </tbody>
@@ -514 +514 @@
       <p>The list of Internet-Draft Shadow Directories can be accessed at &lt;<a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>&gt;.
       </p>
-      <p>This Internet-Draft will expire in July 19, 2010.</p>
+      <p>This Internet-Draft will expire in July 21, 2010.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -674 +674 @@
       <ul class="empty">
          <li>A resource may have one, or more than one, representation(s) associated with it at any given instant. Each of these representations
-            is termed a `variant'. Use of the term `variant' does not necessarily imply that the resource is subject to content negotiation.
+            is termed a "variant". Use of the term "variant" does not necessarily imply that the resource is subject to content negotiation.
          </li>
       </ul>
@@ -1777 +1777 @@
       </p>
       <p id="rfc.section.B.1.p.6">If this header is used in a response with the application/octet-stream content-type, the implied suggestion is that the user
-         agent should not display the response, but directly enter a `save response as...' dialog.
+         agent should not display the response, but directly enter a "save response as..." dialog.
       </p>
       <p id="rfc.section.B.1.p.7">See <a href="#content-disposition.issues" title="Content-Disposition Issues">Section&nbsp;7.2</a> for Content-Disposition security issues.

draft-ietf-httpbis/latest/p3-payload.xml

@@ -286 +286 @@
       A resource may have one, or more than one, representation(s)
       associated with it at any given instant. Each of these
-      representations is termed a `variant'.  Use of the term `variant'
+      representations is termed a "variant".  Use of the term "variant"
       does not necessarily imply that the resource is subject to content
       negotiation.
@@ -2670 +2670 @@
    If this header is used in a response with the application/octet-stream
    content-type, the implied suggestion is that the user agent
-   should not display the response, but directly enter a `save response
-   as...' dialog.
+   should not display the response, but directly enter a "save response
+   as..." dialog.
 </t>
 <t>

draft-ietf-httpbis/latest/p4-conditional.html

@@ -400 +400 @@
       <meta name="DC.Creator" content="Reschke, J. F.">
       <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
-      <meta name="DC.Date.Issued" scheme="ISO8601" content="2010-01-01">
+      <meta name="DC.Date.Issued" scheme="ISO8601" content="2010-01-15">
       <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2616">
       <meta name="DC.Description.Abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests.">
@@ -426 +426 @@
             </tr>
             <tr>
-               <td class="left">Expires: July 5, 2010</td>
+               <td class="left">Expires: July 19, 2010</td>
                <td class="right">J. Mogul</td>
             </tr>
@@ -483 +483 @@
             <tr>
                <td class="left"></td>
-               <td class="right">January 1, 2010</td>
+               <td class="right">January 15, 2010</td>
             </tr>
          </tbody>
@@ -513 +513 @@
       <p>The list of Internet-Draft Shadow Directories can be accessed at &lt;<a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>&gt;.
       </p>
-      <p>This Internet-Draft will expire in July 5, 2010.</p>
+      <p>This Internet-Draft will expire in July 19, 2010.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>

draft-ietf-httpbis/latest/p5-range.html

@@ -400 +400 @@
       <meta name="DC.Creator" content="Reschke, J. F.">
       <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest">
-      <meta name="DC.Date.Issued" scheme="ISO8601" content="2010-01-01">
+      <meta name="DC.Date.Issued" scheme="ISO8601" content="2010-01-17">
       <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2616">
       <meta name="DC.Description.Abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 5 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests.">
@@ -426 +426 @@
             </tr>
             <tr>
-               <td class="left">Expires: July 5, 2010</td>
+               <td class="left">Expires: July 21, 2010</td>
                <td class="right">J. Mogul</td>
             </tr>
@@ -483 +483 @@
             <tr>
                <td class="left"></td>
-               <td class="right">January 1, 2010</td>
+               <td class="right">January 17, 2010</td>
             </tr>
          </tbody>
@@ -513 +513 @@
       <p>The list of Internet-Draft Shadow Directories can be accessed at &lt;<a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>&gt;.
       </p>
-      <p>This Internet-Draft will expire in July 5, 2010.</p>
+      <p>This Internet-Draft will expire in July 21, 2010.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -800 +800 @@
          to obtain the entire current entity-body.
       </p>
-      <p id="rfc.section.5.3.p.2">The "If-Range" request-header field allows a client to "short-circuit" the second request. Informally, its meaning is `if
-         the entity is unchanged, send me the part(s) that I am missing; otherwise, send me the entire new entity'.
+      <p id="rfc.section.5.3.p.2">The "If-Range" request-header field allows a client to "short-circuit" the second request. Informally, its meaning is "if
+         the entity is unchanged, send me the part(s) that I am missing; otherwise, send me the entire new entity".
       </p>
       <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span>  <a href="#header.if-range" class="smpl">If-Range</a>   = "If-Range" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.if-range" class="smpl">If-Range-v</a>

draft-ietf-httpbis/latest/p5-range.xml

@@ -656 +656 @@
 <t>
    The "If-Range" request-header field allows a client to "short-circuit" the second
-   request. Informally, its meaning is `if the entity is unchanged, send
+   request. Informally, its meaning is "if the entity is unchanged, send
    me the part(s) that I am missing; otherwise, send me the entire new
-   entity'.
+   entity".
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Range"/><iref primary="true" item="Grammar" subitem="If-Range-v"/>

draft-ietf-httpbis/latest/p7-auth.html

@@ -394 +394 @@
       <meta name="DC.Creator" content="Reschke, J. F.">
       <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
-      <meta name="DC.Date.Issued" scheme="ISO8601" content="2010-01-01">
+      <meta name="DC.Date.Issued" scheme="ISO8601" content="2010-01-17">
       <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2616">
       <meta name="DC.Description.Abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 7 defines HTTP Authentication.">
@@ -425 +425 @@
             </tr>
             <tr>
-               <td class="left">Expires: July 5, 2010</td>
+               <td class="left">Expires: July 21, 2010</td>
                <td class="right">HP</td>
             </tr>
@@ -478 +478 @@
             <tr>
                <td class="left"></td>
-               <td class="right">January 1, 2010</td>
+               <td class="right">January 17, 2010</td>
             </tr>
          </tbody>
@@ -508 +508 @@
       <p>The list of Internet-Draft Shadow Directories can be accessed at &lt;<a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>&gt;.
       </p>
-      <p>This Internet-Draft will expire in July 5, 2010.</p>
+      <p>This Internet-Draft will expire in July 21, 2010.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -787 +787 @@
             the user for credentials.
          </li>
-         <li>Applications which include a session termination indication (such as a `logout' or `commit' button on a page) after which
-            the server side of the application `knows' that there is no further reason for the client to retain the credentials.
+         <li>Applications which include a session termination indication (such as a "logout" or "commit" button on a page) after which
+            the server side of the application "knows" that there is no further reason for the client to retain the credentials.
          </li>
       </ul>

draft-ietf-httpbis/latest/p7-auth.xml

@@ -576 +576 @@
 
      <t>Applications which include a session termination indication
-        (such as a `logout' or `commit' button on a page) after which
-        the server side of the application `knows' that there is no
+        (such as a "logout" or "commit" button on a page) after which
+        the server side of the application "knows" that there is no
         further reason for the client to retain the credentials.</t>
   </list>