DCBase

Idea: grouping of different supported features that are known to occur together frequently, can save bandwidth.

Hubbased implementation idea:

Client connects to hub, signals it supports SUGR, sends: HSUP <sid> ADSUGR AD..
Hub can send the groups to the client: SUGR <sid> GR<name>,<feature1>,<feature2> GR<name>,<feature1> etc..
for example: SUGR <sid> GRSECA,ADCS,KEYP,SUDP

From then on, when the hub receives all features in a certain group, it can send the groupname instead of all the separate features to all clients that support SUGR.

The client doesn't have to, or maybe even shouldn't use the groupnames when sending to the hub, only use them to parse incoming groups. It will only cost some bandwidth on the download side of the hub.

I'm not sure how much bandwidth this would save. Also the added complexity doesn't seem worth any small gain you may get.

The example seems to suggest adding 39 bytes (7 in the SUP and 32 from the SUGR message) to save 21 bytes. Am I reading this incorrectly?

The point is not to save bandwidth in the SUP, but rather in the INF's SU field.

There are a few things that should be noted/discussed;

When should the command be sent? Before hub INF?
The command length should be 3, not 4 characters...
If the SU field in the INF is used, then it's possible there will be a clash if someone picks a FCC that is the same as a group.. so, really a new field should be used.. 
Should groups in groups be possible? If yes, how do we identify groups from normal FCCs?

I agree with darkKlor.

Realistically, how many times is your client going to broadcast a change in its SU field?

My guess is never, after the login handshake.

From the hub point of view, you are making a tiny reduction per INF you have to send for the login handshake (and when new clients log in), but this is pittence compaired to the rest of the data sent in the INF

However, if you are concerned with the hub bandwidth, just get around to implementing ZLIF

~Andrew

Agrees with darkKlor.