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¹ -- done

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.

[mcarans]

Is there a plan for releasing 1.1? I think it would be a good prompt for library implementers to support the significant changes that have been made since 1.0. That in turn will hopefully prompt some developers who've been reticent to use TOML (and specifically pyproject.toml) to reconsider since I think the changes overcome concerns or limitations that they had raised.

[eksortso]

@mcarans This would be better discussed in #915, I think. It's a little off-topic here, though I knew v1.1.0 would be released at some point (there's no timeframe set yet) when I posted a few weeks ago.

This is a significant subject, I know, because Python 3.11 was released yesterday, and it has built-in support for TOML parsing in its standard library (the tomllib module, based on tomli. Standard libraries change slowly, and I know that. But the exposure to the format will draw interest from new users.

[mcarans]

@eksortso Thanks for your reply. I have put my comment where you suggested. I'll just say here for completeness that I see a PR in tomli to introduce one of the most important changes since TOML 1.0 but it looks like it is stuck in draft awaiting that change to be official (ie. in a 1.1 release).

[paulehoffman]

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