On 25-Jan-24 13:03, Randy Presuhn wrote:
Hi -
On 2024-01-24 2:43 PM, John Levine wrote:
It appears that Randy Presuhn <randy_presuhn@xxxxxxxxxxxxxxxxxxx> said:
Hi -
An analogy - at my local supermarket, there are expiration dates both on
packaged sushi and on table salt. This proposal seems to be optimizing
for the table salt use case, for which the expiration date is really not
useful at all, rather than for the sushi, where it's really critical.
Maybe I'm missing something, but expired I-Ds seem a lot more like salt
than like sushi. If you have very old salt, you might need to give it
a shake or two before you use it. If you have very old sushi, it can
kill you.
This discussion tells me that we have wildly varying ideas of what I-D
expiration means, and it also seems to depend on where the draft is
going, e.g., an expired draft that's been adopted by a WG means something
different from one that's in the Independent stream or one that's just
sitting there not adopted by anyone.
I tend to look at drafts from the perspective of the potential
implementer, placing a premium on interoperability. Documents left on
the shelf to rot (and yes, from the perspective of an ever-changing
environment, they do rot) may be historically interesting, but rarely
foster interoperability with anything other than premature
implementations built using the same obsolete draft.
Fair enough, but none of that can be deduced from the text of a draft,
including the phrase about "will expire on". It can at best be deduced
from the status visible in the datatracker. The current boilerplate is
unhelpful. If that "will expire on" sentence was replaced by
"For the status of this document, see https://datatracker.ietf.org/doc/draft-name-foo-bar/.";
that might be more use and the expiry date would no longer be there to create confusion.
But I'd still like to abolish the make-work of bumping the version number every six months.
Brian
Brian
