Changeset 1829 for draft-ietf-httpbis/latest/p1-messaging.html

Timestamp:

19/08/12 04:39:58 (8 years ago)

Author:

fielding@…

Message:

(editorial) a few tweaks to remove ambiguous or meaningless text

File:

• draft-ietf-httpbis/latest/p1-messaging.html (modified) (7 diffs)

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

@@ -867 +867 @@
       <p id="rfc.section.2.2.p.1">When considering the design of HTTP, it is easy to fall into a trap of thinking that all user agents are general-purpose browsers
          and all origin servers are large public websites. That is not the case in practice. Common HTTP user agents include household
-         appliances, stereos, scales, software/firmware updaters, command-line programs, mobile apps, and communication devices in
-         a multitude of shapes and sizes. Likewise, common HTTP origin servers include home automation units, configurable networking
-         components, office machines, autonomous robots, news feeds, traffic cameras, ad selectors, and video delivery platforms.
+         appliances, stereos, scales, firmware update scripts, command-line programs, mobile apps, and communication devices in a multitude
+         of shapes and sizes. Likewise, common HTTP origin servers include home automation units, configurable networking components,
+         office machines, autonomous robots, news feeds, traffic cameras, ad selectors, and video delivery platforms.
       </p>
       <p id="rfc.section.2.2.p.2">The term "user agent" does not imply that there is a human user directly interacting with the software agent at the time of
@@ -878 +878 @@
       <p id="rfc.section.2.2.p.3">The implementation diversity of HTTP means that we cannot assume the user agent can make interactive suggestions to a user
          or provide adequate warning for security or privacy options. In the few cases where this specification requires reporting
-         of errors to the user, it is acceptable for such reporting to only be visible in an error console or log file. Likewise, requirements
-         that an automated action be confirmed by the user before proceeding can me met via advance configuration choices, run-time
-         options, or simply not proceeding with the unsafe action.
+         of errors to the user, it is acceptable for such reporting to only be observable in an error console or log file. Likewise,
+         requirements that an automated action be confirmed by the user before proceeding can me met via advance configuration choices,
+         run-time options, or simply not proceeding with the unsafe action.
       </p>
       <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a id="transport-independence" href="#transport-independence">Connections and Transport Independence</a></h2>
@@ -938 +938 @@
          to the HTTP communication, though the tunnel might have been initiated by an HTTP request. A tunnel ceases to exist when both
          ends of the relayed connection are closed. Tunnels are used to extend a virtual connection through an intermediary, such as
-         when transport-layer security is used to establish private communication through a shared firewall proxy.
+         when transport-layer security is used to establish confidential communication through a shared firewall proxy.
       </p>
       <p id="rfc.section.2.4.p.10"><span id="rfc.iref.i.3"></span>  <span id="rfc.iref.t.3"></span>  <span id="rfc.iref.c.3"></span> The above categories for intermediary only consider those acting as participants in the HTTP communication. There are also
@@ -1115 +1115 @@
       </p>
       <p id="rfc.section.2.8.2.p.2">All of the requirements listed above for the "http" scheme are also requirements for the "https" scheme, except that a default
-         TCP port of 443 is assumed if the port subcomponent is empty or not given, and the TCP connection <em class="bcp14">MUST</em> be secured for privacy through the use of strong encryption prior to sending the first HTTP request.
+         TCP port of 443 is assumed if the port subcomponent is empty or not given, and the TCP connection <em class="bcp14">MUST</em> be secured through the use of strong encryption prior to sending the first HTTP request.
       </p>
       <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.25"></span>  <a href="#https.uri" class="smpl">https-URI</a> = "https:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ]
@@ -2059 +2059 @@
          the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host.
       </p>
-      <p id="rfc.section.6.2.p.10">For organizations that have strong privacy requirements for hiding internal structures, a proxy or gateway <em class="bcp14">MAY</em> combine an ordered subsequence of Via header field entries with identical received-protocol values into a single such entry.
-         For example,
+      <p id="rfc.section.6.2.p.10">A proxy or gateway <em class="bcp14">MAY</em> combine an ordered subsequence of Via header field entries into a single such entry if the entries have identical received-protocol
+         values. For example,
       </p>
       <div id="rfc.figure.u.56"></div><pre class="text">  Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
@@ -2612 +2612 @@
       </p>
       <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a>&nbsp;<a id="personal.information" href="#personal.information">Personal Information</a></h2>
-      <p id="rfc.section.8.1.p.1">HTTP clients are often privy to large amounts of personal information (e.g., the user's name, location, mail address, passwords,
-         encryption keys, etc.), and <em class="bcp14">SHOULD</em> be very careful to prevent unintentional leakage of this information. We very strongly recommend that a convenient interface
-         be provided for the user to control dissemination of such information, and that designers and implementers be particularly
-         careful in this area. History shows that errors in this area often create serious security and/or privacy problems and generate
-         highly adverse publicity for the implementer's company.
+      <p id="rfc.section.8.1.p.1">HTTP clients are often privy to large amounts of personal information, including both information provided by the user to
+         interact with resources (e.g., the user's name, location, mail address, passwords, encryption keys, etc.) and information
+         about the user's browsing activity over time (e.g., history, bookmarks, etc.). HTTP implementations need to prevent unintentional
+         leakage of this information.
       </p>
       <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a>&nbsp;<a id="abuse.of.server.log.information" href="#abuse.of.server.log.information">Abuse of Server Log Information</a></h2>
@@ -2660 +2659 @@
       <p id="rfc.section.8.5.p.4">Users need to be aware that intermediaries are no more trustworthy than the people who run them; HTTP itself cannot solve
          this problem.
-      </p>
-      <p id="rfc.section.8.5.p.5">The judicious use of cryptography, when appropriate, might suffice to protect against a broad range of security and privacy
-         attacks. Such cryptography is beyond the scope of the HTTP/1.1 specification.
       </p>
       <h2 id="rfc.section.8.6"><a href="#rfc.section.8.6">8.6</a>&nbsp;<a id="attack.protocol.element.size.overflows" href="#attack.protocol.element.size.overflows">Protocol Element Size Overflows</a></h2>