Re: [Tools-discuss] Expiry Doctrine (Re: Expired draft on the w.g. status pages [was Re: disappearing IDs on www.ietf.org])

Michael Richardson <mcr+ietf@sandelman.ca> Sun, 13 September 2020 00:28 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 706913A0140 for <tools-discuss@ietfa.amsl.com>; Sat, 12 Sep 2020 17:28:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 CZH0M637YKaf for <tools-discuss@ietfa.amsl.com>; Sat, 12 Sep 2020 17:28:39 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 671673A0128 for <tools-discuss@ietf.org>; Sat, 12 Sep 2020 17:28:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id C4371389B4; Sat, 12 Sep 2020 20:07:24 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id u5A3rnMUaiJC; Sat, 12 Sep 2020 20:07:20 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 50571389A7; Sat, 12 Sep 2020 20:07:20 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DC6B5A9A; Sat, 12 Sep 2020 20:28:33 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Carsten Bormann <cabo@tzi.org>, Russ Housley <housley@vigilsec.com>, Tools Team Discussion <tools-discuss@ietf.org>
In-Reply-To: <BCB7C223-EFDE-46D3-A4E2-82068C688547@tzi.org>
References: <8657.1599751932@localhost> <84c8d593-c7b6-4327-338f-9b2b0e7a36e0@levkowetz.com> <0C6D4DE2-F9F3-4C7C-8427-264F34C8C2B7@tzi.org> <26d795d2-3761-2950-4346-62f849d86eed@nostrum.com> <7792.1599768579@localhost> <C73D6AB9-694E-458E-AEEE-45DBDEF623C5@vigilsec.com> <3B281EED-CDCE-4025-8C78-7BA689490936@tzi.org> <5B0C691F-EA59-44E9-959F-52445CA58314@gmail.com> <41EEFFCD-DEB9-4950-95B1-F43ACC73CAF1@vigilsec.com> <2F82E43A-39CF-4C99-BE9E-CD84D2BE21B3@gmail.com> <C44C644D-C24A-4839-BB61-F758AA2D7BF1@vigilsec.com> <BCB7C223-EFDE-46D3-A4E2-82068C688547@tzi.org>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Sat, 12 Sep 2020 20:28:33 -0400
Message-ID: <24860.1599956913@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tools-discuss/B-QY4xGxY49Yx4eX6Py0unUKA0g>
Subject: Re: [Tools-discuss] Expiry Doctrine (Re: Expired draft on the w.g. status pages [was Re: disappearing IDs on www.ietf.org])
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: Sun, 13 Sep 2020 00:28:42 -0000

Carsten Bormann <cabo@tzi.org> wrote:
    > A little Saturday metacomment:

Were you in the shower again today, to have such deep thoughts?

    > What actually happens is that URLs for Internet-Drafts are generated by
    > various pieces of software (email, web pages) and propagate into other
    > places.  At the time they are first generated, these Internet-Drafts
    > are not expired yet.  The expiry doctrine makes us delete the data
    > behind these URLs at expiry time, making the URLs we use for
    > Internet-Drafts *unstable* URIs.

    > The archive can be addressed by *stable* URIs, but these are not the
    > ones generated during the pre-expiry usage of Internet-Drafts.  Stable
    > URIs need to be generated manually, which mostly does not happen at the
    > time the URIs propagate into various places.

+1

    > By making expiry (and replacement) a dynamic *property* of a draft.
    > (Note that there is text in each draft that describes the current value
    > of this property based on the current date — this text is actually more
    > likely untrue than true, and this has caused all kinds of problems with
    > people taking the text at face value.  Instead it should point to a
    > resource where the true current state can be ascertained.)

Since the draft knows when it expires, maybe it could mark itself.
As, I don't really want to put in JS into HTML generated WG drafts, I wonder
how to do this with CSS.
A simple way I can think of is to reference some CSS file that includes the
date of expiry.... [oh my I didn't know we import google hosted fonts]
And there is JS in there already. Oh. Unhappy face.
Do HTML generated RFCs have JS in them?

Anyway, I had mind something like:
   <link href="202009.css" rel="stylesheet" type="text/css">

which would go into every draft issues in September, and six months after 2020-09-30, would
make the draft have an expired mark on it.

    > I cannot finish this note without noticing how all this is not in the
    > domain of the RFC editor — we have kept the domain of authoring and
    > progressing documents out of this domain and are continuously baffled
    > by the process discontinuities that the cliff between authoring and
    > publishing creates.  We need to think about the entire process of RFC
    > creation in a unified way to reduce the obstacles.

Agreed.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide