Skip to content

Relax ISUPPORT key syntax to allow vendor prefixes #250

Open
@emersion

Description

@emersion

This would allow for e.g. draft/FOO and soju.im/BAR.

Motivation: right now ISUPPORT is first-come first-served, ie. as soon as a server starts introducing its own server-specific ISUPPORT token without asking anyone else the token cannot ever be re-used if it's not general enough.

For instance, if soju starts advertising FILEHOST as an HTTP POST endpoint and HTTP authentication based on IRC credentials, and the standardization process ends with a different consensus, then the final token will need to be FILEHOST2 or something, or else existing clients will break. As another example, maybe soju starts shipping ICON, and the standardization process ends up with a consensus that a size template is desirable, then existing clients will misbehave because they won't handle the templating.

Additionally, the unprefixed token doesn't make it clear where the token is coming from (is it a vendor extension, a draft, or a standard thing?).

In general, having ISUPPORT tokens as first-come first-served doesn't foster discussion among IRC developers. Everybody just does their own thing and ends up having to go along with whatever the first person designed, or come up with their own mostly similar but slightly different ISUPPORT token.

IRCv3 capabilities have prefixes exactly for this reason. Why should we have prefixes for caps but not for ISUPPORT, since without prefixes both can result in client breakage?

soju and Ergo already send vendor-prefixed ISUPPORT tokens, and no client breakage has been reported.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions