Ignore:
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:
1 edited

Legend:

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

    r1828 r1829  
    867867      <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
    868868         and all origin servers are large public websites. That is not the case in practice. Common HTTP user agents include household
    869          appliances, stereos, scales, software/firmware updaters, command-line programs, mobile apps, and communication devices in
    870          a multitude of shapes and sizes. Likewise, common HTTP origin servers include home automation units, configurable networking
    871          components, office machines, autonomous robots, news feeds, traffic cameras, ad selectors, and video delivery platforms.
     869         appliances, stereos, scales, firmware update scripts, command-line programs, mobile apps, and communication devices in a multitude
     870         of shapes and sizes. Likewise, common HTTP origin servers include home automation units, configurable networking components,
     871         office machines, autonomous robots, news feeds, traffic cameras, ad selectors, and video delivery platforms.
    872872      </p>
    873873      <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
     
    878878      <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
    879879         or provide adequate warning for security or privacy options. In the few cases where this specification requires reporting
    880          of errors to the user, it is acceptable for such reporting to only be visible in an error console or log file. Likewise, requirements
    881          that an automated action be confirmed by the user before proceeding can me met via advance configuration choices, run-time
    882          options, or simply not proceeding with the unsafe action.
     880         of errors to the user, it is acceptable for such reporting to only be observable in an error console or log file. Likewise,
     881         requirements that an automated action be confirmed by the user before proceeding can me met via advance configuration choices,
     882         run-time options, or simply not proceeding with the unsafe action.
    883883      </p>
    884884      <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>
     
    938938         to the HTTP communication, though the tunnel might have been initiated by an HTTP request. A tunnel ceases to exist when both
    939939         ends of the relayed connection are closed. Tunnels are used to extend a virtual connection through an intermediary, such as
    940          when transport-layer security is used to establish private communication through a shared firewall proxy.
     940         when transport-layer security is used to establish confidential communication through a shared firewall proxy.
    941941      </p>
    942942      <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
     
    11151115      </p>
    11161116      <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
    1117          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.
     1117         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.
    11181118      </p>
    11191119      <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> ]
     
    20592059         the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host.
    20602060      </p>
    2061       <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.
    2062          For example,
     2061      <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
     2062         values. For example,
    20632063      </p>
    20642064      <div id="rfc.figure.u.56"></div><pre class="text">  Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
     
    26122612      </p>
    26132613      <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>
    2614       <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,
    2615          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
    2616          be provided for the user to control dissemination of such information, and that designers and implementers be particularly
    2617          careful in this area. History shows that errors in this area often create serious security and/or privacy problems and generate
    2618          highly adverse publicity for the implementer's company.
     2614      <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
     2615         interact with resources (e.g., the user's name, location, mail address, passwords, encryption keys, etc.) and information
     2616         about the user's browsing activity over time (e.g., history, bookmarks, etc.). HTTP implementations need to prevent unintentional
     2617         leakage of this information.
    26192618      </p>
    26202619      <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>
     
    26602659      <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
    26612660         this problem.
    2662       </p>
    2663       <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
    2664          attacks. Such cryptography is beyond the scope of the HTTP/1.1 specification.
    26652661      </p>
    26662662      <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>
Note: See TracChangeset for help on using the changeset viewer.