Support special characters [<>&"] in the password (PW) attribute of the HTTPPROXY element in the SCMPCLNT DD input stream

We are trying to use the "network delivery" function of SMP/E. At our site we need to go through a proxy server to access the Internet. The proxy server requires a "service account" userid and password to be authenticated using NTLM. However, the password we have been given for our service account userid contains a special character ("<"). We have no control over the password that is assigned, so we have to expect that some passwords will contain special characters. When we configure that password on the <HTTPPROXY> element that is read from the SMPCLNT DD by the GIMGTPKG program, the program exits with RC=12 and the message:

GIM20313S ** THERE IS A SYNTAX ERROR IN THE CONTROL STATEMENT FROM DD STATEMENT SMPCLNT AT COLUMN 38.

Steps to reproduce:
Execute PGM=GIMGTPKG with the following (redacted) SCMPCLNT DD input:

<CLIENT retry="3"
javahome="/_PRDS/JAVA2800/SAJV80M/"
javadebugoptions="-Dhttp.auth.preference=ntlm -Dhttp.maxRedirects=2
-Djavax.net.debug -Djava.security.debug
-Dhttp.auth.ntlm.domain=our.company.com"
downloadmethod="https"
downloadkeyring="javatruststore">
<HTTPPROXY host="our.proxy.host"
user="our.proxy.userid" pw="xxx:<x]xxxxxxx#" port="8080">
</HTTPPROXY>
</CLIENT>

For the purpose of reporting this issue, all alphabetic characters in the pw attribute value have been replaced with 'x' leaving only the original non-alphabetic characters.

We have read in the SMP/E that the pw attribute "specifies a password value that will allow access to the proxy server. Password values can be from 1 to 80 characters excluding the reserved XML characters, less than (<), greater than (>), double quotation mark (") and ampersand (&)."

However, we are still logging this issue as a defect because we believe that the XML specification has not been followed (and there must be many other customers who don't want to compromise their password security rules by eliminating certain characters from passwords)

Expected outcome:
We should be able to use XML entities to encode the '<', '>', '&' and '"' characters. In this instance, we should be able to code &lt; in place of the '<' character.