[rfc-i] Re: Normative ABNF [was Re: Re: Normative information in RFC imagery]

On 2025-05-19, at 20:20, Paul Kyzivat wrote: > > On 5/19/25 2:06 PM, Carsten Bormann wrote: > >> we need to make for ... an “RFC filesystem”. > > I've seen a couple of mentions of this in the thread. > Are you hypothesizing, or is there such a thing. My proto

[rfc-i] Re: Normative ABNF [was Re: Re: Normative information in RFC imagery]

On 2025-05-19, at 20:02, Paul Kyzivat wrote: > > But AFAIK we don't have a way to submit multiple pieces of source data for > portions of a document, that are then automatically processed by different > tools and assembled to create the authoritative form. … and that is indeed a significant s

[rfc-i] Re: Normative ABNF [was Re: Re: Normative information in RFC imagery]

On 2025-05-19, at 18:18, Nico Williams wrote: > > Mind you, I'm skeptical of expressing any normative requirements with > ABNF. Or even in an LALR(1), LALR(k), LR, GLR, or other parser grammars > unless code, pseudocode, or normative natural language text is > associated with relevant "actions".

[rfc-i] Re: Normative ABNF [was Re: Re: Normative information in RFC imagery]

On 17. May 2025, at 22:36, Brian E Carpenter wrote: > > 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, i

[rfc-i] Re: Normative ABNF [was Re: Re: Normative information in RFC imagery]

On 17. May 2025, at 16: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: >>

[rfc-i] Re: Normative elements in RFCXML

On 17. May 2025, at 03:50, Paul Kyzivat wrote: > > So you are still saying that the RFCs that use ABNF normatively would have > been better if they had not? I have a little demonstration, not for ABNF but for the related data definition language CDDL. Section 6.2.2 of RFC 7071 in conjunction

[rfc-i] Re: Normative ABNF [was Re: Re: Normative information in RFC imagery]

>> I don’t know why this means it can’t be normative — it just describes a >> superset, and the remaining details can then be supplied in English (rule >> “verbatim” in 7.1, I think). > > Yes, but also the quoted-string, hexadecimal, and base-64 rules, when they > start with a number. There i

[rfc-i] Re: RFC 9633 SVG is unreadable

On 16. May 2025, at 07:52, Michael Richardson wrote: > > Additionally, I have yet to find an obvious way to display just a diagram > itself. Both so that I can zoom better, but also so that I can extract the > diagram for a slide, etc. I usually wind up diving into the XML or HTML and > yanking

[rfc-i] Re: Normative ABNF [was Re: Re: Normative information in RFC imagery]

On 14. May 2025, at 17:41, Marc Petit-Huguenin wrote: > > https://datatracker.ietf.org/doc/draft-rivest-sexp/ is a good example of a > language whose ABNF cannot be normative (that's because the s-exp variant > described in it is non-context free). I think you are saying that the ABNF doesn’t

[rfc-i] Re: RFC 9633 SVG is unreadable

On 16. May 2025, at 04:51, Brian E Carpenter wrote: > > Simply remove the width and height elements, but leave the viewbox as is, and > the diagram will scale when you resize the browser window (up to screen > width, and down to a minimum). Not all diagrams benefit from scaling them up indefi

[rfc-i] Re: RFC 9633 SVG is unreadable (was: Normative information in RFC imagery)

On 15. May 2025, at 06:28, Martin Thomson wrote: > > That resource is not present. $ curl -I https://www.rfc-editor.org/rfc/rfc-local.css HTTP/2 404 date: Thu, 15 May 2025 04:50:41 GMT content-type: text/html; charset=utf-8 Maybe reacting to the (incorrect for a CSS) media type of the 404 respo

[rfc-i] Re: Normative information in RFC imagery

Hi Alexis, (Resending to the list, too :-) On Wed, May 14, 2025 at 1:27 PM Alexis Rossi wrote: >> >> >> On Wed, May 14, 2025 at 3:59 AM Carsten Bormann wrote: >> On 14. May 2025, at 11:09, Michael Richardson wrote: >>> >>> We needed an abstra

