= Proposed ADC extensions

These are extensions which have been proposed but lack implementation, detail
or testing before they can be added to the real ADC spec.

=== REGX - Regular expressions in searches
This extension adds to the SCH command an additional operator RE that takes a
Perl regular expression (http://perldoc.perl.org/perlre.html) with full
Unicode support. Clients that support this must send "REGX" in their support
string in the INF SU field.

=== ADCS - Secure ADC <work-in-progress>
==== Introduction
Secure ADC connections can be established using a TLS tunnel, both for hub and
for client connections. Certificates can be used to authenticate both hub and
user, for example by making the hub the root CA, and only allow clients signed
by the hub to connect. Ephemeral keys should be use to ensure forward secrecy
when possible.

==== Client-Hub encryption
TLS client-hub connections can be initiated either by negotiating the feature
"ADCS" on connection or by using the protocol adcs:// when initiating the
connection. Hubs can choose to request a certificate for the user on login,
and use this certificate to replace password-based login.

==== Client-Client encryption
TLS client-client connections can be established either by negotiating the
feature "ADCS" on connection or by specifying "ADCS/1.0" in the CTM protocol
field. Clients supporting encrypted connections must indicate this in the INF
SU field with "ADCS"

=== UCMD - User commands
User commands are used to send hub-specific commands to the client which
provide useful shortcuts for the user. These commands contain strings which
must be sent back to the hub and parameter substitutions in the strings. Each
user command has a display name, a string to be sent to the hub, and one or
more categories where it may appear. The strings passed to the hub must first
be passed through a dictionary replacement that replaces all keywords in the
string and then through the equivalent of the C standard function "strftime",
with the current time.

==== CMD
 CMD name

Context: F

Name uniquely (per hub) identifies a particular user command. The name may
contain "/" to indicate a logical structure on the viewing client, where each
"/" introduces a new submenu level. Other than name, the command also has a
number of flags that further detail what to do with it.

[separator="|"]
``_
RM | 1 = Remove command
CT | Context, the following flags summed:
   | 1 = Hub command, client parameters only
   | 2 = User list command, client and user parameters
   | 4 = Search result command, client, user and file parameters
   | 8 = File list command, client, user and file parameters
TT | The full text to be sent to hub, including FOURCC and any parameters
CO | 1 = Constrained, when sending this command on multiple users (for example in search results), constrain it to once per CID only
SP | 1 = Insert separator instead of command name (name must still be present to uniquely identify the command)
___

Keywords are specified using "%[keyword]". Unknown keywords must be replaced
by the empty string. Additionally, all %-substitutions of the C function
"strftime" must be supported.

The following tables specify the parameters that must be available.

Client parameters

[separator="|"]
``_
myCID | Client CID
mySID | Client SID
myXX  | One for each flag on that particular hub; for example, myI4 and myNI
___

User parameters

[separator="|"]
``_
userCID | User CID
userSID | SID of the user
userXX  | One for each flag the user sent; for example, userI4 and userNI
___

File parameters

[separator="|"]
``_
fileXX | One for each flag contained within a search result or file list entry (see RES)
___

Hub parameters

[separator="|"]
``_
hubXX | One for each flag of the hub
___

// vim: set syntax=asciidoc:
