One document matched: draft-snell-httpbis-ext-frames-01.xml

<?xml version="1.0"?> 
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ 
  <!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
  <!ENTITY rfc6265 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6265.xml'>
]>
<?rfc toc="yes"?> 
<?rfc strict="yes"?> 
<?rfc symrefs="yes" ?> 
<?rfc sortrefs="yes"?> 
<?rfc compact="yes"?> 
<rfc category="info" ipr="trust200811" docName="draft-snell-httpbis-ext-frames-01"> 
  <front> 
    <title abbrev="Extension Frame Types for HTTP 2.0"> 
      HTTP/2.0 Discussion: Extension Frame Types
    </title> 
 
    <author initials="J.M." surname="Snell" fullname="James M Snell"> 
      <address> 
        <email>jasnell@gmail.com</email> 
      </address> 
    </author> 
    
    <date month="November" year="2013" /> 
 
    <keyword>I-D</keyword> 
    <keyword>http</keyword>
    <keyword>spdy</keyword>
 
    <abstract> 
      <t>This memo describes the structure and use cases for a handful of
      "extension" frames types for HTTP 2.0. The purpose of this document
      is to add to the overall discussion around the development of HTTP 2.0
      by describing ways in which the framing layer can be leveraged and 
      extended.</t> 
    </abstract> 
 
  </front> 
  
  <middle> 

    <section title="Overview">
      
      <t>
        HTTP/2.0 frame types are currently identified using an unstructured
        8-bit identifier. The current draft specification currently defines
        10 standard frame types and establishes an IANA registry to track 
        and manage new "extension" frame types.
      </t>
      
      <t>
        This memo proposes a handful of changes to the current specification
        to better support the definition and use of extension frame types.
      </t>
      
    </section>
      
      <section title="Structured Frame Type Identifier">
      
        <t>
          First, it is proposed that the frame type identifier be restructured
          such that if the most significant bit is set, the frame type is
          understood to be "end-to-end".
        </t>
      
        <t>
          When an intermediary encounters an unknown or unsupported end-to-end
          frame type, and the stream ID is not zero (0), it MUST either terminate 
          the stream with an RST_STREAM or pass the frame through untouched and 
          unmodified. If the stream ID is zero, the intermediary SHOULD ignore
          the frame but MAY choose to signal a connection error.
        </t>
      
        <t>
          Additionally, end-to-end frame types are always subject to HTTP/2.0
          flow control mechanisms. 
        </t>
      
        <t>
          If the most significant bit in the frame type identifier is not 
          set, the frame type is understood to be "hop-by-hop".
        </t>
      
        <t>
          When an endpoint encounters unknown or unsupported hop-by-hop
          frame types, the frame SHOULD be ignored. However, endpoints MAY
          choose to signal either a stream or connection error.
        </t>
      
        <texttable>
          <ttcol>Type Range</ttcol>
          <ttcol>Handling (Stream = 0)</ttcol>
          <ttcol>Handling (Stream > 0)</ttcol>
          <ttcol>Flow Controlled</ttcol>
        
          <c>0x00-7F</c>
          <c>SHOULD Ignore</c>
          <c>Stream Error</c>
          <c>No</c>
        
          <c>0x80-FF</c>
          <c>SHOULD Ignore</c>
          <c>MUST Forward or Error</c>
          <c>Yes</c>
        
        </texttable>
      
      </section>
      
      <section title="Update DATA Frame Type Identifier">
        
        <t>
          To reflect the proposed change to the type identifier structure,
          it is further proposed that the type identifier of the existing
          DATA frame be changed to 0x80.
        </t>
        
      </section>
      
      <section title="Reserved Private-Use Frame Type Range">
        
        <t>
          The upper range of each frame type segment (0x6B-0x7F and 0xEB-FF)
          would be reserved as "Private Use" and cannot be assigned as part
          of the IANA registry. 
        </t>
        
      </section>
      
      <section title="New INFO hop-by-hop Frame Type">
        
        <t>
          It is further proposed that a new "INFO" hop-by-hop frame 
          type (0x0B) be introduced. The purpose of the INFO frame 
          is to allow endpoints to exchange additional "ok to ignore"
          "Information Records" associated with a connection or stream.
        </t>
        
        <t>
          The INFO frame contains a sub-header with the following 
          format:
        </t>
        
        <figure><artwork><![CDATA[
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |        Info Group ID (16)     |       Info Item ID (16)       |
  +---------------------------------------------------------------+
  |                       Info-specific payload                 ...
  +---------------------------------------------------------------+
        ]]></artwork></figure>

        <t>
          Each "Information Record" type is identified by a 16-bit 
          "Group" ID followed by a 16-bit "Group Local" ID. The 
          remaining format of the information record depends entirely
          on the information record type. The Group ID 0x0 is reserved 
          for use by Standards Track RFC's.
        </t>
        
        <t>
          INFO frames are always hop-by-hop. If an endpoint encounters
          an INFO frame that uses an unrecognized information record type 
          identifier, the endpoint MUST simply ignore the frame. Processing 
          of an INFO frame MUST never modify the state of the connection 
          or stream.
        </t>
        
        <t>
          INFO frames can be sent on any stream in the "open" or "half-closed 
          (remote)" states, or can be sent on stream ID 0 at any time.
        </t>
        
        <t>
          Note: The INFO frame is modeled after the structure for 
          "Extension Frames" proposed by <xref target="BishopExtensions" />.
        </t>
        
      </section>
              
  </middle> 

  <back>
    <references title="Normative References"> 
      &rfc2119;
    </references>
    
    <references title="Informational References">
      
      <reference anchor="BishopExtensions">
        <front>
          <title>Extension Frames in HTTP/2.0</title>
          <author initials="M." surname="Bishop" fullname="Mike Bishop"/>
          <date year="2013" month="November"/>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-bishop-http2-extension-frames-00" />
      </reference>
      
    </references>
    
  </back>
</rfc>