Date: Wed, 04 Apr 2018 13:17:35 +0000 (UTC)
From: ekr <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4ab23ada81335bfa4535b8d6020c663dcedf779bad192cf0000000116dc926f92a169ce115ea54e@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/1068/c378596154@github.com>
In-Reply-To: <quicwg/base-drafts/pull/1068@github.com>
References: <quicwg/base-drafts/pull/1068@github.com>
Subject: Re: [quicwg/base-drafts] Extension frames (#1068)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_5ac4d06f508f4_53b22ad7a106eed0102287";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/B3TvJ3K_NeombpD0GOgN-SOkJRU>

----==_mimepart_5ac4d06f508f4_53b22ad7a106eed0102287
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

I'm not a huge fan of this design, for two reasons:

1. The mapping seems complex, and really only serves to save a few bytes. As I think I observed in Melbourne, given that QUIC already has variable length integers and we are only presently defining a very small number of frame types, why don't simply declare the frame type to be a varint. Then we will have an unlimited number of extension frame types, and we can assign low (hence short) frame types to anything that becomes a standard (thus not paying any bytes there) and non-standard frame types can just use longer numbers, without any mapping.

2. Because this design couples frame type negotiation and its code point, that means that if you want to negotiate parameters for the use of extension frames, you then need a separate transport parameters negotiation for *that*

I'm certainly sympathetic for people's desire to not have a bunch of transport parameters messages whose only purpose is to signal "I support feature X" (this is kind of an annoyance in TLS) but I think that can actually be dealt with in a cleaner way: Simply have TP contain a list of numbers (varints) which define the features that you are advertising. This wouldn't be the only way to do things and so if you had a feature that needed negotiation, you could still do it that way, but simple features could be indicated this way.




-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1068#issuecomment-378596154
----==_mimepart_5ac4d06f508f4_53b22ad7a106eed0102287
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p>I'm not a huge fan of this design, for two reasons:</p>
<ol>
<li>
<p>The mapping seems complex, and really only serves to save a few bytes. A=
s I think I observed in Melbourne, given that QUIC already has variable len=
gth integers and we are only presently defining a very small number of fram=
e types, why don't simply declare the frame type to be a varint. Then we wi=
ll have an unlimited number of extension frame types, and we can assign low=
 (hence short) frame types to anything that becomes a standard (thus not pa=
ying any bytes there) and non-standard frame types can just use longer numb=
ers, without any mapping.</p>
</li>
<li>
<p>Because this design couples frame type negotiation and its code point, t=
hat means that if you want to negotiate parameters for the use of extension=
 frames, you then need a separate transport parameters negotiation for <em>=
that</em></p>
</li>
</ol>
<p>I'm certainly sympathetic for people's desire to not have a bunch of tra=
nsport parameters messages whose only purpose is to signal "I support featu=
re X" (this is kind of an annoyance in TLS) but I think that can actually b=
e dealt with in a cleaner way: Simply have TP contain a list of numbers (va=
rints) which define the features that you are advertising. This wouldn't be=
 the only way to do things and so if you had a feature that needed negotiat=
ion, you could still do it that way, but simple features could be indicated=
 this way.</p>

<p style=3D"font-size:small;-webkit-text-size-adjust:none;color:#666;">&mda=
sh;<br />You are receiving this because you are subscribed to this thread.<=
br />Reply to this email directly, <a href=3D"https://github.com/quicwg/bas=
e-drafts/pull/1068#issuecomment-378596154">view it on GitHub</a>, or <a hre=
f=3D"https://github.com/notifications/unsubscribe-auth/AWbkq3pjBk3O6Sg3d9B-=
Pe_GIskx1VBOks5tlMfvgaJpZM4RsLKs">mute the thread</a>.<img src=3D"https://g=
ithub.com/notifications/beacon/AWbkqxGFi5AMNsj09MdZpH7erv4tmqrbks5tlMfvgaJp=
ZM4RsLKs.gif" height=3D"1" width=3D"1" alt=3D"" /></p>
<div itemscope itemtype=3D"http://schema.org/EmailMessage">
<div itemprop=3D"action" itemscope itemtype=3D"http://schema.org/ViewAction=
">
  <link itemprop=3D"url" href=3D"https://github.com/quicwg/base-drafts/pull=
/1068#issuecomment-378596154"></link>
  <meta itemprop=3D"name" content=3D"View Pull Request"></meta>
</div>
<meta itemprop=3D"description" content=3D"View this Pull Request on GitHub"=
></meta>
</div>

<script type=3D"application/json" data-scope=3D"inboxmarkup">{"api_version"=
:"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"Gi=
tHub"},"entity":{"external_key":"github/quicwg/base-drafts","title":"quicwg=
/base-drafts","subtitle":"GitHub repository","main_image_url":"https://clou=
d.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290=
892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/asset=
s/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name=
":"Open in GitHub","url":"https://github.com/quicwg/base-drafts"}},"updates=
":{"snippets":[{"icon":"PERSON","message":"@ekr in #1068: I'm not a huge fa=
n of this design, for two reasons:\r\n\r\n1. The mapping seems complex, and=
 really only serves to save a few bytes. As I think I observed in Melbourne=
, given that QUIC already has variable length integers and we are only pres=
ently defining a very small number of frame types, why don't simply declare=
 the frame type to be a varint. Then we will have an unlimited number of ex=
tension frame types, and we can assign low (hence short) frame types to any=
thing that becomes a standard (thus not paying any bytes there) and non-sta=
ndard frame types can just use longer numbers, without any mapping.\r\n\r\n=
2. Because this design couples frame type negotiation and its code point, t=
hat means that if you want to negotiate parameters for the use of extension=
 frames, you then need a separate transport parameters negotiation for *tha=
t*\r\n\r\nI'm certainly sympathetic for people's desire to not have a bunch=
 of transport parameters messages whose only purpose is to signal \"I suppo=
rt feature X\" (this is kind of an annoyance in TLS) but I think that can a=
ctually be dealt with in a cleaner way: Simply have TP contain a list of nu=
mbers (varints) which define the features that you are advertising. This wo=
uldn't be the only way to do things and so if you had a feature that needed=
 negotiation, you could still do it that way, but simple features could be =
indicated this way.\r\n\r\n\r\n"}],"action":{"name":"View Pull Request","ur=
l":"https://github.com/quicwg/base-drafts/pull/1068#issuecomment-378596154"=
}}}</script>=

----==_mimepart_5ac4d06f508f4_53b22ad7a106eed0102287--