92 lines
3.9 KiB
Markdown
92 lines
3.9 KiB
Markdown
|
---
|
||
|
|
title: "`pre-away` Extension"
|
||
|
|
layout: spec
|
||
|
|
meta-description: A capability allowing client connections to be marked AWAY during connection registration
|
||
|
|
work-in-progress: true
|
||
|
|
copyrights:
|
||
|
|
-
|
||
|
|
name: "Shivaram Lingamneni"
|
||
|
|
period: "2023"
|
||
|
|
email: "slingamn@cs.stanford.edu"
|
||
|
|
---
|
||
|
|
|
||
|
|
## Notes for implementing experimental vendor version
|
||
|
|
|
||
|
|
This is an experimental specification for a vendored extension.
|
||
|
|
|
||
|
|
No guarantees are made regarding the stability of this extension.
|
||
|
|
Backwards-incompatible changes can be made at any time without prior notice.
|
||
|
|
|
||
|
|
Software implementing this work-in-progress specification MUST NOT use the
|
||
|
|
unprefixed `pre-away` CAP name. Instead, implementations SHOULD use the
|
||
|
|
`soju.im/pre-away` CAP name to be interoperable with other software implementing
|
||
|
|
a compatible work-in-progress version.
|
||
|
|
|
||
|
|
## Introduction
|
||
|
|
|
||
|
|
Some IRC server implementations offer a mode of operation where a single
|
||
|
|
nickname can be associated with multiple concurrent client connections, or no
|
||
|
|
client connections. Typically, such implementations are bouncers (i.e.,
|
||
|
|
intermediaries between the client and another server), but some are full server
|
||
|
|
implementations.
|
||
|
|
|
||
|
|
Such implementations may wish to update publicly visible state depending on the
|
||
|
|
status of the user's actual client connections. For example, if the user has no
|
||
|
|
active connections, it may be desirable to mark them as AWAY, then mark them
|
||
|
|
un-AWAY if they reconnect. However, a client implementation may wish to connect
|
||
|
|
without active involvement from the user, e.g. to retrieve
|
||
|
|
[chathistory][], in which case it would be undesirable to suggest
|
||
|
|
that the user is present. This extension provides a mechanism for such clients
|
||
|
|
to flag their connections as automatically initiated, so servers can disregard
|
||
|
|
them for this or other purposes related to user presence.
|
||
|
|
|
||
|
|
## Implementation
|
||
|
|
|
||
|
|
This specification introduces a new capability, `soju.im/pre-away`. Clients
|
||
|
|
wishing to make use of this specification MUST negotiate the capability; this
|
||
|
|
gives the server more information about the context and meaning of the client's
|
||
|
|
`AWAY` commands.
|
||
|
|
|
||
|
|
If the capability has been negotiated, servers MUST accept the `AWAY` command
|
||
|
|
before connection registration has completed. The `AWAY` command has its normal
|
||
|
|
semantics, except that servers SHOULD treat the form:
|
||
|
|
|
||
|
|
AWAY *
|
||
|
|
|
||
|
|
i.e. an `AWAY` message consisting of the single character `*`, as indicating
|
||
|
|
that the user is not present for an unspecified reason. Clients MAY also send
|
||
|
|
`AWAY *` post-registration to indicate that the user is no longer present for an
|
||
|
|
unspecified reason.
|
||
|
|
|
||
|
|
In its conventional form:
|
||
|
|
|
||
|
|
AWAY :Gone to lunch. Back in 5
|
||
|
|
|
||
|
|
the `AWAY` command MAY be used pre-registration to set a human-readable away
|
||
|
|
message associated with the connection as usual. Similarly, `AWAY` with no
|
||
|
|
parameters indicates that the user is present.
|
||
|
|
|
||
|
|
If the client's nickname was not already present on the server, then `AWAY`
|
||
|
|
pre-registration sets the away message but does not inhibit reporting of the
|
||
|
|
change in nickname status, e.g. via [monitor][].
|
||
|
|
|
||
|
|
Clients that have negotiated this capability and subsequently receive `*` as an
|
||
|
|
away message (for example, in `301 RPL_AWAY` or [away-notify][])
|
||
|
|
SHOULD treat it as indicating that the user is not present for an unspecified
|
||
|
|
reason. Servers MAY substitute a human-readable message for the `*` if it would
|
||
|
|
otherwise be relayed as an away message.
|
||
|
|
|
||
|
|
## Implementation considerations
|
||
|
|
|
||
|
|
This section is non-normative.
|
||
|
|
|
||
|
|
In general, the server-side aggregation of away statuses across multiple
|
||
|
|
connections is outside the scope of this specification. However, in most cases,
|
||
|
|
an away message of `*` should be treated as though the connection did not exist
|
||
|
|
at all (for example, it should not supersede a human-readable `AWAY` message set
|
||
|
|
by another connection, even if it is more recent).
|
||
|
|
|
||
|
|
[chathistory]: https://ircv3.net/specs/extensions/chathistory
|
||
|
|
[monitor]: https://ircv3.net/specs/extensions/monitor
|
||
|
|
[away-notify]: https://ircv3.net/specs/extensions/away-notify
|