The topic says it all, would be nice to have test vectors that are 'officially' valid, and ones which are officially 'invalid' so we can test for conformance in the parser.

Updated 3March2014

There's been a lot of discussion over IRC about the current implementation and how it appears to differ from implementation to implementation. Also some people don't like knock having it's own numerics.

In light of this, I think the best course is to go with a KNOCK cap, if it's enabled then we follow our implementation, if it's not enabled then we don't care. It'll fall-back to whatever the current server has decided to use for their implementation.

What we've got so far:
With no message: :knocking-user!ident@host KNOCK #chan
With message: :knocking-user!ident@host KNOCK #chan :user-message

We'll still need to form some sort of error message to give out if the channel is blocking knocks (+K on some servers) and similar. But this seems to be a good basis.

As per IRCv3.1, the optional away-notify extension is designed to keep track of a user state. The same can be said for the proposed MONITOR extension in IRCv3.2 but for a different state, being online or offline. Rather than having 2 different commands with two different syntaxes that do the same thing it may be easier to merge the two together to provide some consistency while keeping backward compatibility on the already published away-notify extension.

I see two changes to merge the two extensions:

1. Add 2 extra "states" available to a user on top of the current single "away" state - "online" and "offline".
2. While away-notify will only send an AWAY message to users sharing a channel with a state changing user, I propose that the MONITOR command tells the server to also notify us of the change of state for a target as if we were sharing a channel.

With the above changes, a client should be able to monitor multiple users without the need to be sharing a channel. This will enable clients "friends list" implementations to be developed far easier with more functionality while also keeping the syntax broad enough to allow future expansion with different states if required.

Possible MONITOR extension syntax changes
:<server> 730 <nick> <state>:target[,target2]*

Possible new syntax based upon away-notify
:nick!user@host STATE ONLINE|OFFLINE|AWAY [:message]

Only projects who participate in IRCv3 should be listed on website. It's better not to confuse people.

I am not sure if the title says anything, but discussion started at atheme/atheme#415 (comment) and there it was said that this is ircv3 thing.

I open this issue, because no one else seems to do it.

There was some discussion on IRC about how this could be done, some of them were:

• Log all #IRCv3 chatter
• Log all #IRCv3 chatter + grep 'terms' and tag all lines within 50 lines of these 'terms' as relating to a certain issue. (The issue they would be tagged as would be the grepped term)
• Opening GitHub issues and/or gists

So, all three of these have their ups and downs:

Log-all
Pro: This would be nice because any user could at any time read the backlog of the channel.
Con: Not many people like the idea of public logging, and in the case of private information accidentally being put out, there's not a whole lot you can do.

Log-all + grep
Pro: This is good for the same reason as the first, with the added benifit of being able to select the 'terms'/issues you wished to read backlog for, the grepping wouldn't be 100% perfect but it would work well enough for this, I believe.
Con: This is also bad for the same reason as the first, not many people like public logging, etc. Also this has the added downfall of someone needing to write a script to grep + tag issues to lines or do it manually.

I thought this was a great idea when I suggested it but after taking some time to review how it would be implemented I don't think it would be worthwhile to take time to add this.

Open Github issues
Pro: This is without a doubt the easiest one to implement. Before bringing up a discussion on IRC open a GitHub issue with all the relevent information about what you are suggesting and then ask for comments on IRC about how to go about it. This would require that the GitHub issue be updated whenever new information came up.
Con: We may end up with lots of unused github issues and some github issues may not get updated with new information as they should.

All-in-all after looking over the three major options that were given on IRC, I'm in favor of the third option. This would require some slight changes to the way issues are updated but I think it would help sort out a couple of issues I see on IRC, those issues being:

• Constantly reitterating what was said previously because someone was absent
• Lack of any prior log of why a specification was changed

Now the account-tag issue for example, that went through at least 5 major changes since it was originally opened on github and due to there being no public log to why those changes happened some of them were reverted once and some multiple times, by the third or fourth itteration we were right back where the spec originally started before it changed again.

I think that all changes to a specification should not be squashed and the original commit messages should stand until it is ready to be merged into master so that during the on-going discussion there is a clear trail of what has happened and why.

