# Internet-Intranet Input Method Protocol (IIIMP) Specification
Revision 3.0 Draft 0.2

Authors:
Hideki Hiura (hiura@openi18n.org), OpenI18N.org, Free Standards Group
Hidetoshi Tajima (hidetoshi.tajima@eng.sun.com), Global Products Engineering, Sun Microsystems, Inc.

Document Date:
2004-07-14

## Contents

This document specifies the Internet-Intranet Input Method Protocol (IIIMP), which leverages network-based input method services for the Internet, Network Computer and Java. While IIIMP is designed for use by applications on Network Computers, this specification discusses its operation on other hardware platforms.

The IIIMP is the language in which all the information of text input can be communicated between Input Method Server and Clients in the network. The server and clients can operate either on different platforms in the network or on the same platform.

The IIIMP is the language which will be able to underline all software in various platforms among the network. The software of the Internet, Network Computer, Unix, Windows, or Java, can be the client of the Input Method Server.

The IIIMP is independent from any human language. Characters in the IIIMP is encoded in UTF-16 format, as the data format of STRING or TEXT, so almost any human languages written in the world today can be input.

0. Requirements Terminology
1. Request Header
2. Byte Order
3. Data Types and Notation

3.1 Primitive Data Types
3.2 Composite Data Types

4. Pre-Connection
5. Event Flow Control
6. Lookup Choice Operations
7. Object Downloading
8. Input Method Attributes
9. Input Context Attributes
10. Annotation Attributes
11. Protocol Format
Appendix A. Basic Protocol Numbers
Appendix B. Values for Character Subsets
Appendix C. CCDEF

# Requirements Terminology

Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in RFC2119.

# 1. Request Header

> Protocol packets contain basic request packet headers.

> There are two types of basic request packets:

> - 4-byte length
> - 8-byte length

> The basic request packets are distinguished from each other by the first bit in the packet header(either 0 or 1).

> ## 4-Byte Length Packet Header

> | TYPE: |  | CARD1: #x00
> | OPCODE: |  | CARD7
> | PACKET LENGTH: |  | CARD24

> ## 8-Byte Length Packet Header

> | TYPE: |  | CARD1: #x01
> | OPCODE: |  | CARD7
> | PACKET LENGTH: |  | CARD56

The 7-bit OPCODE field specifies the core request package represented by the packet. All OPCODE values are listed in the Appendix A of this document.

The PACKET LENGTH field specifies length of the packet as the number of 4-byte elements. The length excludes the length of header. The length field is always transmitted with the most significant byte first. Hence, the total length of a packet can be calculated as follows:

      // From 24-bit packet length field

       total_length = (
    		    (16-23 bit) << 16) +
    		    ( 8-15 bit) <<  8) +
    		    ( 0- 7 bit) <<  0)
    		   ) * 4;

      // From 56-bit packet length field

       total_length = (
    		    (48-56 bit) << 48) +
    		    (40-47 bit) << 40) +
    		    (32-39 bit) << 32) +
    		    (24-31 bit) << 24) +
    		    (16-23 bit) << 16) +
    		    ( 8-15 bit) <<  8) +
    		    ( 0- 7 bit) <<  0)
    		   ) * 4;

Return to Contents

# 2. Byte Order

> For remote clients, the IIIMP can be built on top of any reliable byte stream. The client must send an initial byte of data to identify the byte order to be employed. The value of the byte must be octal 102 or 154. The value 102 (ASCII uppercase B) means values are transmitted most significant byte first, and value 154 (ASCII lowercase l) means values are transmitted least significant byte first. Except where explicitly noted in the protocol, all 16-bit and 32-bit quantities sent by the client must be transmitted with this byte order, and all 16-bit and 32-bit quantities returned by the server will be transmitted with this byte order.
> The client sends the byte order in the IM_CONNECT request when the connection between Server and Client is setup. The server is responsible for adjusting the byte order for the client.

Return to Contents

# 3. Data Types and Their Notation

> ## 3.1 Primitive Data Types

> > The following primitive data types are used in the core IIIMP request.

> > CARD1 |  | 1-bit cardinal
> > CARD7 |  | 7-bit cardinal
> > CARD15 |  | 15-bit cardinal
> > CARD16 |  | 16-bit cardinal
> > CARD24 |  | 24-bit cardinal
> > CARD32 |  | 32-bit cardinal
> > CARD56 |  | 56-bit cardinal
> > INT16 |  | 16-bit signed integer
> > INT32 |  | 32bit signed integer
> > CHAR |  | 16-bit Unicode code element
> > BITMASK16 |  | 16-bit bitmask
> > BITMASK32 |  | 32-bit bitmask
> > PADDING |  | Where N is some expression and Pad(N) is the number of bytes needed to round N up to a multiple of four. Pad(N) = (4 - (N mod 4)) mod 4

> LISTof

> > LISTof representation is used to identify a numbered list of elements of one type.

> ## 3.2 Composite Data Types

> > The following composite data types, which are combinations of any predefined primitive data types, are used in the core IIIMP request.

> > STRING

> > > 2 | 2n | byte length of LISTofCHAR
> > > 2n | LISTofCHAR | Unicode code elements
> > > p |  | unused, p=Pad(2 + 2n)

> > FEEDBACK

> > > 4 | CARD32 | Feedback

> > FEEDBACK_ATTR

> > > 4 | CARD32 | Feedback ID
> > > 4 | CARD32 | Feedback

> > The Feedback ID 0 (zero) is registered for the following visual attributes to emphasize a character:

> > #0 | Normal Video
> > #1 | Reverse Video
> > #2 | Underline

> > Other Feedback Id-s and values will be pre-negotiated. Details are pending.

> > CHAR_WITH_FEEDBACK

> > > 2 | CHAR | Unicode code element
> > > 2 | 4n | byte length of Feedback attribute array
> > > 4n | LISTofFEEDBACK_ATTR | feedbacks

> > OPERATION

> > > 4n | STRING | operation identifier
> > > 2 | n | byte length of value
> > > n |  | value
> > > p |  | unused, p=Pad(n)

> > Operation identifier must be one of the predefined strings in the CCDEF rules.

> > ANNOTATION_VALUE

> > > 4 | INT32 | start index
> > > 4 | INT32 | end index
> > > 4 | n | byte length of value
> > > n |  | value
> > > p |  | unused, p=Pad(n)

> > ANNOTATION

> > > 4 | CARD32 | attribute-ID
> > > 4 | 4n | byte length of list of annotation value
> > > 4n | LISTofANNOTATION_VALUE | list of annotation value

> > TEXT

> > > 4 | 4n | byte length of list of char_with_feedback
> > > 4n | LISTofCHAR_WITH_FEEDBACK | list of char with feedbacks
> > > 4 | 4m | byte length of list of annotation
> > > 4m | LISTofANNOTATION | list of annotation

> > The 'start index' field in an 'annotation value' data specifies the index of the character in the list of CHARS of the given TEXT, from which the given annotation value should be applied.
> > The 'end index' field in an 'annotation value' data specifies the index of the character in the list of CHARS of the given TEXT, to which the given annotation value should be applied. The index value to the first character in the list of CHARS is 0, and the index to the last character is (length_of_character - 1).
> > Either or both of 4m/4n of the TEXT can be 0.

> > ATTRIBID

> > > 1/8 | CARD1 | Predefined Indicator
> > > 15/8 | CARD15 | Enumerated ID Value

