Changeset 563 for draft-ietf-httpbis/latest/p1-messaging.html

Timestamp:

24/03/09 20:48:26 (11 years ago)

Author:

julian.reschke@…

Message:

replace <list> elements used for indentation by <x:note> elements

File:

• draft-ietf-httpbis/latest/p1-messaging.html (modified) (6 diffs)

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

@@ -471 +471 @@
          <tr>
             <td class="header left"></td>
-            <td class="header right">March 12, 2009</td>
+            <td class="header right">March 24, 2009</td>
          </tr>
       </table>
@@ -845 +845 @@
       <p id="rfc.section.2.1.2.p.1"> <span class="comment" id="rfc.comment.1">[<a href="#rfc.comment.1" class="smpl">rfc.comment.1</a>: TBD: Define and explain purpose of https scheme.]</span> 
       </p>
-      <dl class="empty">
-         <dd> <b>Note:</b> the "https" scheme is defined in <a href="#RFC2818" id="rfc.xref.RFC2818.1"><cite title="HTTP Over TLS">[RFC2818]</cite></a>.
-         </dd>
-      </dl>
+      <div class="note"> 
+         <p> <b>Note:</b> the "https" scheme is defined in <a href="#RFC2818" id="rfc.xref.RFC2818.1"><cite title="HTTP Over TLS">[RFC2818]</cite></a>.
+         </p> 
+      </div>
       <h3 id="rfc.section.2.1.3"><a href="#rfc.section.2.1.3">2.1.3</a>&nbsp;<a id="uri.comparison" href="#uri.comparison">URI Comparison</a></h3>
       <p id="rfc.section.2.1.3.p.1">When comparing two URIs to decide if they match or not, a client <em class="bcp14">SHOULD</em> use a case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions: 
@@ -965 +965 @@
       <p id="rfc.section.3.1.p.8">Due to interoperability problems with HTTP/1.0 proxies discovered since the publication of <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, caching proxies <em class="bcp14">MUST</em>, gateways <em class="bcp14">MAY</em>, and tunnels <em class="bcp14">MUST NOT</em> upgrade the request to the highest version they support. The proxy/gateway's response to that request <em class="bcp14">MUST</em> be in the same major version as the request.
       </p>
-      <p id="rfc.section.3.1.p.9"> </p>
-      <dl class="empty">
-         <dd> <b>Note:</b> Converting between versions of HTTP may involve modification of header fields required or forbidden by the versions involved.
-         </dd>
-      </dl>
+      <div class="note"> 
+         <p> <b>Note:</b> Converting between versions of HTTP may involve modification of header fields required or forbidden by the versions involved.
+         </p> 
+      </div>
       <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="date.time.formats" href="#date.time.formats">Date/Time Formats</a></h2>
       <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;<a id="full.date" href="#full.date">Full Date</a></h3>
@@ -979 +978 @@
          that parse the date value <em class="bcp14">MUST</em> accept all three formats (for compatibility with HTTP/1.0), though they <em class="bcp14">MUST</em> only generate the RFC 1123 format for representing HTTP-date values in header fields. See <a href="#tolerant.applications" title="Tolerant Applications">Appendix&nbsp;A</a> for further information.
       </p>
-      <dl class="empty">
-         <dd> <b>Note:</b> Recipients of date values are encouraged to be robust in accepting date values that may have been sent by non-HTTP applications,
+      <div class="note"> 
+         <p> <b>Note:</b> Recipients of date values are encouraged to be robust in accepting date values that may have been sent by non-HTTP applications,
             as is sometimes the case when retrieving or posting messages via proxies/gateways to SMTP or NNTP.
-         </dd>
-      </dl>
+         </p> 
+      </div>
       <p id="rfc.section.3.2.1.p.5">All HTTP date/time stamps <em class="bcp14">MUST</em> be represented in Greenwich Mean Time (GMT), without exception. For the purposes of HTTP, GMT is exactly equal to UTC (Coordinated
          Universal Time). This is indicated in the first two formats by the inclusion of "GMT" as the three-letter abbreviation for
@@ -1219 +1218 @@
          thus a proxy <em class="bcp14">MUST NOT</em> change the order of these field values when a message is forwarded.
       </p>
-      <p id="rfc.section.4.2.p.11"> </p>
-      <dl class="empty">
-         <dd> <b>Note:</b> the "Set-Cookie" header as implemented in practice (as opposed to how it is specified in <a href="#RFC2109" id="rfc.xref.RFC2109.1"><cite title="HTTP State Management Mechanism">[RFC2109]</cite></a>) can occur multiple times, but does not use the list syntax, and thus cannot be combined into a single line. (See Appendix
+      <div class="note"> 
+         <p> <b>Note:</b> the "Set-Cookie" header as implemented in practice (as opposed to how it is specified in <a href="#RFC2109" id="rfc.xref.RFC2109.1"><cite title="HTTP State Management Mechanism">[RFC2109]</cite></a>) can occur multiple times, but does not use the list syntax, and thus cannot be combined into a single line. (See Appendix
             A.2.3 of <a href="#Kri2001" id="rfc.xref.Kri2001.1"><cite title="HTTP Cookies: Standards, Privacy, and Politics">[Kri2001]</cite></a> for details.) Also note that the Set-Cookie2 header specified in <a href="#RFC2965" id="rfc.xref.RFC2965.1"><cite title="HTTP State Management Mechanism">[RFC2965]</cite></a> does not share this problem.
-         </dd>
-      </dl>
+         </p> 
+      </div>
       <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a>&nbsp;<a id="message.body" href="#message.body">Message Body</a></h2>
       <p id="rfc.section.4.3.p.1">The message-body (if any) of an HTTP message is used to carry the entity-body associated with the request or response. The
@@ -1373 +1371 @@
          above to replace a null path-absolute with "/".
       </p>
-      <p id="rfc.section.5.1.2.p.17"> </p>
-      <dl class="empty">
-         <dd> <b>Note:</b> The "no rewrite" rule prevents the proxy from changing the meaning of the request when the origin server is improperly using
+      <div class="note"> 
+         <p> <b>Note:</b> The "no rewrite" rule prevents the proxy from changing the meaning of the request when the origin server is improperly using
             a non-reserved URI character for a reserved purpose. Implementors should be aware that some pre-HTTP/1.1 proxies have been
             known to rewrite the request-target.
-         </dd>
-      </dl>
+         </p> 
+      </div>
       <p id="rfc.section.5.1.2.p.18">HTTP does not place a pre-defined limit on the length of a request-target. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the 414 (URI Too Long) status if the received request-target
          would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 8.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).