Also, the issue-head should be updated each time the specification changes to reflect the new specification and to explain why something-X was chosen over something-Y. I think that by doing this the end-result will be less needless changes and a cleaner discussion platform for debates to happen on.

Hello,

I brought this up with @kaniini and he asked me to file a bug. In the course of compiling numerics for my IRC library, I located the following conflicts between numeric 270:

Inspircd:
RPL_MAPUSERS - (comment: insp. specific)
RPL_PRIVS - charybdis (says it comes from ircu who added it in 2000, before inspircd existed ;p).

I think this is a bug, so I'm posting it here. Numeric conflicts aren't a good thing.

This includes/references all non-complete tasks from 25 January 2014 (#34).

BATCH:

• Batch limits were a bad idea. Remove them.
• Add batch types (netsplit/netjoin/etc.) to indicate how messages are associated. (gist)
• Note that empty batches can occur.
• Batch reference tags are opaque strings.

CAP 3.2:

• Add an optional version number to CAP LS indicating support for IRCv3.2 CAP.
• Add cap-notify for notifying on changes in cap availability, as a separate specification not tied to CAP 3.2.

SCTP:

• Add specification for SCTP support.
• SCTP support MUST include a requirement for DTLS.

Title pretty much says it all. I will not participate in this any further until it occurs.

One of IRC's biggest drawbacks is that sessions are bound to the lifetime of a single TCP connection. This is what makes it unsuitable for the mobile networks of the current decade.

I suggest the following, provided that the client presents an SSL client certificate: Implement a "RESURRECT old-nickname" command as an alternative to the normal NICK/USER on connect. Provided that the client certificate matches the client certificate on the session of old-nickname, old-nickname's connection will be terminated and replaced by the new TCP connection. Since the client already knows the state, this eliminates the current nasty quit/join as well as the retransmission of most of the state.

Things to consider:

• How should the server determine which data has not arrived at the client the previous time? Is there a portable way to determine how much data on a TCP connection was not yet ACKed by the client and to simply resend this data over the new socket? (not quite so easy, since SSL and padding is getting in the way. The easiest way might be to send data, and check whether the previous data was ACKed before subsequent calls to write(2))
• What do we do if the hostmask changed because the client switched from 3G to wifi or vice versa.

Comments welcome, since this is a very rough draft (but something I would consider to be very important).

Edit: fixed markdown.

http://wiki.znc.in/Privmsg

Adding away-notify and account-notify support to MONITOR. Users will get the 'updates' from away and account notify with MONITOR if they have those capabilities enabled.

The client should send MONITOR + <nick> when the user PMs another person, NOT when the user recieves a PM. After so much inactivitiy the client should auto-remove the MONITOR

Normal usage:

:nick!user@host PRIVMSG nick2 :initial pm
MONITOR + nick2
:nick2!user@host ACCOUNT nick2
:nick2!user@host AWAY :I'm not currently here

and then after so much inactivity, the client can send MONITOR - nick2

In the case of the current MONITOR list being full, clients would need to respect the MONITOR=XXX in the 005 numeric and remove a user before sending another, eg:

:nick!user@host PRIVMSG nick2 :initial pm
MONITOR - oldnick
MONITOR + nick2
:nick2!user@host ACCOUNT nick2
:nick2!user@host AWAY :I'm not currently here

Only clients that support away-notify or account-notify should be getting the AWAY/ACCOUNT messages, the rest would get the MONITOR-specific stuff.

Clients should maintain two lists for MONITOR, one that users specify in the clients that should be on the MONITOR list 100% of the time, and another that is used for the query-specific stuff.

If/When clients have to remove old nicknames they should never remove nicks from the list of nicks that users want to be on the list 100% of the time, only from the second list.

I made this topic to track the status of the IRC discussion, I think it all the non-metadata specific stuff in it, because quite frankly I don't understand the metadata stuff yet. I will update it with new information when/if new information is given.

It would be cool if all Markdown files had the .md filename suffix – then Github itself could render them and I could link to a specific file when there's a delay in updating the main website.

If a server can no longer support a CAP that was requested by a client and ACKed by the server(e.g. a module being unloaded), what should the server send to the client so that the client can be aware of this?

Specification draft available here

With the recent issues of backwards compatibility with CAP LS 3.2 things I propose changing the name of capabilities from name to name-X.X where X.X is the IRCv3 version it was released with.

So all current specifications would stay without a version and are defaulted to version 3.1, all 3.2 specs should be renamed to 'spec-3.2' before it's final release. (Eg: batch-3.2)

The reasoning behind this is simple, new technology could come out that previous specifications would benefit from, extended-join is a good example, it could use the account tag from 3.2.

This would require absolutely ZERO change for the client author wanting to implement this, aside from requesting extended-join-3.2 for example instead of extended-join.

So, let's say we release batch-3.2 with the IRCv3.2 release, batch does fine for 4-5 versions before there finally needs to be a revision to it. It's as simple as adding the revisions and re-releasing it as batch-3.7. Clients can update and start requesting batch-3.7 when the support it, and continue requesting batch-3.2 until they do.

But to think that these specifications will not change at all for the duration of IRCv3 is simply not possible. The extended-join is just the first example of this, it will happen again.

This was originally a smaller post under issue #60 but I have moved it here as it is an entirely separate issue.

Client attaches a cookie to the request and get that same cookie back in the response message(s).
Useful for ZNC, when multiple clients are connected, instead of hacky http://wiki.znc.in/Route_replies

See #51

There's been some discussion over this and the simplest thing to do would be to add something like MSGLEN=512 to the 005 numeric. Similar to AWAYLEN, NICKLEN, and CHANNELLEN, etc.

Reasons for doing this instead of a CAP

• Line lengths should be the same for every user, so there's no confusion over what portion of a message a user actually saw.
• It's not going to break clients. Clients that care about the 512 limit will truncate, clients that don't care will read from the line as they always have.
• This is how the length of many other things were added, for clients that support reading from the 005 numeric for things such as this it would be a trivial fix to add MSGLEN=XXX
• Clients don't actually need to support CAP for this to work. Making it easier for clients that don't support CAP to implement this.
• There's nothing to actually 'negotiate' here. It's simply stating the max length of the line for the specific server.

If a CAP is added then users with the CAP should not be able to send messages over 512bytes to anywhere that contains a user without the CAP. It should not truncate or split the line, it should return an error.

Mode/topic/etc lines should error if the line is over 512 bytes with users in the channel that do not have the CAP enabled.

Currently, there is some disparity in client support of the STATUSMSG extension. I would like to include provisions for STATUSMSG in IRCv3.The current "IRCv2" STATUSMSG implementation has a 005 token advertise that STATUSMSG is supported, and a client sends a STATUSMSG by prefixing a channel name with one of the characters found in the value of STATUSMSG, which corresponds to a PREFIX flag. This same construct is then sent to those clients that receive the message, but not all clients correctly handle all such cases.

I would like a CAP token be added for covering STATUSMSG support, with the following effects:

• The capability token for STATUSMSG merely indicates support or no support: the actual prefixes in question would stay in 005 as they are now.
• If a client requests the STATUSMSG capability, it MUST correctly handle any channel name prefixed with any STATUSMSG character in any PRIVMSG or NOTICE message, treating them the same as normal channel messages. The server shall send these STATUSMSG prefixed messages, basically exactly as it does currently.
• A server MUST NOT support a character as both a STATUSMSG prefix and as a CHANTYPE.
• If a client that negotiates capabilities does NOT negotiate the STATUSMSG capability, then the server SHALL NOT send any channel name prefixed with any STATUSMSG characters. The server will still deliver messages sent this way, just the client would not be able to distinguish them. The server SHOULD reject any such message sent by the client.
• A server is NOT required to remove STATUSMG from its 005 if a client negotiates no support for STATUSMSG.

For clients that do not negotiate capabilities, IRCv2 fallback basically has us treating the client as if it had sent the token.

capability-negotiation in my opinion, would be better served to users if it was a rolling version.

Currently we have just CAP LS, but we want to add things to 3.2 which may break 3.1, see #34

My proposal is we keep a rolling version of CAP to be equal to the current version of the IRCv3.x spec.

• Requesting CAP LS will default to 3.1 and will send all 3.1 specs, as well as higher specs that can be sent in the 3.1 version of CAP.
• Requesting CAP LS v3.2 will send all specifications 3.2 and below, as well as higher specs that can be sent in the 3.2 version of CAP.
• So on and so forth up the version ladder.

Doing things this way means that updating CAP itself will not break clients who depend on a previous version of the spec, and will have time to rewrite their implementation before requesting the newer version to get the capabilities associated with it.

All new specifications being written should have a section denoting the lowest CAP-version they support, so authors will know not to send those to clients requesting a version lower than that.

Versioning capabilities was moved from this issue to #61

The index doesn't have full links to requirements so I had to copy-paste it and fix the links by myself (for https://github.com/ProgVal/Limnoria/issues/1015).

## IRCv3.1

### Base Extensions
* [ ] [IRC Version 3.1: Capability Negotiation](https://github.com/ircv3/ircv3-specifications/blob/master/specification/capability-negotiation-3.1)
* [ ] [IRC Version 3.1: `multi-prefix` Extension](https://github.com/ircv3/ircv3-specifications/blob/master/extensions/multi-prefix-3.1)
* [ ] [IRC Version 3.1: `sasl` Extension](https://github.com/ircv3/ircv3-specifications/blob/master/extensions/sasl-3.1)

### Optional Extensions

* [ ] [IRC Version 3.1: `account-notify` Extension](https://github.com/ircv3/ircv3-specifications/blob/master/extensions/account-notify-3.1)
* [ ] [IRC Version 3.1: `away-notify` Extension](https://github.com/ircv3/ircv3-specifications/blob/master/extensions/away-notify-3.1)
* [ ] [IRC Version 3.1: `extended-join` Extension](https://github.com/ircv3/ircv3-specifications/blob/master/extensions/extended-join-3.1)
* [ ] [IRC Version 3.1: `tls` Extension](https://github.com/ircv3/ircv3-specifications/blob/master/extensions/tls-3.1)

## IRCv3.2

* [ ] [IRC Version 3.2: Capability Negotiation 3.2](https://github.com/ircv3/ircv3-specifications/blob/master/specification/capability-negotiation-3.2.md)
* [ ] [IRC Version 3.2: Message Intents](https://github.com/ircv3/ircv3-specifications/blob/master/specification/message-intents-3.2.md)
* [ ] [IRC Version 3.2: Message Tags](https://github.com/ircv3/ircv3-specifications/blob/master/specification/message-tags-3.2.md)
* [ ] [IRC Version 3.2: Metadata](https://github.com/ircv3/ircv3-specifications/blob/master/specification/metadata-3.2.md)
* [ ] [IRC Version 3.2: `account-tag` Extension](https://github.com/ircv3/ircv3-specifications/blob/master/extensions/account-tag-3.2.md)
* [ ] [IRC Version 3.2: `monitor` Extension](https://github.com/ircv3/ircv3-specifications/blob/master/specification/monitor-3.2.md)

### Optional Extensions

* [ ] [IRC Version 3.2: `account-tag` Extension](https://github.com/ircv3/ircv3-specifications/blob/master/extensions/account-tag-3.2.md)
* [ ] [IRC Version 3.2: `batch` Extension](https://github.com/ircv3/ircv3-specifications/blob/master/extensions/batch-3.2.md)
* [ ] [IRC Version 3.2: `cap-notify` Extension](https://github.com/ircv3/ircv3-specifications/blob/master/extensions/cap-notify-3.2.md)
* [ ] [IRC Version 3.2: `chghost` Extension](https://github.com/ircv3/ircv3-specifications/blob/master/extensions/chghost-3.2.md)
* [ ] [IRC Version 3.2: `invite-notify` Extension](https://github.com/ircv3/ircv3-specifications/blob/master/extensions/invite-notify-3.2.md)
* [ ] [IRC Version 3.2: `sasl` Extension](https://github.com/ircv3/ircv3-specifications/blob/master/extensions/sasl-3.2.md)
* [ ] [IRC Version 3.2: `self-message` Extension](https://github.com/ircv3/ircv3-specifications/blob/master/extensions/self-message-3.2.md)
* [ ] [IRC Version 3.2: `server-time` Extension](https://github.com/ircv3/ircv3-specifications/blob/master/extensions/server-time-3.2.md)
* [ ] [IRC Version 3.2: `userhost-in-names` Extension](https://github.com/ircv3/ircv3-specifications/blob/master/extensions/userhost-in-names-3.2.md)

## Additional Documentation

*  [ ] [SASL: DH-AES mechanism](https://github.com/ircv3/ircv3-specifications/blob/master/documentation/sasl-dh-aes.md)
*  [ ] [SASL: DH-BLOWFISH mechanism](https://github.com/ircv3/ircv3-specifications/blob/master/documentation/sasl-dh-blowfish.md)
*  [ ] [Batch: `netsplit` type](https://github.com/ircv3/ircv3-specifications/blob/master/extensions/batch/netsplit.md)

Specification draft available here

There was a discussion on IRC about not allowing MONITOR to accept hostmasks due to the amount of time you may have to spend doing lookups on connect/disconnect/away/account/etc if the server has many different hostmasks being monitored.

How hostmasks differ:
If you are matching nicks then when a user connects you could instantly lookup that nick. There would be no confusion about which MONITOR that nick belongs to.

With hostmasks, since you can do *!*@example.com, or *[email protected], or even *!*@*.com, a connecting user may match multiple different MONITORs and this would mean you would have to loop for every MONITOR to check which one(s) it matches.

This also means that if using away-notify and account-notify with MONITOR integration, you would need to loop for every MONITOR and do hostmask checks when away/account status changes.

Edit :: Added how hostmasks differ from nick lookups

I opened this to track the status of this discussion and will update the issue accordingly as new information comes in.

Note that some implementations in the wild have vendor specific variations. E.g. rules on case sensitivity, the H (real host names) option, join-delayed channel members.

It would be useful to document the base compatibility case for new implementations and highlight any areas where vendor-extensions are possible.

https://github.com/quakenet/snircd/blob/master/doc/readme.who
http://faerion.sourceforge.net/doc/irc/whox.var

By not sending unknown commands to server, all the server side aliases break including /ns, /nickserv etc. This again can be viewed as security issue as those server side aliases usually check that the server is U-lined.

Currently most of clients require manual configuration

• WeeChat: /set irc.network.send_unknown_commands on
• irssi: dispatch.pl (if I understood correctly)
• Pidgin: no workaround according to @SaberUK.

I am opening this issue in hope something could be defined in the future to solve this issue.

A few things that imho must be done before 3.2 and isn't specific to any extension:

• Add the .md extension to all markdown files.
• Format all specifications (old and new) to look saner.
• Add examples to all extensions that don't have one.

Implementing the enhancements in #44 would be good too, but I'm not aware of anyone working on those, so I propose we do this minimal treatment for now.

With the recent discussion of JSON there have been mentions of making user<->services integration better. Before this happens I think that services themselves need to become a bit more standardized. (Discussed briefly during the course of issue #55)

• db format

This is one of the major things that needs to become standardized. Services should be allowed to support any db format they wish but MUST support using and converting to the IRCv3-standard format.

• Flags/access/xop/templates/levels

Flags: I believe these are the future. They should however be changed from single-letter identifiers to full-word. Or we'll have the same 52-letter limit issue that modes are currently having.

Some current flags and possible full-word names:

XOP: The current XOP system (whatever that may be in it's specific implementation) should be removed and replaced with 'Templates'.

Templates: This is a perfect replacement for XOP. Network-wide templates should be set for certain levels like, VOP, OP, etc, and then those templates would translate to certain flags for the given level.

VOP could get AutoVoice and CanViewFlags, OP would get more like AutoChanOp, CanSetChanOp, CanKick, CanBan, CanUnban, etc

Users could also edit the templates on a per-channel basis to suit their specific wants/needs.

Access/Levels: Personally I think this should be removed entirely. It's not flexible enough for me to want to fight to keep it. It's basically a slide-rule [---|-] and as you move up the rule you get more access. It's a 'you get this + everything below this point' kind of idea, and I'm against that.

Translating Access/Levels to Flags: This 'may' be possible to do, but I'm against it. I think that it would be a bit messy to do and we would have to map all flags to a default 'access-level', and I'm sure that would cause a ton of debate on which flags should be given at each level.

This was discussed briefly last night or the night before. Basic idea is allowing users to send queries to nick=accountname instead of just nick, similar to the nick@server format that has been used before.

If =accountname doesn't match the services account of the nick the message is being sent to it should be rejected with an error.

The account-tag CAP is using (at the time of writing this) the !service account name for network-based services. If that is accepted then it should be used in this as well for conformity.

Since this doesn't require any additional client support a CAP to support it is unneeded. It should be denoted in the 005 numeric as ACCOUNTMSG for servers that support this.

Edit :: SECUREMSG was renamed to ACCOUNTMSG due to the CAP that was going to use that name being renamed to account-tag

Currently playback messages are treated as regular messages by bouncers and provide no indication to a client that they are replay messages. Certain clients such as Textual assume that replay messages is one with the server-time tag added. This is the current behavior of znc. There is no reason that a server cannot add a server-time tag to all messages, thus I propose that a new tag be added that indicates a playback message to clients.

Clients may like to specially handle playback messages. For example, Textual has an option to not post notifications for playback messages. There are other use cases such as handling joins and parts. If a client knows that the message is part of the playback it need not update it channel state. This issue was discussed in #znc where in order to support joins and parts in the playback buffer, either the znc bouncer would have to maintain an 'old state' which is from the start of the playback buffer or clients could simply print joins and parts from the playback buffer.

A new CAP would be needed to support this feature thereby enabling a bouncer to freely send joint, parts, etc. The responsibility of the client would be to understand messages with this tag do not reflect the current state of a channel and as such should not be acted upon.

Allow clients to roam to another server and retain their complete state in case their server has to be shut down or rebooted (due to system upgrades, etc.).

General changes

• One issue for one proposal/suggestion/fix.
• Issues are assigned to the people who volunteered to work on them from the organization. Non-members can post on the issue and submit a PR with their solution, but in the end it's the responsibility of the organization member for the task to be finished on time.

Milestones

Two types of milestones

• Version-based
  The issue is to be resolved by the next IRCv3 "release", for example v3.2.
• Meeting-based
  The issue is to be resolved until the given working group meeting, so the solution can be discussed on the meeting.

Labels

• Consensus needed: no consensus yet.
• Accepted: consensus reached, change accepted.
• Rejected: consensus reached, change rejected.
• Blocking: the next IRCv3 version won't be released before this issue is addressed.
• Trivial: the change does not intend to introduce a behavior change, e.g. fixing typos, correcting broken links, changing formatting, fixing ambiguous sentences. This is mainly for pull requests.
• RFC: the proposed change is not final, suggested changes to it are welcome.

Since almost everyone uses an application to connect to IRC (instead of telnet 😀) it would be nice if IRC could handle OAuth as an authentication method.

This would enable SSO and make life easier when IRC is in a closed environment (e.g. enterprise or some other private endeavor).

Raised by @jwheare

What was talked about #111 at IRC.

Someone else can probably also explain this issue better. Have something in ISUPPORT to list the commands that the server supports and their syntax, so clients can know that server supports those commands and send those commands to server directly without /quote. Primarily /nickserv etc.

Updates to IRCv3 capability specification and sasl extension were discussed; this is my TODO list for updating the actual text:

CAP 3.2:

• note that client may use CAP at any time, even after registration (to annoy euIRC)
• re-add multi-line CAP LS * caps… from draft-mitchell-irc-capabilities-02
• add either CAP NEW caps… or CAP LS + caps… to announce newly available capabilities (syntax depends on whether multi-line LS is approved)
• note that ircd should use CAP ACK -caps… to announce capabilities no longer available (#33)
• decide if it's actually CAP ACK -caps… or CAP DEL caps…
• allow caps with values (sasl=PLAIN,EXTERNAL)
• Add account-msg

SASL updates:

• reauth (#103)
• add missing numeric 908 to the spec
• note that clients should expect numeric 908 and reduce their mechanisms-to-try list according to it
• allow clients to use AUTHENTICATE ? to query for a mechanism list
• document DH-BLOWFISH
• document DH-AES
• <Aerdan> Oh, right. 'Make it actually look like a specification.'
• import server spec to the repository
• mention that the capability is sticky if the user has authenticated
• mention for the mechanism inventors out there that new mechs should support authz as the SASL RFC says

Other 3.2:

• Batch limit specified at start of batch, limit to be maximum allowed messages in batch.

This has been removed, see #40.

Right now replies for remote WHOIS can get lost due to server ping timeouts.
This is not ideal for e.g. znc which allows you to connect to it using multiple clients and if if you /whois someone ideally the whois reply should not go to all attached clients but only to a single one who did the /whois.

It would be much easier for the znc guys to handle this situation if they knew the whois is going to get a reply no matter what happens on the server side.

I propose a new token to be added to 005/ISUPPORT which, if present, would guarantee that every single whois sent to the server will receive a reply, though not necessarily in the same order as they were sent.

Enableable by a cap json

E.g.

{
    "source": "nick!user@host",
    "verb": "PRIVMSG",
    "params": [
        "#channel",
        "Hello world!"
    ],
    "tags": {
        "server-time": "2014-03-10T08:28:43.126Z"
    }
}

One of issues solved by this: #54

The following has been written by @Aerdan and has been added to the first post for newcomers.

Why JSON?

The IRC protocol is structurally limited and doesn't allow for sideband information (e.g. message tags) without extending the protocol format. In addition, the IRC protocol is standardized on a strict 512-byte message, CRLF included. This means that any extensions which aim to add functionality of interest to users is inherently limited in what it can do. (See extended-join for an existing example of how adding features alters standard commands.)

JSON allows us to add new properties to messages without requiring clients to support those properties. They don't have to know, mind, or care about the size of those properties, either, because they are effectively invisible to clients which don't support them. This is not the case with message-tags, because every tag has a cost proportionate to the length of its name, plus the length + 1 of its contents, if it has a value, + 1 for each tag after the first.

Well, why not XML/protobuf/msgpack/insert message format here?

JSON is the most appropriate choice because we want a text-friendly protocol that plays well with real humans. It is also widely-supported, with implementations for every language anyone could possibly want to write IRC software in, unlike other formats. We don't want XML because XML is inherently unsuitable for messaging, particularly when people routinely write messages with control codes inside.

But this is going to break IRC! Waaaaah!

What? You mean it's not already broken? CAP exists because there was no way for clients to negotiate new features. Many other IRCv3 features exist to make the IRC experience better, and almost all of them could not exist without CAP.

But... But...

Any comments from this point on which are not constructive or additive to this debate will be purged with extreme prejudice. (Most of) You are adults. Act like it.

Proposal for adding OTP-support to IRCv3 SASL

Incentive

Adding support for OTP-login to services packages as of now would have to involve logging in SASL-users and prevent them from executing commands until the user provides an OTP token.
It is ugly, as it leads to the user being logged in, and getting their account name set, despite not having completed authentication. RPL_LOGGEDIN and RPL_SASLSUCCESS would also be somewhat misleading.

Proposed solution

The simplest solution appears to me to be to tack OTP on top of what we already have.
When a SASL user with OTP enabled requests the mech-list, services would list its options prefixed with 'OTP-'. For example "OTP-PLAIN,OTP-EXTERNAL".
During authentication, the client would send its OTP token before doing the rest of the auth like normal. The OTP token should be verified after username and password.

Example with plain:

C: AUTHENTICATE OTP-PLAIN
S: AUTHENTICATE +
C: AUTHENTICATE MTIzNDU2
S: AUTHENTICATE +
C: AUTHENTICATE c2h1dHRlcgBzaHV0dGVyAHlheXBvbmllcw==
S: 900
S: 903

Example with external:

C: AUTHENTICATE OTP-EXTERNAL
S: AUTHENTICATE +
C: AUTHENTICATE MTIzNDU2
S: AUTHENTICATE +
C: AUTHENTICATE +
S: 900
S: 903

This should be fairly simple to implement in existing software, as it can handle authentication in the existing providers as normal after dealing with the OTP part.

During the transition period, the IRC server SHOULD perform this translation until a
point in time is reached where translation is no longer necessary.

I felt the need to point out that this should state it MUST perform this translation. not SHOULD perform it. Also IRCv3 should NOT be changing the way things currently work. This will break older clients years down the road.

It's entirely fine to create opt-in things to do stuff differently, but there should be no 'transition period' moving from the old way to the new way. The old way must always work.

Specification available here

Hello,

I have noticed a glaring flaw in the spec for IRCv3. It is obvious that this flaw is intentional and is supposed to be a feature, but I'm going to point out why it's a bad idea.

Namely, the flaw involves the length of tags being unspecified.

"BUT FIXED-LENGTH BUFFERS SUCK"

No, they prevent an attacker from clogging the server with a tag that could be of theoretically unbound length, not to mention simplify the handling of buffers and parsing.

I know that the authors of the spec seem to be from the ZNC team and they have fancy C++ string functions and all that, but C doesn't like unbounded buffers. It means parsing and buffering becomes harder than it has to.

Even ignoring the previous issue, unbounded tags are a terrible idea. The obvious workaround is "clip at a sane limit."

But what should this limit be? Implementation-defined is not acceptable - it needlessly shifts the burden onto client authors for no reason except for server developer laziness. @kaniini thinks, based on discussions with him on IRC, it should be bound at 512. This still keeps the 512 char limit for messages, but also reserves 512 chars for tags. I think this is a sensible solution and makes it relatively quick and easy to implement tags if you update your parse() and add a separate buffer for them.

Thoughts? Feelings? Rotten tomatoes?

Simplify the version number in CAP LS (and the possible version extension) to be an integer.

A lot of people asked what is the difference between WATCH and MONITOR, I think a reasoning should be added to the document.

I believe that the website is presently organized suboptimally, in that most content is placed on one page. I propose, therefore, that it be migrated to Jekyll and that the following model be used for arranging documentation:

/index -- explain what IRCv3 is and what we're doing.
/$version/index -- explain, briefly, the goals of IRCv$version and enumerate the specifications therein.
/$version/$specname -- documents the relevant specification
/documentation/ -- contains all documentation relevant to IRCv3 implementations which is not itself a specification, e.g. SASL mechanisms.
/implementations -- lists all compliant implementations, probably by version.

I think Bootstrap would be a good basis for look & feel, however it shouldn't use the default colours.

A conservative amount of numerics (10?) should be reserved for each vendor upon request to avoid single numeric reservation requests

This is what I had in mind when I proposed JSON encoding for IRC.

Standard RFC1459 chunks

RFC1459: :kaniini!~kaniini@rabbit PRIVMSG #ircv3 :hello world\r\n

This: [{}, "kaniini!~kaniini@rabbit", "PRIVMSG", "#ircv3", "hello world"]\r\n

RFC1459: ERROR :Go away\r\n

This: [{}, null, "ERROR", "Go away"]\r\n

RFC1459: CAPAB \r\n

This: [{}, null, "CAPAB"]\r\n

Tags

IRCv3.2: @tag1=a;tag2=b :[email protected] PRIVMSG #ircv3 :hello\r\n

This: [{"tag1": "a", "tag2": "b"}, "[email protected]", "PRIVMSG", "#ircv3", "hello"]\r\n

IRCv3.2: @tag1=;tag2 :Kyth JOIN #ircv3\r\n

This: [{"tag1": "", "tag2": true}, "Kyth", "JOIN", "#ircv3"]\r\n

Incidentally, this is the only type of JSON encoding we have any interest in implementing in Tethys. The stuff on bug #55 will never ever happen there, so consider that proposal DOA.

Yes, it's based on a subset of JSON. This is also a subset of YAML, too. Furthermore, I do not care about some idiot on hacker news's pet protocol, XMPP, protobuf, or any other nonsense. We will not implement any of those in Tethys, so consider those proposals DOA too. It's either RFC1459 or this, period.