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.
To prevent perceived input lag, clients may choose not to wait for an acknowledgment from the server before displaying sent messages to users. Clients may instead choose to display a temporary local message that is replaced once the
echo-message acknowledgment is received. However, correlating these is not straightforward, as the server may modify them before acknowledgment. There are also additional complications for self-targeted private messages.
A specification for labeled replies is being drafted that addresses this limitation. Clients may choose to postpone adoption of
echo-message until that draft is complete.
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
Previous versions of this specification didn’t include the Limitations section.