DCS and PID handling in Kannel

The GSM data coding scheme (DCS) is broken up by Kannel into various 
seperate fields, as I've seen. The protocol id, however, is passed 
through as an opaque octet.

Why is that? PID could concievably be treated the same way as DCS, and 
broken up into human-friendly fields like replace_msg_class, 
message_type, etc.

On the other hand, I'd actually prefer the following:

DCS and PID should also be accepted (and sent to applications) as-is; 
any additional fields are sugar for the application (so the developers 
of CGI servers for Kannel don't need to deal with the full hairiness of 
the GSM params).

My problem with Kannel's DCS handling is that there are in many cases 
two valid representations for certain combinations of message class and 
user data coding scheme. Since Kannel shreds DCS into a bunch of fields, 
if I want to reconstruct the original DCS of the MO SM, I have a 
harmless but icky ambiguity; in many cases, I'll provide a new value 
that SHOULD be semantically equivalent, but MIGHT not be for some buggy 
devices/firmware/etc.

Wouldn't it be easier just to add an INTEGER field to the sms message 
type, and pass the DCS through "as-is"?

Thanks,

David WHITE
CONNECT AUSTRIA