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

Timestamp:

Aug 18, 2012, 9:39:58 PM (7 years ago)

Author:

fielding@…

Message:

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

File:

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

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

@@ -399 +399 @@
    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,
+   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
@@ -419 +419 @@
    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.
+   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,
@@ -551 +551 @@
    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
+   transport-layer security is used to establish confidential communication
    through a shared firewall proxy.
 </t>
@@ -938 +938 @@
    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 &MUST; be secured for privacy through the
+   and the TCP connection &MUST; be secured through the
    use of strong encryption prior to sending the first HTTP request.
 </t>
@@ -2842 +2842 @@
 </t>
 <t>
-   For organizations that have strong privacy requirements for hiding
-   internal structures, a proxy or gateway &MAY; combine an ordered
-   subsequence of Via header field entries with identical received-protocol
-   values into a single such entry. For example,
+   A proxy or gateway &MAY; combine an ordered subsequence of Via header
+   field entries into a single such entry if the entries have identical
+   received-protocol values. For example,
 </t>
 <figure><artwork type="example">
@@ -3704 +3703 @@
 <section title="Personal Information" anchor="personal.information">
 <t>
-   HTTP clients are often privy to large amounts of personal information
+   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 &SHOULD; 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.
+   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.
 </t>
 </section>
@@ -3801 +3796 @@
    Users need to be aware that intermediaries are no more trustworthy than
    the people who run them; HTTP itself cannot solve this problem.
-</t>
-<t>
-   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.
 </t>
 </section>