Below is a write-up (or at least what I think I've gathered) of the discussions here and on the hub.

=== CCPM - Client to client private messages
This extension adds support for private messages in a client to client context. The extension adds support for the C-type for MSG, and uses a field in the (C-type) INF to signal that the connection should be used for private messages.

Implementations shall signal "CCPM" in the SU field of their (H-type) INF.

Implementations should differentiate between a C-C transfer connection and a C-C private message connection, so as to allow transfers and chat at the same time. The initiating client should issue a secondary CTM/RCM sequence to deal with the other connection. Implementations shall disallow GET (and other file transfer commands) in the private message connection.

Implementations may choose if private messages shall be allowed in unencrypted connections. Implementations may choose for which users that are allowed to send them private messages, so as to avoid spam (e.g., only trusted users, hub operators etc may initiate a C-C private message).

Removing the INF field 'PM' shall cause a disconnect of the connection (with an appropriate STA).

Implementations may decide what to do when the hub connection is lost during a private message connection.

Implementations should adhere to any requirements the DI field in the QUI command in BASE poses regarding non-file transfer connections. Beyond that is up to implementations.

[options="autowidth"]
|=====
|PM |Field in the CINF to denote that the connection should be used for private messages. The field's value should be '1'.
|=====

Regarding the DI field, it's possible that there is a requirement to change it from

Any client that has this flag in the QUI message should have its transfers terminated by other clients connected to it, as it is unwanted in the system

to

Any client that has this flag in the QUI message should have its file transfer connections terminated by other clients connected to it, as it is unwanted in the system. Extensions may further limit non-file transfer connections.

- "Implementations shall signal "CCPM" in the SU field of their (H-type) INF." > It's usually a BINF so I would change "H-type" to "hub-targeted".
- Add a note about the possibility of reusing a port on one end and only changing it on the other, as that isn't obvious as evidenced by the first posts in this thread.
- Add a note about the impossibility in the above port-being-reused case when going through NAT-T to then have a C-C PM and transfers at the same time.
- "Implementations may choose if private messages shall be allowed in unencrypted connections." sounds too sweet; I would give it some weight by strongly advising to encrypyt C-C PMs.
- The "PM" parameter of the "MSG" command is not required in C-C PMs.

There are a few novelties here regarding error handling that are probably not all implemented in DC++ - to be checked...

=== CCPM - Client to client private messages
This extension adds support for private messages in a client to client context. The extension adds support for the C-type for MSG, and uses a field in the (C-type) INF to signal that the connection should be used for private messages.

Implementations shall signal "CCPM" in the SU field of their hub-targeted INF.

Implementations should differentiate between a C-C transfer connection and a C-C private message connection, so as to allow transfers and chat at the same time. The initiating client should issue a secondary CTM/RCM sequence to deal with the other connection. Implementations shall disallow GET (and other file transfer commands) in the private message connection.

Implementations are strongly discouraged but may choose to allow private messages in unencrypted connections.

Implementations may choose for which users that are allowed to send them private messages, so as to avoid spam (e.g., only trusted users, hub operators etc may initiate a C-C private message).

Removing the INF field 'PM' shall cause a disconnect of the connection (with an appropriate STA).

Implementations may decide what to do when the hub connection is lost during a private message connection.

Implementations should adhere to any requirements the DI field in the QUI command in BASE poses regarding non-file transfer connections. Beyond that is up to implementations.

The same port may, but needn't be, reused for a file transfer connection and a private message connection. Concurrent connections may be rendered unfeasible with extensions such as NAT-T.

The "PM" field of the MSG command should not be used in C-C private messages.

[options="autowidth"]
|=====
|PM |Field in the CINF to denote that the connection should be used for private messages. The field's value should be '1'.
|=====