ircv3-ideas

ircv3-ideas copied to clipboard

At the moment we use the draft/ prefix for spec proposals that are seeking IRCv3 standardisation.

This has the benefit of not cluttering the CAP/tag namespaces with proposals that end up being rejected or modified to the point of incompatibility.

However, it also means that implementations need to keep supporting these draft/ prefixed specs for an indefinite period of time. The longer a spec takes to be finalised, the worse this gets.

It's worth considering how this issue played out on the web platform, with the deprecation of the "X-" prefix for non-standard HTTP headers:

https://datatracker.ietf.org/doc/html/rfc6648

I think it might be time to deprecate draft/ for published (i.e. merged) work in progress specs. We can continue to use them for initial proposals, test implementations, and vendors should continue to use their own prefixes for private use specifications.

Any thoughts?

Refs:

• https://ircv3.net/specs/extensions/capability-negotiation#draft-capabilities
• https://ircv3.net/specs/extensions/message-tags#drafts
• https://github.com/ircv3/ircv3-specifications/pull/215
• https://github.com/ircv3/ircv3-specifications/issues/221

I think it might be time to deprecate draft/ for published (i.e. merged) work in progress specs.

I'm worried this would encourage us to keep PRs open for very long times, for fear of releasing a bad "undraft" version.

Otherwise, I don't mind either way.

As there are a couple of new draft specs ready to merge, it would be good to get a resolution on this.

@SadieCat can you elaborate on your thumbs down?

I'd particularly appreciate any opinions from people who implement drafts and @DarthGandalf @DanielOaks @grawity @syzop @edk0 @jesopo @slingamn

👍 is fine, please elaborate with a comment if 👎

The current process has been working well for me, possibly because the complexity is pushed off onto other people. Here's what I've been doing:

1. Implement a draft/ spec in Ergo
2. Make possibly backwards-incompatible changes to it during the draft process, taking into account the state of the overall ecosystem. For example, with draft/chathistory, we made an incompatible change after publication (switching from the * target to the TARGETS subcommand) without bumping the version number, because all the implementers were on the same page about it and it didn't have the potential to create real-world incompatibilities. With draft/resume we bumped the version number repeatedly, ending up on draft/resume-0.5.
3. When the spec is ratified, strip the draft/ prefix on the server side and go straight to the ratified name. The prefixed name is no longer accepted, and clients are expected to negotiate the ratified name.

So, on the one hand it seems like I'm getting the better side of the bargain here, and other people may be having more difficulties with the status quo. On the other hand, it seems like if we had merged CHATHISTORY as chathistory, no prefix, we would now be on chathistory-1 or chathistory-1.1 or something, which seems like cruft and also like it would hamper our ability to "bury" the original, deprecated version.

Am I misunderstanding the issues at stake here?

I believe you're right. The tradoff here is "we need a useless rename from draft/xxx to xxx" VS "final versions are likely to contain a version number".