> > > The value of Predefined Indicater is defined as follows;

> > > #0 | Enumerated ID values are in the primitive predefined type, which is not bound to particular instance of such type.
> > > #1 | Enumerated ID values are session dependent, dynamically negotiated value, which is specifically bound to particular instance of such type.

> > CLIENTDESCRIPTOR

> > > 4n | STRING | Application type
> > > 4k | STRING | Operating system name
> > > 4l | STRING | Operating system architecture
> > > 4m | STRING | Operating system version

> > OBJECTDESCRIPTOR

> > > 2 | CARD16 | Object category
> > > 2 |  | unused, 2=Pad(2)
> > > 4 | CARD32 | Object size
> > > 2 | ATTRIBID | Pridefined attribute-ID to describe primitive type of object
> > > 2 | ATTRIBID | Dynamically assigned attribute-ID
> > > 4k | STRING | Object name in the reversed domain unique name
> > > 4l | STRING | Object description in HRN
> > > 4m | STRING | Object Signature
> > > 4n | STRING | Object User

> > > The value of Object category is defined as follows;

> > > #0 | GUI Object
> > > #1 | LWE Object
> > > #2 | Syntax Rule Object
> > > #3 | IM Manager rule Object
> > > #4 | Preloading LWE Object

> > > The Object User is the input method editor name with which the the object is of use. If the object can be used by any input method editor, the Object User field should be "GENERIC".

> > CCDEF(Character Conversion Definition Rule File)

> > > 4m | STRING | contents of ccdef

> > LANGUAGE

> > > 4m | STRING | Human Readable Name of language
> > > 4n | STRING | language identifier

> > > The language identifier is a tag string to be spelled out as specified in RFC 1766, making use only of registered tag values or of user-defined language tag starting with the characters "x-".

> > JARFILE_OBJECT

> > > 4 | 4m | byte length of class name list
> > > 4m | LISTofSTRING | class names
> > > 4 | n | byte length of jar file
> > > n |  | jar file byte stream
> > > p |  | unused, p=Pad(n)

> > INPUTMETHOD_DESCRIPTOR

> > > 2 | ATTRIBID | Input method identifier
> > > 2 |  | unused, p=Pad(2)
> > > 4m | STRING | input method name in the reversed unique domain name
> > > 4l | STRING | Human Readable Name of input method
> > > 4 | 4n | byte length of supported language list
> > > 4n | LISTofLANGUAGE | supported language list

> > IMATTRIBUTE

> > > 2 | ATTRIBID | attribute-ID
> > > 2 |  | unused, 2=Pad(2)
> > > 4 | n | byte length of value
> > > n |  | value
> > > p |  | unused, p=Pad(n)

> > ICATTRIBUTE

> > > 2 | ATTRIBID | attribute-ID
> > > 2 | n | byte length of value
> > > n |  | value
> > > p |  | unused, p=Pad(n)

> > KEYEVENT

> > > 4 | INT32 | keycode
> > > 4 | INT32 | keychar
> > > 4 | INT32 | key modifier
> > > 4 | INT32 | time stamp

> > CONTENTS

> > > 4 | CARD32 #0 #1 #2 | type STRING TEXT KEYEVENT

> > > If type is #0, the arguments continue as follows.

> > > 4n | STRING | string with no feedback

> > > If type is #1, the arguments continue as follows.

> > > 4n | TEXT | text

> > > If type is #2, the arguments continue as follows. The type #2 is used only in the IM_FORWARD_EVENT message or IM_FORWARD_EVENT_WITH_OPERATIONS message.

> > > 4 | 4n | byte length of key event list
> > > 4n | LISTofKEYEVENT | key event list

> > HOTKEYCTL

> > > 2 | CARD16 | HOTKEY ID
> > > 1 | CARD8 #1 #0 | State Flag Enabled Disabled
> > > 1 | CARD8 #2 #1 #0 | Action flag event forwarding toggle event forwarding on event forwarding off

> > > If state flag is #1, the corresponding hostkey is in function, If state flag is #0, the corresponding hostkey is temporally suspended.

> > > If Action flag is #2, the result of the action on corresponding hostkey would toggle the event forwarding. If Action flag is #1, the result of the action on corresponding hostkey would enable event forwarding. If Action flag is #0, the result of the action on corresponding hostkey would disable event forwarding.

> > HOTKEY

> > > 4 | HOTKEYCTRL | hotkey control
> > > 4 | n | byte length of HOTKEY keyevent
> > > n | LISTofKEYEVENT | List of hotkeys
> > > 4m | STRING | Text label for the hotkeys

Return to Contents

# 4. Pre-Connection

> The location of Input Method service is specified by a URL, as follows:

>     iiimp://servername:portid

> The servername is the name of the host running the IIIMP server, and portid the port id used by the IIIMP server.

Return to Contents

# 5. Event Flow Control

> IIIMP supports two event flow models for communication between the Input Method Server and Clients: Static Event Flow and Dynamic Event Flow.

> Static Event Flow requires that input events always be sent from the clients to the server soon after the connection is setup, and the server gets ready to start input method service.

> Dynamic Event Flow, however, requires that only those input events which need to be processed (converted) be sent from the clients to the server.

> For instance, when the client needs to input both ASCII characters and Chinese characters, it is most likely that ASCII characters can be input directly from a keyboard, but Chinese characters will be able to input only through Input Method. Then, the client does not send input events to the server when it inputs ASCII, but it does when it inputs Chinese and the input events are processed by the server, so their key events need not be sent to the server.

> The Dynamic Event Flow is used to reduce the number of input events exchanged between the Input Method Clients and the Server as well as the number of context switches, resulting in improved performance.

> To enable Dynamic Event Flow, the server is responsible for sending a list of on-keys in IM_REGISTER_TRIGGER_KEYS request. When an input event matches one of on-keys, the client sends the IM_TRIGGER_NOTIFY message to notify the server that the client will start forwarding input events, and the server should start input method service.

> While the 'on-keys' field in IM_REGISTER_TRIGGER_KEYS is required to do Dynamic Event Flow, the 'off-keys' field is optional.

> If the server set off-keys as well, and the client gets an input event matching one of off-keys, then the client sends the IM_TRIGGER_NOTIFY message to notify the server to stop forwarding input events, and the server should also stop input method service.. If the server did not register any off-keys, then the server will send the IM_TRIGGER_NOTIFY message to the client to stop forwarding input events.

Return to Contents

# 6. Lookup Choice Operations

> The Input Method Server sends IM_LOOKUP_CHOICE_START to the Input Method client at the beginning of the lookup choice operation and IM_LOOKUP_CHOICE_DONE at the end. This gives the client an opportunity to perform any necessary internal setup or cleanup of lookup operation.

> In the IM_LOOKUP_CHOICE_START message, the server should inform the client of the following attributes of the lookup choice operation:

> Which is Master

> > This attribute tells the client how the server will handle the lookup choice operation.

> > When the attribute is set to #1 (ServerIsMaster), the server issues the IM_LOOKUP_CHOICE_DRAW message every time the lookup candidates are changed. Thus, the server will never send IM_LOOKUP_CHOICE_PROCESS to update the page.

> > When the attribute is set to #2 (ClientIsMaster), the server issues the IM_LOOKUP_CHOICE_DRAW message with all the lookup candidates at one time. The client displays the candidates on a number of pages, using the values of choice_per_window, number_of_columns, and number_of_rows. The server will issue IM_LOOKUP_CHOICE_PROCESS to let the client page backward and forward or let the client select a candidate.

