A REG command proposal
Posted: 03 Aug 2009, 01:32
This is designed to allow a common method of registration between client and hub, rather than the current use of hub-specific commands such as +regme.
REG
Context: F, T
REG UPx ME CNx CIx CCx TO data
For x, 1 means true or allow, 0 (zero) means false or deny.
For client to hub: This can only be sent by a user with permission to register others e.g. an Operator.
UPx - (optional) Indicates this message should update the registration of a user i.e. change registration method and/or portability settings, or remove registration. A client may interpret this message to inform the user of the changes to portability.
ME - the method via which the user should be registered. One of ID (Client ID), NI (Nickname), IP (IP Address) or RE (Revoke). If the hub does not allow this registration method, a STA should be sent informing the operator. The hub may strip this parameter before forwarding the message to the user.
The following parameters are portability options, and are for both client-to-hub and hub-to-client communication. If a parameter is not supplied, the default is deny. They are all optional.
CNx - Change Nickname - target user will be able to connect with a different Nickname. Should register internally via Client ID or IP Address.
CIx - Change IP - target user will be able to connect from a different IP Address. Should register internally via Client ID or Nickname.
CCx - Change Client - target user will be able to connect from a different client. Should register internally via Nickname or IP Address.
For hub to client: This parameter is generated by the hub.
TO - (optional) Timeout. The hub may specify how long (in seconds) the registration offer remains valid. If the user does not cancel, the receiving client should cancel automatically after this period.
data - The data parameter is at least 24 random bytes (base32 encoded). Same as GPA.
Info:
Register. This command may be sent by a client to register a user. It allows an operator to initiate the registration process and define the portability of the registered user's account. The client should respond with a PAS message containing the password specified by the user.
Example:
1) An operator selects a user in their client and clicks a Register button. This launches a dialog allowing the operator to nominate a method of registration, and the portability options for the registered user.
2) When the operator presses OK, the client sends a DREG message e.g.:
DREG <my_sid> <target_sid> MEID CN1 CI1 - the user will be registered via their Client ID and able to change their Nickname and IP Address. They will be unable to use a different client.
DREG <my_sid> <target_sid> MEID - the user will be registered via their Client ID, but not able to change their Nickname, IP Address or client.
3) The hub will generate a data parameter. It must store all parameters in it's state until the user replies with a PAS message. It may limit the time it retains this state by appending a TO parameter when it is forwarded to the user. It may also strip the ME parameter, since the client does not require it e.g. DREG <my_sid> <target_sid> MEID CN1 CI1 becomes DREG <my_sid> <target_sid> CN1 CI1 TO60 data, which specifies the offer will expire after 60 seconds.
4) The client receives the message and display a dialog to the user, informing them that <my_sid> is trying to register them, requesting a password, and informing them of the portability options (e.g. via disabled checkboxes). If a TO parameter was included, it should exit the dialog after the time expires.
5) If the user enters a password and accepts the dialog, the client should send a PAS message back to the hub. The data parameter from REG is used as the random binary data in PAS.
6) The hub will register the user with the retained state and the password specified in the PAS message.
Additionally, an operator may want to update or remove the user's registration.
To update, the operator would send DREG <my_sid> <target_sid> UP1 MEID to remove all portability from a user registered with the Client ID method.
To revoke registration, send DREG <my_sid> <target_sid> UP1 MERE with no additional parameters.
Missing: A way for an operator's client to get the registration details of a user. Maybe a REG message with no parameters, or something. Or extra INF flags sent to OP's.
Note: Currently a PAS message is only valid in the Verify state. This would need to change to allow the Normal state too.
Comments are welcome
REG
Context: F, T
REG UPx ME CNx CIx CCx TO data
For x, 1 means true or allow, 0 (zero) means false or deny.
For client to hub: This can only be sent by a user with permission to register others e.g. an Operator.
UPx - (optional) Indicates this message should update the registration of a user i.e. change registration method and/or portability settings, or remove registration. A client may interpret this message to inform the user of the changes to portability.
ME - the method via which the user should be registered. One of ID (Client ID), NI (Nickname), IP (IP Address) or RE (Revoke). If the hub does not allow this registration method, a STA should be sent informing the operator. The hub may strip this parameter before forwarding the message to the user.
The following parameters are portability options, and are for both client-to-hub and hub-to-client communication. If a parameter is not supplied, the default is deny. They are all optional.
CNx - Change Nickname - target user will be able to connect with a different Nickname. Should register internally via Client ID or IP Address.
CIx - Change IP - target user will be able to connect from a different IP Address. Should register internally via Client ID or Nickname.
CCx - Change Client - target user will be able to connect from a different client. Should register internally via Nickname or IP Address.
For hub to client: This parameter is generated by the hub.
TO - (optional) Timeout. The hub may specify how long (in seconds) the registration offer remains valid. If the user does not cancel, the receiving client should cancel automatically after this period.
data - The data parameter is at least 24 random bytes (base32 encoded). Same as GPA.
Info:
Register. This command may be sent by a client to register a user. It allows an operator to initiate the registration process and define the portability of the registered user's account. The client should respond with a PAS message containing the password specified by the user.
Example:
1) An operator selects a user in their client and clicks a Register button. This launches a dialog allowing the operator to nominate a method of registration, and the portability options for the registered user.
2) When the operator presses OK, the client sends a DREG message e.g.:
DREG <my_sid> <target_sid> MEID CN1 CI1 - the user will be registered via their Client ID and able to change their Nickname and IP Address. They will be unable to use a different client.
DREG <my_sid> <target_sid> MEID - the user will be registered via their Client ID, but not able to change their Nickname, IP Address or client.
3) The hub will generate a data parameter. It must store all parameters in it's state until the user replies with a PAS message. It may limit the time it retains this state by appending a TO parameter when it is forwarded to the user. It may also strip the ME parameter, since the client does not require it e.g. DREG <my_sid> <target_sid> MEID CN1 CI1 becomes DREG <my_sid> <target_sid> CN1 CI1 TO60 data, which specifies the offer will expire after 60 seconds.
4) The client receives the message and display a dialog to the user, informing them that <my_sid> is trying to register them, requesting a password, and informing them of the portability options (e.g. via disabled checkboxes). If a TO parameter was included, it should exit the dialog after the time expires.
5) If the user enters a password and accepts the dialog, the client should send a PAS message back to the hub. The data parameter from REG is used as the random binary data in PAS.
6) The hub will register the user with the retained state and the password specified in the PAS message.
Additionally, an operator may want to update or remove the user's registration.
To update, the operator would send DREG <my_sid> <target_sid> UP1 MEID to remove all portability from a user registered with the Client ID method.
To revoke registration, send DREG <my_sid> <target_sid> UP1 MERE with no additional parameters.
Missing: A way for an operator's client to get the registration details of a user. Maybe a REG message with no parameters, or something. Or extra INF flags sent to OP's.
Note: Currently a PAS message is only valid in the Verify state. This would need to change to allow the Normal state too.
Comments are welcome