I think we're into the territory of guildlore and licensing here, which is something Sunsite as a class of curated public domain works did better than the free for all we see these days, however as an Officious Bystander I am concerned about elitism given the well worn tracks made by professional Court intermediaries who don't know how to grok.
I do understand that making standards accessible to lay people is a challenge that as a collective we are ill equipped to address - a tooling issue - but I can not support constraining information about critical infrastructure to the realm of specialists because we know where that road lead.
Maybe we need to find support for an educational arm of the IETF so that we can enhance accessibility without sacrificing quality control.
Let's face it, few of us would be able to build an electronic computer from scratch to run software implementing standards - if we had to start from stone age technology - and certainly not within a single human lifetime, for a given value of human.
Well, maybe Jon Postel, but presumably even he had limits.
The question is do we want to foster community learning for a better world for all or do we want to be selectmen making decisions on behalf of an electorate that doesn't even know they are entitled to vote?
AI is making great strides with preserving concepts across cultures, including a recent test I did into Klingon and back to my dialect, and although the returned words were surprising and nothing I would ever have considered it was nonetheless an apt choice.
I suggest we give serious consideration to AI tooling as co-author of documents proofread in peer review along the current standardisation channels.
At the very least AI can help by asking questions based on relatively good ERRATA and later versions of earlier standards.
Then all we need to worry about is a secretaries revolt or strike action demanding better pay and conditions, mindful of reabolition of slavery and death penalty, per Charter.
This the same topic as symposia and Etruria.
Mindful of the origin story for Watson&Crick, two men in a bar with different backgrounds cracking the double-helix aspect of DNA with all the good and bad that follows, we don't want to exclude ideas from other fields because they are out protection against what I'm sure we're all guilty of - only testing the scenarios we've considered based on our constrained understanding of all the possible use cases.
Classic example of that is continuous reinvention of transactional processing systems when SMTP already allowed fan-out and round robin, together with delivery acknowledgement and read receipts, and indeed product recall notices [1] as an unofficial standard implented by Google, Microsoft and others - experienced by myself as interference in Matters before Court constiting a Public Nuisance.
Phil.
[1] https://www.ietf.org/archive/id/draft-leiba-morg-message-recall-00.html
-------- Original Message --------
On 16/05/2025 16:11, Eric Rescorla wrote:
On Fri, May 16, 2025 at 7:59 AM Paul Kyzivat <[email protected]> wrote:
On 5/16/25 8:45 AM, Marc Petit-Huguenin wrote:
> An additional reason why I think that English sentences are better than ABNF or any other formalism as the normative part of a standard track RFC: most people understand what an English sentence means,
Most people *in the world* don't understand ABNF.
If we restrict the population to those people who can understand and
wish to implement an RFC, then most probably understand both.
To pile on here a little, I don't think our objective should be to have our
RFCs understandable by the general public, but rather by the intended
audience, which is implementors, protocol designers, reviewers, etc.
I think that audience is best served by having the specifications be
precise, even if that comes at some readability cost to people with
less context. In my experience the tension between precision and
accessibility by non-specialists is quite common and not confined
to technology. This isn't a call for unnecessary formalism, but rather
agreement with Carsten and Paul that formalism is a useful part
of precise specification, even while it is not capable of capturing
everything we mean to say.
-Ekr
publickey - [email protected] - 0x98990EF9.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ rfc-interest mailing list -- [email protected] To unsubscribe send an email to [email protected]
