From ba923b3bd0545aa6ebadf5fd5de9c75b6aec5acf Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Thu, 5 Jul 2018 11:08:35 -0700 Subject: [PATCH 1/2] Add extensibility section --- draft-ietf-quic-http.md | 38 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 321f2c7c26..4d516ada5e 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -1197,6 +1197,44 @@ HTTP_MALFORMED_FRAME (0x01XX): be indicated with the code (0x10D). +# Extensions to HTTP/QUIC + +HTTP/QUIC permits extension of the protocol. Within the limitations described +in this section, protocol extensions can be used to provide additional services +or alter any aspect of the protocol. Extensions are effective only within the +scope of a single HTTP/QUIC connection. + +This applies to the protocol elements defined in this document. This does not +affect the existing options for extending HTTP, such as defining new methods, +status codes, or header fields. + +Extensions are permitted to use new frame types ({{frames}}), new settings +({{settings-parameters}}), new error codes ({{errors}}), or new unidirectional +stream types ({{unidirectional-streams}}). Registries are established for +managing these extension points: frame types ({{iana-frames}}), settings +({{iana-settings}}), error codes ({{iana-error-codes}}), and stream types +({{iana-stream-types}}). + +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. + +Extensions that could change the semantics of existing protocol components MUST +be negotiated before being used. For example, an extension that changes the +layout of the HEADERS frame cannot be used until the peer has given a positive +signal that this is acceptable. In this case, it could also be necessary to +coordinate when the revised layout comes into effect. + +This document doesn't mandate a specific method for negotiating the use of an +extension but notes that a setting ({{settings-parameters}}) could be used for +that purpose. If both peers set a value that indicates willingness to use the +extension, then the extension can be used. If a setting is used for extension +negotiation, the initial value MUST be defined in such a fashion that the +extension is initially disabled. + + # Considerations for Transitioning from HTTP/2 HTTP/QUIC is strongly informed by HTTP/2, and bears many similarities. This From b60e838b2dc5a8172e3163bf44ab06c0b7612720 Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Fri, 6 Jul 2018 16:48:32 -0700 Subject: [PATCH 2/2] Default, not initial --- draft-ietf-quic-http.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 4d516ada5e..691f22b815 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -1231,8 +1231,8 @@ This document doesn't mandate a specific method for negotiating the use of an extension but notes that a setting ({{settings-parameters}}) could be used for that purpose. If both peers set a value that indicates willingness to use the extension, then the extension can be used. If a setting is used for extension -negotiation, the initial value MUST be defined in such a fashion that the -extension is initially disabled. +negotiation, the default value MUST be defined in such a fashion that the +extension is disabled if the setting is omitted. # Considerations for Transitioning from HTTP/2