ircv3-ideas

ircv3-ideas copied to clipboard

Currently we have very similar formatting in multiple places but each differ slightly (or currently being discussed):

• ISUPPORT tokens
• CAP
• Message tags
• WEBIRC extended info
• Metadata

We could do with picking and sticking to a format for any future key/val related structures for consistency. I bring this up now since the topic has arisen for the WEBIRC extended info format and being discussed for metadata.

Message tag format

• Full characters support including spaces with escaping
• Fits into a single IRC argument if required
• Requires escaping

ISUPPORT tokens

• Simpler to use
• Does not support spaces in values
• Cannot be used in a single IRC argument

Why is this important?

Having multiple ways to do the same thing causes confusion and extra bloat in our software. Consistency in a protocol is also important for implementors to stay sane. And I enjoy my sanity at times.

Personally I'm in favour of the existing message tag format being used as the standard key/val formatting, simply because it is the more flexible format and supports spaces that may be required. While some things may not need support for spaces and other characters, consistency is still an important factor and we don't want to be locking things in such a way that it can't be extended in future.

Thoughts?

Quick addition as @SaberUK mentioned on IRC; ISUPPORT tokens do in fact support spaces but using a different format than message tags.

Examples of each for comparison:

ISUPPORT tokens (spaces escaped as \x20, k/v indicated by = and separated by space, : and , used within keys for nesting/lists, as well as some custom rules)

KEY1=space\x20value TARGMAX=NAMES:1,LIST:1 PREFIX=(qaohv)~&@%+ {"KEY1": "space value", "TARGMAX": {"NAMES": 1, "LIST": 1}, "PREFIX": {"q": "~", "a": "&", "o": "@", "h": "%", "v": "+"}

CAP (no spaces allowed, k/v indicated by = and separated by space, = and , used within keys for nesting/lists)

sts=duration=123,port=6697 sasl=PLAIN,EXTERNAL {"sts": {"duration": "123", "port": "6697"}, "sasl": ["PLAIN", "EXTERNAL"]}

Message tags (spaces escaped as \s, k/v indicated by = and separated with ;, json used for complex values)

displayname=james\swheare;+draft/emoji=[{"url":"https://example.com/emoji.png","idx":[[0,1]]}] {"displayname": "james wheare". "+draft/emoji": [{"url":"https://example.com/emoji.png","idx":[[0,1]]}]}

Metadata (spaces allowed in last param, only one k/v per line, standard irc args)

METADATA * key * :space value {"key": "space value"}

WEBIRC extended info (spaces support undefined, nesting undefined, k/v indicated by = and separated by space) WEBIRC <password> <gateway> <hostname> <ip> :flag1 flag2=x flag3 {"flag1": null, "flag2": "x", "flag3": null}

It's worth noting that nested/complex data type representations aren't really standardised in any high level spec, but are defined by convention on a per key basis. This is probably an oversight that we should avoid repeating for future specs if they need complex values.