TOML as an RFC?

[mnot]

Have you considered publishing v1.0.0 as an RFC?

I can see two immediate benefits:

• The format would be easier to use / reference from other RFCs and by other standards efforts.
• You could get application/toml registered¹.

If you'd consider it, I'd be happy to help - you don't have to go through the full standards process, the independent stream would be very appropriate for this and comparatively lightweight.

Footnotes

1. You don't need an RFC for the full format to get the registration -- but it does require some sort of standards publication. ↩

[paulehoffman]

+1 to the "happy to help". @mnot and I both have written dozens of RFCs (although none together, yet).

[pradyunsg]

Have you considered publishing v1.0.0 as an RFC?

Yes! That's the motivation behind keeping the language grammer in ANBF.

IIUC, the blocker here is one of the authors figuring out the "paperwork" of the process and doing it. Help would very much be welcome! :)

[paulehoffman]

If one of the main contributors wants to step up as the primary author, I'm happy to walk you through the paperwork. @mnot will probably do so as well, and may agree with me on some of it. :-)

[mnot]

Definitely. Consider us at your disposal. From our side, we just need buy-in from the TOML project and someone to work with; we can handle the process issues, etc.

[eksortso]

I'm just a bit player here. But with a number of serious enhancements in the pipeline, TOML v1.1.0 would be a better candidate for an RFC once it's released. Is there an immediate demand for an RFC to be filed now, or can we take the time to propose one with TOML's new features?

Deferring until the v1.1.0 release would also give us an opportunity to move toward a set of documents that would line up more with the requirements of an RFC, where it would make sense to further that process in the project as it stands.

[ChristianSi]

Yes, I agree. The changes made since TOML 1.0 are significant and certainly justify the release of 1.1 in the foreseeable future. So, to be really future-proof, that's a better target for standardization.

[arp242]

I did a bit of work to write an "RFC-style" specification for TOML; still some work to do (I just wrote it as Markdown for now, as that's easier for me so I can focus on the text and not formatting).

An RFC will "lock down" TOML quite a bit; which is both a good and bad thing: it's good so we have a stable format we can rely on the long term, it's bad since updates will be harder. I think it would be good to make sure we really have everything nailed down first.

Looking at the open issues/PRs, "Add a duration/timedelta type" and "hex floatingpoint values" are something we can still go either way on; there's no clear consensus. "Implementation-defined values", "custom type syntax", and "add Filesize" seem like a fairly solid "no". "Relax comment parsing" is WIP, and the others are all clarifications or other things that don't really change the semantics.

I propose a future "TOML 1.1" (whenever that will be released) functions as a "RFC release candidate"; we can wait for a bit after its release for feedback from implementers and users, maybe make a few tweaks if need be, and then submit the RFC.

[paulehoffman]

I'm happy to help with the mechanical part of the RFC process, including the Markdown stuff.

[robertlagrant]

Just wondering if this is likely to happen. I don't see it in the registry. We have a use for it!

[eksortso]

Your use may give this process a boost! What's your use case?