Changeset 879


Ignore:
Timestamp:
Jul 23, 2010, 2:19:25 AM (9 years ago)
Author:
julian.reschke@…
Message:

change citing style to match RFC Editor expectations (see <​http://www.rfc-editor.org/rfc-style-guide/rfc-style>, Section 3.3)

Location:
draft-ietf-httpbis/latest
Files:
6 edited

Legend:

Unmodified
Added
Removed

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

    r878 r879  
    21362136         <li>
    21372137            <p>If the transfer-coding being tested is one of the transfer-codings listed in the TE field, then it is acceptable unless it
    2138                is accompanied by a qvalue of 0. (As defined in <a href="#quality.values" title="Quality Values">Section&nbsp;6.4</a>, a qvalue of 0 means "not acceptable.")
     2138               is accompanied by a qvalue of 0. (As defined in <a href="#quality.values" title="Quality Values">Section&nbsp;6.4</a>, a qvalue of 0 means "not acceptable".)
    21392139            </p>
    21402140         </li>

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

    r877 r879  
    31413141         listed in the TE field, then it is acceptable unless it
    31423142         is accompanied by a qvalue of 0. (As defined in <xref target="quality.values"/>, a
    3143          qvalue of 0 means "not acceptable.")</t>
     3143         qvalue of 0 means "not acceptable".)</t>
    31443144    </x:lt>
    31453145    <x:lt>

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

    r878 r879  
    715715      </p>
    716716      <div class="note" id="rfc.section.2.1.p.3">
    717          <p> <b>Note:</b> This use of the term "character set" is more commonly referred to as a "character encoding." However, since HTTP and MIME
     717         <p> <b>Note:</b> This use of the term "character set" is more commonly referred to as a "character encoding". However, since HTTP and MIME
    718718            share the same registry, it is important that the terminology also be shared.
    719719         </p>
    … …  
    736736      <h3 id="rfc.section.2.1.1"><a href="#rfc.section.2.1.1">2.1.1</a>&nbsp;<a id="missing.charset" href="#missing.charset">Missing Charset</a></h3>
    737737      <p id="rfc.section.2.1.1.p.1">Some HTTP/1.0 software has interpreted a Content-Type header without charset parameter incorrectly to mean "recipient should
    738          guess." Senders wishing to defeat this behavior <em class="bcp14">MAY</em> include a charset parameter even when the charset is ISO-8859-1 (<a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a>) and <em class="bcp14">SHOULD</em> do so when it is known that it will not confuse the recipient.
     738         guess". Senders wishing to defeat this behavior <em class="bcp14">MAY</em> include a charset parameter even when the charset is ISO-8859-1 (<a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a>) and <em class="bcp14">SHOULD</em> do so when it is known that it will not confuse the recipient.
    739739      </p>
    740740      <p id="rfc.section.2.1.1.p.2">Unfortunately, some older HTTP/1.0 clients did not deal properly with an explicit charset parameter. HTTP/1.1 recipients <em class="bcp14">MUST</em> respect the charset label provided by the sender; and those user agents that have a provision to "guess" a charset <em class="bcp14">MUST</em> use the charset from the content-type field if they support that charset, rather than the recipient's preference, when initially
    … …  
    10311031      <div id="rfc.figure.u.15"></div><pre class="text">  Accept: audio/*; q=0.2, audio/basic
    10321032</pre><p id="rfc.section.5.1.p.8"> <em class="bcp14">SHOULD</em> be interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% mark-down in
    1033          quality."
     1033         quality".
    10341034      </p>
    10351035      <p id="rfc.section.5.1.p.9">If no Accept header field is present, then it is assumed that the client accepts all media types. If an Accept header field
    … …  
    10411041          text/x-dvi; q=0.8, text/x-c
    10421042</pre><p id="rfc.section.5.1.p.12">Verbally, this would be interpreted as "text/html and text/x-c are the preferred media types, but if they do not exist, then
    1043          send the text/x-dvi representation, and if that does not exist, send the text/plain representation."
     1043         send the text/x-dvi representation, and if that does not exist, send the text/plain representation".
    10441044      </p>
    10451045      <p id="rfc.section.5.1.p.13">Media ranges can be overridden by more specific media ranges or specific media types. If more than one media range applies
    … …  
    11431143      <ol>
    11441144         <li>If the content-coding is one of the content-codings listed in the Accept-Encoding field, then it is acceptable, unless it
    1145             is accompanied by a qvalue of 0. (As defined in <a href="p1-messaging.html#quality.values" title="Quality Values">Section 6.4</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, a qvalue of 0 means "not acceptable.")
     1145            is accompanied by a qvalue of 0. (As defined in <a href="p1-messaging.html#quality.values" title="Quality Values">Section 6.4</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, a qvalue of 0 means "not acceptable".)
    11461146         </li>
    11471147         <li>The special "*" symbol in an Accept-Encoding field matches any available content-coding not explicitly listed in the header
    … …  
    11891189      </p>
    11901190      <div id="rfc.figure.u.24"></div><pre class="text">  Accept-Language: da, en-gb;q=0.8, en;q=0.7
    1191 </pre><p id="rfc.section.5.4.p.5">would mean: "I prefer Danish, but will accept British English and other types of English." (see also <a href="http://tools.ietf.org/html/rfc4647#section-2.3">Section 2.3</a> of <a href="#RFC4647" id="rfc.xref.RFC4647.2"><cite title="Matching of Language Tags">[RFC4647]</cite></a>)
     1191</pre><p id="rfc.section.5.4.p.5">would mean: "I prefer Danish, but will accept British English and other types of English". (see also <a href="http://tools.ietf.org/html/rfc4647#section-2.3">Section 2.3</a> of <a href="#RFC4647" id="rfc.xref.RFC4647.2"><cite title="Matching of Language Tags">[RFC4647]</cite></a>)
    11921192      </p>
    11931193      <p id="rfc.section.5.4.p.6">For matching, <a href="http://tools.ietf.org/html/rfc4647#section-3">Section 3</a> of <a href="#RFC4647" id="rfc.xref.RFC4647.3"><cite title="Matching of Language Tags">[RFC4647]</cite></a> defines several matching schemes. Implementations can offer the most appropriate matching scheme for their requirements.
    … …  
    12491249         it is intended.
    12501250      </p>
    1251       <p id="rfc.section.5.6.p.6">Multiple languages <em class="bcp14">MAY</em> be listed for content that is intended for multiple audiences. For example, a rendition of the "Treaty of Waitangi," presented
     1251      <p id="rfc.section.5.6.p.6">Multiple languages <em class="bcp14">MAY</em> be listed for content that is intended for multiple audiences. For example, a rendition of the "Treaty of Waitangi", presented
    12521252         simultaneously in the original Maori and English versions, would call for
    12531253      </p>
    12541254      <div id="rfc.figure.u.29"></div><pre class="text">  Content-Language: mi, en
    12551255</pre><p id="rfc.section.5.6.p.8">However, just because multiple languages are present within a representation does not mean that it is intended for multiple
    1256          linguistic audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin," which is clearly
     1256         linguistic audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin", which is clearly
    12571257         intended to be used by an English-literate audience. In this case, the Content-Language would properly only include "en".
    12581258      </p>

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

    r874 r879  
    408408  <t>
    409409    <x:h>Note:</x:h> This use of the term "character set" is more commonly
    410     referred to as a "character encoding." However, since HTTP and
     410    referred to as a "character encoding". However, since HTTP and
    411411    MIME share the same registry, it is important that the terminology
    412412    also be shared.
    … …  
    444444<t>
    445445   Some HTTP/1.0 software has interpreted a Content-Type header without
    446    charset parameter incorrectly to mean "recipient should guess."
     446   charset parameter incorrectly to mean "recipient should guess".
    447447   Senders wishing to defeat this behavior &MAY; include a charset
    448448   parameter even when the charset is ISO-8859-1 (<xref target="ISO-8859-1"/>) and &SHOULD; do so when
    … …  
    10291029<t>
    10301030   &SHOULD; be interpreted as "I prefer audio/basic, but send me any audio
    1031    type if it is the best available after an 80% mark-down in quality."
     1031   type if it is the best available after an 80% mark-down in quality".
    10321032</t>
    10331033<t>
    … …  
    10491049   the preferred media types, but if they do not exist, then send the
    10501050   text/x-dvi representation, and if that does not exist, send the text/plain
    1051    representation."
     1051   representation".
    10521052</t>
    10531053<t>
    … …  
    11801180         the Accept-Encoding field, then it is acceptable, unless it is
    11811181         accompanied by a qvalue of 0. (As defined in &qvalue;, a
    1182          qvalue of 0 means "not acceptable.")</t>
     1182         qvalue of 0 means "not acceptable".)</t>
    11831183
    11841184      <t>The special "*" symbol in an Accept-Encoding field matches any
    … …  
    12611261<t>
    12621262   would mean: "I prefer Danish, but will accept British English and
    1263    other types of English."
     1263   other types of English".
    12641264   (see also <xref target="RFC4647" x:sec="2.3" x:fmt="of"/>)
    12651265</t>
    … …  
    13861386   Multiple languages &MAY; be listed for content that is intended for
    13871387   multiple audiences. For example, a rendition of the "Treaty of
    1388    Waitangi," presented simultaneously in the original Maori and English
     1388   Waitangi", presented simultaneously in the original Maori and English
    13891389   versions, would call for
    13901390</t>
    … …  
    13961396   does not mean that it is intended for multiple linguistic audiences.
    13971397   An example would be a beginner's language primer, such as "A First
    1398    Lesson in Latin," which is clearly intended to be used by an
     1398   Lesson in Latin", which is clearly intended to be used by an
    13991399   English-literate audience. In this case, the Content-Language would
    14001400   properly only include "en".

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

    r878 r879  
    638638</pre><p id="rfc.section.2.p.3">A "strong entity-tag" <em class="bcp14">MAY</em> be shared by two representations of a resource only if they are equivalent by octet equality.
    639639      </p>
    640       <p id="rfc.section.2.p.4">A "weak entity-tag," indicated by the "W/" prefix, <em class="bcp14">MAY</em> be shared by two representations of a resource only if the representations are equivalent and could be substituted for each
     640      <p id="rfc.section.2.p.4">A "weak entity-tag", indicated by the "W/" prefix, <em class="bcp14">MAY</em> be shared by two representations of a resource only if the representations are equivalent and could be substituted for each
    641641         other with no significant change in semantics. A weak entity-tag can only be used for weak comparison.
    642642      </p>
    … …  
    711711         one normally would expect that if the representation (including both representation header fields and representation body)
    712712         changes in any way, then the associated validator would change as well. If this is true, then we call this validator a "strong
    713          validator."
     713         validator".
    714714      </p>
    715715      <p id="rfc.section.4.p.2">However, there might be cases when a server prefers to change the validator only on semantically significant changes, and
    716716         not when insignificant aspects of the representation change. A validator that does not always change when the representation
    717          changes is a "weak validator."
    718       </p>
    719       <p id="rfc.section.4.p.3">An entity-tag is normally a strong validator, but the protocol provides a mechanism to tag an entity-tag as "weak." One can
     717         changes is a "weak validator".
     718      </p>
     719      <p id="rfc.section.4.p.3">An entity-tag is normally a strong validator, but the protocol provides a mechanism to tag an entity-tag as "weak". One can
    720720         think of a strong validator as one that changes whenever the sequence of bits in a representation changes, while a weak value
    721721         changes whenever the meaning of a representation changes. Alternatively, one can think of a strong validator as part of an

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

    r874 r879  
    330330</t>
    331331<t>
    332    A "weak entity-tag," indicated by the "W/" prefix, &MAY; be shared by
     332   A "weak entity-tag", indicated by the "W/" prefix, &MAY; be shared by
    333333   two representations of a resource only if the representations are equivalent and
    334334   could be substituted for each other with no significant change in
    … …  
    460460   header fields and representation body) changes in any way, then the
    461461   associated validator would change as well. If this is true, then we
    462    call this validator a "strong validator."
     462   call this validator a "strong validator".
    463463</t>
    464464<t>
    … …  
    466466   validator only on semantically significant changes, and not when
    467467   insignificant aspects of the representation change. A validator that does not
    468    always change when the representation changes is a "weak validator."
     468   always change when the representation changes is a "weak validator".
    469469</t>
    470470<t>
    471471   An entity-tag is normally a strong validator, but the protocol
    472    provides a mechanism to tag an entity-tag as "weak." One can think of
     472   provides a mechanism to tag an entity-tag as "weak". One can think of
    473473   a strong validator as one that changes whenever the sequence of bits
    474474   in a representation changes, while a weak value changes whenever the
Note: See TracChangeset for help on using the changeset viewer.