[rfc-i] Re: RFC 9633 SVG is unreadable (was: Normative information in RFC imagery)

> And I’m myopic. That always helps with immersing in dense diagrams :-) Should I be seeing these errors: Refused to apply style from 'https://www.rfc-editor.org/rfc/rfc-local.css' because its MIME type ('text/html') is not a supported stylesheet MIME type, and strict MIME checking is enabl

[rfc-i] Re: Description techniques [was Re: Normative information in RFC imagery]

Hi Marc, semi-facetious... > I spent the last 10 years trying to convince people at the IETF to use formal > methods to reduce errata and updates (with little success). 10 years is not enough. (ABNF was invented 1977 and became STD in 2008.) > I also recently proposed a modification to RFCXM

[rfc-i] Re: swagger APIs

On 14. May 2025, at 16:23, Paul Duffy (paduffy) wrote: > > It was required that both the OpenAPI and Protobuf definitions be inlined > within the draft. It's a mess (not directly usable by developer tools … That is indeed a problem. I made a quick prototype a while ago how the RPC might want

[rfc-i] Re: Normative information in RFC imagery

On 14. May 2025, at 11:09, Michael Richardson wrote: > > We needed an abstract that was higher level than the markdown tables. I often generate tables from CSV files. E.g., https://github.com/cbor-wg/draft-ietf-cbor-cde (Files with “table” in the name.) In this case, this is a CSV, which coul

[rfc-i] Re: Normative information in RFC imagery

On 14. May 2025, at 01:24, Brian E Carpenter wrote: > > Just to take a recent example, anyone consulting RFC 9686 using a screen > reader will not obtain an overview of the address registration mechanism > (only described by Fig. 1) and will have to guess the length of the > option-code and opti

[rfc-i] Re: Normative information in RFC imagery

On 14. May 2025, at 00:00, Alexis Rossi wrote: > > Is the community interested in supporting accessibility Certainly, accessibility is good. > by trying to make sure future RFCs can be fully read and understood without > relying on information in imagery? Well, we have heard several people w

[rfc-i] Re: Guidance for References to NIST FIPS and SPs

On 2025-05-05, at 19:07, Ted Harrison wrote: > > The RPC has added guidance to the Web Portion of the Style Guide for > references to two National Institute of Standards and Technology (NIST) > document series: Federal Information Processing Standards (FIPS) Publications > and Special Publicat

[rfc-i] Re: Manuscript style (Re: Report from the first-ever high-level RPC Retreat)

On 2025-04-24, at 17:02, Ted Lemon wrote: > > no gratuitous formatting changes to the source code (The XML is not the source code, but:) +1 Grüße, Carsten ___ rfc-interest mailing list -- rfc-interest@rfc-editor.org To unsubscribe send an email to r

[rfc-i] Re: Manuscript style (Re: Report from the first-ever high-level RPC Retreat)

On 23. Apr 2025, at 23:05, Eric Rescorla wrote: > > > > On Wed, Apr 23, 2025 at 1:43 PM Carsten Bormann wrote: > > Formatted? Nothing, if the formatter knows it's all one paragraph. If > > you're reading the source though then it's annoying, like th

[rfc-i] Re: Manuscript style (Re: Report from the first-ever high-level RPC Retreat)

> Formatted? Nothing, if the formatter knows it's all one paragraph. If > you're reading the source though then it's annoying, like this: > > Formatted? > Nothing, if the formatter knows it's all one paragraph. > If you're reading the source though then it's annoying, like this: Interesting. I

[rfc-i] Re: Manuscript style (Re: Report from the first-ever high-level RPC Retreat)

