CMD Context verification

[Pirre]

A ADC hub has the obligation to forward "Unknown" ADC commands with the idea that a hubsoft does not need regular updating while the client can still use the latest features in that hub, this is a nice idea but ...

As it seems to be the general idea that the commands context (B, H, I, etc) needs to be verifyed by the hub ( its not really specified in the protocol who needs to do this) there is a problem,

A hub can not verify the context for a command it does not know.

1: This can be a command not (yet) included in the extentions but simply something a client dev has introduced , when this happen the client version doing this will need its own context verification for that command anyway ( the clients who does not know the command drop it, so no problem there)

2: It can be a command that is at that moment included in the extentions but the hubsoft is outdated, then there is a problem , the clients trust the hub will take care of the verification but it does not, so a potential security risk is created.

Therefore i propose to specify explicitly in the protocol that the responsibility to do this verification is a client matter, he is the only one who knows what commands it will use.

It will avoid future problems and a mix of who is doing what.

The hub can still have its own verifications to avoid sending commands with a bad context for its own protection or to simply save band but the client should not trust that it does.

[Pretorian]

The client shouldn't really care what the type is, as specified in the beginning that clients should only use the type to parse the message. I think a better way to solve this would be as I described here; http://www.dcbase.org/forums/viewtopic.php?f=18&t=781