> Choice per Window

> > This attribute specifies the number of lookup candidates to display in a lookup window at a time.

> Number of Rows

> > This attribute specifies the number of rows of lookup candidates to display in a lookup window.

> Number of Columns

> > This attribute specifies the number of columns of lookup candidates to display in a lookup window.

> Drawing up Direction

> > This attribute specifies the drawing direction of lookup candidates.

> Which owns Label

> > This attribute indicates whether a list of lookup candidates in IM_LOOKUP_CHOICE_DRAW is sent with an associated list of index labels. When the attribute is set to #0 (ServerOwnsLabel), candidates are sent with as many index labels. When it is set to #1 (ClientOwnsLabel), no index label is sent, and the client is responsible for putting proper index label to every candidate.

Return to Contents

# 7. Object Downloading

> IIIMF supports object downloading where either binary or text data objects to perform operations at IIIM client side can be down-loaded from IIIM server.

> A binary data object types supported in IIIMP V2.0 is an input method GUI object which performs preedit, lookup, status, or auxiliary function, or a light weight engine object which should work as front-end input method on IIIM client side and collaborate well with the associated IIIM server.

> A text data object supported in IIIMP V2.0 is character conversion rule file, which is written in pre-defined format syntax, called CCDEF. It describes the rules of key-action binding and text composition which should be performed on the client side.

## 7.1 Downloading Convention

> Any single set of IIIM Protocol sequence starts from one protocol packet from IIIMCF and ends with the corresponding synchronous reply packet from IIIMSF. Any subsequent protocol which IIIMSF needs to initiate must be put between such an outer request-and-reply roundtrip protocol sequence initiated by IIIMCF. This is an IIIM Protocol principal to simplify the parsing process of protocol, and a limitation of IIIM Protocol.

> Object downloading opration follows this IIIM Protocol principal. Basic downloading operation is always initiated by client as either active downloading request or passive downloading request.

> Downloading operation is always triggered by the client sending IM_GETIMVALUES to the server with any of GUIObjectList, LWEObjectList, or SyntaxRuleObjectList as its arguments. Each IM values returned as a part of IM_GETIMVALUES_REPLY. includes the dynamically defined ATTRIBID(thus, Predfined Indicator of ATTRIBID is set to 1) as well as the description of each objects the server holds, as a part of either GUIOBJECTID, LWEOBJECTID, or SRULEOBJECTID.

> The client is to choose which object to load by the object description information in the List of *OBJECTID returned from the server, then spcify the ATTRIBID associated with the particular concrete object with subsequent IM_GETIMVALUES or IM_GETICVALUES. The conrete object itself corresponding with the specified ATTRIBID is returned from the server as a part of IM_GETIMVALUES_REPLY. or IM_GETICVALUES_REPLY

> server. For the associated input method attribute ID, refer to the next section, 8. Input Method Attributes.

### Active downloading convention

> Active downloading request is a pure pulling operation. IIIMCF simply issues IM_GETIMVALUES or IM_GETICVALUES with an attribute-ID of Downloadable Object List.

> Downloadable Object List contains a list of a set of IM Attribute ID dynamically allocated, object type, size, name, HRN, and signature as an authenticatioon information. The signature is bound to the ACL referred by IIIMCF to validate the objects linked with the host and the domain where the objects is loaaaded from.

> IIIMCF then issues IM_GETIMVALUES with one or more of the attribute-IDs dynamically assigned by IIIMSF and given to IIIMCF as a part of the Downloadable Object list returned from IIIMSF.

### Passive downloading convention

> Passive downloading request is a convention to allow IIIMSF to send a proxy which initiates further object downloading by initiating an active downloading.

> IIIMCF which wishes to allow object downloading must issues IM_GETIMVALUES with an attribute-ID of Downloadable Object List. The name of a special proxy frontend is reserved IIIMSF prepares

> The physical loading trigger must be initiated from client as a part of IM_GETIMVALUES convention before IM_CREATEIC.

> IIIMCF must issue IM_GETIMVALUES with PRELOADOBJECTLIST attribute to retrieve the list of object to preload, then IIIMCF shall preload the objects accordingly. The PRELOADOBJECTLIST returns LIST of LWEOBJECTID to be preloaded.

Return to Contents

# 8. Input Method Attributes

> The input method Attribute is communicated with enumerated ID values in ATTRIBID data type. classified into two category; Predefined primitive attributes and dynamically negotiated, concrete attributes. The predefined attributes are used to describe the type of the attribute in the dynamically negotiated, concrete attributes, and the dyanamically negotiated The predefined Input Method attributes are listed in the following tables.

> Name | ATTRIBID | Value Type | [S]et/[G]et
> --- | --- | --- | ---
> Input Method List | #0x1001 | LISTofINPUTMETHOD_DESCRIPTOR | S(Server->Client)
> Object Descriptor List | #0x1010 | LISTofOBJECTDESCRIPTOR | S(Server->Client)
> Client Descriptor | #0x1011 | CLIENTDESCRIPTOR | S(Client->Server)
> Character Conversion Definition Rule | #0x1030 | CCDEF | G(Client->Server)
> Jar GUI Object | #0x1031 | JARFILE_OBJECT | G(Client->Server)
> Jar Light Weight Engine Object | #0x1032 | JARFILE_OBJECT | G(Client->Server)
> Binary GUI Object | #0x1033 | BINARYFILE_OBJECT, for java clients | G(Client->Server)
> Binary Light Weight Engine Object | #0x1034 | BINARYFILE_OBJECT | G(Client->Server)
> SCRIPT GUI Object | #0x1035 | BINARYFILE_OBJECT, for java clients | G(Client->Server)
> SCRIPT Light Weight Engine Object | #0x1036 | BINARYFILE_OBJECT | G(Client->Server)

> Input Method List

> The input method list attribute gives a list of input methods, Note that the "input method" terminology is used for both local front-end input method objects on client side, and remote input methods on server side.

> Character Conversion Definition Rule

> The CCDEF(Character Conversion Definition Rule) is a text file down-loaded from the Input Method Server to Input Method client. The client parses the content of the file and understands the rules of text composition and key-action binding which the server expects the client to perform.

> GUI Object
> Light Weight Engine Object

> Both of the input method attributes are sent from the server to the client with IM_GETIMVALUES_REPLY protocol when the client sends IM_GETIMVALUES to query the attribute. The format of the value is different according to client machine architecture type. For Java clients, jar file format is used.

Return to Contents

# 9. Input Context Attributes

> The input context Attribute is communicated with enumerated ID values in ATTRIBID data type. classified into two category; Predefined primitive attributes and dynamically negotiated, concrete attributes. The predefined attributes are used to describe the type of the attribute in the dynamically negotiated, concrete attributes, and the dyanamically negotiated The predefined Input Context attributes are listed in the following tables.

> Name | ATTRIBID | Value Type | [S]et/[G]et
> --- | --- | --- | ---
> InputLanguage | #01 | STRING | CSG
> Character Subsets | #02 | LISTofCARD32 | CSG
> InputMethod | #03 | CARD16 | CSG

> Input Language

> The input language attribute gives the server a hint on an input language so that the server can tune an input method service appropriately.
> The value of the language attribute is a tag to be spelled out as specified in RFC 1766, making use only of registered tag values or of user-defined language tag starting with the characters "x-". The behavior of user-defined language attribute is undefined.

