Re: [Tools-discuss] How do we diagnose DOI errors?

Martin Thomson <mt@lowentropy.net> Mon, 19 October 2020 06:19 UTC

Return-Path: <mt@lowentropy.net>
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACF863A0EB5 for <tools-discuss@ietfa.amsl.com>; Sun, 18 Oct 2020 23:19:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level:
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=SDkavsyZ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QrG5Z7HI
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 ZGl02mZ0wVL9 for <tools-discuss@ietfa.amsl.com>; Sun, 18 Oct 2020 23:19:56 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A6813A13F9 for <tools-discuss@ietf.org>; Sun, 18 Oct 2020 23:19:56 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 810C95C00E6; Mon, 19 Oct 2020 02:19:55 -0400 (EDT)
Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Mon, 19 Oct 2020 02:19:55 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm3; bh=3hbh3vRwxtldwXpN5o0YwnT8xlJb I0JGKRzhOJ079L4=; b=SDkavsyZR9SqeobC5kX87aLwhuUbGI8dvrNAfGB3Teea Meg4G96xj6IGGJfoXFr6cPCCvGh1z6xHszxLG2oegq6kMp8FgwTY5/tsZUzwoRQ+ Ose/Qp6jT7wcWU/4i0KFdVg2VXN36S/gHDnT1JRV7KmUSPSy05/zR/zjc/+sODVJ wNTBg+qBRkOIhAd571lvm3qpVp2eO+Pv9A4WVoafQuaaJC52vMPc30608bYys+LW ikLw9x45AEKV2pJ1bHmFuLdrq2j0DlDC3E+MSugCIFdHF3PLoz+r/QO0fEJeC2f/ SghqeGBclLtED0kgYxtSRpLaLofVoHm3r0izR8vKpQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=3hbh3v RwxtldwXpN5o0YwnT8xlJbI0JGKRzhOJ079L4=; b=QrG5Z7HI15wOUV54Y1wqDU N6o9/A6nC6kEN9r1E04Zuez+/QJGposAjnRI+96RXZkaVSFBxwBg/5Kk9eXNk5rK rKdtrhayiMRTSHw5xrHeAMOvq3btUXKE/PmGTpOAFe+ELmEz5j1pviwFLOMJwcWN 7xA4DqP4u8MdOZwoVQZgFo8QkBUKpe28RgOF1X5B1i0/AhGttCzWceKlAn9ZU3iw oZs9h4EkQKjLelVXxpVFo7BkWRnjaTSsjA+npIGA5j/XBxin1u0rCHyXnlokAe3Y I+cvcEti22NirPAyDJFAboRO/ojCugFdCb7htYDcfcssJabruE2slW8kI2bda1Gw ==
X-ME-Sender: <xms:CjCNX2prHeNyFm-7ciULzqnRlKC1wFyIH4t87iiMJFAjnd-6IfcHvQ> <xme:CjCNX0oUtlvzrPDquVnxzCVtCwnJ7LnKHa8cv9Hx_1oPwRFYi6v_0-tBPq4IZilhH hmyk7kawl36tnwnk2E>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrjedtgddutdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecugg ftrfgrthhtvghrnhepffeiveejgeeijefghfduuefffeeugfefteduhfelheeitedugeej jeejvefhkeeinecuffhomhgrihhnpeguohhirdhorhhgnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgv th
X-ME-Proxy: <xmx:CjCNX7N3WXoJpapIQbTNkCDcx0eMQZZZBAdqbmb6jMPog8VqA2Duzg> <xmx:CjCNX141ilF2jHcOW67WKDzMDW4fF48i9gZYEB80SqedMWrz4VFl0A> <xmx:CjCNX17xttZMTwhOOlIKQE9SQRjt7s1_6mUvLv9NWjYJQtZtuFDn1g> <xmx:CzCNX2XGiD2-dX6FtsN19uNHGprHOsMcrJ8_a219yeXXNdDm3KMFVA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id D2BAE20093; Mon, 19 Oct 2020 02:19:54 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-489-gf39678d-fm-20201011.001-gf39678d0
Mime-Version: 1.0
Message-Id: <1c73edad-56f1-4eda-a835-db593c316968@www.fastmail.com>
In-Reply-To: <51FF31EC-14A2-40C5-BE66-A9B57552EE9B@tzi.org>
References: <181dadfc-37bf-46ad-b907-853cad3dccd2@www.fastmail.com> <51FF31EC-14A2-40C5-BE66-A9B57552EE9B@tzi.org>
Date: Mon, 19 Oct 2020 17:19:34 +1100
From: Martin Thomson <mt@lowentropy.net>
To: Carsten Bormann <cabo@tzi.org>
Cc: tools-discuss@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tools-discuss/LHJGmw_sz6jIHe69RlaF5xWc6UY>
Subject: Re: [Tools-discuss] How do we diagnose DOI errors?
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion <tools-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-discuss/>
List-Post: <mailto:tools-discuss@ietf.org>
List-Help: <mailto:tools-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Oct 2020 06:19:58 -0000

On Mon, Oct 19, 2020, at 16:39, Carsten Bormann wrote:
> On 2020-10-19, at 03:58, Martin Thomson <mt@lowentropy.net> wrote:
> > 
> > I've come to rely on this mechanism for citing documents, but it isn't good if it isn't reliable.  Some better information about how this operates would be great.
> 
> As far as I understand, the DOI bibxml is based on the doilit tool that 
> is part of kramdown-rfc2629 (which in turn is using 
> https://dx.doi.org/).  A 24-h cache helps keeping the load down but the 
> data reasonably fresh.  As far as I can see, all kinds of errors are 
> mapped to 404.
> 
> One tweak that can help coping with doi.org outages might be keeping 
> the cache indefinitely.  Freshness could still be achieved by *trying* 
> to get a refresh after 24 h, but keeping the cached value in place if 
> that fails for some reason.

That seems like a reasonable enhancement.  These outages are far to frequent for my liking.  This is hardly the first occurrence.

You can tune the timeout right down at the same time; these rarely change and anyone who uses these often (through CI, for instance) will ensure that they are kept fresh enough.  (stale-while-revalidate...)

You might need to consider whether or not the cache needs an occasional flush to avoid unbounded accumulation of old entries.