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

Joseph Touch <> Thu, 26 March 2020 03:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 110233A0DEC for <>; Wed, 25 Mar 2020 20:50:10 -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)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZQc3c_05eObg for <>; Wed, 25 Mar 2020 20:50:08 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5002D3A0E21 for <>; Wed, 25 Mar 2020 20:50:08 -0700 (PDT)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 69C6FF4070B; Wed, 25 Mar 2020 20:49:57 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id CE646F4070B for <>; Wed, 25 Mar 2020 20:49:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qN-o0kkwS125 for <>; Wed, 25 Mar 2020 20:49:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPS id F078FF406D6 for <>; Wed, 25 Mar 2020 20:49:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=/rk/GGEUKI5pJZfrQ1uIEowNpv5vf+sFsU16E+WdJ7U=; b=JrvvSv9C8kzSRL3n+EY6socua WmXhdXZsyuLKIJyl8aGE00iB7IFK9mstqVAIUYfJ4aEkPIQwRycU+bu4wGvM2QKHXVIkIHjrEyjx9 h0QYXKZBBR/G2Gr/ufLP8GyARpWQ/pxYWX9Py0pv4UjrZlDnkA8eERuza96YcXn8/Rr6ZmQ10vnwb ewIM7Ngot2ypqfzLi/n+Vc0O5gr2PPyhhYTtqQou+BdUK2fiNW/7IrSl2d3UeNFf5nqzkH+P7zjRP uJpil/2yCUO+izyAbykFMfvf7lGTgSOcF777sxw+hBoDKFhsj/Zr2ULU+V8uahJdyAYHJBKAOtkQ6 vltc17JqA==;
Received: from ([]:54970 helo=[]) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <>) id 1jHJWp-001Qp0-FL; Wed, 25 Mar 2020 23:50:03 -0400
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joseph Touch <>
In-Reply-To: <>
Date: Wed, 25 Mar 2020 20:49:58 -0700
Message-Id: <>
References: <> <> <> <> <> <> <>
To: "Joel M. Halpern" <>
X-Mailer: Apple Mail (2.3445.9.1)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
X-From-Rewrite: unmodified, already matched
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: <>, <>
Cc: "" <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: "rfc-interest" <>

> On Mar 25, 2020, at 8:40 PM, Joel M. Halpern <> wrote:
> The problem was to my mind very clearly stated.  We burn person-hours figuring out what we mean each time any document gets tagged this way. We want the relationship tags, so we can find things.  But our current "updates" tag has multiple meanings, so people get very confused.

Any of the proposed new tags arguably applies to many different things. What’s the difference between extends and changes? When does a change affect compatibility - only when it causes a failure or when it causes a change of any kind?

These are “angels on the head of a pin” discussions. The only solution to understanding how one doc updates another is a *discussion* in that doc. No single set of terms will capture the nuances necessary to decide what parts of an update are critical vs. not. That’s a responsibility of the updates doc author. Thinking a tag will solve that problem is naive.

To be clear, I wish we did have some rigor here. Something that said “hey, to spec a protocol, provide a FSM”. But we don’t.

For decades, some even asserted (incorrectly) that the API of a protocol wasn’t part of its spec and was out of scope (an *implementation* of an API might be, but 793 has a good example of one that is necessary and not implementation details).

“Updates” means just that - it affects the base document in a way that MIGHT be hazardous to ignore. That means you need to read the doc to find out why, to what extent, and how that affects what you want to do.

There is no shortcut here.

> I am sure that there are other choices.  (We are much too clever.)  But I would prefer not to stick my head in the sand and pretend something that regularly causes this much confusion is just fine.

I’m not ignoring the problem. I’m just not naive enough to believe a handful of tags fixes it either.

rfc-interest mailing list