> For example, to specify a language to Japanese, the tag should be used is "ja" (composed of ISO 639 language id) or, alternatively, "ja-JP" (composed of ISO 639 language id plus ISO 3166 country id).

> Although RFC 1766 specifies that language tag are not case significant, IIIMP only allows the entire language tag in lowercase.

> Character Subsets

> The subsets of the Unicode character set that input methods of this input context should be allowed to input. If the attribute is not set, or 0 length of list is set, the Input Method Server will be allowed to input all characters.
> The predefined values for character subsets are listed in the Appendix B. Names of character subsets are derived from Class java.lang.Character.Subset of Java Developer Kit, Version 1.2.

> Input Method

> The value of the input method ic-attribute is an integer of CARD16 type, which is one of the ATTRIBID values in the INPUTMETHOD_DESCRIPTOR list, which has been sent from IIIMSF to the IIIMCF.

Return to Contents

# 10. Annotation Attributes

> The predefined annotation attributes are listed in the following tables.

> Name: | ID: | Value Type: | Synopsis:

> Input String | #01 | TEXT | text input before conversion
> Reading | #02 | TEXT | reading of the text
> Part of speech | #03 | STRING | type of speech
> Clause | #04 | STRING | type of clause

> Input String

> The input string annotation attribute gives the input string which leaded to the associated text as conversion result.

> Reading

> The reading annotation attribute gives the reading of some text in the associated text. The reading annotation is often used in those languages where the written form of the text and the pronunciation of a word are only loosely related.

> Part of speech

> The part of speech annotation attribute gives the information how the associated text should be broken up into parts of speech, which usually correspond to words.

> Clause

> The clause annotation attribute gives the information how the associated text should be broken up into parts of clause, which usually correspond to phrases.

Return to Contents

# 11. Protocol Format

> IM_CONNECT(Client->Server)

> > 1 | #x42 MSB first #x6c LSB first | byte order
> > 1 | CARD8 | protocol version
> > 4m | STRING | user name
> > 2 | n | byte length of client auth protocol names
> > 4n | LISTofSTRING | client auth protocol names

> > The client must first send the IM_CONNECT message after the network connection is done. The list specifies the names of authentication protocols the Input Method Server is willing to perform. If the client needs no authentication, the list may be omitted.

> > The protocol version specifies the version of the IIIMP which the server supports. This document specifies version #x02.

> > The user name field is formatted as follows:

> >     	<user_login_name>@<user_host_name>#<client_machine_type>

> IM_CONNECT_REPLY(Server->Client)

> > 2 | CARD16 | input method id
> > 2 | 4n | byte length of list of language names
> > 4n | LISTofSTRING | list of language names

> > The server is responsible for sending IM_CONNECT_REPLY to the client, containing a supported language names to perform input. The client will wait until IM_CONNECT_REPLY is sent since IM_CONNECT is a synchronous request.

> IM_DISCONNECT(Client->Server)

> > 2 | CARD16 | input method id
> > 2 |  | unused, p=Pad(2)

> > The client should send the IM_DISCONNECT request before it shuts the network connection.

> IM_DISCONNECT_REPLY(Server->Client)

> > 2 | CARD16 | input method id
> > 2 |  | unused, p=Pad(2)

> > The server is required for sending back IM_DISCONNECT_REPLY to the client, The client will wait until IM_DISCONNECT_REPLY is sent since IM_DISCONNECT is a synchronous request.

> IM_REGISTER_TRIGGER_KEYS(Server->Client)

> > 2 | CARD16 | input method id
> > 2 |  | unused, p=Pad(2)
> > 4 | 4n | byte length of on-keys
> > 4n | LISTofKEYEVENT | trigger keys to turn on
> > 4 | 4m | byte length of off-keys
> > 4m | LISTofKEYEVENT | trigger keys to turn off

> > To switch the event flow to the Dynamic Event Flow model, the server is responsible for sending IM_REGISTER_TRIGGER_KEYS request to the client after it receives IM_CONNECT and before it sends IM_CONNECT_REPLY. If the server does not send IM_REGISTER_TRIGGER_KEYS, the client will always forward input events to the server, in accord with the Static Event Flow model.

> IM_TRIGGER_NOTIFY(Client<->Server)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id
> > 2 | CARD16 #0 #1 | flag on off
> > 2 |  | unused, 2=Pad(2)

> IM_TRIGGER_NOTIFY_REPLY(Client<->Server)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id

> > The client uses the IM_TRIGGER_NOTIFY request to notify the server that an input event occurred which matches either on-keys or off-keys which have been registered with IM_REGISTER_TRIGGER_KEYS.

> > If the server has only registered on-keys, the server must notify the client to stop forwarding input events to the server. To do so, the server sends the IM_TRIGGER_NOTIFY message to the client.

> > The receiver of IM_TRIGGER_NOTIFY request is responsible for sending IM_TRIGGER_NOTIFY_REPLY to the sender. The sender will wait until IM_TRIGGER_NOTIFY_REPLY is sent since IM_TRIGGER_NOTIFY is a synchronous request.

> IM_REGISTER_HOT_KEYS(Server->Client)

> > 2 | CARD16 | input method id
> > 2 |  | unused, p=Pad(2)
> > 2 | CARD16 #1 #0 | State Flag session specific hotkey global hotkey
> > 2 | n | byte length of LISTofHOTKEY
> > n | LISTofHOTKEY | hotkey list

> IM_CONTROL_HOTKEYS(Server->Client)

> > 2 | CARD16 | input method id
> > 2 |  | unused, p=Pad(2)
> > 2 | CARD16 #1 #0 | State Flag session specific hotkey global hotkey
> > 2 | n | byte length of LISTofHOTKEYCTL
> > n | LISTofHOTKEYCTL | hotkey control list

> IM_HOTKEY_NOTIFY(Client<->Server)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id
> > 2 | CARD16 | hotkey id
> > 2 | CARD16 | index of KEYEVENT in ListOfHOTKEY

> IM_HOTKEY_NOTIFY_REPLY(Client<->Server)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id

> IM_SETIMVALUES(Client<->Server)

> > 2 | CARD16 | input method id
> > 2 |  | unused, 2=Pad(2)
> > 4 | 4n | byte length of im-attribute
> > 4n | LISTofIMATTRIBUTE | im-attributes

> > The client sends IM_SETIMVALUES request to set a list of IMATTRIBUTE.

> IM_SETIMVALUES_REPLY(Server<->Client)

> > 2 | CARD16 | input method id
> > 2 |  | unused, p=Pad(2)

> > The server is responsible for setting a given list of IMATTRIBUTES to the input method connection for the client and sending IM_SETIMVALUES_REPLY back to the client after receiving IM_SETIMVALUES request. The client will wait until IM_SETIMVALUES_REPLY is sent since IM_SETIMVALUES is a synchronous request.

> IM_GETIMVALUES(Client->Server)

> > 2 | CARD16 | input method id
> > 2 |  | unused, 2=Pad(2)
> > 4 | 2n | byte length of im-attribute
> > 2n | LISTofCARD16 | im-attribute
> > p |  | unused, p=Pad(2n)

> > The client sends IM_GETIMVALUES request to get a list of IMATTRIBUTE.

> IM_GETIMVALUES_REPLY(Server->Client)

> > 2 | CARD16 | input method id
> > 2 |  | unused, 2=Pad(2)
> > 4 | 4n | byte length of im-attribute
> > 4n | LISTofIMATTRIBUTE | im-attributes