On 2025-04-23, at 17:40, Eric Rescorla wrote: > > However, it makes it harder to *read* the document directly in > the markdown, which I spend much more time doing. Now I’m curious — what makes NSNL harder to read (and compared to what)? (I should mention that I generally fulfill my desire to l

[rfc-i] Re: Manuscript style (Re: Report from the first-ever high-level RPC Retreat)

On 2025-04-23, at 17:13, Marc Petit-Huguenin wrote: > > do that Well, the format you want to have is one-line-per-sentence (OLPS). The format that I consider good style for development is new-sentence-new-line (NSNL), where other newlines can be inserted as needed (but, preferably, not mechani

[rfc-i] Manuscript style (Re: Report from the first-ever high-level RPC Retreat)

On 23. Apr 2025, at 16:13, Michael Richardson wrote: > > What would also help would be if everyone started every new sentence on a > newline. It doesn't matter if they wrap the sentence into multiple lines, > but having a new sentence on a newline simplies git diff. Indeed, that is generally th

[rfc-i] Re: Report from the first-ever high-level RPC Retreat

On 22. Apr 2025, at 22:14, Jean Mahoney wrote: > > There would still be a few formatting updates to make in the RFCXML file: > adding displayreference if needed, boilerplate updates, etc. Right, and I’d like to know what these gaps in functionality of kramdown-rfc are… (Or gaps in documentat

[rfc-i] Re: Report from the first-ever high-level RPC Retreat

On 2025-04-21, at 22:54, Jean Mahoney wrote: > > > o Once the authors have approved the copy edits, we convert > the file to RFCXML and make formatting updates. Hi Jean, Just out of curiosity: Why is “formatting updates” considered to be the realm of XML (while content, understandably

[rfc-i] Re: Report from the first-ever high-level RPC Retreat

On 2025-04-22, at 18:45, Michael Richardson wrote: > > My colleague mouse, has a tool "git-interactive", which is like "git app -p" > in that it lets one stage chunks to a commit. If the RPC uses emacs, magit is a tool of choice for committing selected sets of changes. Grüße, Carsten __

[rfc-i] Re: Mutable properties of RFCs

On 16. Apr 2025, at 19:37, Jean Mahoney wrote: > >> rfc2497 > > [JM] Has an em dash in the [EU164] reference. *If* you decode it as ISO-8859-1, there is a soft hyphen (not an em dash) in that file (in http://stan­dards.ieee.org/ ). If I decode it as Mac-Roman (to pick

[rfc-i] Re: Can we add ORCIDs to the XML vocabulary?

On 2025-04-14, at 17:33, John R. Levine wrote: > > Remember the point of this dicussion, that ORCID is an identifier that is > likely to help find people whose contact info has gone stale. An > "unmaintained" library catalog doesn't strike me as useful for that purpose. There is no doubt that

[rfc-i] Re: Can we add ORCIDs to the XML vocabulary?

On 14. Apr 2025, at 03:08, John R. Levine wrote: > > That would work although I would be pretty surprised if there were another > identifier other than ORCID. It's been around for over a decade and everyone > in academic publishing uses it. Well, I don’t know about you, but maybe I’d like to

[rfc-i] Re: Can we add ORCIDs to the XML vocabulary?

Technically speaking, this is a link relation type, as defined in RFC 8288 [1]. [1]: https://www.rfc-editor.org/rfc/rfc8288#section-2.1 A registry is at: https://www.iana.org/assignments/link-relations/ [2]: https://authors.ietf.org/rfcxml-vocabulary#address [3]: https://authors.ietf.org/rfcxml

[rfc-i] Re: Mutable properties of RFCs

On 20. Mar 2025, at 07:11, Robert Sparks wrote: > > > On 3/20/25 11:09 AM, Carsten Bormann wrote: >> On 20. Mar 2025, at 04:45, Jean Mahoney >> wrote: >>> [JM] TEXT is used for RFCs created in the RFCXML v3 era. ASCII is for older >>> RFCs. The TEXT l

[rfc-i] Re: Mutable properties of RFCs

On 20. Mar 2025, at 04:45, Jean Mahoney wrote: > > [JM] TEXT is used for RFCs created in the RFCXML v3 era. ASCII is for older > RFCs. The TEXT label indicates the file can contain non-ASCII characters [2]. There are a dozen or so pre-v3 RFCs that are beyond-ASCII. (And actually a couple that a

[rfc-i] Re: [saag] Re: Re: RFCs vs Standards

On 14. Dec 2024, at 20:23, Randy Bush wrote: > >> Or if somebody suggests doing half of the work on slack, point to: >> https://specificsuggestions.com/share/EN/4299.html > > of course that does not apply to github issues vs mailing list > discussion Actually, IETF and its precursors started to

[rfc-i] Re: [saag] Re: Re: RFCs vs Standards

On 2024-12-13, at 18:49, Randy Bush wrote: > >> There are a lot of people who have mastered using the CIA simple >> sabotage field manual >> https://www.cia.gov/static/5c875f3ec660e092cf893f60b4a288df/SimpleSabotage.pdf > > charaacterizing folk who disagree with you as saboteurs is neither > pol

[rfc-i] Re: [saag] RFCs vs Standards

>> The way things are arranged here kind of works, even if ugly in come >> corners, and nobody has yet come up with a proposed change that would >> actually improve the outcome. >> > On 2024-12-11, at 15:01, Eric Rescorla wrote: > Rather, nobody has come up with a proposed change that can get

[rfc-i] Re: [saag] RFCs vs Standards

On 2024-12-11, at 13:56, Eliot Lear wrote: > > For what it's worth, I have far less of a problem with IANA assignments to > drafts than I do with drafts not being considered working documents. I believe the magical solution to all this is: Make no changes. The way things are arranged here k

[rfc-i] Re: [ianabis] [saag] Re: RFCs vs Standards

On 10. Dec 2024, at 22:32, Joel Halpern wrote: > > Where we disagree seems to be in the reading of RFC 8126. If we want to give > the Expert latitude to decide if the registry entry is allowed based on an > I-D, we use the "Expert Review" branch. If we want to require a > specification, we u

[rfc-i] Re: [saag] Re: RFCs vs Standards

On 10. Dec 2024, at 22:02, Joel Halpern wrote: > > 4) Related to 3, citing an I-D for an IANA registry that requires a stable > specification seems very odd. I agree with your first three points, but this one is off. The I-D by definition is guaranteed stable and accessible, so that is not th

[rfc-i] Re: [saag] RFCs vs Standards

or registries wanting RFCs there is “RFC >> required”. I am against any registry saying that "permanent and readily >> available" internet-drafts are NOT OK, but pointing to a website outside of >> the IETF is… > > On 12/10/24, 2:49 PM, "Carsten Bormann" mai

[rfc-i] Re: [saag] RFCs vs Standards

On 2024-12-10, at 13:52, John Mattsson wrote: > > • Internet-drafts are obviously "permanent and readily available", I > don’t see why that is debated. For registries wanting RFCs there is “RFC > required”. I am against any registry saying that "permanent and readily > available" intern

[rfc-i] Re: I-D expiry [was Re: RFCs vs Standards]

On 8. Dec 2024, at 02:15, Stephen Farrell wrote: > > > Hiya, > > On 07/12/2024 23:51, Carsten Bormann wrote: >> any I-D) being inappropriate to cite > > Well, I-Ds truly are not great things to cite because: > > - if you only cite the file name(e.g. [1]) th

[rfc-i] Re: [saag] Re: RFCs vs Standards

On 2024-12-06, at 02:28, Joel Halpern wrote: > > While we could change the policies, historically there have been very good > reasons why "specification required" does not have "openly available" as a > requirement. Among other things, we generally don't tell other SDOs how to > do business (

[rfc-i] Re: [saag] Re: RFCs vs Standards

On 2. Dec 2024, at 05:58, Joel Halpern wrote: > > Please don't mess with it. +1 Grüße, Carsten ___ rfc-interest mailing list -- rfc-interest@rfc-editor.org To unsubscribe send an email to rfc-interest-le...@rfc-editor.org