misplaced 'bad gateway' in Reply PDU

kannel gateway version 1.2.1
Agilent test equipment
gateway and Apache http server running on different hosts
LAN traffic recorded on the gateway host
download to a mobile station behind the Agilent

the short version: when trying to download via WAP a (sound) file which is 
large, the gateway responds with '0x62' (bad gateway) in the status field of 
the Reply-PDU. Shouldn't it be '0x4D' (request entity too large)?

the long version: in the first Connect-PDU the mobile offers rather big client 
and server SDUs. The gateway aborts the connect, since it has SAR (segmentation 
and re-assembly) not implemented (however, the large SDUs are ACK'ed.) Now the 
mobile tries again connecting with a much, much smaller SDU, which succeeds. 
But trying to download a file larger than the currently valid (and small) SDU 
fails (which is perfectly ok.) However, the gateway sets the status of the 
Reply-PDU to '0x62' (bad gateway)!

Consulting the 'Wireless Session Protocol Specification' (5-July-2001, section 
8.2.3.3) reveals that the PDU status field should have a similar meaning than 
those in http. 

RFC 2616: the error id in question is 502. Section 10.5.3 (Bad Gateway) reads:
"The server, while acting as a gateway or proxy, received an invalid response 
from the upstream server it accessed in attempting to fulfill the request."
which is actually not the case: the very reason is that the file for download 
is too large (for whatever reason too large...) But this is handled in Section 
10.4.14 (Request Entity Too Large), error id 413:
"The server is refusing to process a request because the request entity is 
larger than the server is willing or able to process. ..." The PDU status field 
for this is '0x4D' (request entity too large)

So the question here is: is kannel right in giving back a 'bad server' status, 
or were 'request entity too large' more appropriate? (Which by the way would 
enable the mobile station to bring up a more expressive error message!)

Regards
Claus