> > The server is responsible for sending IM_GETIMVALUES_REPLY with a list of IMATTRIBUTE which were requested by the client. The client will wait until IM_GETIMVALUES_REPLY is sent since IM_GETIMVALUES is a synchronous request.

> IM_CREATEIC(Client->Server)

> > 2 | CARD16 | input method id
> > 2 | 4n | byte length of ic-attribute
> > 4n | LISTofICATTRIBUTE | ic-attributes

> > The client sends IM_CREATEIC request for the server to create a new input context.

> IM_CREATEIC_REPLY(Server->Client)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id

> > The server is responsible for creating a new input context for the client and sending IM_CREATEIC_REPLY back to the client after receiving IM_CREATEIC request. The input context id should consist of an unique value for the server, so that the server can get the associated input context to any further request of the client. The client will wait until IM_CREATEIC_REPLY is sent since IM_CREATEIC is a synchronous request.

> IM_DESTROYIC(Client->Server)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id

> > The client sends IM_DESTROYIC request for the server to destroy the input context.

> IM_DESTROYIC_REPLY(Server->Client)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id

> > The server is responsible for destroying the input context associated to the given input context id.

> > The server may send other requests to the sender, to update preedit text or the status indicator window, to set choices in lookup window, or to commit a string or text before sending IM_DESTROYIC_REPLY back to the client.

> > The client will wait until IM_DESTROYIC_REPLY is sent since IM_DESTROYIC is a synchronous request.

> IM_SETICVALUES(Client->Server)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id
> > 2 | 4n | byte length of ic-attribute
> > 4n | LISTofICATTRIBUTE | ic-attributes
> > 2 |  | unused, 2=Pad(2)

> > The client sends IM_SETICVALUES request to set a list of ICATTRIBUTE.

> IM_SETICVALUES_REPLY(Server->Client)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id

> > The server is responsible for setting a given list of ICATTRIBUTES to the specified input context for the client and sending IM_SETICVALUES_REPLY back to the client, after receiving IM_SETICVALUES request. The client will wait until IM_SETICVALUES_REPLY is sent since IM_SETICVALUES is a synchronous request.

> IM_GETICVALUES(Client->Server)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id
> > 2 | 2n | byte length of ic-attribute
> > 2n | LISTofCARD16 | ic-attribute
> > p |  | unused, p=Pad(2+2n)

> > The client sends IM_GETICVALUES request to get a list of ICATTRIBUTE.

> IM_GETICVALUES_REPLY(Server->Client)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id
> > 2 | 4n | byte length of ic-attribute
> > 4n | LISTofICATTRIBUTE | ic-attributes
> > 2 |  | unused, 2=Pad(2)

> > The server is responsible for sending IM_GETICVALUES_REPLY with a list of ICATTRIBUTE which were requested by the client. The client will wait until IM_GETICVALUES_REPLY is sent since IM_GETICVALUES is a synchronous request.

> IM_SETICFOCUS(Client->Server)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id

> > The client sends IM_SETICFOCUS request to the server.

> IM_SETICFOCUS_REPLY(Server->Client)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id

> > The server is responsible for unsetting the input focus from the current input context, and setting the input focus to the associated input context and sending IM_SETICFOCUS_REPLY back to the client after receiving IM_SETICFOCUS request. The client will wait until IM_SETICFOCUS_REPLY is sent since IM_SETICFOCUS is a synchronous request.

> IM_UNSETICFOCUS(Client->Server)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id

> > The client sends IM_UNSETICFOCUS request to the server.

> IM_UNSETICFOCUS_REPLY(Server->Client)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id

> > The server is responsible for unsetting the input focus from the associated input context and sending IM_UNSETICFOCUS_REPLY back to the client after receiving IM_UNSETICFOCUS request. The client will wait until IM_UNSETICFOCUS_REPLY is sent since IM_UNSETICFOCUS is a synchronous request.

> IM_RESETIC(Client->Server)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id

> > The client sends IM_RESETIC request to notify the server to reset the input context for the given input context ID.

> IM_RESETIC_REPLY(Server->Client)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id

> > The server may send other requests to the sender, to update preedit text or the status indicator window, to set choices in lookup window, or to commit a string or text before sending IM_RESETIC_REPLY back to the client.

> > The client will wait until IM_RESETIC_REPLY is sent since IM_RESETIC is a synchronous request.

> IM_PREEDIT_START(Server->Client)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id

> > The server sends IM_PREEDIT_START request to notify the client to do the setup for the region of text input conversion.

> IM_PREEDIT_START_REPLY(Client->Server)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id
> > 4 | INT32 | max length of preedit string

> > The max length of preedit string attribute is a positive integer or -1 (-1 indicates there is no limit).

> > The client is responsible for sending IM_PREEDIT_START_REPLY back to the server after receiving IM_PREEDIT_START request. The server will wait until IM_PREEDIT_START_REPLY is sent since IM_PREEDIT_START is a synchronous request.

> IM_PREEDIT_DRAW(Server->Client)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id
> > 4 | INT32 | caret
> > 4 | INT32 | change first
> > 4 | INT32 | change length
> > 4n | CONTENTS | preedit string or text

> > The server sends IM_PREEDIT_DRAW request to let the client do some operation to the preedit text.

> > The client is responsible for updating a buffer of the preedit text. The fields 'caret', 'change first', 'change length', and 'preedit string or text' have specific meanings according to the possible operations.

> > > Text Deletion:
> > > When the CONTENTS field contains 0 length of text data, it indicates the delete operation. The text to be deleted is then the current text in the buffer from position chg_first (starting at zero) on a character length of chg_length.

> > > When the CONTENTS field contains possible length of text data, it indicates either insertion or replacement of text in the buffer.

> > > Text Insertion:
> > > A chg_length value of zero indicates that text must be inserted right at the position specified by chg_first. A value of zero for chg_first specifies the first character in the buffer.

> > > Text Replacement:
> > > A positive chg_length indicates that chg_length number of characters, starting at chg_first must be replaced by text, whose length is specified in the text field of the CONTENTS data.

> > > Moving Cursor position:
> > > The caret field identifies the character position before which the cursor should be placed - after modification to the preedit buffer by insertion/replacement/deletion has been completed. For example, if caret is zero, the cursor is at the beginning of the buffer. If the caret is one, the cursor is between the first and second character.

> IM_PREEDIT_DRAW_REPLY(Client->Server)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id

> > The client is responsible for sending IM_PREEDIT_DRAW_REPLY back to the server after receiving IM_PREEDIT_DRAW request. The server will wait until IM_PREEDIT_DRAW_REPLY is sent since IM_PREEDIT_DRAW is a synchronous request.

> IM_PREEDIT_DONE(Server->Client)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id

> > The server sends IM_PREEDIT_DONE request to notify the client to do the cleanup for the region of text input conversion.

> IM_PREEDIT_DONE_REPLY(Client->Server)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id

> > The client is responsible for sending IM_PREEDIT_DONE_REPLY back to the server after receiving IM_PREEDIT_DONE request. The server will wait until IM_PREEDIT_DONE_REPLY is sent since IM_PREEDIT_DONE is a synchronous request.

> IM_STATUS_START(Server->Client)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id

> > The server sends IM_STATUS_START request to notify the client to do the setup for the region of input method status indication.

> IM_STATUS_START_REPLY(Client->Server)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id

