International Support

There are several issues associated with device and service management systems which cross international borders, including:

• Providing support for international character sets in descriptions, class names , etc. defining the model. May I, for example, define a class called ?

• Providing support for international character sets in error and other messages originating from the WBEM server or providers. How does the code of a provider know whether to return an error message in Greek, Russian, or English?

• Allowing an operator to specify locale (which may govern the modeldevice X is not available in country Y and therefore should not appear in menus ) and language (which need not correspond to the locale).

• Allowing a string property to have several values simultaneously , each in a different language.

The issue of international support is covered briefly in Section 4.8 of the "CIM Operations over HTTP" specification (DSP0200). I address a variety of the international topics in the subsections below, but be aware that there can be significant differences between what the standard requires and what particular implementations currently deliver.

International Characters in CIM

In mof specifications, a different approach has been taken to international alphabets depending on whether or not the results are likely to be read outside the programming community (which is expected to be able to read English).

It is assumed that there is no need for internal keywords (e.g., the keyword "class" in mof or the IMETHODCALL tag in a CIM-XML message) to be in other than English as spoken in the United States of America because these keywords are only seen by programmers.

For the names of classes, properties, and other names which might be seen by an operator, the DMTF's Common Information Model Specification (DSP0004) defines the subset of Unicode characters that may be used. This includes most international characters.

Languages between WBEM Client and WBEM Server

It is fortunate that the WBEM client/server interface is encoded in XML because XML already has support for tagging and encoding different character sets and languages: all XML processors are required to read UTF-8 encoded strings (UTF-8 is defined in RFC2279 and encodes characters using sequences of 1 to 6 octetssee the glossary entry for Unicode). XML also allows the language of the contents of a message to be specified.

CIM-XML messages are, of course, commonly carried by HTTP(S) and HTTP supports support header fields known as Accept-Language and Content-Language. Accept-Language allows a client, when it invokes an exchange with a server, to specify the natural languages in which it can accept the response. For example,

 Accept-Language: da, en-gb;q=0.8, en;q=0.7 

means: "I prefer Danish, but will accept British English (with 80 percent acceptability) and other types of English (70 percent acceptability)."

Content-Language is set by both the client and the server and specifies the target audience for the contents of the HTTP message (not all of the words used in the message need be in the specified languagea page called "Teach Yourself French" is clearly aimed at an English-speaking audience, but will contain words in French).

International Providers

The XML and HTTP support described above is, of course, necessary, but not sufficient for a fully international interface between the WBEM client and server. In addition, the WBEM server has to exploit this underlying support and pass it on to the providers. You must therefore write your providers in such a way that they can exploit the information from the WBEM server. In particular:

• Ensure that all the strings in your code accept UTF-8 characters. openPegasus, for example, has a String class available for use by providers which stores the string using UTF-8 characters.

• Ensure that all constant strings (error messages, etc.) are included in a configuration file rather than being hard-coded into programs so that different languages can be acceptedhandle Accept-Language from the server. Ensure that you rephrase messages which might be offensive in some cultures and which will not translate well ("Parent terminated and child killed ").

• Ensure that you do not build messages from component parts . This may work in one language but lead to incorrect grammar in another.

• Avoid non-ASCII encodings (e.g., EBCDIC) if at all possible since ASCII maps cleanly to UTF-8 and other encodings.