Ignore:
Timestamp:
Jul 24, 2010, 12:25:07 AM (9 years ago)
Author:
fielding@…
Message:

(editorial) use might instead of may where it might be confused with MAY

File:
1 edited

Legend:

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

    r899 r901  
    265265   actions should be reflected in corresponding changes to the
    266266   observable interface provided by servers. However, since multiple
    267    clients may act in parallel and perhaps at cross-purposes, we
     267   clients might act in parallel and perhaps at cross-purposes, we
    268268   cannot require that such changes be observable beyond the scope
    269269   of a single response.
     
    429429</t>
    430430<t>
    431    The OWS rule is used where zero or more linear whitespace characters may
     431   The OWS rule is used where zero or more linear whitespace characters might
    432432   appear. OWS &SHOULD; either not be produced or be produced as a single SP
    433433   character. Multiple OWS characters that occur within field-content &SHOULD;
     
    569569   Note that the terms client and server refer only to the roles that
    570570   these programs perform for a particular connection.  The same program
    571    may act as a client on some connections and a server on others.  We use
     571   might act as a client on some connections and a server on others.  We use
    572572   the term "user agent" to refer to the program that initiates a request,
    573573   such as a WWW browser, editor, or spider (web-traversing robot), and
     
    578578   Most HTTP communication consists of a retrieval request (GET) for
    579579   a representation of some resource identified by a URI.  In the
    580    simplest case, this may be accomplished via a single bidirectional
     580   simplest case, this might be accomplished via a single bidirectional
    581581   connection (===) between the user agent (UA) and the origin server (O).
    582582</t>
     
    640640   are present in the request/response chain. There are three common
    641641   forms of intermediary: proxy, gateway, and tunnel.  In some cases,
    642    a single intermediary may act as an origin server, proxy, gateway,
     642   a single intermediary might act as an origin server, proxy, gateway,
    643643   or tunnel, switching behavior based on the nature of each request.
    644644</t>
     
    653653   travels the whole chain will pass through four separate connections.
    654654   Some HTTP communication options
    655    may apply only to the connection with the nearest, non-tunnel
     655   might apply only to the connection with the nearest, non-tunnel
    656656   neighbor, only to the end-points of the chain, or to all connections
    657    along the chain. Although the diagram is linear, each participant may
     657   along the chain. Although the diagram is linear, each participant might
    658658   be engaged in multiple, simultaneous communications. For example, B
    659    may be receiving requests from many clients other than A, and/or
     659   might be receiving requests from many clients other than A, and/or
    660660   forwarding requests to servers other than C, at the same time that it
    661661   is handling A's request.
     
    677677   requests via translation through the HTTP interface.  Some translations
    678678   are minimal, such as for proxy requests for "http" URIs, whereas
    679    other requests may require translation to and from entirely different
     679   other requests might require translation to and from entirely different
    680680   application-layer protocols. Proxies are often used to group an
    681681   organization's HTTP requests through a common intermediary for the
     
    701701   A "tunnel" acts as a blind relay between two connections
    702702   without changing the messages. Once active, a tunnel is not
    703    considered a party to the HTTP communication, though the tunnel may
     703   considered a party to the HTTP communication, though the tunnel might
    704704   have been initiated by an HTTP request. A tunnel ceases to exist when
    705705   both ends of the relayed connection are closed. Tunnels are used to
     
    713713<iref item="cache"/>
    714714<t>
    715    Any party to HTTP communication that is not acting as a tunnel may
    716    employ an internal cache for handling requests.
    717715   A "cache" is a local store of previous response messages and the
    718716   subsystem that controls its message storage, retrieval, and deletion.
    719717   A cache stores cacheable responses in order to reduce the response
    720718   time and network bandwidth consumption on future, equivalent
    721    requests. Any client or server may include a cache, though a cache
     719   requests. Any client or server &MAY; employ a cache, though a cache
    722720   cannot be used by a server while it is acting as a tunnel.
    723721</t>
     
    737735   A response is "cacheable" if a cache is allowed to store a copy of
    738736   the response message for use in answering subsequent requests.
    739    Even when a response is cacheable, there may be additional
     737   Even when a response is cacheable, there might be additional
    740738   constraints placed by the client or by the origin server on when
    741739   that cached response can be used for a particular request. HTTP
     
    771769<t>
    772770   In HTTP/1.0, most implementations used a new connection for each
    773    request/response exchange. In HTTP/1.1, a connection may be used for
    774    one or more request/response exchanges, although connections may be
     771   request/response exchange. In HTTP/1.1, a connection might be used for
     772   one or more request/response exchanges, although connections might be
    775773   closed for a variety of reasons (see <xref target="persistent.connections"/>).
    776774</t>
     
    790788   The &lt;minor&gt; number is incremented when the changes made to the
    791789   protocol add features which do not change the general message parsing
    792    algorithm, but which may add to the message semantics and imply
     790   algorithm, but which might add to the message semantics and imply
    793791   additional capabilities of the sender. The &lt;major&gt; number is
    794792   incremented when the format of a message within the protocol is
     
    842840<x:note>
    843841  <t>
    844     <x:h>Note:</x:h> Converting between versions of HTTP may involve modification
     842    <x:h>Note:</x:h> Converting between versions of HTTP might involve modification
    845843    of header fields required or forbidden by the versions involved.
    846844  </t>
     
    854852   throughout HTTP as the means for identifying resources. URI references
    855853   are used to target requests, indicate redirects, and define relationships.
    856    HTTP does not limit what a resource may be; it merely defines an interface
     854   HTTP does not limit what a resource might be; it merely defines an interface
    857855   that can be used to interact with a resource via HTTP. More information on
    858856   the scope of URIs and resources can be found in <xref target="RFC3986"/>.
     
    930928<t>
    931929   Regardless of the form of host identifier, access to that host is not
    932    implied by the mere presence of its name or address. The host may or may
    933    not exist and, even when it does exist, may or may not be running an
     930   implied by the mere presence of its name or address. The host might or might
     931   not exist and, even when it does exist, might or might not be running an
    934932   HTTP server or listening to the indicated port. The "http" URI scheme
    935933   makes use of the delegated nature of Internet names and addresses to
     
    955953   would presumably be identified using a different URI scheme, just as
    956954   the "https" scheme (below) is used for servers that require an SSL/TLS
    957    transport layer on a connection. Other protocols may also be used to
     955   transport layer on a connection. Other protocols might also be used to
    958956   provide access to "http" identified resources --- it is only the
    959957   authoritative interface used for mapping the namespace that is
     
    995993   Unlike the "http" scheme, responses to "https" identified requests
    996994   are never "public" and thus are ineligible for shared caching.
    997    Their default is "private" and may be further constrained via use
     995   Their default is "private" and might be further constrained via use
    998996   of the Cache-Control header field.
    999997</t>
     
    10921090   header field. The presence of whitespace might be an attempt to trick a
    10931091   noncompliant implementation of HTTP into ignoring that field or processing
    1094    the next line as a new request, either of which may result in security
     1092   the next line as a new request, either of which might result in security
    10951093   issues when implementations within the request chain interpret the
    10961094   same message differently. HTTP/1.1 servers &MUST; reject such a message
     
    11251123   of octets in an encoding that is a superset of US-ASCII.  Attempting
    11261124   to parse HTTP as a stream of Unicode characters in a character encoding
    1127    like UTF-16 may introduce security flaws due to the differing ways
     1125   like UTF-16 might introduce security flaws due to the differing ways
    11281126   that such parsers interpret invalid characters.
    11291127</t>
     
    13111309     If a message is received with both a Transfer-Encoding header field and a
    13121310     Content-Length header field, the Transfer-Encoding overrides the Content-Length.
    1313      Such a message may indicate an attempt to perform request or response
     1311     Such a message might indicate an attempt to perform request or response
    13141312     smuggling (bypass of security-related checks on message routing or content)
    13151313     and thus should be handled as an error.  The provided Content-Length &MUST;
     
    14311429   General-header field names can be extended reliably only in
    14321430   combination with a change in the protocol version. However, new or
    1433    experimental header fields may be given the semantics of general
     1431   experimental header fields might be given the semantics of general
    14341432   header fields if all parties in the communication recognize them to
    14351433   be general-header fields. Unrecognized header fields are treated as
     
    19361934  <t>
    19371935    <x:h>Note:</x:h> Recipients of date values are encouraged to be robust in
    1938     accepting date values that may have been sent by non-HTTP
     1936    accepting date values that might have been sent by non-HTTP
    19391937    applications, as is sometimes the case when retrieving or posting
    19401938    messages via proxies/gateways to SMTP or NNTP.
     
    19561954<t>
    19571955   Transfer-coding values are used to indicate an encoding
    1958    transformation that has been, can be, or may need to be applied to a
     1956   transformation that has been, can be, or might need to be applied to a
    19591957   payload body in order to ensure "safe transport" through the network.
    19601958   This differs from a content coding in that the transfer-coding is a
     
    26542652<t>
    26552653   Because of the presence of older implementations, the protocol allows
    2656    ambiguous situations in which a client may send "Expect: 100-continue"
     2654   ambiguous situations in which a client might send "Expect: 100-continue"
    26572655   without receiving either a 417 (Expectation Failed) status
    26582656   or a 100 (Continue) status. Therefore, when a client sends this
     
    27952793
    27962794
    2797 <section title="Miscellaneous notes that may disappear" anchor="misc">
     2795<section title="Miscellaneous notes that might disappear" anchor="misc">
    27982796<section title="Scheme aliases considered harmful" anchor="scheme.aliases">
    27992797<t>
     
    28642862   a connection-token in the Connection header field, not by any
    28652863   corresponding additional header field(s), since the additional header
    2866    field may not be sent if there are no parameters associated with that
     2864   field might not be sent if there are no parameters associated with that
    28672865   connection option.
    28682866</t>
     
    30883086</t>
    30893087<t>
    3090    Its value may consist of the keyword "trailers" and/or a comma-separated
     3088   Its value might consist of the keyword "trailers" and/or a comma-separated
    30913089   list of extension transfer-coding names with optional accept
    30923090   parameters (as described in <xref target="transfer.codings"/>).
     
    38653863</t>
    38663864<t>
    3867    The judicious use of cryptography, when appropriate, may suffice to
     3865   The judicious use of cryptography, when appropriate, might suffice to
    38683866   protect against a broad range of security and privacy attacks. Such
    38693867   cryptography is beyond the scope of the HTTP/1.1 specification.
     
    42264224  <seriesInfo name="RFC" value="1950"/>
    42274225  <annotation>
    4228     RFC 1950 is an Informational RFC, thus it may be less stable than
     4226    RFC 1950 is an Informational RFC, thus it might be less stable than
    42294227    this specification. On the other hand, this downward reference was
    42304228    present since the publication of RFC 2068 in 1997 (<xref target="RFC2068"/>),
     
    42454243  <seriesInfo name="RFC" value="1951"/>
    42464244  <annotation>
    4247     RFC 1951 is an Informational RFC, thus it may be less stable than
     4245    RFC 1951 is an Informational RFC, thus it might be less stable than
    42484246    this specification. On the other hand, this downward reference was
    42494247    present since the publication of RFC 2068 in 1997 (<xref target="RFC2068"/>),
     
    42764274  <seriesInfo name="RFC" value="1952"/>
    42774275  <annotation>
    4278     RFC 1952 is an Informational RFC, thus it may be less stable than
     4276    RFC 1952 is an Informational RFC, thus it might be less stable than
    42794277    this specification. On the other hand, this downward reference was
    42804278    present since the publication of RFC 2068 in 1997 (<xref target="RFC2068"/>),
     
    48634861   experimental implementations of persistent connections are faulty,
    48644862   and the new facilities in HTTP/1.1 are designed to rectify these
    4865    problems. The problem was that some existing HTTP/1.0 clients may be
    4866    sending Keep-Alive to a proxy server that doesn't understand
     4863   problems. The problem was that some existing HTTP/1.0 clients might
     4864   send Keep-Alive to a proxy server that doesn't understand
    48674865   Connection, which would then erroneously forward it to the next
    48684866   inbound server, which would establish the Keep-Alive connection and
     
    48954893   Transfer-coding and message lengths all interact in ways that
    48964894   required fixing exactly when chunked encoding is used (to allow for
    4897    transfer encoding that may not be self delimiting); it was important
     4895   transfer encoding that might not be self delimiting); it was important
    48984896   to straighten out exactly how message lengths are computed. (Sections
    48994897   <xref target="transfer.codings" format="counter"/>, <xref target="message.body" format="counter"/>,
     
    55715569    <t>
    55725570      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/88"/>:
    5573       "205 Bodies" (took out language that implied that there may be
     5571      "205 Bodies" (took out language that implied that there might be
    55745572      methods for which a request body MUST NOT be included)
    55755573    </t>
Note: See TracChangeset for help on using the changeset viewer.