Ignore:
Timestamp:
31/07/10 01:06:01 (11 years ago)
Author:
fielding@…
Message:

Replace lowercase should with less normative words, where possible.

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

Legend:

Unmodified
Added
Removed

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

    r968 r969  
    263263   of received communication, and the expected behavior of recipients.
    264264   If the communication is considered in isolation, then successful
    265    actions should be reflected in corresponding changes to the
     265   actions ought to be reflected in corresponding changes to the
    266266   observable interface provided by servers. However, since multiple
    267267   clients might act in parallel and perhaps at cross-purposes, we
    … …  
    11071107   empty line received where a Request-Line is expected. In other words, if
    11081108   the server is reading the protocol stream at the beginning of a
    1109    message and receives a CRLF first, it should ignore the CRLF.
     1109   message and receives a CRLF first, it &SHOULD; ignore the CRLF.
    11101110</t>
    11111111<t>
    … …  
    13331333     Such a message might indicate an attempt to perform request or response
    13341334     smuggling (bypass of security-related checks on message routing or content)
    1335      and thus should be handled as an error.  The provided Content-Length &MUST;
     1335     and thus ought to be handled as an error.  The provided Content-Length &MUST;
    13361336     be removed, prior to forwarding the message downstream, or replaced with
    13371337     the real message-body length after the transfer-coding is decoded.
    … …  
    16031603    meaning of the request when the origin server is improperly using
    16041604    a non-reserved URI character for a reserved purpose.  Implementors
    1605     should be aware that some pre-HTTP/1.1 proxies have been known to
     1605    need to be aware that some pre-HTTP/1.1 proxies have been known to
    16061606    rewrite the request-target.
    16071607  </t>
    … …  
    33113311   The HTTP Upgrade Token Registry defines the name space for product
    33123312   tokens used to identify protocols in the Upgrade header field.
    3313    Each registered token should be associated with one or a set of
    3314    specifications, and with contact information.
    3315 </t>
    3316 <t>
    3317    Registrations should be allowed on a First Come First Served basis as
    3318    described in <xref target="RFC5226" x:sec="4.1" x:fmt="of"/>. These
    3319    specifications need not be IETF documents or be subject to IESG review, but
    3320    should obey the following rules:
     3313   Each registered token is associated with contact information and
     3314   an optional set of specifications that details how the connection
     3315   will be processed after it has been upgraded.
     3316</t>
     3317<t>
     3318   Registrations are allowed on a First Come First Served basis as
     3319   described in <xref target="RFC5226" x:sec="4.1" x:fmt="of"/>. The
     3320   specifications need not be IETF documents or be subject to IESG review.
     3321   Registrations are subject to the following rules:
    33213322  <list style="numbers">
    33223323    <t>A token, once registered, stays registered forever.</t>
    … …  
    33243325       registration.</t>
    33253326    <t>The registration &MUST; name a point of contact.</t>
    3326     <t>The registration &MAY; name the documentation required for the
    3327        token.</t>
     3327    <t>The registration &MAY; name a set of specifications associated with that
     3328       token. Such specifications need not be publicly available.</t>
    33283329    <t>The responsible party &MAY; change the registration at any time.
    33293330       The IANA will keep a record of all such changes, and make them
    … …  
    33373338  </list>
    33383339</t>
    3339 <t>
    3340    It is not required that specifications for upgrade tokens be made
    3341    publicly available, but the contact information for the registration
    3342    should be.
    3343 </t>
    33443340</section>
    33453341
    … …  
    34533449<section title="Header Field Registration" anchor="header.field.registration">
    34543450<t>
    3455    The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> should be updated
     3451   The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> shall be updated
    34563452   with the permanent registrations below (see <xref target="RFC3864"/>):
    34573453</t>
    … …  
    35303526   The entries for the "http" and "https" URI Schemes in the registry located at
    35313527   <eref target="http://www.iana.org/assignments/uri-schemes.html"/>
    3532    should be updated to point to Sections <xref target="http.uri" format="counter"/>
     3528   shall be updated to point to Sections <xref target="http.uri" format="counter"/>
    35333529   and <xref target="https.uri" format="counter"/> of this document
    35343530   (see <xref target="RFC4395"/>).
    … …  
    36933689<t>
    36943690   The HTTP Transfer Codings Registry located at <eref target="http://www.iana.org/assignments/http-parameters"/>
    3695    should be updated with the registrations below:
     3691   shall be updated with the registrations below:
    36963692</t>
    36973693<texttable align="left" suppress-title="true" anchor="iana.transfer.coding.registration.table">
    … …  
    37323728<t>
    37333729   The HTTP Status Code Registry located at <eref target="http://www.iana.org/assignments/http-upgrade-tokens/"/>
    3734    should be updated with the registration below:
     3730   shall be updated with the registration below:
    37353731</t>
    37363732<texttable align="left" suppress-title="true">
    … …  
    38603856</t>
    38613857<t>
    3862    Proxy operators should protect the systems on which proxies run as
     3858   Proxy operators need to protect the systems on which proxies run as
    38633859   they would protect any system that contains or transports sensitive
    38643860   information. In particular, log information gathered at proxies often
    38653861   contains highly sensitive personal information, and/or information
    3866    about organizations. Log information should be carefully guarded, and
    3867    appropriate guidelines for use should be developed and followed.
     3862   about organizations. Log information needs to be carefully guarded, and
     3863   appropriate guidelines for use need to be developed and followed.
    38683864   (<xref target="abuse.of.server.log.information"/>).
    38693865</t>
    38703866<t>
    3871    Proxy implementors should consider the privacy and security
     3867   Proxy implementors need to consider the privacy and security
    38723868   implications of their design and coding decisions, and of the
    38733869   configuration options they provide to proxy operators (especially the

  • draft-ietf-httpbis/latest/p2-semantics.xml

    r968 r969  
    729729<iref item="Safe Methods" primary="true"/>
    730730<t>
    731    Implementors should be aware that the software represents the user in
    732    their interactions over the Internet, and should be careful to allow
     731   Implementors need to be aware that the software represents the user in
     732   their interactions over the Internet, and need to allow
    733733   the user to be aware of any actions they take which might have an
    734734   unexpected significance to themselves or others.
    … …  
    13291329    <x:h>Note:</x:h> An earlier version of this specification recommended a
    13301330    maximum of five redirections (<xref target="RFC2068" x:fmt="," x:sec="10.3"/>).
    1331     Content developers should be aware that there might be clients that
     1331    Content developers need to be aware that some clients might
    13321332    implement such a fixed limitation.
    13331333  </t>
    … …  
    21792179   obsolete or mistyped links to be traced for maintenance. Some servers use
    21802180   Referer as a means of controlling where they allow links from (so-called
    2181    "deep linking"), but it should be noted that legitimate requests are not
    2182    required to contain a Referer header field.
     2181   "deep linking"), but legitimate requests do not always
     2182   contain a Referer header field.
    21832183</t>
    21842184<t>
    … …  
    23292329</t>
    23302330<t>
    2331    The HTTP Method Registry should be created at <eref target="http://www.iana.org/assignments/http-methods"/>
     2331   The HTTP Method Registry shall be created at <eref target="http://www.iana.org/assignments/http-methods"/>
    23322332   and be populated with the registrations below:
    23332333</t>
    … …  
    23912391<t>
    23922392   The HTTP Status Code Registry located at <eref target="http://www.iana.org/assignments/http-status-codes"/>
    2393    should be updated with the registrations below:
     2393   shall be updated with the registrations below:
    23942394</t>
    23952395<?BEGININC p2-semantics.iana-status-codes ?>
    … …  
    25852585<section title="Header Field Registration" anchor="header.field.registration">
    25862586<t>
    2587    The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> should be updated
     2587   The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> shall be updated
    25882588   with the permanent registrations below (see <xref target="RFC3864"/>):
    25892589</t>
    … …  
    27442744</t>
    27452745<t>
    2746    Authors of services should not use GET-based forms for the submission of
    2747    sensitive data because that data will be encoded in the request-target. Many
     2746   Authors of services &SHOULD-NOT; use GET-based forms for the submission of
     2747   sensitive data because that data will be placed in the request-target. Many
    27482748   existing servers, proxies, and user agents log or display the request-target
    27492749   in places where it might be visible to third parties. Such services can

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

    r968 r969  
    409409</t>
    410410<t>
    411    Implementors should be aware of IETF character set requirements <xref target="RFC3629"/>
     411   Implementors need to be aware of IETF character set requirements <xref target="RFC3629"/>
    412412   <xref target="RFC2277"/>.
    413413</t>
    … …  
    13001300    the user, we remind implementors of  the fact that users are not
    13011301    familiar with the details of language matching as described above,
    1302     and should provide appropriate guidance. As an example, users
     1302    and ought to be provided appropriate guidance. As an example, users
    13031303    might assume that on selecting "en-gb", they will be served any
    13041304    kind of English document if British English is not available. A
    … …  
    16071607<section title="Header Field Registration" anchor="header.field.registration">
    16081608<t>
    1609    The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> should be updated
     1609   The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> shall be updated
    16101610   with the permanent registrations below (see <xref target="RFC3864"/>):
    16111611</t>
    … …  
    16991699<t>
    17001700   The HTTP Content Codings Registry located at <eref target="http://www.iana.org/assignments/http-parameters"/>
    1701    should be updated with the registration below:
     1701   shall be updated with the registration below:
    17021702</t>
    17031703<texttable align="left" suppress-title="true" anchor="iana.content.coding.registration.table">
    … …  
    26052605</t>
    26062606<t>
    2607    Implementors should note that conversion will break any cryptographic
     2607   Conversion will break any cryptographic
    26082608   checksums applied to the original content unless the original content
    26092609   is already in canonical form. Therefore, the canonical form is

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

    r965 r969  
    704704  <list><t>
    705705      <x:h>Note:</x:h> The general principle behind these rules is that HTTP/1.1
    706       servers and clients should transmit as much non-redundant
     706      servers and clients ought to transmit as much non-redundant
    707707      information as is available in their responses and requests.
    708708      HTTP/1.1 systems receiving this information will make the most
    … …  
    903903      <x:h>Note:</x:h> If a client uses an arbitrary date in the If-Modified-Since
    904904      header instead of a date taken from the Last-Modified header for
    905       the same request, the client should be aware of the fact that this
    906       date is interpreted in the server's understanding of time. The
    907       client should consider unsynchronized clocks and rounding problems
    908       due to the different encodings of time between the client and
    909       server. This includes the possibility of race conditions if the
     905      the same request, the client needs to be aware that this
     906      date is interpreted in the server's understanding of time.
     907      Unsynchronized clocks and rounding problems, due to the different
     908      encodings of time between the client and server, are concerns.
     909      This includes the possibility of race conditions if the
    910910      document has changed between the time it was first requested and
    911911      the If-Modified-Since date of a subsequent request, and the
    … …  
    11071107<t>
    11081108   The HTTP Status Code Registry located at <eref target="http://www.iana.org/assignments/http-status-codes"/>
    1109    should be updated with the registrations below:
     1109   shall be updated with the registrations below:
    11101110</t>
    11111111<?BEGININC p4-conditional.iana-status-codes ?>
    … …  
    11321132<section title="Header Field Registration" anchor="header.field.registration">
    11331133<t>
    1134    The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> should be updated
     1134   The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> shall be updated
    11351135   with the permanent registrations below (see <xref target="RFC3864"/>):
    11361136</t>

  • draft-ietf-httpbis/latest/p5-range.xml

    r965 r969  
    520520<t>
    521521   The "Content-Range" header field is sent with a partial representation to
    522    specify where in the full representation the payload body should be
     522   specify where in the full representation the payload body is intended to be
    523523   applied.
    524524</t>
    … …  
    883883<t>
    884884   The HTTP Status Code Registry located at <eref target="http://www.iana.org/assignments/http-status-codes"/>
    885    should be updated with the registrations below:
     885   shall be updated with the registrations below:
    886886</t>
    887887<?BEGININC p5-range.iana-status-codes ?>
    … …  
    908908<section title="Header Field Registration" anchor="header.field.registration">
    909909<t>
    910    The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> should be updated
     910   The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> shall be updated
    911911   with the permanent registrations below (see <xref target="RFC3864"/>):
    912912</t>
    … …  
    957957</t>
    958958<t>
    959    The HTTP Range Specifier Registry should be created at <eref target="http://www.iana.org/assignments/http-range-specifiers"/>
     959   The HTTP Range Specifier Registry shall be created at <eref target="http://www.iana.org/assignments/http-range-specifiers"/>
    960960   and be populated with the registrations below:
    961961</t>

  • draft-ietf-httpbis/latest/p6-cache.xml

    r965 r969  
    280280   <list>
    281281      <t>The time at which the origin server intends that a representation
    282       should no longer be returned by a cache without further validation.</t>
     282      no longer be returned by a cache without further validation.</t>
    283283   </list>
    284284</t>
    … …  
    566566<t>
    567567   If an origin server wishes to force a cache to validate every request, it
    568    can assign an explicit expiration time in the past. This means that the
    569    response is always stale, so that caches should validate it before using it
    570    for subsequent requests. <cref anchor="TODO-response-stale">This wording
    571    might cause confusion, because the response might still be served
    572    stale.</cref>
     568   can assign an explicit expiration time in the past to indicate that the
     569   response is already stale.  Compliant caches will validate the cached response
     570   before reusing it for subsequent requests.
    573571</t>
    574572<t>
    … …  
    17411739</t>
    17421740<t>
    1743    The HTTP Cache Directive Registry should be created at <eref
     1741   The HTTP Cache Directive Registry shall be created at <eref
    17441742   target="http://www.iana.org/assignments/http-cache-directives"/> and be
    17451743   populated with the registrations below:
    … …  
    18171815  The Message Header Field Registry located at <eref 
    18181816  target="http://www.iana.org/assignments/message-headers/message-header-index.html" />
    1819   should be updated with the permanent registrations below (see <xref target="RFC3864" />):
     1817  shall be updated with the permanent registrations below (see <xref target="RFC3864" />):
    18201818</t>
    18211819<?BEGININC p6-cache.iana-headers ?>
    … …  
    18811879   on the cache can reveal information long after a user believes that the
    18821880   information has been removed from the network. Therefore, cache contents
    1883    should be protected as sensitive information.
     1881   need to be protected as sensitive information.
    18841882</t>
    18851883</section>

  • draft-ietf-httpbis/latest/p7-auth.xml

    r965 r969  
    486486<t>
    487487   The HTTP Status Code Registry located at <eref target="http://www.iana.org/assignments/http-status-codes"/>
    488    should be updated with the registrations below:
     488   shall be updated with the registrations below:
    489489</t>
    490490<?BEGININC p7-auth.iana-status-codes ?>
    … …  
    511511<section title="Header Field Registration" anchor="header.field.registration">
    512512<t>
    513    The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> should be updated
     513   The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> shall be updated
    514514   with the permanent registrations below (see <xref target="RFC3864"/>):
    515515</t>
Note: See TracChangeset for help on using the changeset viewer.