One document matched: draft-snell-http-prefer-01.xml

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY rfc2616 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml'>
  <!ENTITY rfc4918 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4918.xml'>
  <!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
  <!ENTITY rfc3864 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3864.xml'>
]>
<?rfc toc="yes"?>
<?rfc strict="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<rfc ipr="full3978" docName="draft-snell-http-prefer-01">
  <front>
    <title abbrev="HTTP Prefer">
      Prefer Header for HTTP
    </title>

    <author initials="J.M." surname="Snell" fullname="James M Snell">
      <organization></organization>
      <address>
        <postal>
          <street></street>
          <city></city> <region></region> <code></code>
          <country></country>
        </postal>
        <phone></phone>
        <email>jasnell@gmail.com</email>
        <uri>http://www.snellspace.com</uri>
      </address>
    </author>
    
    <date month="December" year="2007" />

    <area>Applications</area>
    <workgroup>Individual Submission</workgroup>
    <keyword>I-D</keyword>
    <keyword>http</keyword>
    <keyword>prefer</keyword>

    <abstract>
      <t>This specification defines a new HTTP header that can be
      used by a client to request that certain behaviors be implemented
      by a server while processing a request.</t>
    </abstract>

  </front>
  
  <middle>
    <section anchor="intro" title="Introduction">

      <t>This specification defines a new HTTP header that can be
      used by a client to request that certain behaviors be implemented
      by a server while processing a request.</t>
      
      <t>In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 
      "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 
      are to be  interpreted as described in <xref target="RFC2119" />.</t>

    </section>
        
    <section title="The Prefer Request Header">
    
      <t>The Prefer request-header is used to indicate that particular 
      server behaviors are preferred, but not required, by the client.  Prefer
      is similar in nature to the Expect header defined by <xref target="RFC2616" /> 
      with the exception that servers are allowed to ignore a clients stated 
      preferences.</t>
      
      <figure><artwork>
  Prefer       =  "Prefer" ":" 1#preference

  preference   =  "return-no-content" | preference-extension
  preference-extension =  token [ "=" ( token | quoted-string )
                          *prefer-params ]
  prefer-params =  ";" token [ "=" ( token | quoted-string ) ]
      </artwork></figure>
  
      <t>This header is defined with an extensible syntax to allow for future
      extensions. A server that does not understand or is unable to comply with 
      any of the preference values in the Prefer field of a request MUST ignore 
      those values and MUST NOT stop processing or signal an error.</t>
      
      <t>Comparison of preference values is case-insensitive for unquoted 
      tokens and is case-sensitive for quoted-string preference-extensions.</t>
      
      <t>The Prefer mechanism is hop-by-hop: that is, an HTTP proxy MAY 
      choose to honor a preference even if the origin server does not. However,
      the Prefer request-header itself is end-to-end; it MUST be forwarded if 
      the request is forwarded.</t>
      
    </section>
     
    <section title="The "return-no-content" Preference">
      
      <t>The "return-no-content" token indicates that the client prefers
      that the server not include an entity in the response to a successful request.
      Typically, such responses would use the 204 No Content status code as 
      defined in Section 10.2.5 of <xref target="RFC2616" />, but other status
      codes can be used as appropriate.</t>
      
    </section>
      
    <section title="IANA Considerations">

      <t>The 'Prefer' request header should be added to the permanent 
      registry (see <xref target="RFC3864" />).</t>
        
    <t><figure><artwork>
    Header field name: Prefer
    
    Applicable Protocol: HTTP
    
    Status: standard
    
    Author/Change controller: IETF
    
    Specification document: this specification
    </artwork></figure></t>
      
    </section>
    
  
    <section title="Security Considerations">
    
      <t>Specific preferences requested by a client can introduce security 
      considerations and concerns beyond those discussed in <xref target="RFC2616" />.
      Implementors must refer to the specifications and descriptions of those
      preferences to determine the security considerations relevant to each.</t>
    
    </section>
    
  </middle>
  
  <back>

    <references title="Normative References">
      &rfc2119;
      &rfc2616;
      &rfc3864;
    </references>
    
    <section title="Acknowledgements">
      <t>The author greatfully acknowledges the input from the IETF HTTP
      mailing list on the development of this document.</t>

    </section>
    <section title="Changes">
      <t>TODO</t>            
    </section>
      
    <section title="Notes to RFC Editor">
      <t>The RFC Editor should remove this section and the Changes section.</t>
    </section>
    
    <section title="Editorial Notes">
      <t>We need to determine how new preference codes are created/registered</t>
    </section>
    
  </back>

</rfc>