MIME-Version: 1.0
References: <CACdeXiLEnvmqmxSgXbvAwEo0rgm-F59RL2sk0Ugu6PNuiDkfsw@mail.gmail.com>
In-Reply-To: <CACdeXiLEnvmqmxSgXbvAwEo0rgm-F59RL2sk0Ugu6PNuiDkfsw@mail.gmail.com>
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Fri, 27 Sep 2019 14:44:22 +0100
Message-ID: <CALGR9obGGx6OZoKXi73NNRJfNnnazma5=F79Y1D94Lxb9VGEew@mail.gmail.com>
Subject: Re: Add application parameters to QUIC handshake and use it for H3
 SETTINGS
To: Nick Harper <nharper=40google.com@dmarc.ietf.org>
Cc: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000203fb30593891605"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/FPUP7tu3msg2FPR9STdP5lOdUSU>
Precedence: list

--000000000000203fb30593891605
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Sep 27, 2019 at 1:52 AM Nick Harper <nharper=3D
40google.com@dmarc.ietf.org> wrote:

> This also provides opportunities for future features. Since the
> exchange of SETTINGS occurs before application data, a new feature
> doesn=E2=80=99t need to be specified in a way to provide an upgrade path =
from
> =E2=80=9Cvanilla=E2=80=9D H3 to something including this feature, and ins=
tead be
> guaranteed that the new feature can be used for the entire connection.
>
> Without application parameters, each application that needs to
> advertise or negotiate application settings needs its own mechanism to
> do so. This would result in multiple transport parameters or
> extensions leading to duplication of work and layering violations.
> Applications could instead exchange these settings in application
> data, meaning that each application needs to define the semantics of
> application data received before and after the settings have been
> exchanged, as H3 currently does.
>
>
HTTP/3 defines rules for processing its application parameter messages:
SETTINGS frames MUST NOT contain duplicate settings, a receiver MAY treat
this as a connection error with an application error code.

If SETTINGS were to move to QUIC handshake, would you expect that a
receiver of such a bogus message would generate a CONNECTION_CLOSE of type
0x1d? I'm guessing the checks would take place after ALPN selection had
taken place (at the server).

--000000000000203fb30593891605
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Fri, Sep 27, 2019 at 1:52 AM Nick =
Harper &lt;nharper=3D<a href=3D"mailto:40google.com@dmarc.ietf.org">40googl=
e.com@dmarc.ietf.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex">
This also provides opportunities for future features. Since the<br>
exchange of SETTINGS occurs before application data, a new feature<br>
doesn=E2=80=99t need to be specified in a way to provide an upgrade path fr=
om<br>
=E2=80=9Cvanilla=E2=80=9D H3 to something including this feature, and inste=
ad be<br>
guaranteed that the new feature can be used for the entire connection.<br>
<br>
Without application parameters, each application that needs to<br>
advertise or negotiate application settings needs its own mechanism to<br>
do so. This would result in multiple transport parameters or<br>
extensions leading to duplication of work and layering violations.<br>
Applications could instead exchange these settings in application<br>
data, meaning that each application needs to define the semantics of<br>
application data received before and after the settings have been<br>
exchanged, as H3 currently does.<br>
<br></blockquote><div><br></div><div>HTTP/3 defines rules for processing it=
s application parameter messages: SETTINGS frames MUST NOT contain duplicat=
e settings, a receiver MAY treat this as a connection error with an applica=
tion error code.</div><div><br></div><div>If SETTINGS were to move to QUIC =
handshake, would you expect that a receiver of such a bogus message would g=
enerate a CONNECTION_CLOSE of type 0x1d? I&#39;m guessing the checks would =
take place after ALPN selection had taken place (at the server). </div></di=
v></div>

--000000000000203fb30593891605--