octetstring

John Dennis jdennis at redhat.com
Wed Mar 20 03:06:31 UTC 2013


I need to pass binary data.

If I understand correctly from DSP0004 (Version 2.7.0) "Common 
Information Model (CIM) Infrastructure" one is supposed to apply the 
octetstring qualifier to a uint8 array. This is defined in section 
5.6.3.35 "OctetString". The first 4 octets in the buffer encode the length.

There are examples in the existing standard mof files which do this. 
However there are also odd usages of Octetstring applied to string 
arrays with comments to the effect only the first array element is to be 
populated. According to 5.6.3.35 such arrays also encode the length 
information, the entire data is encoded as hexadecimal character pairs.

However the CMPI specification makes no mention of octetstrings, nor do 
I see how the description in section 5.6.3.35 would even be passed in 
the existing CMPI model.

Konkret does not seem to understand the octetstring qualifier either. 
Declaring a uint8 array qualified with the octetstring qualifier 
produces a KUint8A, in other words an standard CMPI array of uint8 
(accessed one octet at a time with no embedded length, just normal array 
count).

One of the problems of passing a CMPI array of uint8 is there is no 
direct access to the data buffer, one must iterate over the uint8 array 
calling getElementAt() for each octet copying the data into a local 
buffer. This is highly inefficient.

What is the correct way to pass binary data?

Given that neither CMPI nor Konkret seem to understand the OctetString 
qualifier and the access methodology is both awkward and inefficient for 
arrays I'm wondering if one should use a string instead. Strings are 
supposed to be encoded in UTF-8 which implies their underlying 
representation is based on octets (i.e. not UCS2 or UCS4).

Is binary data one of those areas that isn't gracefully handled because 
it's an oddity?

-- 
John Dennis <jdennis at redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/


More information about the openlmi-devel mailing list