Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Reserved frame types and the other reserved frame types #2997

Merged
merged 2 commits into from
Sep 6, 2019
Merged

Reserved frame types and the other reserved frame types #2997

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
7e5dce1
Additional clarity on reserved frame types and the other reserved fra…
MikeBishop Aug 28, 2019
6235e8c
Reserved anchor
MikeBishop Sep 6, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 17 additions & 9 deletions draft-ietf-quic-http.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -422,7 +422,7 @@ PUSH_PROMISE frames are not part of the response; see {{server-push}} for more
details.

Frames of unknown types ({{extensions}}), including reserved frames
({{frame-grease}}) MAY be sent on a request or push stream before, after, or
({{frame-reserved}}) MAY be sent on a request or push stream before, after, or
interleaved with other frames described in this section.

The HEADERS and PUSH_PROMISE frames might reference updates to the QPACK dynamic
Expand Down Expand Up @@ -890,7 +890,7 @@ A sender can close or reset a unidirectional stream unless otherwise specified.
A receiver MUST tolerate unidirectional streams being closed or reset prior to
the reception of the unidirectional stream header.

### Control Streams
### Control Streams

A control stream is indicated by a stream type of `0x00`. Data on this stream
consists of HTTP/3 frames, as defined in {{frames}}.
Expand Down Expand Up @@ -974,6 +974,7 @@ comparison between HTTP/2 and HTTP/3 frames is provided in {{h2-frames}}.
| GOAWAY | Yes | No | No | {{frame-goaway}} |
| MAX_PUSH_ID | Yes | No | No | {{frame-max-push-id}} |
| DUPLICATE_PUSH | No | Yes | No | {{frame-duplicate-push}} |
| Reserved | Yes | Yes | Yes | {{frame-reserved} |
{: #stream-frame-mapping title="HTTP/3 frames and stream type overview"}

Certain frames can only occur as the first frame of a particular stream type;
Expand Down Expand Up @@ -1373,18 +1374,22 @@ uses a Push ID that they have since consumed and discarded are forced to ignore
the DUPLICATE_PUSH.


### Reserved Frame Types {#frame-grease}
### Reserved Frame Types {#frame-reserved}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that you're discussing H2 reserved types in this section, maybe it should be {#frame-reserved}?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps, but those anchors don't appear in the final doc, so I care less. Still, there are only three references, so it's a minor change.

Frame types of the format `0x1f * N + 0x21` for integer values of N are reserved
to exercise the requirement that unknown types be ignored ({{extensions}}).
These frames have no semantics, and can be sent when application-layer padding
is desired. They MAY also be sent on connections where no data is currently
being transferred. Endpoints MUST NOT consider these frames to have any meaning
upon receipt.
These frames have no semantics, and can be sent on any open stream when
application-layer padding is desired. They MAY also be sent on connections where
no data is currently being transferred. Endpoints MUST NOT consider these frames
to have any meaning upon receipt.

The payload and length of the frames are selected in any manner the
implementation chooses.

Frame types which were used in HTTP/2 where there is no corresponding HTTP/3
frame have also been reserved ({{iana-frames}}). These frame types MUST NOT be
sent, and receipt MAY be treated as an error of type HTTP_UNEXPECTED_FRAME.


# Error Handling {#errors}

Expand Down Expand Up @@ -1486,7 +1491,10 @@ Implementations MUST ignore unknown or unsupported values in all extensible
protocol elements. Implementations MUST discard frames and unidirectional
streams that have unknown or unsupported types. This means that any of these
extension points can be safely used by extensions without prior arrangement or
negotiation.
negotiation. However, where a known frame type is required to be in a specific
location, such as the SETTINGS frame as the first frame of the control stream
(see {{control-streams}}), an unknown frame type does not satisfy that
requirement and SHOULD be treated as an error.

Extensions that could change the semantics of existing protocol components MUST
be negotiated before being used. For example, an extension that changes the
Expand Down Expand Up @@ -1516,7 +1524,7 @@ security considerations of {{!ALTSVC}} also apply.
Where HTTP/2 employs PADDING frames and Padding fields in other frames to make a
connection more resistant to traffic analysis, HTTP/3 can either rely on
transport-layer padding or employ the reserved frame and stream types discussed
in {{frame-grease}} and {{stream-grease}}. These methods of padding produce
in {{frame-reserved}} and {{stream-grease}}. These methods of padding produce
different results in terms of the granularity of padding, the effect of packet
loss and recovery, and how an implementation might control padding.

Expand Down