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

[Michael Richardson <[e-mail]>]

Carsten Bormann <[e-mail]> 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 <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide