From time to time, users may wish to obtain information about their chatting partners without bothering them. Users who wish to make certain types of informational items available for this purpose can publish them through their clients and servers as queryable properties.
The following client/server messages, which are discussed in "Message Definitions," are used for exchanging properties:
When a user wishes to query a property of another user, he does so by sending a query message to the other user's client. When the client being queried receives this message, it extracts the name of the property being queried and decides whether or not to reveal that property's value. The queried client has several options:
Each property is given a name that is expressable as an ASCII or Unicode string. However, all characters in a property's name must be 'A'-'Z', 'a'-'z', '_' (underscore), '0'-'9', or '.' (dot). (There is no need to support property names containing characters from other languages because there should only be one standard name for any queryable concept, regardless of the client's preferred language, and that name ought to be given in American English, the language most likely to be used by ODSIMS implementors and users.) Properties, however, can contain any type of data, including ASCII text, Unicode text, kanji, and even binary image data. To minimize confusion, all property names are case-insensitive.
ODSIMS defines a set of canonical names for certain queryable properties. Clients are not required to support them, but they should at least reserve these property names for their intended purposes. The standard names are listed below::
| name | value |
|---|---|
ONLINE |
whether or not the client is on-line; byte value; 1 for on-line, 0 for off-line |
IDLE_TIME |
how long the client's machine has been idle; integer string; number of seconds since last interaction |
STATUS |
user's status message; string value; "out to lunch," "back in five minutes," etc. |
EMAIL |
user's preferred email address; string value |
IP_ADDR |
client's current IP address; string value; dotted-decimal or host name |
More properties will be defined and canonized in future revisions of this protocol as the need arises. Of course, publishing some properties to untrusted parties can compromise security or privacy, so clients must give their users the ability to select which properties will be available to which users.
To servers that support it, clients can upload properties to their servers so that the servers can answer property queries even when the clients being queried are off-line. Servers supporting this feature will still forward queries to their clients when their clients are on-line, but will answer them automatically when the clients are unavailable.
Clients can send out property announcements to other clients even when they haven't issued a query for that property. The manner in which this is done is no different than the manner in which a property query is answered. In fact, a query is actually nothing more than an invitation to a client to make a property announcement.