Ignore:
Timestamp:
19/01/14 09:51:24 (6 years ago)
Author:
fielding@…
Message:

(editorial) remove usage of We; move definition of transforming proxy into the only section that uses it, removing the need for non-transforming proxy to be defined; clean up redundant paragraphs in description of cache-control extensions; see #531

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p2-semantics.html

    r2562 r2563  
    448448  }
    449449  @bottom-center {
    450        content: "Expires July 22, 2014";
     450       content: "Expires July 23, 2014";
    451451  }
    452452  @bottom-right {
     
    493493      <meta name="dct.creator" content="Reschke, J. F.">
    494494      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    495       <meta name="dct.issued" scheme="ISO8601" content="2014-01-18">
     495      <meta name="dct.issued" scheme="ISO8601" content="2014-01-19">
    496496      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    497497      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.">
     
    521521            <tr>
    522522               <td class="left">Intended status: Standards Track</td>
    523                <td class="right">January 18, 2014</td>
     523               <td class="right">January 19, 2014</td>
    524524            </tr>
    525525            <tr>
    526                <td class="left">Expires: July 22, 2014</td>
     526               <td class="left">Expires: July 23, 2014</td>
    527527               <td class="right"></td>
    528528            </tr>
     
    553553            in progress”.
    554554         </p>
    555          <p>This Internet-Draft will expire on July 22, 2014.</p>
     555         <p>This Internet-Draft will expire on July 23, 2014.</p>
    556556      </div>
    557557      <div id="rfc.copyrightnotice">
     
    848848         <div id="rfc.iref.s.1"></div>
    849849         <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a href="#representations">Representations</a></h1>
    850          <p id="rfc.section.3.p.1">If we consider that a resource could be anything, and that the uniform interface provided by HTTP is similar to a window through
     850         <p id="rfc.section.3.p.1">Considering that a resource could be anything, and that the uniform interface provided by HTTP is similar to a window through
    851851            which one can observe and act upon such a thing only through the communication of messages to some independent actor on the
    852             other side, then we need an abstraction to represent ("take the place of") the current or desired state of that thing in our
    853             communications. We call that abstraction a representation <a href="#REST" id="rfc.xref.REST.1"><cite title="Architectural Styles and the Design of Network-based Software Architectures">[REST]</cite></a>.
     852            other side, an abstraction is needed to represent ("take the place of") the current or desired state of that thing in our
     853            communications. That abstraction is called a representation <a href="#REST" id="rfc.xref.REST.1"><cite title="Architectural Styles and the Design of Network-based Software Architectures">[REST]</cite></a>.
    854854         </p>
    855855         <p id="rfc.section.3.p.2">For the purposes of HTTP, a "<dfn>representation</dfn>" is information that is intended to reflect a past, current, or desired state of a given resource, in a format that can be
     
    859859         <p id="rfc.section.3.p.3">An origin server might be provided with, or capable of generating, multiple representations that are each intended to reflect
    860860            the current state of a <a href="#resources" class="smpl">target resource</a>. In such cases, some algorithm is used by the origin server to select one of those representations as most applicable to
    861             a given request, usually based on <a href="#content.negotiation" class="smpl">content negotiation</a>. We refer to that one representation as the "<dfn>selected representation</dfn>" and use its particular data and metadata for evaluating conditional requests <a href="#Part4" id="rfc.xref.Part4.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a> and constructing the payload for <a href="#status.200" class="smpl">200 (OK)</a> and <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> responses to GET (<a href="#GET" id="rfc.xref.GET.1" title="GET">Section&nbsp;4.3.1</a>).
     861            a given request, usually based on <a href="#content.negotiation" class="smpl">content negotiation</a>. This "<dfn>selected representation</dfn>" is used to provide the data and metadata for evaluating conditional requests <a href="#Part4" id="rfc.xref.Part4.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a> and constructing the payload for <a href="#status.200" class="smpl">200 (OK)</a> and <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> responses to GET (<a href="#GET" id="rfc.xref.GET.1" title="GET">Section&nbsp;4.3.1</a>).
    862862         </p>
    863863         <div id="representation.metadata">
     
    42134213            <p id="rfc.section.9.6.p.2">There are a number of request header fields that might reveal information to servers that is sufficiently unique to enable
    42144214               fingerprinting. The <a href="#header.from" class="smpl">From</a> header field is the most obvious, though it is expected that From will only be sent when self-identification is desired by
    4215                the user. Likewise, Cookie header fields are deliberately designed to enable re-identification, so we can assume that fingerprinting
    4216                concerns only apply to situations where cookies are disabled or restricted by the user agent's configuration.
     4215               the user. Likewise, Cookie header fields are deliberately designed to enable re-identification, so fingerprinting concerns
     4216               only apply to situations where cookies are disabled or restricted by the user agent's configuration.
    42174217            </p>
    42184218            <p id="rfc.section.9.6.p.3">The <a href="#header.user-agent" class="smpl">User-Agent</a> header field might contain enough information to uniquely identify a specific device, usually when combined with other characteristics,
Note: See TracChangeset for help on using the changeset viewer.