Ignore:
Timestamp:
14/09/13 23:59:24 (7 years ago)
Author:
fielding@…
Message:

rephrase misused SHOULDs; addresses #472

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

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r2393 r2398  
    15551555         the user agent <em class="bcp14">MUST</em> count the terminating CRLF octets as part of the message body length.
    15561556      </p>
    1557       <p id="rfc.section.3.5.p.2">In the interest of robustness, servers <em class="bcp14">SHOULD</em> ignore at least one empty line received where a request-line is expected. In other words, if a server is reading the protocol
    1558          stream at the beginning of a message and receives a CRLF first, the server <em class="bcp14">SHOULD</em> ignore the CRLF.
     1557      <p id="rfc.section.3.5.p.2">In the interest of robustness, a server that is expecting to receive and parse a request-line <em class="bcp14">SHOULD</em> ignore at least one empty line (CRLF) received prior to the request-line.
    15591558      </p>
    15601559      <p id="rfc.section.3.5.p.3">Although the line terminator for the start-line and header fields is the sequence CRLF, recipients <em class="bcp14">MAY</em> recognize a single LF as a line terminator and ignore any preceding CR.
     
    26442643      <p id="rfc.section.9.3.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 6.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.30"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 6.5</a> of <a href="#Part2" id="rfc.xref.Part2.31"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Additional status codes related to capacity limits have been defined by extensions to HTTP <a href="#RFC6585" id="rfc.xref.RFC6585.1"><cite title="Additional HTTP Status Codes">[RFC6585]</cite></a>.
    26452644      </p>
    2646       <p id="rfc.section.9.3.p.4">Recipients <em class="bcp14">SHOULD</em> carefully limit the extent to which they read other fields, including (but not limited to) request methods, response status
    2647          phrases, header field-names, and body chunks, so as to avoid denial of service attacks without impeding interoperability.
     2645      <p id="rfc.section.9.3.p.4">Recipients ought to carefully limit the extent to which they read other fields, including (but not limited to) request methods,
     2646         response status phrases, header field-names, and body chunks, so as to avoid denial of service attacks without impeding interoperability.
    26482647      </p>
    26492648      <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a>&nbsp;<a id="message.integrity" href="#message.integrity">Message Integrity</a></h2>
     
    26702669         needs to be securely stored and appropriate guidelines followed for its analysis. Anonymization of personal information within
    26712670         individual entries helps, but is generally not sufficient to prevent real log traces from being re-identified based on correlation
    2672          with other access characteristics. As such, access traces that are keyed to a specific client should not be published even
    2673          if the key is pseudonymous.
    2674       </p>
    2675       <p id="rfc.section.9.5.p.3">To minimize the risk of theft or accidental publication, log information should be purged of personally identifiable information,
     2671         with other access characteristics. As such, access traces that are keyed to a specific client are unsafe to publish even if
     2672         the key is pseudonymous.
     2673      </p>
     2674      <p id="rfc.section.9.5.p.3">To minimize the risk of theft or accidental publication, log information ought to be purged of personally identifiable information,
    26762675         including user identifiers, IP addresses, and user-provided query parameters, as soon as that information is no longer necessary
    26772676         to support operational needs for security, auditing, or fraud control.
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r2393 r2398  
    19051905</t>
    19061906<t>
    1907    In the interest of robustness, servers &SHOULD; ignore at least one
    1908    empty line received where a request-line is expected. In other words, if
    1909    a server is reading the protocol stream at the beginning of a
    1910    message and receives a CRLF first, the server &SHOULD; ignore the CRLF.
     1907   In the interest of robustness, a server that is expecting to receive and
     1908   parse a request-line &SHOULD; ignore at least one empty line (CRLF)
     1909   received prior to the request-line.
    19111910</t>
    19121911<t>
     
    38363835</t>
    38373836<t>
    3838    Recipients &SHOULD; carefully limit the extent to which they read other
     3837   Recipients ought to carefully limit the extent to which they read other
    38393838   fields, including (but not limited to) request methods, response status
    38403839   phrases, header field-names, and body chunks, so as to avoid denial of
     
    38863885   but is generally not sufficient to prevent real log traces from being
    38873886   re-identified based on correlation with other access characteristics.
    3888    As such, access traces that are keyed to a specific client should not
    3889    be published even if the key is pseudonymous.
     3887   As such, access traces that are keyed to a specific client are unsafe to
     3888   publish even if the key is pseudonymous.
    38903889</t>
    38913890<t>
    38923891   To minimize the risk of theft or accidental publication, log information
    3893    should be purged of personally identifiable information, including
     3892   ought to be purged of personally identifiable information, including
    38943893   user identifiers, IP addresses, and user-provided query parameters,
    38953894   as soon as that information is no longer necessary to support operational
  • draft-ietf-httpbis/latest/p2-semantics.html

    r2396 r2398  
    14701470         appropriate error message containing sufficient information to explain why the representation is unsuitable. The <a href="#status.409" class="smpl">409 (Conflict)</a> or <a href="#status.415" class="smpl">415 (Unsupported Media Type)</a> status codes are suggested, with the latter being specific to constraints on <a href="#header.content-type" class="smpl">Content-Type</a> values.
    14711471      </p>
    1472       <p id="rfc.section.4.3.4.p.5">For example, if the target resource is configured to always have a <a href="#header.content-type" class="smpl">Content-Type</a> of "text/html" and the representation being PUT has a Content-Type of "image/jpeg", then the origin server <em class="bcp14">SHOULD</em> do one of:
     1472      <p id="rfc.section.4.3.4.p.5">For example, if the target resource is configured to always have a <a href="#header.content-type" class="smpl">Content-Type</a> of "text/html" and the representation being PUT has a Content-Type of "image/jpeg", the origin server ought to do one of:
    14731473      </p>
    14741474      <ol class="la">
     
    18671867      <p id="rfc.section.5.3.2.p.6">The example</p>
    18681868      <div id="rfc.figure.u.25"></div><pre class="text">  Accept: audio/*; q=0.2, audio/basic
    1869 </pre><p id="rfc.section.5.3.2.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
     1869</pre><p id="rfc.section.5.3.2.p.8">is interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% mark-down in
    18701870         quality".
    18711871      </p>
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r2396 r2398  
    14601460   For example, if the target resource is configured to always have a
    14611461   <x:ref>Content-Type</x:ref> of "text/html" and the representation being PUT
    1462    has a Content-Type of "image/jpeg", then the origin server &SHOULD; do one of:
     1462   has a Content-Type of "image/jpeg", the origin server ought to do one of:
    14631463   <list style="letters">
    14641464      <t>reconfigure the target resource to reflect the new media type;</t>
     
    21282128</artwork></figure>
    21292129<t>
    2130    &SHOULD; be interpreted as "I prefer audio/basic, but send me any audio
     2130   is interpreted as "I prefer audio/basic, but send me any audio
    21312131   type if it is the best available after an 80% mark-down in quality".
    21322132</t>
  • draft-ietf-httpbis/latest/p4-conditional.html

    r2394 r2398  
    682682         data is available prior to the response header fields being sent and the digest does not need to be recalculated every time
    683683         a validation request is received. However, if a resource has distinct representations that differ only in their metadata,
    684          such as might occur with content negotiation over media types that happen to share the same data format, then the origin server <em class="bcp14">SHOULD</em> incorporate additional information in the validator to distinguish those representations.
     684         such as might occur with content negotiation over media types that happen to share the same data format, then the origin server
     685         needs to incorporate additional information in the validator to distinguish those representations.
    685686      </p>
    686687      <p id="rfc.section.2.1.p.6">In contrast, a "weak validator" is representation metadata that might not change for every change to the representation data.
  • draft-ietf-httpbis/latest/p4-conditional.xml

    r2394 r2398  
    244244   only in their metadata, such as might occur with content negotiation over
    245245   media types that happen to share the same data format, then the origin
    246    server &SHOULD; incorporate additional information in the validator to
     246   server needs to incorporate additional information in the validator to
    247247   distinguish those representations.
    248248</t>
  • draft-ietf-httpbis/latest/p7-auth.html

    r2393 r2398  
    726726      <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="header.authorization" href="#header.authorization">Authorization</a></h2>
    727727      <p id="rfc.section.4.1.p.1">The "Authorization" header field allows a user agent to authenticate itself with an origin server — usually, but not necessarily,
    728          after receiving a <a href="#status.401" class="smpl">401
    729             (Unauthorized)</a> response. Its value consists of credentials containing information of the user agent for the realm of the resource being requested.
     728         after receiving a <a href="#status.401" class="smpl">401 (Unauthorized)</a> response. Its value consists of credentials containing the authentication information of the user agent for the realm of the
     729         resource being requested.
    730730      </p>
    731731      <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.6"></span>  <a href="#header.authorization" class="smpl">Authorization</a> = <a href="#challenge.and.response" class="smpl">credentials</a>
    732 </pre><p id="rfc.section.4.1.p.3">If a request is authenticated and a realm specified, the same credentials <em class="bcp14">SHOULD</em> be valid for all other requests within this realm (assuming that the authentication scheme itself does not require otherwise,
    733          such as credentials that vary according to a challenge value or using synchronized clocks).
     732</pre><p id="rfc.section.4.1.p.3">If a request is authenticated and a realm specified, the same credentials are presumed to be valid for all other requests
     733         within this realm (assuming that the authentication scheme itself does not require otherwise, such as credentials that vary
     734         according to a challenge value or using synchronized clocks).
    734735      </p>
    735736      <p id="rfc.section.4.1.p.4">See <a href="p6-cache.html#caching.authenticated.responses" title="Storing Responses to Authenticated Requests">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a> for details of and requirements pertaining to handling of the Authorization field by HTTP caches.
  • draft-ietf-httpbis/latest/p7-auth.xml

    r2393 r2398  
    362362  <x:anchor-alias value="Authorization"/>
    363363<t>
    364    The "Authorization" header field allows a user agent to authenticate
    365    itself with an origin server &mdash; usually, but not necessarily, after receiving a <x:ref>401
    366    (Unauthorized)</x:ref> response. Its value consists of credentials containing
    367    information of the user agent for the realm of the resource being
    368    requested.
     364   The "Authorization" header field allows a user agent to authenticate itself
     365   with an origin server &mdash; usually, but not necessarily, after receiving
     366   a <x:ref>401 (Unauthorized)</x:ref> response. Its value consists of
     367   credentials containing the authentication information of the user agent for
     368   the realm of the resource being requested.
    369369</t>
    370370<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Authorization"/>
     
    372372</artwork></figure>
    373373<t>
    374    If a request is
    375    authenticated and a realm specified, the same credentials &SHOULD;
    376    be valid for all other requests within this realm (assuming that
    377    the authentication scheme itself does not require otherwise, such
    378    as credentials that vary according to a challenge value or using
    379    synchronized clocks).
     374   If a request is authenticated and a realm specified, the same credentials
     375   are presumed to be valid for all other requests within this realm (assuming
     376   that the authentication scheme itself does not require otherwise, such as
     377   credentials that vary according to a challenge value or using synchronized
     378   clocks).
    380379</t>
    381380<t>
Note: See TracChangeset for help on using the changeset viewer.