Jul 13, 2012, 1:57:46 AM (7 years ago)

(editorial) clean up a few Notes

Created a section on implementation diversity to replace the confusing
and awkward note about user agents not always having interactive users.

1 edited


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

    r1760 r1762  
    145145<note title="Editorial Note (To be removed by RFC Editor)">
    146146  <t>
    147     Discussion of this draft ought to take place on the HTTPBIS working group
     147    Discussion of this draft takes place on the HTTPBIS working group
    148148    mailing list (ietf-http-wg@w3.org), which is archived at
    149149    <eref target="http://lists.w3.org/Archives/Public/ietf-http-wg/"/>.
    303303<iref primary="true" item="recipient"/>
    305    Note that the terms client and server refer only to the roles that
     305   The terms client and server refer only to the roles that
    306306   these programs perform for a particular connection.  The same program
    307307   might act as a client on some connections and a server on others.  We use
    314314   message.
    316 <x:note>
    317   <t>
    318     &Note; The term 'user agent' covers both those situations where
    319     there is a user (human) interacting with the software agent (and for which
    320     user interface or interactive suggestions might be made, e.g., warning the
    321     user or given the user an option in the case of security or privacy
    322     options) and also those where the software agent can act autonomously.
    323   </t>
    324 </x:note>
    326317   Most HTTP communication consists of a retrieval request (GET) for
    338329<iref primary="true" item="response"/>
    340    A client sends an HTTP request to the server in the form of a <x:dfn>request</x:dfn>
     331   A client sends an HTTP request to a server in the form of a <x:dfn>request</x:dfn>
    341332   message, beginning with a request-line that includes a method, URI, and
    342333   protocol version (<xref target="request.line"/>),
    351    A server responds to the client's request by sending one or more HTTP
     342   A server responds to a client's request by sending one or more HTTP
    352343   <x:dfn>response</x:dfn>
    353344   messages, each beginning with a status line that
    389380<x:span anchor="exbody">Hello World!
     384<section title="Implementation Diversity" anchor="implementation-diversity">
     386   When considering the design of HTTP, it is easy to fall into a trap of
     387   thinking that all user agents are general-purpose browsers and all origin
     388   servers are large public websites. That is not the case in practice.
     389   Common HTTP user agents include household appliances, stereos, scales,
     390   software/firmware updaters, command-line programs, mobile apps,
     391   and communication devices in a multitude of shapes and sizes.  Likewise,
     392   common HTTP origin servers include home automation units, configurable
     393   networking components, office machines, autonomous robots, news feeds,
     394   traffic cameras, ad selectors, and video delivery platforms.
     397   The term "user agent" does not imply that there is a human user directly
     398   interacting with the software agent at the time of a request. In many
     399   cases, a user agent is installed or configured to run in the background
     400   and save its results for later inspection (or save only a subset of those
     401   results that might be interesting or erroneous). Spiders, for example, are
     402   typically given a start URI and configured to follow certain behavior while
     403   crawling the Web as a hypertext graph.
     406   The implementation diversity of HTTP means that we cannot assume the
     407   user agent can make interactive suggestions to a user or provide adequate
     408   warning for security or privacy options.  In the few cases where this
     409   specification requires reporting of errors to the user, it is acceptable
     410   for such reporting to only be visible in an error console or log file.
     411   Likewise, requirements that an automated action be confirmed by the user
     412   before proceeding can me met via advance configuration choices,
     413   run-time options, or simply not proceeding with the unsafe action.
    1637    HTTP's use of Content-Length is significantly different from how it is
    1638    used in MIME, where it is an optional field used only within the
    1639    "message/external-body" media-type.
    1640 </t>
    1641 <t>
    16421661   Any Content-Length field value greater than or equal to zero is valid.
    16431662   Since there is no predefined limit to the length of an HTTP payload,
    16581677   length.
     1680  <t>
     1681   &Note; HTTP's use of Content-Length for message framing differs
     1682   significantly from the same field's use in MIME, where it is an optional
     1683   field used only within the "message/external-body" media-type.
     1684  </t>
Note: See TracChangeset for help on using the changeset viewer.