Jan 11, 2008, 9:09:10 PM (12 years ago)

editorial: make introductions more active and consistent

1 edited


  • draft-ietf-httpbis/latest/p4-conditional.xml

    r160 r163  
    1616  <!ENTITY ID-YEAR "2008">
    1717  <!ENTITY messaging                  "<xref target='Part1' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     18  <!ENTITY caching                    "<xref target='Part6' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1819  <!ENTITY header-if-range            "<xref target='Part5' x:rel='#header.if-range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1920  <!ENTITY header-range               "<xref target='Part5' x:rel='#header.range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    208209<section title="Introduction" anchor="introduction">
    210    This document defines aspects of HTTP related to conditional
    211    request messages based on time stamps and entity-tags.  Right now it
    212    only includes the extracted relevant sections of <xref target="RFC2616">RFC 2616</xref>
    213    with only minor changes.  This introduction will be revised in the next draft.
     211   This document defines HTTP/1.1 response metadata for indicating potential
     212   changes to payload content, including modification time stamps and opaque
     213   entity-tags, and the HTTP conditional request mechanisms that allow
     214   preconditions to be placed on a request method.  Conditional GET requests
     215   allow for efficient cache updates.  Other conditional request methods are
     216   used to protect against overwriting or misunderstanding the state of a
     217   resource that has been changed unbeknownst to the requesting client.
     220   This document is currently disorganized in order to minimize the changes
     221   between drafts and enable reviewers to see the smaller errata changes.
     222   The next draft will reorganize the sections to better reflect the content.
     223   In particular, the sections on resource metadata will be discussed first
     224   and then followed by each conditional request-header, concluding with a
     225   definition of precedence and the expectation of ordering strong validator
     226   checks before weak validator checks.  It is likely that more content from
     227   &caching; will migrate to this part, where appropriate.
     228   The current mess reflects how widely dispersed these topics and associated
     229   requirements had become in <xref target="RFC2616"/>.
Note: See TracChangeset for help on using the changeset viewer.