Changeset 908 for draft-ietf-httpbis/latest/p3-payload.xml

Timestamp:

Jul 24, 2010, 1:30:41 AM (9 years ago)

Author:

fielding@…

Message:

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

File:

• draft-ietf-httpbis/latest/p3-payload.xml (modified) (13 diffs)

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

@@ -230 +230 @@
    associated metadata header fields that define how the payload is intended
    to be interpreted by a recipient, the request header fields that
-   may influence content selection, and the various selection algorithms
+   might influence content selection, and the various selection algorithms
    that are collectively referred to as HTTP content negotiation.
 </t>
@@ -394 +394 @@
    method used with one or more tables to convert a sequence of octets
    into a sequence of characters. Note that unconditional conversion in
-   the other direction is not required, in that not all characters may
-   be available in a given character set and a character set may provide
+   the other direction is not required, in that not all characters might
+   be available in a given character set and a character set might provide
    more than one sequence of octets to represent a particular character.
    This definition is intended to allow various kinds of character
@@ -434 +434 @@
    value of a parameter in a Content-Type header (within a request or
    response), in which case the parameter value of the charset parameter
-   may be quoted.
+   can be quoted.
 </t>
 <t>
@@ -583 +583 @@
 </t>
 <t>
-   A parameter value that matches the <x:ref>token</x:ref> production may be
+   A parameter value that matches the <x:ref>token</x:ref> production can be
    transmitted as either a token or within a quoted-string. The quoted and
    unquoted values are equivalent. 
@@ -790 +790 @@
 </t>
 <t>
-   Clients that do so risk drawing incorrect conclusions, which may expose
+   Clients that do so risk drawing incorrect conclusions, which might expose
    additional security risks (e.g., "privilege escalation"). Implementers are
    encouraged to provide a means of disabling such "content sniffing" when it
@@ -796 +796 @@
 </t>
 <t>
-   Content-Encoding may be used to indicate any additional content
+   Content-Encoding is used to indicate any additional content
    codings applied to the data, usually for the purpose of data
    compression, that are a property of the representation.  There is
@@ -840 +840 @@
    capabilities to be expressed by a client are large (such as when many
    different formats are supported by a user-agent), server-driven
-   negotiation becomes unwieldy, and may not be appropriate. Conversely,
+   negotiation becomes unwieldy, and might not be appropriate. Conversely,
    when the number of representations to choose from is very large,
-   agent-driven negotiation may not be appropriate.
+   agent-driven negotiation might not be appropriate.
 </t>
 <t>
@@ -892 +892 @@
     </t>
     <t>
-         It may limit a public cache's ability to use the same response
+         It might limit a public cache's ability to use the same response
          for multiple user's requests.
     </t>
@@ -929 +929 @@
    header fields or body of the initial response, with each
    representation identified by its own URI. Selection from among the
-   representations may be performed automatically (if the user agent is
+   representations can be performed automatically (if the user agent is
    capable of doing so) or manually by the user selecting from a
    generated (possibly hypertext) menu.
@@ -1455 +1455 @@
    contains a report on the action's status and the same report is
    available (for future access with GET) at the given URI.  For
-   example, a purchase transaction made via the POST method may
+   example, a purchase transaction made via the POST method might
    include a receipt document as the payload of the 200 response;
    the Content-Location value provides an identifier for retrieving
@@ -2064 +2064 @@
   <seriesInfo name="RFC" value="1950"/>
   <annotation>
-    RFC 1950 is an Informational RFC, thus it may be less stable than
+    RFC 1950 is an Informational RFC, thus it might be less stable than
     this specification. On the other hand, this downward reference was 
     present since the publication of RFC 2068 in 1997 (<xref target="RFC2068"/>),
@@ -2083 +2083 @@
   <seriesInfo name="RFC" value="1951"/>
   <annotation>
-    RFC 1951 is an Informational RFC, thus it may be less stable than
+    RFC 1951 is an Informational RFC, thus it might be less stable than
     this specification. On the other hand, this downward reference was 
     present since the publication of RFC 2068 in 1997 (<xref target="RFC2068"/>),
@@ -2114 +2114 @@
   <seriesInfo name="RFC" value="1952"/>
   <annotation>
-    RFC 1952 is an Informational RFC, thus it may be less stable than
+    RFC 1952 is an Informational RFC, thus it might be less stable than
     this specification. On the other hand, this downward reference was 
     present since the publication of RFC 2068 in 1997 (<xref target="RFC2068"/>),