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

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.xml (modified) (6 diffs)

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

@@ -592 +592 @@
    <cref>TBD: Define and explain purpose of https scheme.</cref>
 </t>
-<t><list><t>
-  <x:h>Note:</x:h> the "https" scheme is defined in <xref target="RFC2818"/>.
-</t></list></t>
+<x:note>
+  <t>
+    <x:h>Note:</x:h> the "https" scheme is defined in <xref target="RFC2818"/>.
+  </t>
+</x:note>
 </section>
 
@@ -825 +827 @@
    the same major version as the request.
 </t>
-<t>
-  <list>
-    <t>
-      <x:h>Note:</x:h> Converting between versions of HTTP may involve modification
-      of header fields required or forbidden by the versions involved.
-    </t>
-  </list>
-</t>
+<x:note>
+  <t>
+    <x:h>Note:</x:h> Converting between versions of HTTP may involve modification
+    of header fields required or forbidden by the versions involved.
+  </t>
+</x:note>
 </section>
 
@@ -869 +869 @@
    in header fields. See <xref target="tolerant.applications"/> for further information.
 </t>
-<t><list><t>
-      <x:h>Note:</x:h> 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.
-</t></list></t>
+<x:note>
+  <t>
+    <x:h>Note:</x:h> 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.
+  </t>
+</x:note>
 <t>
    All HTTP date/time stamps &MUST; be represented in Greenwich Mean Time
@@ -1308 +1310 @@
    change the order of these field values when a message is forwarded.
 </t>
-<t>
-  <list><t>
+<x:note>
+  <t>
    <x:h>Note:</x:h> the "Set-Cookie" header as implemented in
    practice (as opposed to how it is specified in <xref target="RFC2109"/>)
@@ -1316 +1318 @@
    for details.) Also note that the Set-Cookie2 header specified in
    <xref target="RFC2965"/> does not share this problem. 
-  </t></list>
-</t>
+  </t>
+</x:note>
   
 </section>
@@ -1621 +1623 @@
    except as noted above to replace a null path-absolute with "/".
 </t>
-<t>
-  <list><t>
-      <x:h>Note:</x:h> 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.
-  </t></list>
-</t>
+<x:note>
+  <t>
+    <x:h>Note:</x:h> 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.
+  </t>
+</x:note>
 <t>
    HTTP does not place a pre-defined limit on the length of a request-target.