> > The client is responsible for sending IM_STATUS_START_REPLY back to the server after receiving IM_STATUS_START request. The server will wait until IM_STATUS_START_REPLY is sent since IM_STATUS_START is a synchronous request.

> IM_STATUS_DRAW(Server->Client)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id
> > 4n | CONTENTS | status string or text

> > The server sends IM_STATUS_DRAW request to notify the client to update the region of input method status indication with the given text in the CONTENTS data.

> IM_STATUS_DRAW_REPLY(Client->Server)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id

> > The client is responsible for sending IM_STATUS_DRAW_REPLY back to the server after receiving IM_STATUS_DRAW request. The server will wait until IM_STATUS_DRAW_REPLY is sent since IM_STATUS_DRAW is a synchronous request.

> IM_STATUS_DONE(Server->Client)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id

> > The server sends IM_STATUS_DONE request to notify the client to do the cleanup for the region of input method status indication.

> IM_STATUS_DONE_REPLY(Client->Server)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id

> > The client is responsible for sending IM_STATUS_DONE_REPLY back to the server after receiving IM_STATUS_DONE request. The server will wait until IM_STATUS_DONE_REPLY is sent since IM_STATUS_DONE is a synchronous request.

> IM_FORWARD_EVENT(Client<->Server)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id
> > 4n | CONTENTS | forwarded string, text or event

> > The IM_FORWARD_EVENT request is used for forwarding input events from the client to the server to filter the input event, and do text input conversion. On the other hand, IM_FORWARD_EVENT is also used for forwarding the input events from the server to the client if the event previously forwarded from the client is not filtered by the server.

> IM_FORWARD_EVENT_REPLY(Client<->Server)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id

> > The client will wait until IM_RESETIC_REPLY is sent since IM_RESETIC is a synchronous request.

> > The receiver of IM_FORWARD_EVENT may send other requests to the sender to update preedit text or the status indicator window, to set choices in lookup window, or to commit a string or text before sending IM_FORWARD_EVENT_REPLY back to the sender.

> > The sender will wait until IM_FORWARD_EVENT_REPLY is sent since IM_FORWARD_EVENT is a synchronous request.

> IM_FORWARD_EVENT_WITH_OPERATIONS(Client<->Server)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id
> > 4m | CONTENTS | forwarded string, text or event
> > 4 | 4n | byte length of operation list
> > 4n | LISTofOPERATION | operation list

> > The IM_FORWARD_EVENT_WITH_OPERATIONS request is used for forwarding input events from the client to the server to filter the input event, and do text input conversion. On the other hand, IM_FORWARD_EVENT_WITH_OPERATIONS is also used for forwarding the input events from the server to the client if the event previously forwarded from the client is not filtered by the server.

> IM_FORWARD_EVENT_WITH_OPERATIONS_REPLY(Client<->Server)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id
> > 4 | 4n | byte length of unprocessed operation list
> > 4n | LISTofOPERATION | unprocessed operation list

> > The receiver of IM_FORWARD_EVENT_WITH_OPERATIONS may send other requests to the sender, to update preedit text, to update the status indicator window, to set choices in lookup window, or to commit a string or text before sending IM_FORWARD_EVENT_WITH_OPERATIONS_REPLY back to the sender.

> > The sender will wait until IM_FORWARD_EVENT_WITH_OPERATIONS_REPLY is sent since IM_FORWARD_EVENT_WITH_OPERATIONS is a synchronous request.

> > If all the given operations in IM_FORWARD_EVENT_WITH_OPERATIONS has been successfully processed, then IM_FORWARD_EVENT_WITH_OPERATIONS_REPLY contains no list of unprocessed operation.

> IM_COMMIT_STRING(Server->Client)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id
> > 4n | CONTENTS | commit string or text

> > The server sends IM_COMMIT_STRING to the client to commit a string or text, specified in the given CONTENTS field. The IM_COMMIT_STRING may be sent as the result of former IM_FORWARD_EVENT request from the client.

> IM_LOOKUP_CHOICE_START(Server->Client)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id
> > 2 | CARD16 #1 #2 | which is master ServerIsMaster ClientIsMaster
> > 2 | CARD16 | choice per window
> > 2 | CARD16 | number of rows
> > 2 | CARD16 | number of columns
> > 2 | CARD16 #0 #1 | drawing up direction DrawingUpHorizontally DrawingUpVertically
> > 2 | CARD16 #0 #1 | which owns label ServerOwnsLabel ClientOwnsLabel

> > The server sends IM_LOOKUP_CHOICE_START request to notify the client to do the setup for the region of lookup choice operation. Once the server sends IM_LOOKUP_CHOICE_START request, it must not send IM_LOOKUP_CHOICE_START again to the client before it sends IM_LOOKUP_CHOICE_DONE. has been called.

> IM_LOOKUP_CHOICE_START_REPLY(Client->Server)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id

> > The client is responsible for sending IM_LOOKUP_CHOICE_START_REPLY back to the server after receiving IM_LOOKUP_CHOICE_START request. The server will wait until IM_LOOKUP_CHOICE_START_REPLY is sent since IM_LOOKUP_CHOICE_START is a synchronous request.

> IM_LOOKUP_CHOICE_DRAW(Server->Client)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id
> > 4 | INT32 | index of first candidate
> > 4 | INT32 | index of last candidate
> > 4 | INT32 | index of current candidate
> > 4 | 4l | byte length of choice list
> > 4l | LISTofTEXT | choice list
> > 4 | 4m | byte length of index label list
> > 4m | LISTofTEXT | index label list
> > 4n | TEXT | title

> > The server sends IM_LOOKUP_CHOICE_DRAW to let the client update choices in the lookup region. The IM_LOOKUP_CHOICE_DRAW is always sent after the server sent IM_LOOKUP_CHOICE_START and before will send the IM_LOOKUP_CHOICE_DONE to the client.

> IM_LOOKUP_CHOICE_DRAW_REPLY(Client->Server)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id

> > The client is responsible for sending IM_LOOKUP_CHOICE_DRAW_REPLY back to the server after receiving IM_LOOKUP_CHOICE_DRAW request. The server will wait until IM_LOOKUP_CHOICE_DRAW_REPLY is sent since IM_LOOKUP_CHOICE_DRAW is a synchronous request.

> IM_LOOKUP_CHOICE_PROCESS(Server->Client)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id
> > 2 | CARD16 #0 #1 | type INDEX PAGE

> > If type is #0, the arguments continue as follows:

> > 2 | INT16 | index of selected choice

> > If type is #1, the arguments continue as follows:

> > 2 | CARD16 #1 #2 #3 #4 | PAGE NEXT_PAGE PREV_PAGE FIRST_PAGE LAST_PAGE

> > The server sends IM_LOOKUP_CHOICE_PROCESS to let the client change pages backward and forward or let the client select a candidate. The IM_LOOKUP_CHOICE_PROCESS is always sent after the server sent IM_LOOKUP_CHOICE_START and before will send the IM_LOOKUP_CHOICE_DONE to the client.

> IM_LOOKUP_CHOICE_PROCESS_REPLY(Client->Server)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id

> > The client is responsible for sending IM_LOOKUP_CHOICE_PROCESS_REPLY back to the server after receiving IM_LOOKUP_CHOICE_PROCESS request. The server will wait until IM_LOOKUP_CHOICE_PROCESS_REPLY is sent since IM_LOOKUP_CHOICE_PROCESS is a synchronous request.

