Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
 by ietfa.amsl.com (Postfix) with ESMTP id AE535131355
 for <quic-issues@ietfa.amsl.com>; Wed, 12 Dec 2018 16:28:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.459
X-Spam-Level: 
X-Spam-Status: No, score=-9.459 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001,
 HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key)
 header.d=github.com
Received: from mail.ietf.org ([4.31.198.44])
 by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id n1CScLSisYAP for <quic-issues@ietfa.amsl.com>;
 Wed, 12 Dec 2018 16:28:29 -0800 (PST)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by ietfa.amsl.com (Postfix) with ESMTPS id D4381130F58
 for <quic-issues@ietf.org>; Wed, 12 Dec 2018 16:28:28 -0800 (PST)
Date: Wed, 12 Dec 2018 16:28:27 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com;
 s=pf2014; t=1544660907;
 bh=i8EioADRFq/i1SL4DK0wFciNuc6F+HxxfOP2hebCk60=;
 h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID:
 List-Archive:List-Post:List-Unsubscribe:From;
 b=jisT45JZfpQ09Mnhwi5DVqgRfN7JWOfhYe1jmBsAir7KTFu36GDByDVFBBf0rDBE7
 mQ8fx1IPivDWQ8UDBOofu0SNRafr8RprYktwCN+Z3qAhJtkvWvDJ5YEhUGlh31SiBS
 4a2WpffeM3FGK9YXBZT4kLoisXSglBZcus4hkMTY=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4aba34442cde8f5be055eb5aa7a674759137126f2f392cf00000001182969ab92a169ce173d8649@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2115/c446796679@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2115@github.com>
References: <quicwg/base-drafts/pull/2115@github.com>
Subject: Re: [quicwg/base-drafts] Clean up text on Maximum Table Size. (#2115)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_5c11a7abbd92a_43c33f9aaeed45bc2889ea";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/RC4_03yfxiG8aNhK0ZA9ccBdyHs>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG
 <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>,
 <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>,
 <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Dec 2018 00:28:31 -0000


----==_mimepart_5c11a7abbd92a_43c33f9aaeed45bc2889ea
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

So I don't think that the amount of *used* space (your A) is that important in the text.  What is most relevant is the amount of space the decoder allows (the setting, your C) and the amount of space the encoder is using (your B).

If we can avoid talking too much about the occupied space, then we might be in a better position.  If we have to, we can talk about "used" or "occupied" space.

I'd like to suggest "maximum table capacity" (C), "table capacity" (B), and "table size" (A).  Would that be better?  I think that avoids the problems you are talking about by using the word "capacity".

-- 
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/2115#issuecomment-446796679
----==_mimepart_5c11a7abbd92a_43c33f9aaeed45bc2889ea
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p>So I don't think that the amount of <em>used</em> space (your A) is th=
at important in the text.  What is most relevant is the amount of space t=
he decoder allows (the setting, your C) and the amount of space the encod=
er is using (your B).</p>
<p>If we can avoid talking too much about the occupied space, then we mig=
ht be in a better position.  If we have to, we can talk about "used" or "=
occupied" space.</p>
<p>I'd like to suggest "maximum table capacity" (C), "table capacity" (B)=
, and "table size" (A).  Would that be better?  I think that avoids the p=
roblems you are talking about by using the word "capacity".</p>

<p style=3D"font-size:small;-webkit-text-size-adjust:none;color:#666;">&m=
dash;<br />You are receiving this because you are subscribed to this thre=
ad.<br />Reply to this email directly, <a href=3D"https://github.com/quic=
wg/base-drafts/pull/2115#issuecomment-446796679">view it on GitHub</a>, o=
r <a href=3D"https://github.com/notifications/unsubscribe-auth/AWbkq6yG0D=
O6o7igmP2mqPWb1ppG_5Vuks5u4Z8rgaJpZM4ZOCa2">mute the thread</a>.<img src=3D=
"https://github.com/notifications/beacon/AWbkq9S5ujwyHtPpcus7JuTeODMboyXC=
ks5u4Z8rgaJpZM4ZOCa2.gif" height=3D"1" width=3D"1" alt=3D"" /></p>
<script type=3D"application/json" data-scope=3D"inboxmarkup">{"api_versio=
n":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name"=
:"GitHub"},"entity":{"external_key":"github/quicwg/base-drafts","title":"=
quicwg/base-drafts","subtitle":"GitHub repository","main_image_url":"http=
s://assets-cdn.github.com/images/email/message_cards/header.png","avatar_=
image_url":"https://assets-cdn.github.com/images/email/message_cards/avat=
ar.png","action":{"name":"Open in GitHub","url":"https://github.com/quicw=
g/base-drafts"}},"updates":{"snippets":[{"icon":"PERSON","message":"@mart=
inthomson in #2115: So I don't think that the amount of *used* space (you=
r A) is that important in the text.  What is most relevant is the amount =
of space the decoder allows (the setting, your C) and the amount of space=
 the encoder is using (your B).\r\n\r\nIf we can avoid talking too much a=
bout the occupied space, then we might be in a better position.  If we ha=
ve to, we can talk about \"used\" or \"occupied\" space.\r\n\r\nI'd like =
to suggest \"maximum table capacity\" (C), \"table capacity\" (B), and \"=
table size\" (A).  Would that be better?  I think that avoids the problem=
s you are talking about by using the word \"capacity\"."}],"action":{"nam=
e":"View Pull Request","url":"https://github.com/quicwg/base-drafts/pull/=
2115#issuecomment-446796679"}}}</script>
<script type=3D"application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/quicwg/base-drafts/pull/2115#issuecomment-4=
46796679",
"url": "https://github.com/quicwg/base-drafts/pull/2115#issuecomment-4467=
96679",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>=

----==_mimepart_5c11a7abbd92a_43c33f9aaeed45bc2889ea--

