It's a tooling issue. Not sure what the solution is yet, but there are plenty of examples of works expressed differently being compatible at the ABI layer, so maybe we need to look at ways to compile down to ABI and express in RFC formats. I'll review ABNF at some point because at first glance Brian is wrong however this is a consequence of how digital technology has evolved over the decades - variable length opcodes as used in serial computers are better but binary was only a hotfix to work around the signal noise impacting analogue systems.
Phil. If you have received this message by common mistake, please contact the sender as soon as possible - you may be committing an offence if you copy it, or make use of any information contained in it for any purpose, or disclose its contents to any other person. Messages sent and received may not be private and may be the subject of monitoring. Sent from Proton Mail Android -------- Original Message -------- On 17/05/2025 21:36, Brian E Carpenter <[email protected]> wrote: > On 18-May-25 02:32, Paul Kyzivat wrote: > > On 5/17/25 1:27 AM, Julian Reschke wrote: > >> On 16.05.2025 17:22, Salz, Rich 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, > >>> > >>> Can you imagine defining HTTP without ABNF? Or any other text-based > >>> protocol that the IETF works on? > >> > >> <https://www.rfc-editor.org/rfc/rfc9651#appendix-D-2.3.1> > > I assume that was meant to be > https://www.rfc-editor.org/rfc/rfc9651#name-structured-data-types > > > > > > I've encountered this style before while doing genart reviews. > > It does seem to precisely define they syntax. But it takes an order of > > magnitude more text than equivalent ABNF would. > > > > I fail to grasp any benefits that this provides. Are there any? > > I don't know because I'm not visually impaired. I thought that was > the reason we were having this conversation. However, RFC 9651 explains > exactly why it uses all that English: > > " Appendix C. ABNF > > This section uses the Augmented Backus-Naur Form (ABNF) notation [RFC5234] > to illustrate the expected syntax of Structured Fields. However, it cannot be > used to validate their syntax because it does not capture all requirements." > > > > > Conciseness is valuable in definitions of syntax. It makes it easier to > > see the forest before getting lost among the trees. > > That's true. But what RFC 9651 is saying is that some of the trees > are not implied by the ABNF, and therefore the ABNF is defective. > > Brian > _______________________________________________ > rfc-interest mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
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]