> If the server has chosen a candidate from the lookup choices, the server must send IM_COMMIT_STRING to the client, and then send IM_LOOKUP_CHOICE_DONE as defined below.

> IM_LOOKUP_CHOICE_DONE(Server->Client)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id

> > The server sends IM_LOOKUP_CHOICE_DONE request to notify the client to do the cleanup for the region of lookup choice operation.

> IM_LOOKUP_CHOICE_DONE_REPLY(Client->Server)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id

> > The client is responsible for sending IM_LOOKUP_CHOICE_DONE_REPLY back to the server after receiving IM_LOOKUP_CHOICE_DONE request. The server will wait until IM_LOOKUP_CHOICE_DONE_REPLY is sent since IM_LOOKUP_CHOICE_DONE is a synchronous request.

> IM_AUX_START(Server->Client)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id
> > 4 | CARD32 | auxiliary window class index
> > 4n | STRING | input method name

> IM_AUX_START_REPLY(Client->Server)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id
> > 4 | CARD32 | auxiliary window class index
> > 4n | STRING | input method name

> > The client is responsible for sending IM_AUX_START_REPLY back to the server after receiving IM_AUX_START request. The server will wait until IM_AUX_START_REPLY is sent since IM_AUX_START is a synchronous request.

> IM_AUX_DRAW(Server->Client)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id
> > 4 | CARD32 | auxiliary window class index
> > 4l | STRING | input method name
> > 4 | 4m | byte length of integer value list
> > 4m | LISTofCARD32 | integer value list
> > 4 | 4n | byte length of string value list
> > 4n | LISTofSTRING | string value list

> IM_AUX_DRAW_REPLY(Client->Server)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id
> > 4 | CARD32 | auxiliary window class index
> > 4n | STRING | input method name

> > The client is responsible for sending IM_AUX_DRAW_REPLY back to the server after receiving IM_AUX_DRAW request. The server will wait until IM_AUX_DRAW_REPLY is sent since IM_AUX_DRAW is a synchronous request.

> IM_AUX_DONE(Server->Client)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id
> > 4 | CARD32 | auxiliary window class index
> > 4n | STRING | input method name

> IM_AUX_DONE_REPLY(Client->Server)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id
> > 4 | CARD32 | auxiliary window class index
> > 4n | STRING | input method name

> > The client is responsible for sending IM_AUX_DONE_REPLY back to the server after receiving IM_AUX_DONE request. The server will wait until IM_AUX_DONE_REPLY is sent since IM_AUX_DONE is a synchronous request.

> IM_AUX_SETVALUES(Client->Server)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id
> > 4 | CARD32 | auxiliary window class index
> > 4l | STRING | input method name
> > 4 | 4m | byte length of integer value list
> > 4m | LISTofCARD32 | integer value list
> > 4 | 4n | byte length of string value list
> > 4n | LISTofSTRING | string value list

> IM_AUX_SETVALUES_REPLY(Server->Client)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id
> > 4 | CARD32 | auxiliary window class index
> > 4n | STRING | input method name

> > The server is responsible for sending IM_AUX_SETVALUES_REPLY back to the client after receiving IM_AUX_SETVALUES request. The client will wait until IM_AUX_SETVALUES_REPLY is sent since IM_AUX_SETVALUES is a synchronous request.

> IM_AUX_GETVALUES(Client->Server)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id
> > 4 | CARD32 | auxiliary window class index
> > 4l | STRING | input method name
> > 4 | 4m | byte length of integer value list
> > 4m | LISTofCARD32 | integer value list
> > 4 | 4n | byte length of string value list
> > 4n | LISTofSTRING | string value list

> IM_AUX_GETVALUES_REPLY(Server->Client)

> > 2 | CARD16 | input method id
> > 2 | CARD16 | input context id
> > 4 | CARD32 | auxiliary window class index
> > 4l | STRING | input method name
> > 4 | 4m | byte length of integer value list
> > 4m | LISTofCARD32 | integer value list
> > 4 | 4n | byte length of string value list
> > 4n | LISTofSTRING | string value list

> > The server is responsible for sending IM_AUX_GETVALUES_REPLY back to the client after receiving IM_AUX_GETVALUES request. The client will wait until IM_AUX_GETVALUES_REPLY is sent since IM_AUX_GETVALUES is a synchronous request.

> Return to Contents

> # Appendix A. Basic Protocol Numbers

> | Protocol |  | Number
> | IM_CONNECT |  | #001
> | IM_CONNECT_REPLY |  | #002
> | IM_DISCONNECT |  | #003
> | IM_DISCONNECT_REPLY |  | #004
> | IM_REGISTER_TRIGGER_KEYS |  | #005
> | IM_TRIGGER_NOTIFY |  | #006
> | IM_TRIGGER_NOTIFY_REPLY |  | #007
> | IM_SETIMVALUES |  | #008
> | IM_SETIMVALUES_REPLY |  | #009
> | IM_GETIMVALUES |  | #010
> | IM_GETIMVALUES_REPLY |  | #011
> | IM_FORWARD_EVENT |  | #012
> | IM_FORWARD_EVENT_REPLY |  | #013
> | IM_COMMIT_STRING |  | #014
> | IM_FORWARD_EVENT_WITH_OPERATIONS |  | #015
> | IM_FORWARD_EVENT_WITH_OPERATIONS_REPLY |  | #016
> | IM_CREATEIC |  | #020
> | IM_CREATEIC_REPLY |  | #021
> | IM_DESTROYIC |  | #022
> | IM_DESTROYIC_REPLY |  | #023
> | IM_SETICVALUES |  | #024
> | IM_SETICVALUES_REPLY |  | #025
> | IM_GETICVALUES |  | #026
> | IM_GETICVALUES_REPLY |  | #027
> | IM_SETICFOCUS |  | #028
> | IM_SETICFOCUS_REPLY |  | #029
> | IM_UNSETICFOCUS |  | #030
> | IM_UNSETICFOCUS_REPLY |  | #031
> | IM_RESETIC |  | #032
> | IM_RESETIC_REPLY |  | #033
> | IM_PREEDIT_START |  | #040
> | IM_PREEDIT_START_REPLY |  | #041
> | IM_PREEDIT_DRAW |  | #042
> | IM_PREEDIT_DRAW_REPLY |  | #043
> | IM_PREEDIT_DONE |  | #046
> | IM_PREEDIT_DONE_REPLY |  | #047
> | IM_STATUS_START |  | #050
> | IM_STATUS_START_REPLY |  | #051
> | IM_STATUS_DRAW |  | #052
> | IM_STATUS_DRAW_REPLY |  | #053
> | IM_STATUS_DONE |  | #054
> | IM_STATUS_DONE_REPLY |  | #055
> | IM_LOOKUP_CHOICE_START |  | #070
> | IM_LOOKUP_CHOICE_START_REPLY |  | #071
> | IM_LOOKUP_CHOICE_DRAW |  | #072
> | IM_LOOKUP_CHOICE_DRAW_REPLY |  | #073
> | IM_LOOKUP_CHOICE_DONE |  | #074
> | IM_LOOKUP_CHOICE_DONE_REPLY |  | #075
> | IM_LOOKUP_CHOICE_PROCESS |  | #076
> | IM_LOOKUP_CHOICE_PROCESS_REPLY |  | #077
> | IM_AUX_START |  | #090
> | IM_AUX_START_REPLY |  | #091
> | IM_AUX_DRAW |  | #092
> | IM_AUX_DRAW_REPLY |  | #093
> | IM_AUX_DONE |  | #094
> | IM_AUX_DONE_REPLY |  | #095
> | IM_AUX_SETVALUES |  | #096
> | IM_AUX_SETVALUES_REPLY |  | #097
> | IM_AUX_GETVALUES |  | #098
> | IM_AUX_GETVALUES_REPLY |  | #099

