[meta] Capability names we develop with SHOULD NOT be the same as the final names

[DanielOaks]

The capability names that are used for in-progress specifications should not be the same names that are used on the final, ratified versions of those specifications.

We should not use the same names on draft specs because people will write clients and/or servers to that draft spec, particularly as a part of #215's new process and the implementation requirements. If the spec is changed in major ways to fix problems found by implementers, we will run into issues where some clients and servers respond to that capability name with the old, in-development behaviour of that spec.

We can tell implementers not to put the code responding to those draft features into public releases, but I think so long as the same name is used for draft and final caps, this will happen and may cause us issues. Especially for long-standing draft issues, like if sts sits as a draft for quite a while and we end up significantly changing it.

Here's an example of what I mean:

• Draft name: draft/sts-1
• Draft name: draft/sts-2
• Draft name: draft/sts-3
• Final: sts

We don't want to use the vendor tag to say the name of the implementer that put forth the feature, because it's being workshopped as an IRCv3 spec. We don't want to use the name of the IRCv3 org, because people may think it has our 'approval' due to that.

Under this sort of process, it would be submitted with the draft name, and any implementations for it would respond to the draft name. When it becomes ratified as part of an IRCv3 release it would be changed to the final name.

See also #215

[M2Ys4U]

It's worth considering the advice in RFC 6648 - Deprecating the "X-" Prefix and Similar Constructs in Application Protocols here.

[attilamolnar]

@M2Ys4U
Are you referring to

Creators of new parameters to be used in the context of application
protocols:

1. SHOULD assume that all parameters they create might become
   standardized, public, commonly deployed, or usable across
   multiple implementations.
2. SHOULD employ meaningful parameter names that they have reason to
   believe are currently unused.
3. SHOULD NOT prefix their parameter names with "X-" or similar
   constructs.

[jwheare]

X-header deprecation is a controversial matter, and there is arguably still a use for them, mainly as internal headers that only apply to a very specific server or client. I think that's the sweet spot for vendor prefixing.

Similarly vendor prefixed CSS features are controversial [1] [2]

---

I think we need to decide how we want CAP versioning to work. As mentioned re: invite-notify in: #206 (comment) there's a need to define a convention for this, and consider how it will work.

Let's consider an example of a CAP that goes through drafts, into release and then has several version bumps:

foo-draft
foo-draft-2
foo
foo-2
foo-3

1. Servers will initially advertise foo-draft to allow initial implementation testing from clients. At this stage, no promises are made for long term support, draft CAPs might disappear at any time.

2. And so, a significant modification is made to the draft and foo-draft-2 begins to be advertised. At this point, foo-draft will likely go away, and any clients that supported it may remove support.

However, there is a risk that some servers retain foo-draft support and then cease to continue development. In that case, a client MAY choose to keep support for the draft spec in CAP negotiation, because it might provide useful functionality even on badly maintained servers, as long as they're happy to maintain client support, but the likely and desired outcome is that the draft disappears from use entirely.

Similarly, servers MAY choose to keep advertising draft specs in case clients are no longer maintained. It will likely come down to how useful a feature is (even in draft form) and how broadly used the unmaintained client/servers are.

In this case, clients MUST only request the newest version, and servers MUST treat it as an error to request multiple versions.

3. So, now the spec is finalised and foo is ratified. As an aside, given CAPs are being versioned independently, I think this leads to specs being published independently from an overall release cycle, e.g. 3.3. Holding up specs until an arbitrary number are ready to be published is needless in my opinion.

At this point, again the draft specs will hopefully disappear from use, but if not, no biggy.

4. At this stage, backwards incompatible changes are made to foo and a new version needs to be released, so foo-2 is born. In this case, the previous foo is much more likely to stick around, so clients may of course request the old as well as newer versions.

At this stage is that servers/clients are more likely to advertise/support multiple versions of a spec, to ensure as broad client support as possible. The latest version behaviour from before still apples.

5. Again, backwards incompatible changes are made, and foo-3 is born, at this stage, the initial foo may start to be withdrawn, but there's no rule about it.

---

So, points for discussion:

• Draft naming scheme
• Version number suffix scheme
• Version as CAP value? Doesn't work as standard for CAPs that already use their value, no standard syntax for multi-value or key-value caps is defined, though STS uses sts=key1=value1,key2=value2 and SASL3.2 has comma separated values.
  Perhaps a foo=v=1 value could be defined for this purpose, possibly requiring CAP LS 303
• Publishing specs and spec updates independently of a bundled overall version number

An example of versioned specs from browsers: WebSocket, using the Sec-WebSocket-Version header: https://en.wikipedia.org/wiki/WebSocket#Browser_implementation

---

Also, is it worth thinking about how deprecation will work? Will servers start to send warnings to clients that request deprecated (but still advertised) CAPs? Will clients issue warnings to users when connecting to servers that only advertise deprecated CAPs?

This is probably undesirable, as these warnings will end up being shown to users who can't do anything about them (apart from put pressure on client developers/network operators to upgrade, probably a hopeless battle).

[Mikaela]

There is also issue that many users might not receive updates with the final capabilities if they are using from repository.

With ZNC the issue is so bad that the topic says how old specific versions are:

www.znc.in | ZNC 1.6.2: http://wiki.znc.in/ChangeLog/1.6.2 | ZNC 1.6.3-rc1 | http://znc.in/nightly | https://github.com/znc/znc | Development at #znc-dev | Debian stable: 1.4 is 1.5 years old | Debian oldstable: 0.206 is 3.5 years old | don't randomly PM people | https://blog.mehl.mx/2014/i-love-znc-because-ilovefs/ | znc.pem is currently reloaded every connect

Debian olstable is still widely used and it's very common to encounter user claiming to be on the latest version and then the version output says

With WeeChat again the latest version is 1.4, but thanks to Debian 0.3.8 is widely encountered too.

I am sure this issue is not specific to Debian and ZNC and WeeChat and it's something that should be considered before removing draft versions as "everyone will just use the latest version of the client anyway".

Oh, and I don't know how much mIRC is cared about, but I imagine as it has a lot of cracked versions around, it's probably fragmented like Android.

All pre-7.0 versions of mIRC don't support cap in the first place, and mIRC encourages people to implement CAP support via script anyhow (e.g. sasl, since user auth is not something mIRC does itself).

[DanielOaks]

We seem to be doing this to some degree currently, so... this can be closed I guess. We should probably have a note about it somewhere at some point.