Re: [rfc-i] draft-kuehlewind-update-tag/

Mark Nottingham <> Wed, 25 March 2020 23:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1DF5E3A0123 for <>; Wed, 25 Mar 2020 16:01:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.451
X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.b=QP085TYT; dkim=fail (2048-bit key) reason="fail (message has been altered)" header.b=vWCFv1VX
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 91UzsmLDshit for <>; Wed, 25 Mar 2020 16:01:14 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8C7153A0DFB for <>; Wed, 25 Mar 2020 16:01:13 -0700 (PDT)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 8FA2DF40711; Wed, 25 Mar 2020 16:01:02 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id F1341F40711 for <>; Wed, 25 Mar 2020 16:01:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=QP085TYT; dkim=pass (2048-bit key) header.b=vWCFv1VX
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dcf3WVe78_DT for <>; Wed, 25 Mar 2020 16:00:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPS id EF1ADF406D6 for <>; Wed, 25 Mar 2020 16:00:50 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id E07534D5; Wed, 25 Mar 2020 19:00:55 -0400 (EDT)
Received: from mailfrontend2 ([]) by compute4.internal (MEProxy); Wed, 25 Mar 2020 19:00:56 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=z Pw8boRrKnyJD1yenXp+XlcsjHu57y5VRoh3Au5f4ek=; b=QP085TYTTG3zQgLuw o8CiwZu0SWef/eCPTbUkaZkGslyjJP19MFekh6xEoffj7VYNCcXvmVHWCGHLIAB7 aLHgpzp4aJoliGEeeKG37JMwtx1Q0f090W8DWIPHtx+J0VRgMFgAg64wk0bqt8OS 9eTgRjaNpIHx6eLINNiwuzPcMeeeP77VkJpe/frUg8OU20/tlmh1vxlnbaDAZNTN n+JjKGEexS8LdDzq8S4RZxNzBeJoEhGYyTHdUCIwFdF7yJyDLVO3foNM3VIJCIFH Et6taPS6MNg/09jsg4zVc6LtbSLUAT10DEMvZuyJSygBiHByEPaqpBDUtePkoCAM qQvrw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding: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=fm2; bh=zPw8boRrKnyJD1yenXp+XlcsjHu57y5VRoh3Au5f4 ek=; b=vWCFv1VXo0zVb3QTM2DZ6BuG5XsR+5UghjMV9xGImKET9ao08vQLIzXDn sX+VqRuDPcQQVx+kpOauzHNmYXq0fjEsAlJ2CK9eyL///8u4oKckOu+5Oxlk93fi Zcl8PJu1kmNqxTEY8r/kNzdAg+1clrgQcJWGRXohgoCbBjhM145pNkbMRBBvDCfS DiXA47XOMmynnxVo8XDgDbGO0OD7HVxi4IwibgQcaF+pk1kZNFhhARuw6G4GOAUS COQ+QUO15kr8siG+xwQwgNMb9+52WuYbRegtIwISZog/1hbkYib+fFWpepcnj1E+ 6oPDYceyvkwdy5Yy/cgUc17U2jKrA==
X-ME-Sender: <xms:peJ7XrE8hjyj-OYblxFpYfP_tHaIJG8Qv5NPQqW5ETcBBBmnWToxUw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudehhedgtdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinh epmhhnohhtrdhnvghtnecukfhppeduudelrddujedrudehkedrvdehudenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrd hnvght
X-ME-Proxy: <xmx:peJ7XrnlWAXKON271OkuyDIBVzmlatpNt4vKXmDNYgPwhGkJs7gv8g> <xmx:peJ7XmmJlEJ9vHXLah7GEeXrSKogCFaAr-wUAWnRLCKXAirtAAztdQ> <xmx:peJ7XktT4PEVwd6pF7fGYCsi5zJCD46s7KKpLfm8OZJHrDmECJNuFg> <xmx:p-J7Xg3jzKetH28Og6XsLxIMIDLTr7TrGR0l3S-PnWwIUjH7YqEV2g>
Received: from (unknown []) by (Postfix) with ESMTPA id 92FDF306769A; Wed, 25 Mar 2020 19:00:52 -0400 (EDT)
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.\))
From: Mark Nottingham <>
In-Reply-To: <>
Date: Thu, 26 Mar 2020 10:00:49 +1100
Message-Id: <>
References: <>
To: Martin Duke <>
X-Mailer: Apple Mail (2.3608.
Subject: Re: [rfc-i] draft-kuehlewind-update-tag/
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the RFC series and RFC Editor functions." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: "rfc-interest" <>

> On 26 Mar 2020, at 9:41 am, Martin Duke <> wrote:
> What I was going to say in the queue:
> Like mnot, I think Updated should mean "Amended". It may be worth it to change the term just to create awareness to tighten the meaning.

To expand on discussion a bit -- one of the things that kept on coming up was that "updated" was never well-defined, causing this confusion. So one approach we could take would be to _define it_.  But having data about how bad the confusion is would help make the decision of whether to do that vs. mint a new term.

> But I dislike the idea of having "Extends" and "See Also". I foresee foundational documents (like RFC 793) with a few pages of RFC references before the text starts. That is useless. Plus the formal existence of these categories will encourage people to use them.


> If we would like better forward-tracing of standards evolution through time, I would prefer if the datatracker and rfc-editor pages simply listed the times the RFC was cited by other RFCs both normatively and informatively. I think that would be sufficient and automatable.
> TLDR, rename Updated to Amended, build the citation tool, and call it done.

I don't think we should call it done.

To me, this is further evidence that a linearly-numbered series of archival documents as the primary source of truth is damaging. 

We'd be better served if the documents that most people referred to were what's called "consolidated acts" in legislation. The source documents would still be available and immutable, but not primary references (unless there's a dispute about the consolidation). 

That implies that we'd need a new kind of WG output -- one that "patches" existing documents. Not hard, but requires some conventions and discipline by the authors. That patch could then be applied and the resulting consolidation published by the RFC Editor, or someone else. And both the original document and the patch would still be available separately, for when that matters.

The problem in all of this is that brand of "RFC numbers" has been built up over the year, and people are conditioned to use them as the primary reference. Giving the consolidated documents their own numbers is pointless, because they should be stable, not changing every time there's a new patch.

STD and friends seem to have failed. A tentative suggestion -- still publish RFC *numbers* for archival documents, but publish RFC *names* -- e.g., RFC-HTTP -- for consolidated documents that *can* be updated over time.


Mark Nottingham

rfc-interest mailing list