> Return to Contents

> # Appendix B. Values for Character Subsets

> Character Subset: | Value: | Synopsis:

> BASIC_LATIN | #1 | Constant for the Unicode character block of the same name
> LATIN_1_SUPPLEMENT | #2 | Constant for the Unicode character block of the same name
> LATIN_EXTENDED_A | #3 | Constant for the Unicode character block of the same name
> LATIN_EXTENDED_B | #4 | Constant for the Unicode character block of the same name
> IPA_EXTENTIONS | #5 | Constant for the Unicode character block of the same name
> SPACING_MODIFIER_LETTERS | #6 | Constant for the Unicode character block of the same name
> COMBINING_DIACRITICAL_MARKS | #7 | Constant for the Unicode character block of the same name
> GREEK | #8 | Constant for the Unicode character block of the same name
> CYRILLIC | #9 | Constant for the Unicode character block of the same name
> ARMENIAN | #10 | Constant for the Unicode character block of the same name
> HEBREW | #11 | Constant for the Unicode character block of the same name
> ARABIC | #12 | Constant for the Unicode character block of the same name
> DEVANAGARI | #13 | Constant for the Unicode character block of the same name
> BENGALI | #14 | Constant for the Unicode character block of the same name
> GURMUKHI | #15 | Constant for the Unicode character block of the same name
> GUJARATI | #16 | Constant for the Unicode character block of the same name
> ORIYA | #17 | Constant for the Unicode character block of the same name
> TAMIL | #18 | Constant for the Unicode character block of the same name
> TELUGU | #19 | Constant for the Unicode character block of the same name
> KANNADA | #20 | Constant for the Unicode character block of the same name
> MALAYALAM | #21 | Constant for the Unicode character block of the same name
> THAI | #22 | Constant for the Unicode character block of the same name
> LAO | #23 | Constant for the Unicode character block of the same name
> TIBETAN | #24 | Constant for the Unicode character block of the same name
> GEORGIAN | #25 | Constant for the Unicode character block of the same name
> HANGUL_JAMO | #26 | Constant for the Unicode character block of the same name
> LATIN_EXTENDED_ADDITIONAL | #27 | Constant for the Unicode character block of the same name
> GREEK_EXTENDED | #28 | Constant for the Unicode character block of the same name
> GENERAL_PUNCTUATION | #29 | Constant for the Unicode character block of the same name
> SUPERSCRIPTS_AND_SUBSCRIPTS | #30 | Constant for the Unicode character block of the same name
> CURRENCY_SYMBOLS | #31 | Constant for the Unicode character block of the same name
> COMBINING_MARKS_FOR_SYMBOLS | #32 | Constant for the Unicode character block of the same name
> LETTERLIKE_SYMBOLS | #33 | Constant for the Unicode character block of the same name
> NUMBER_FORMS | #34 | Constant for the Unicode character block of the same name
> ARROWS | #35 | Constant for the Unicode character block of the same name
> MATHEMATICAL_OPERATORS | #36 | Constant for the Unicode character block of the same name
> MISCELLANEOUS_TECHNICAL | #37 | Constant for the Unicode character block of the same name
> CONTROL_PICTURES | #38 | Constant for the Unicode character block of the same name
> OPTICAL_CHARACTER_RECOGNITION | #39 | Constant for the Unicode character block of the same name
> ENCLOSED_ALPHANUMERICS | #40 | Constant for the Unicode character block of the same name
> BOX_DRAWING | #41 | Constant for the Unicode character block of the same name
> BLOCK_ELEMENTS | #42 | Constant for the Unicode character block of the same name
> GEOMETRIC_SHAPES | #43 | Constant for the Unicode character block of the same name
> MISCELLANEOUS_SYMBOLS | #44 | Constant for the Unicode character block of the same name
> DINGBATS | #45 | Constant for the Unicode character block of the same name
> CJK_SYMBOLS_AND_PUNCTUATION | #46 | Constant for the Unicode character block of the same name
> HIRAGANA | #47 | Constant for the Unicode character block of the same name
> KATAKANA | #48 | Constant for the Unicode character block of the same name
> BOPOMOFO | #49 | Constant for the Unicode character block of the same name
> HANGUL_COMPATIBILITY_JAMO | #50 | Constant for the Unicode character block of the same name
> KANBUN | #51 | Constant for the Unicode character block of the same name
> ENCLOSED_CJK_LETTERS_AND_MONTHS | #52 | Constant for the Unicode character block of the same name
> CJK_COMPATIBILITY | #53 | Constant for the Unicode character block of the same name
> CJK_UNIFIED_IDEOGRAPHS | #54 | Constant for the Unicode character block of the same name
> HANGUL_SYLLABLES | #55 | Constant for the Unicode character block of the same name
> SURROGATES_AREA | #56 | Constant for the Unicode character block of the same name
> PRIVATE_USE_AREA | #57 | Constant for the Unicode character block of the same name
> CJK_COMPATIBILITY_IDEOGRAPHS | #58 | Constant for the Unicode character block of the same name
> ALPHABETIC_PRESENTATION_FORMS | #59 | Constant for the Unicode character block of the same name
> ARABIC_PRESENTATION_FORMS_A | #60 | Constant for the Unicode character block of the same name
> COMBINING_HALF_MARKS | #61 | Constant for the Unicode character block of the same name
> CJK_COMPATIBILITY_FORMS | #62 | Constant for the Unicode character block of the same name
> SMALL_FORM_VARIANTS | #63 | Constant for the Unicode character block of the same name
> ARABIC_PRESENTATION_FORMS_B | #64 | Constant for the Unicode character block of the same name
> HALFWIDTH_AND_FULLWIDTH_FORMS | #65 | Constant for the Unicode character block of the same name
> SPECIALS | #66 | Constant for the Unicode character block of the same name
> LATIN | #67 | Constant for all Latin characters, including the characters in the BASIC_LATIN, LATIN_1_SUPPLEMENT, LATIN_EXTENDED_A, LATIN_EXTENDED_B character blocks
> LATIN_DIGITS | #68 | Constant for the digits included in the BASIC_LATIN character block
> TRADITIONAL_HANZI | #69 | Constant for all Han characters used in writing Traditional Chinese, including a subset of the CJK unified ideographs as well as Traditional Chinese Han characters that may be defined as surrogate characters
> SIMPLIFIED_HANZI | #70 | Constant for all Han characters used in writing Simplified Chinese, including a subset of the CJK unified ideographs as well as Simplified Chinese Han characters that may be defined as surrogate characters
> KANJI | #71 | Constant for all Han characters used in writing Japanese, including a subset of the CJK unified ideographs as well as Japanese Han characters that may be defined as surrogate characters
> HANJA | #72 | Constant for all Han characters used in writing Korean, including a subset of the CJK unified ideographs as well as Korean Han characters that may be defined as surrogate characters
> HALFWIDTH_KATAKANA | #73 | Constant for the half-width katakana subset of the Unicode half-width and full-width forms character block

> Return to Contents

> # Appendix C. CCDEF

> T.B.D

> Return to Contents

> Sun Microsystems, Inc. Confidential