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

Joseph Touch touch at strayalpha.com
Wed Mar 25 20:49:58 PDT 2020

> On Mar 25, 2020, at 8:40 PM, Joel M. Halpern <jmh at joelhalpern.com> 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.


More information about the rfc-interest mailing list