User software (client programs) should be able to determine (limit) bandwidth usage when in Pactor or WINMOR modes on HF.

The unattended station is always the Server and the station operator/owner of this server needs to have the ability to set the bandwidth. It is also necessary so that very limited wide band segments (e.g. US autoforward sub bands) are not used by low bandwidth stations making poor use of these limited spectrums. The station INIATING the connection (the client) KNOWS before hand the bandwidth of the station he is calling (e.g. the server is P3 or WINMOR 1600) and if this illegal for his location THE CLIENT is the one responsible for not making the illegal connection.

Quite right. But it could be much better. Enforcing good amateur practice in precious US wideband segments could be implemented by a switch that identifies the client as a US station that disallows control of bandwidth by the client. There are many clever ways to do that, even transparently; i.e. by gridsquare, or .ini file setting.

In affected countries lawful operation is practical with the present design only if there are many RMS stations that offer narrowband connections to which an affected client can connect. This is not so and unlikely in places like Europe, where there are not large political areas governed by the same rules. Having many more on-air RMS stations, ironically in itself, is also abusive to band usage, and unnecessary given the nature of HF propagation.

The most unfortunate thing about the present design is that it makes UNINTENTIONAL rule breaking very likely by an operator, who, despite his responsibility will naturally assume WINMOR works like the more familiar Pactor modes. It is UNNATURAL design to keep the control of an operator's transmitter from him and investing it in another station in a country with different rules. Unnatural design fosters wrong assumptions. This is a basic principle of good user interface design! You can rightfully argue the responsibility to connect lawfully rests on the client, but it is disingenuous to argue it prevents abuse in one place while allowing it, or even encouraging it elsewhere. Moreover:

Fact: Narrowband protocol transmissions in wideband segments in the US is NOT illegal, just ungentlemanly and not good amateur practice.

Fact: Unintentionally connecting to a wideband RMS from affected countries IS illegal.

The current design offers hard enforcement of good amateur practice in the US while simultaneously offers an operator in an affected country no protection from an infraction of law. There is no balance in the design, and arguments to the contrary are insensitive and US-centric. Winlink is a GLOBAL system.

Granting control to the client prevents unintentional infractions, and it can be done in a way to enforce good amateur usage of crowded US wideband segments.

I can only say thanks for the suggestion.
It is mandatory by law for norwegians on 30m.

On other bands it may be "good ham practise" around the world if some p123 enabled RMS pactors are located unrecommended in the IARU ham band sections recommended for narrow band use, but legal according to law.

Then the option for wide band are always present (legal according to law) if real emcomm suddenly is needed.
But unless emcomm the hams may avoid a growing "bad will" against Winlink system when given client option to choose only narrow band when no more is needed.

Found recently that a PTC2 with no more P3 trials, do lock up when using RMS Express on a pactor frequency allowed by sysop for P1,P2,P3, or P2,P3. New discovery for me.

RMS Express is forcing the PTC2 into P3, but no more P3 trials, so the TNC Locks up stopping all TX.

This will be a world wide problem on all bands for people getting cheap non P3 capable PTCIIs on Ebay or elsewhere.

Solution is switching to AirMail, where BW level can be set manually to P2, and were also AirMail by initialization finds out that the box can only do max P2. This is negotiated to the RMS Pactor. Working well now. 

This ability has always been inherent in the Pactor protocol, so should be easy to implement for pactor.

Would also help for the norwegian law issue on 30m at least on Pactor mode.

I understand that it is more difficult running WINMOR since not built into the protocoll.

The Pactor 2 limitation problem gone a way fixed in RMS Express 1.1.1.4 Thanks.

Before and on RMS E 1.1.7.6 Pactor level 2 (MYLevel 2)only  works on P4Dragon, but does not work on PTCII or PTC2PRO.  It jumps immediately to P3 if the TNC is Pactor 3 licenced and being linked to a RMS Pactor/Trimode accepting P1,2,3,4. Can be illegal due to different countries.

Phil fixed this in 1.1.8.4, official in 1.1.9.0
P2 is now kept in the old models as well if set up.
Thanks. Now Norwegian hams don't risk loosing their license if operating 30m toward rest of EU. Max BW is 1000 Hz for us on that band.