Re: [Tools-discuss] Asynchronous submission

Jennifer Richards <> Tue, 30 May 2023 16:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A4A7DC1519B6 for <>; Tue, 30 May 2023 09:22:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pambNz9fZXCq for <>; Tue, 30 May 2023 09:22:12 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::f34]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 52503C151539 for <>; Tue, 30 May 2023 09:22:12 -0700 (PDT)
Received: by with SMTP id 6a1803df08f44-6260de7cfaeso21102096d6.2 for <>; Tue, 30 May 2023 09:22:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1685463731; x=1688055731; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=k7j2FknDmJEbtmxsLhZ98nIQ7fOgk+EEe+QrzaaWhW4=; b=WCJvD+3/D+lgTCep3u1YlAX6jEAP+3ylnmbSC8KXxFhXNGWBfm3Arb8q7G48qQDCJX +HB+9HPiaikpeAwGo8P0UFoTy+vaagCZHk4FqvrTE+gvPGhBOkj2QUvVBHozwC30skAu T7dytYGWJnKcKPnG/Q/pwRZxxI8RY1+6BlRlfWU1Prho4dYhJaw3/7QmIfuy66iwcR5v mFDAx9nl0e6Beb1Jt+MIbaN3Sh6pD7JCHjpD9h9zBJ5zAbgZxPpa29olLYTG6IkOrFGl 1X2oBGve9LzlOfC5AwTQdndtd0UmGFzWVuIN8FNX2E353eZSqbDu2sHOOB3sHGc0vVSk 6I5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1685463731; x=1688055731; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=k7j2FknDmJEbtmxsLhZ98nIQ7fOgk+EEe+QrzaaWhW4=; b=i1q1lD5m0gYeYuNGMrXfFHoaSnh2Vl/A3m1949NNI0Efyz9K6najA9Nn5kq6vJoaLR 6kaceZo0P3ZIABEYpkchewc0vJA+W0eo4LjmEFluaEQgQQpi4i+HveX7bELfmEHjHBe6 i34g1biQw0tjzif05VfpkC4DLoBImiHfmDhrQFYTtwoRrgo5iU1eEVd0nEWWYNzA2Als 9/cI9Rpa8dIQK+rpufEClaOBwWQUZbYTjZ+xpGhGBGdcATjy5qz3CykPAAj5K8ankq2K DmFVls7uR1vhqS7gZGZ19ymZz+wYSsn/b0E07+//VZ4yQmIa9N7VqxRAyL1wk9mI/5os Bkag==
X-Gm-Message-State: AC+VfDwmwfi6g8uAA56OGvb2azFEZedeQ4E4va8gC+nhLFvH6RcZf4rt XNAWbD1DFllDQ3jSs1ZPbtyRThBKzlkLJKKNzXhOWmur
X-Google-Smtp-Source: ACHHUZ58swG20OtfYoGxmH1JfQv8JSw4SeZ7fX1C1LZVSaniISqzSi4p7f3h9FCdkAiODgWr9BmhhA==
X-Received: by 2002:a05:6214:27e2:b0:621:700b:f9ef with SMTP id jt2-20020a05621427e200b00621700bf9efmr2882966qvb.15.1685463730919; Tue, 30 May 2023 09:22:10 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id ea3-20020ad458a3000000b0062119a7a7a3sm4754774qvb.4.2023. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 May 2023 09:22:10 -0700 (PDT)
Message-ID: <>
Date: Tue, 30 May 2023 13:22:09 -0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.11.2
Content-Language: en-CA
To: Carsten Bormann <>
References: <> <> <>
From: Jennifer Richards <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Tools-discuss] Asynchronous submission
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Tools Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 30 May 2023 16:22:16 -0000

On 2023-05-30 11:48 a.m., Carsten Bormann wrote:
> If the concern is that the server might be loaded by the refreshes, the refresh wait should really be extended based on the server queue size, not on the status of the draft’s processing.

We don't currently have queue details available where they'd be needed 
to make this happen. I am also not sure that there's much of a win vs a 
simple backoff. After the first 10-15 seconds of waiting, it's already a 
"long" wait and the perceived impact of an extra 15 seconds (or 
whatever) after the draft was actually processed is likely to be minimal.

The motivation for using status API is to do better than the current 
method of reloading the entire page before there's an update. The reload 
causes visual glitches on at least some browsers that'd be nice to 
avoid. (A rewrite of the page to be properly dynamic is planned, right 
now just trying to make things usable enough until we get to that.)