Copyright © 2014 Attila Molnar <firstname.lastname@example.org>
Copyright © 2014 J-P Nurmi <email@example.com>
Unlimited redistribution and modification of this document is allowed provided that the above copyright notice and this permission notice remains intact.
This client capability MUST be named
If enabled, servers MUST send
NOTICE messages back to
the client that sent them. If servers apply any modifications to these
messages, they MUST send the final version of the message back to the
For clients, receiving a message with themselves as the sender acts as
an acknowledgement that the message has been delivered to the server.
Clients that receive self-sent
NOTICE messages, MUST
treat them the same way as if the client itself would have sent the
message to the target. Clients may choose to disable local echoing
NOTICE messages altogether, or present them
in pending state.
The capability is useful for clients to get an acknowledgement that a message was delivered. It can be also used for measuring lag between client and server, that is, the time it takes from sending a message to receiving it back.
Furthermore, the capability is useful for users that have multiple clients attached to a bouncer. In this scenario, when users send messages from one client, the messages get automatically relayed to other attached clients. This allows all attached clients to display full conversation.
In the following examples,
firstname.lastname@example.org presents a client
that has enabled the
--> PRIVMSG Attila :hi :email@example.com PRIVMSG Attila :hi
The client interprets the received message as if it had sent a
with contents “hi” to
Another example where a server modifies a message by filtering out text formatting and sends the final version back:
--> PRIVMSG #ircv3 :back from \02lunch\0F :firstname.lastname@example.org PRIVMSG #ircv3 :back from lunch