Changeset 1692 for draft-ietf-httpbis/latest/p4-conditional.xml

Timestamp:

Jun 23, 2012, 5:01:38 AM (7 years ago)

Author:

julian.reschke@…

Message:

Simplify use of "Note:", make upper/lowercase of sentence start consistent; use "—" where appropriate

File:

• draft-ietf-httpbis/latest/p4-conditional.xml (modified) (6 diffs)

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

@@ -15 +15 @@
   <!ENTITY ID-MONTH "June">
   <!ENTITY ID-YEAR "2012">
+  <!ENTITY Note "<x:h xmlns:x='http://purl.org/net/xml2rfc/ext'>Note:</x:h>">
   <!ENTITY architecture               "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY notation                   "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
@@ -484 +485 @@
 <x:note>
   <t>
-    <x:h>Note:</x:h> Previously, opaque-tag was defined to be a quoted-string
+    &Note; Previously, opaque-tag was defined to be a quoted-string
     (<xref target="RFC2616" x:fmt="," x:sec="3.11"/>), thus some recipients
     might perform backslash unescaping. Servers therefore ought to avoid
@@ -635 +636 @@
 <x:note>
   <t>
-    <x:h>Note:</x:h> Content codings are a property of the representation,
+    &Note; Content codings are a property of the representation,
     so therefore an entity-tag of an encoded representation has to be distinct
     from an unencoded representation to prevent conflicts during cache updates
@@ -706 +707 @@
    conditional header fields in the request.
   <list><t>
-      <x:h>Note:</x:h> The general principle behind these rules is that HTTP/1.1
+      &Note; The general principle behind these rules is that HTTP/1.1
       servers and clients ought to transmit as much non-redundant
       information as is available in their responses and requests.
@@ -897 +898 @@
    information with a minimum amount of transaction overhead.
   <list><t>
-      <x:h>Note:</x:h> The Range header field modifies the meaning of If-Modified-Since;
+      &Note; The Range header field modifies the meaning of If-Modified-Since;
       see &header-range; for full details.
     </t><t>
-      <x:h>Note:</x:h> If-Modified-Since times are interpreted by the server, whose
+      &Note; If-Modified-Since times are interpreted by the server, whose
       clock might not be synchronized with the client.
     </t><t>
-      <x:h>Note:</x:h> When handling an If-Modified-Since header field, some
+      &Note; When handling an If-Modified-Since header field, some
       servers will use an exact date comparison function, rather than a
       less-than function, for deciding whether to send a 304 (Not
@@ -911 +912 @@
       header field whenever possible.
     </t><t>
-      <x:h>Note:</x:h> If a client uses an arbitrary date in the If-Modified-Since
+      &Note; If a client uses an arbitrary date in the If-Modified-Since
       header field instead of a date taken from the Last-Modified header field for
       the same request, the client needs to be aware that this