Subject: Re: [irsg] "Updates: RFC xxx" - what does it actually mean ?

From: Erik Wilde <[email-masked]>
Date: Wed, 7 Dec 2016 21:31:49 -0800

hello all.

after an absurdly long silence, here's some feedback:

On 2016-09-23 06:25, Paul Kyzivat wrote:
> ISTM that you are arguing that Updates only applies in cases where there
> is a *revision* as contrasted with an *extension*. I earlier suggested
> that we distinguish these cases, but I was voted down in favor of having
> Updates cover both cases.

as a balance, would it make sense to say that *updates*

- does cover both *revision* and *extension*,
- MAY be used for *extension", and
- MUST be used for *revision*?

i that case, there would be no need to revise (this is nicely 
self-referential!) the metadata practice, but there would be a bit more 
explicit guidance on how to use it.

this could even go as far as proposing that the section about updates 
should have clearly distinct subsections on *revision* and *extension* 
(in case both are used at the same time), or if only one was used, 
should be explicit about which one of them it is.

personally, i think the *extension* case is a bit fuzzy. i can imagine 
cases where indicating them as updates would be helpful (typically when 
extensions happen rarely and establish new general-use protocols). i can 
also imagine cases where indicating them as updates might become 
excessive (if there are many and they are mostly constrained to specific 
use cases). this distinction is fuzzy, but it might be the reason why 
there is some disagreement about the "best" practice.

for a *revision*, things probably are a bit clearer. if i really should 
consult the updating RFC when implementing the updated one, then not 
having this metadata harms interop.

thanks for your patience and cheers,

dret.

-- 
erik wilde | mailto:[email-masked] |
            | http://dret.net/netdret    |
            | http://twitter.com/dret    |

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 8 Dec 2016 08:23:30 +0100

On 8 Dec 2016, at 06:31, Erik Wilde <[email-masked]> wrote:
> extension

There are two kinds of extension of a protocol:

1. making use of planned-ahead extension points

2. extending the protocol in a way that was not originally anticipated

I’d say that (1) is not an “updates” situation (unless those extensions somehow become mandatory even in operation of the existing protocol), while (2) likely is.

Grüße, Carsten

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 8 Dec 2016 12:47:59 -0500

> I’d say that (1) is not an “updates” situation (unless those extensions somehow become mandatory even in operation of the existing protocol), while (2) likely is.

I agree philosophically with this, but the distinction can be fuzzy and 
probably deserves some refinement.

For instance, some protocols have extension points indicated in ABNF, 
using the following sort of pattern:

   frobitz = "foo:" foo-args / "bar:" bar-args / frobitz-extension
   frobitz-extension = token ":" frobitz-extension-value

coupled with text that says implementations should ignore values that 
match frobitz-extension unless another value matches a supported extension.

*Sometimes* an IANA registry is defined for frobitz-extensions. But 
sometimes there is not.

When there is not, it is common for new documents defining extension 
values for frobitz to include ABNF such as:

   frobitz = <defined in RFCnnnn>
   frobitz =/ "baz:" baz-args

In the absence of a registry, ISTM that the redefinition of frobitz is 
the only formal way to hook in the extension, and IMO this is a 
*revision* to the original document.

When there is a registry, IMO it eliminates the need to revise the 
definition of frobitz, and so eliminates the need to mark the new 
document as a revision. The registry then serves as the breadcrumbs to 
discover that there are added values that perhaps should be implemented.

This all only applies to documents that define protocols. Other 
considerations probably apply to other sorts of documents.

	Thanks,
	Paul