Date: Tue, 02 Apr 2019 21:36:14 +0000 (UTC)
From: Alessandro Ghedini <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4abdb16c53f6f39ebfed207476813c33cba4530a8ea92cf0000000118bb97ce92a169ce1931c3e6@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2529/c479213967@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2529@github.com>
References: <quicwg/base-drafts/pull/2529@github.com>
Subject: Re: [quicwg/base-drafts] Allow not creating QPACK codec streams
 (#2529)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_5ca3d5ced2af3_4f373f91b66d45c030372a";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/5bnYrJzW-rECu9_n2ZQaISp5-CE>

----==_mimepart_5ca3d5ced2af3_4f373f91b66d45c030372a
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

I clarified the "An endpoint MAY avoid creating its own encoder stream" part to be more permissive (which was the intention from the beginning, it was just worded wrong).

Things that might need chaning from the above discussions:
1. Should we be explicit about decoder stream creation delay as suggested by @kazuho? I don't think there's anything preventing that right now though.
2. Regarding the "An endpoint MUST allow its peer to create both encoder and decoder streams", the HTTP draft currently says that "Both clients and servers SHOULD send a value of three or greater for the QUIC transport parameter initial_max_uni_streams" but it doesn't talk about `MAX_STREAMS`, so I guess this would be adding a new restriction. I seem to remember that was the consensus for the discussion in Tokyo, but I may be remembering wrong. Thoughts?

-- 
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/2529#issuecomment-479213967
----==_mimepart_5ca3d5ced2af3_4f373f91b66d45c030372a
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p>I clarified the "An endpoint MAY avoid creating its own encoder stream" =
part to be more permissive (which was the intention from the beginning, it =
was just worded wrong).</p>
<p>Things that might need chaning from the above discussions:</p>
<ol>
<li>Should we be explicit about decoder stream creation delay as suggested =
by <a class=3D"user-mention" data-hovercard-type=3D"user" data-hovercard-ur=
l=3D"/hovercards?user_id=3D41567" data-octo-click=3D"hovercard-link-click" =
data-octo-dimensions=3D"link_type:self" href=3D"https://github.com/kazuho">=
@kazuho</a>? I don't think there's anything preventing that right now thoug=
h.</li>
<li>Regarding the "An endpoint MUST allow its peer to create both encoder a=
nd decoder streams", the HTTP draft currently says that "Both clients and s=
ervers SHOULD send a value of three or greater for the QUIC transport param=
eter initial_max_uni_streams" but it doesn't talk about <code>MAX_STREAMS</=
code>, so I guess this would be adding a new restriction. I seem to remembe=
r that was the consensus for the discussion in Tokyo, but I may be remember=
ing wrong. Thoughts?</li>
</ol>

<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/2529#issuecomment-479213967">view it on GitHub</a>, or <a hre=
f=3D"https://github.com/notifications/unsubscribe-auth/AWbkqxPNUNJ5HXb9IiqV=
cnPDqfeQC-M0ks5vc81OgaJpZM4b78tQ">mute the thread</a>.<img src=3D"https://g=
ithub.com/notifications/beacon/AWbkq5St30b3ZPMVHYifmSTvel6XmHJSks5vc81OgaJp=
ZM4b78tQ.gif" height=3D"1" width=3D"1" alt=3D"" /></p>
<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://gith=
ub.githubassets.com/images/email/message_cards/header.png","avatar_image_ur=
l":"https://github.githubassets.com/images/email/message_cards/avatar.png",=
"action":{"name":"Open in GitHub","url":"https://github.com/quicwg/base-dra=
fts"}},"updates":{"snippets":[{"icon":"PERSON","message":"@ghedo in #2529: =
I clarified the \"An endpoint MAY avoid creating its own encoder stream\" p=
art to be more permissive (which was the intention from the beginning, it w=
as just worded wrong).\r\n\r\nThings that might need chaning from the above=
 discussions:\r\n1. Should we be explicit about decoder stream creation del=
ay as suggested by @kazuho? I don't think there's anything preventing that =
right now though.\r\n2. Regarding the \"An endpoint MUST allow its peer to =
create both encoder and decoder streams\", the HTTP draft currently says th=
at \"Both clients and servers SHOULD send a value of three or greater for t=
he QUIC transport parameter initial_max_uni_streams\" but it doesn't talk a=
bout `MAX_STREAMS`, so I guess this would be adding a new restriction. I se=
em to remember that was the consensus for the discussion in Tokyo, but I ma=
y be remembering wrong. Thoughts?"}],"action":{"name":"View Pull Request","=
url":"https://github.com/quicwg/base-drafts/pull/2529#issuecomment-47921396=
7"}}}</script>
<script type=3D"application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/quicwg/base-drafts/pull/2529#issuecomment-479=
213967",
"url": "https://github.com/quicwg/base-drafts/pull/2529#issuecomment-479213=
967",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>=

----==_mimepart_5ca3d5ced2af3_4f373f91b66d45c030372a--