"If [AWAY] is sent with a nonempty parameter (the 'away message')
then the user is set to be away. If this command is sent with no
parameters, or with the empty string as the parameter, the user is no
longer away."
-- https://modern.ircdocs.horse/#away-message
"The LS subcommand is used to list the capabilities supported by the server.
The client should send an LS subcommand with no other arguments to solicit
a list of all capabilities."
"Servers may validate the value (eg. to forbid spaces, as they make it harder
to use the key in JOIN messages). If the value is invalid, they SHOULD
return [ERR_INVALIDMODEPARAM](#errinvalidmodeparam-696).
However, clients MUST be able to handle any of the following:
[ERR_INVALIDMODEPARAM](#errinvalidmodeparam-696)
[ERR_INVALIDKEY](#errinvalidkey-525)
MODE echoed with a different key (eg. truncated or stripped of invalid
characters)
the key changed ignored, and no MODE echoed if no other mode change
was valid.
"Servers may validate the value (eg. to forbid spaces, as they make it harder
to use the key in JOIN messages). If the value is invalid, they SHOULD
return [ERR_INVALIDMODEPARAM](#errinvalidmodeparam-696).
However, clients MUST be able to handle any of the following:
[ERR_INVALIDMODEPARAM](#errinvalidmodeparam-696)
[ERR_INVALIDKEY](#errinvalidkey-525)
MODE echoed with a different key (eg. truncated or stripped of invalid
characters)
the key changed ignored, and no MODE echoed if no other mode change
was valid.
"Servers may validate the value (eg. to forbid spaces, as they make it harder
to use the key in JOIN messages). If the value is invalid, they SHOULD
return [ERR_INVALIDMODEPARAM](#errinvalidmodeparam-696).
However, clients MUST be able to handle any of the following:
[ERR_INVALIDMODEPARAM](#errinvalidmodeparam-696)
[ERR_INVALIDKEY](#errinvalidkey-525)
MODE echoed with a different key (eg. truncated or stripped of invalid
characters)
the key changed ignored, and no MODE echoed if no other mode change
was valid.
"Servers may validate the value (eg. to forbid spaces, as they make it harder
to use the key in JOIN messages). If the value is invalid, they SHOULD
return [ERR_INVALIDMODEPARAM](#errinvalidmodeparam-696).
However, clients MUST be able to handle any of the following:
[ERR_INVALIDMODEPARAM](#errinvalidmodeparam-696)
[ERR_INVALIDKEY](#errinvalidkey-525)
MODE echoed with a different key (eg. truncated or stripped of invalid
characters)
the key changed ignored, and no MODE echoed if no other mode change
was valid.
Use of this numeric:
"The minimum length of <username> is 1, ie. it MUST not be empty.
If it is empty, the server SHOULD reject the command with ERR_NEEDMOREPARAMS
(even an empty parameter is provided)"
https://github.com/ircdocs/modern-irc/issues/85
"If the password supplied does not match the password expected by the server,
then the server SHOULD send ERR_PASSWDMISMATCH and MUST close the connection
with ERROR."
-- https://github.com/ircdocs/modern-irc/pull/172
"When the channel has [invite-only](#invite-only-channel-mode) mode set,
only channel operators may issue INVITE command.
Otherwise, the server MUST reject the command with the ERR_CHANOPRIVSNEEDED
numeric."
-- https://modern.ircdocs.horse/#invite-message
" Only members of the channel are allowed to invite other users.
Otherwise, the server MUST reject the command with the ERR_NOTONCHANNEL
numeric."
-- https://modern.ircdocs.horse/#invite-message
"The server MUST NOT send KICK messages with multiple channels or
users to clients.
This is necessary to maintain backward compatibility with existing
client software."
-- https://modern.ircdocs.horse/#kick-message
"Servers MAY limit the number of target users per KICK command
via the [TARGMAX parameter of RPL_ISUPPORT](#targmax-parameter),
and silently drop targets if the number of targets exceeds the limit."
-- https://modern.ircdocs.horse/#kick-message
"If the "TARGMAX" parameter is not advertised or a value is not sent
then a client SHOULD assume that no commands except the "JOIN" and "PART"
commands accept multiple parameters."
-- https://defs.ircdocs.horse/defs/isupport.html#targmax
"If this parameter is not advertised or a value is not sent then a client
SHOULD assume that no commands except the JOIN and PART commands
accept multiple parameters."
-- https://github.com/ircdocs/modern-irc/pull/113
"The server MUST NOT send KICK messages with multiple channels or
users to clients.
This is necessary to maintain backward compatibility with existing
client software."
-- https://modern.ircdocs.horse/#kick-message
"Servers MAY limit the number of target users per KICK command
via the [TARGMAX parameter of RPL_ISUPPORT](#targmax-parameter),
and silently drop targets if the number of targets exceeds the limit."
-- https://modern.ircdocs.horse/#kick-message
"If the "TARGMAX" parameter is not advertised or a value is not sent
then a client SHOULD assume that no commands except the "JOIN" and "PART"
commands accept multiple parameters."
-- https://defs.ircdocs.horse/defs/isupport.html#targmax
"If this parameter is not advertised or a value is not sent then a client
SHOULD assume that no commands except the JOIN and PART commands
accept multiple parameters."
-- https://github.com/ircdocs/modern-irc/pull/113
In replying to the LINKS message, a server must send
replies back using the RPL_LINKS numeric and mark the
end of the list using an RPL_ENDOFLINKS reply.
In replying to the LINKS message, a server must send
replies back using the RPL_LINKS numeric and mark the
end of the list using an RPL_ENDOFLINKS reply.
"automatic replies must never be
sent in response to a NOTICE message. This rule applies to servers
too - they must not send any error reply back to the client on
receipt of a notice"
<https://tools.ietf.org/html/rfc1459#section-4.4.2>
'automatic replies MUST NEVER be sent in response to a NOTICE message.
This rule applies to servers too - they MUST NOT send any error repl
back to the client on receipt of a notice."
<https://tools.ietf.org/html/rfc2812#section-3.3.2>
“Outputs for each target in the list being monitored, whether
the client is online or offline. All targets that are online will
be sent using RPL_MONONLINE, all targets that are offline will be
sent using RPL_MONOFFLINE.“
-- <https://ircv3.net/specs/extensions/monitor#monitor-s>
"If the channel name is invalid or the channel does not exist,
one RPL_ENDOFNAMES numeric containing the given channel name
should be returned."
-- https://modern.ircdocs.horse/#names-message
"If the channel name is invalid or the channel does not exist,
one RPL_ENDOFNAMES numeric containing the given channel name
should be returned."
-- https://modern.ircdocs.horse/#names-message
Upon receipt of the message, the server will verify the presented (in
the message) authentication identity (authcid) and password (passwd)
with the system authentication database, and it will verify that the
authentication credentials permit the client to act as the (presented
or derived) authorization identity (authzid). If both steps succeed,
the user is authenticated.
[…]
When no authorization identity is provided, the server derives an
authorization identity from the prepared representation of the
provided authentication identity string. This ensures that the
derivation of different representations of the authentication
identity produces the same authorization identity.”
-- <https://tools.ietf.org/html/rfc4616#section-2>
"If the topic of a channel is changed or cleared, every client in that
channel (including the author of the topic change) will receive a TOPIC command
with the new topic as argument (or an empty argument if the topic was cleared)
alerting them to how the topic has changed.
"Servers MAY echo WALLOPS messages to their sender even if they don't have
the 'w' user mode.
Servers MAY send WALLOPS only to operators."
-- https://github.com/ircdocs/modern-irc/pull/118