Ignore:
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:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p4-conditional.xml

    r1691 r1692  
    1515  <!ENTITY ID-MONTH "June">
    1616  <!ENTITY ID-YEAR "2012">
     17  <!ENTITY Note "<x:h xmlns:x='http://purl.org/net/xml2rfc/ext'>Note:</x:h>">
    1718  <!ENTITY architecture               "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1819  <!ENTITY notation                   "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     
    484485<x:note>
    485486  <t>
    486     <x:h>Note:</x:h> Previously, opaque-tag was defined to be a quoted-string
     487    &Note; Previously, opaque-tag was defined to be a quoted-string
    487488    (<xref target="RFC2616" x:fmt="," x:sec="3.11"/>), thus some recipients
    488489    might perform backslash unescaping. Servers therefore ought to avoid
     
    635636<x:note>
    636637  <t>
    637     <x:h>Note:</x:h> Content codings are a property of the representation,
     638    &Note; Content codings are a property of the representation,
    638639    so therefore an entity-tag of an encoded representation has to be distinct
    639640    from an unencoded representation to prevent conflicts during cache updates
     
    706707   conditional header fields in the request.
    707708  <list><t>
    708       <x:h>Note:</x:h> The general principle behind these rules is that HTTP/1.1
     709      &Note; The general principle behind these rules is that HTTP/1.1
    709710      servers and clients ought to transmit as much non-redundant
    710711      information as is available in their responses and requests.
     
    897898   information with a minimum amount of transaction overhead.
    898899  <list><t>
    899       <x:h>Note:</x:h> The Range header field modifies the meaning of If-Modified-Since;
     900      &Note; The Range header field modifies the meaning of If-Modified-Since;
    900901      see &header-range; for full details.
    901902    </t><t>
    902       <x:h>Note:</x:h> If-Modified-Since times are interpreted by the server, whose
     903      &Note; If-Modified-Since times are interpreted by the server, whose
    903904      clock might not be synchronized with the client.
    904905    </t><t>
    905       <x:h>Note:</x:h> When handling an If-Modified-Since header field, some
     906      &Note; When handling an If-Modified-Since header field, some
    906907      servers will use an exact date comparison function, rather than a
    907908      less-than function, for deciding whether to send a 304 (Not
     
    911912      header field whenever possible.
    912913    </t><t>
    913       <x:h>Note:</x:h> If a client uses an arbitrary date in the If-Modified-Since
     914      &Note; If a client uses an arbitrary date in the If-Modified-Since
    914915      header field instead of a date taken from the Last-Modified header field for
    915916      the same request, the client needs to be aware that this
Note: See TracChangeset for help on using the changeset viewer.