GeezerVison is showing github.com — TOML as an RFC? · Issue #870 · toml-lang/toml
DescriptionHave 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 registered1 -- 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
-
You don't need an RFC for the full format to get the registration -- but it does require some sort of standards publication. ↩
Reacted by Jan Pokorný, Dave Ostroske, Stargateur, Kevin Locke, Callum Watkins, Paul Hoffman, Timon Klinkert, Patrick Connolly, Oliver Kahrmann, Alfred Chow and 12 more Reacted by Marcus Johnson Reacted by Alfred Chow, Jozef Pazin and fry69 Reacted by A.J. Stein and fry69 Activitypaulehoffman commented on Mar 12, 2022 +1 to the "happy to help". @mnot and I both have written dozens of RFCs (although none together, yet). pradyunsg commented on Mar 13, 2022
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 commented on Mar 13, 2022 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. :-) Reacted by Patrick Connolly, Dave Ostroske, newhoa, Timon Klinkert, Sebastian Ehlert, mattshaw-revcomm, fry69, Nate Meyer and . mnot commented on Sep 29, 2022 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 commented on Sep 30, 2022 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. Reacted by Christian Siefkes and Bloo Alien ChristianSi commented on Oct 2, 2022 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. Reacted by Dave Ostroske and Bloo Alien mcarans commented on Oct 25, 2022 eksortso commented on Oct 25, 2022 mcarans commented on Oct 25, 2022 paulehoffman commented on Oct 26, 2022 I'm happy to help with the mechanical part of the RFC process, including the Markdown stuff. Reacted by Patrick Connolly, Pradyun Gedam and Alexander Pushkov robertlagrant commented on Mar 5, 2024 Just wondering if this is likely to happen. I don't see it in the registry. We have a use for it! eksortso commented on Mar 5, 2024 Your use may give this process a boost! What's your use case? aamelnikov commented on Sep 6, 2024 Hi,
I am one of designated expert reviewers for Media Types appointed by IETF and I just received a request to register application/toml using the following template:
Name: Ben van Hartingsveldt
Email: [email protected]
Media type name: application
Media subtype name: toml
Required parameters: N/A
Optional parameters: N/A
Encoding considerations: 8bit
Security considerations: (1) TOML files don't contain executable content.
(2) Information contained in TOML files do not require privacy or integrity services. If a client is storing information that is potentially sensitive, some sort of security is recommended. TLS, and specifically HTTPS, are the recommended way to protect potentially sensitive information.
Interoperability considerations: N/A
Published specification: https://toml.io/
Applications which use this media: Various
Fragment identifier considerations: N/A
Restrictions on usage: N/A
Provisional registration? (standards tree only): No
Additional information:
- Deprecated alias names for this type: none
- Magic number(s): none
- File extension(s): .toml
- Macintosh file type code: TEXT
- Object Identifiers: none
General Comments:
Person to contact for further information:
- Name: Ben van Hartingsveldt
- Email: [email protected]
Intended usage: COMMON
Author/Change controller: Ben van Hartingsveldt
Do you have any objections/support/have correction(s) to this registration?
In particular note that the "Change controller" is the person who is contacted when further changes (for example if you decide to publish an RFC describing TOML format) to the media type registration are suggested. (Also note that there is no implication that the Change Controller of the registration has any control over the underlying format.)
Best Regards,
Alexey Reacted by Alexander Pushkov, Christian Siefkes and fry69 paulehoffman commented on Sep 6, 2024 The TOML project seems to be either dead (stuck at 1.0.0) or badly wedged; see #928
Having a media type that does not specify the version may be acceptable, but is possibly dangerous, given that the proposed changes in 1.1.0 are breaking changes to the allow bytes in the format (that is, new restrictions on which Unicode charaters are allowed). OTOH, I'm sure that there are similar problems with other formats that have media types. Reacted by Alexey Melnikov Reacted by Christian Siefkes and fry69 ChristianSi commented on Sep 8, 2024 @aamelnikov While all the suggested values seem correct and I suppose this is a good-faith submission, having as change controller someone who seems to be unrelated to the TOML project is not a good idea, so I too suggest not to accept this submission for now.
Regarding the state of the project: it's currently stalled, because @pradyunsg, the sole remaining maintainer, has largely become inactive but failed to appoint any successors so far. However, there's still hope that that'll change sooner or later and at that point things might move swiftly again.
As for incompatible versions, there's actually no need to worry about that. All versions, from fairly early drafts (I think) up to the latest 1.1 draft, are backwards compatible. As TOML uses semantic versioning, the first breaking changes might come with 2.0, and that's certainly a long time off, if it ever comes. paulehoffman commented on Sep 8, 2024 I agree that having an unrelated person as the change controller is a bad idea. @ChristianSi: are you maybe willing to step up for that role? There is nearly nothing to do but be available for questions in the foreseeable future.
As for the "incompatible versions" part: is there a full list of diffs from 1.0.0 to the intended 1.1.0? I thought that I saw the allowed characters list in parts of 1.1.0 was smaller, meaning that some valid 1.0.0. documents would become invalid. If I'm wrong about that, I'm happy. ChristianSi commented on Sep 9, 2024 @paulehoffman:
@ChristianSi: are you maybe willing to step up for that role? There is nearly nothing to do but be available for questions in the foreseeable future.
Thanks for the suggestion, but while I'm involved with TOML, others such as @eksortso are even more so, and in any case I'm afraid that without a functional maintainer structure such a decision would be arbitrary.
As for the "incompatible versions" part: is there a full list of diffs from 1.0.0 to the intended 1.1.0? I thought that I saw the allowed characters list in parts of 1.1.0 was smaller, meaning that some valid 1.0.0. documents would become invalid. If I'm wrong about that, I'm happy.
Yes, see the "unreleased" section at the start of the Changelog.
There it says: "Relax comment parsing; most control characters are again permitted." So it's the opposite of what you thought: TOML 1.0 is fairly restrictive in what it allows in comments, possibly causing parsing to fail because of stuff that's commented out, which is unintuitive and might lead to nasty surprises, since people generally expect text in comments to be ignored rather than cause parsing errors. So TOML 1.1 attempts to correct that as far as reasonably possible, accepting more documents but never rejecting any that were already valid. mnot commented on Sep 9, 2024 The change controller doesn't need to be a person -- e.g., if you have a community mailing list that could do it - or maybe even the GitHub issues list (although that might raise some eyebrows?).
Another approach would be to nominate Tom Preston-Werner. arp242 commented on Sep 9, 2024 Tom has been active even less than Pradyun.
I think the issue list is fine, and better than any single person. There isn't really an email address for it though. paulehoffman commented on Sep 9, 2024 Or, maybe leave it blank. It is a "general comment", and I think a correct answer is "None". I like @mnot's suggestion, but that is probably a worse can-o-worms than "None" paulehoffman commented on Sep 9, 2024
As for the "incompatible versions" part: is there a full list of diffs from 1.0.0 to the intended 1.1.0? I thought that I saw the allowed characters list in parts of 1.1.0 was smaller, meaning that some valid 1.0.0. documents would become invalid. If I'm wrong about that, I'm happy.
Yes, see the "unreleased" section at the start of the Changelog.
There it says: "Relax comment parsing; most control characters are again permitted." So it's the opposite of what you thought: TOML 1.0 is fairly restrictive in what it allows in comments, possibly causing parsing to fail because of stuff that's commented out, which is unintuitive and might lead to nasty surprises, since people generally expect text in comments to be ignored rather than cause parsing errors. So TOML 1.1 attempts to correct that as far as reasonably possible, accepting more documents but never rejecting any that were already valid.
Thanks! I had misread this in some other comment in an issue or PR. I'm happy that alll of what is proposed is forwards-compatible.
It would be grand if @pradyunsg would cede control to one of the many people here who seem eager, we get 1.1 out, and then put it in the freezer. Reacted by Christian Siefkes aamelnikov commented on Sep 9, 2024
The change controller doesn't need to be a person -- e.g., if you have a community mailing list that could do it - or maybe even the GitHub issues list (although that might raise some eyebrows?).
Another approach would be to nominate Tom Preston-Werner.
Tom Preston-Werner should probably be listed as "Author", but doesn't need to be "Change Controller". aamelnikov commented on Sep 18, 2024
@aamelnikov Thanks for looking into this! Would you recommend getting a provisional registration for TOML in meantime?
I had to research this :-). Provisional might be the next best thing, but I think this can be registered in the main registry after some changes to the submitted registration template are made. ben221199 commented on Oct 14, 2024
Hi, I am one of designated expert reviewers for Media Types appointed by IETF and I just received a request to register application/toml using the following template:
Name: Ben van Hartingsveldt
Email: [email protected]
Media type name: application
Media subtype name: toml
Required parameters: N/A
Optional parameters: N/A
Encoding considerations: 8bit
Security considerations: (1) TOML files don't contain executable content.
(2) Information contained in TOML files do not require privacy or integrity services. If a client is storing information that is potentially sensitive, some sort of security is recommended. TLS, and specifically HTTPS, are the recommended way to protect potentially sensitive information.
Interoperability considerations: N/A
Published specification: https://toml.io/
Applications which use this media: Various
Fragment identifier considerations: N/A
Restrictions on usage: N/A
Provisional registration? (standards tree only): No
Additional information:
- Deprecated alias names for this type: none
- Magic number(s): none
- File extension(s): .toml
- Macintosh file type code: TEXT
- Object Identifiers: none
General Comments:
Person to contact for further information:
- Name: Ben van Hartingsveldt
- Email: [email protected]
Intended usage: COMMON
Author/Change controller: Ben van Hartingsveldt
Do you have any objections/support/have correction(s) to this registration?
In particular note that the "Change controller" is the person who is contacted when further changes (for example if you decide to publish an RFC describing TOML format) to the media type registration are suggested. (Also note that there is no implication that the Change Controller of the registration has any control over the underlying format.)
Best Regards, Alexey
Currently, the reviewer accepted on changing the information to the following, before it was sent to IESG for it to be grandfathered:
The submission was done with good-faith. Tom is mentioned as Author, I as Submitter and the Change controller is currently this issue #870. During submission, I just entered my own name to have a submission already and get the ball rolling. You don't need an RFC to have a media type registered at IANA, but I think it would be a good idea to have eventually TOML standardized in the RFC way. Reacted by Paul Hoffman, Christian Siefkes and Alexey Melnikov ben221199 commented on Oct 21, 2024 Reacted by Richard Gomez, GalaxySnail, Indra, Kevin Locke, Patrick Connolly, Tau Gärtli, Jeff L., Christian Siefkes, Eli, Siddhant Saraf and 2 more Reacted by Patrick Connolly, Tau Gärtli, Christian Siefkes, Stephen Walker-Weinshenker and Gabgobie arp242 commented on Oct 21, 2024 TOML is already standardized – right here. Most implementations follow this reasonably well. Reacted by Christian Siefkes patcon commented on Oct 21, 2024 Appreciate the effort, @ben221199!
re: #870 (comment)
I don't think this person has had any involvement in TOML (AFAIK); I don't think it's a good idea to record them as the contact. -- @arp242
@aamelnikov can you confirm or deny whether having someone minimally involved in the project is how we should leave it? Regardless, now that it's locked in as a milestone, who do you recommend be listed here? (It seems to me it should reflect someone active on the project, yes?) aamelnikov commented on Dec 16, 2024 @patcon Sorry I missed your earlier comment. I think the current registration is fine, as the "Change controller" points to this github issue. I think this gives IANA enough context if somebody contacts IANA and requests changes to the registration. Reacted by Christian Siefkes, Patrick Connolly and Pradyun Gedam pradyunsg commented on Apr 19, 2025 @aamelnikov @ben221199 I'd be happy for the point of contact for the project to be updated to Pradyun Gedam <[email protected]>. If there's a particular process for that, please let me know.
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|