Messages exchanged between clients and servers are wrapped in envelops. Servers may or may not be able to read these envelops, but in most cases they simply forward them without consideration of their contents. Envelops are the key to message encapsulation and protection and provide an extensible framework supporting an infinite variety of encoding and encryption techniques. The ODSIMS committee hopes that third party developers will invent a variety of useful envelop formats to facilitate secure instant messaging.
(A discussion of message envelops, or at least a portion of it, probably belongs in "ODSIMS Client/Server Protocol." However, there are some aspects of message envelops which are distinctly applicable to our discussion of the abstract client/client protocol. Rather than splitting the envelop specification into two parts, we have decided to completely address all issues relating to envelops in this section and refer readers of the other protocol specifications to this section when necessary.)
All envelops are transmitted from server to server as sequences of bytes, but clients and servers exchange them as sequences of ASCII characters. Envelops are represented in quoted ASCII, padded hexadecimal, or a hybrid of these two forms. Hybrids are formed simply by concantenating substrings of the first two types. For example, the following envelop representations are equivalent:
Quoted ASCII segments begin with either a single quote or a double quote, but the same style quote must also be used to terminate them. All characters in quoted ASCII segments are taken exactly as they appear; there are no "escape" mechanisms for special characters. This means, of course, that no quoted ASCII segment can contain the quote that began it. (However, you can strategically select the opening quote based on your desire to embed the other kind of quote in the segment.) Special characters whose ASCII values are less than 32 or greater than 126 are not allowed in a quoted ASCII segment. (These characters must be represented using their hexadecimal values instead.) Note that when an envelop contains Unicode or encrypted content, it is very inefficient, if not impossible, to represent an envelop in quoted ASCII segments. Quoted ASCII segments are intended primarily for debugging (for power users who telnet to ODSIMS servers) and are not encouraged for normal use.
Hexadecimal segments consist of pairs of hexadecimal characters, which include only '0'-'9', 'a'-'f', and 'A'-'F' (case does not matter). Because padded pairs of hexadecimal characters are used to represent each byte, all hexadecimal strings are even in length.
Hyphens may be inserted in an envelop string to facilitate human-readability and debugging, but must be ignored by envelop parsers, unless they are included in a quoted ASCII segment, in which case they are treated as normal ASCII characters. For example, the following envelop representations are equivalent:
An envelop may contain serveral fields. The number,.content, and format of these fields depend on the envelop's internal encoding scheme. Third-party inventors of proprietary envelop encoding schemes are free to define the envelop's contents however they wish.
The first field of every envelop, however, is the same for all envelops regardless of their encoding type, because the purpose of this field is to identify the internal encoding scheme used for the rest of the envelop. This field, called the format field, is a 0-terminated ASCII string that unambiguously identifies the name of the encoding scheme used for the rest of the envelop.
After the encoding scheme, subsequent fields in the message provide additional information, if necessary, about the envelop's internal encoding. The presense of these secondary fields depends entirely on the encoding scheme selected by the first field, and is defined by the inventors of that particular envelop format. However an envelop is encoded, however, somewhere in that envelop there must be a "data field." Generic interfaces to plugins supporting various encoding schemes should provide methods for extracting an envelop's data field.
At present, ODSIMS 0.1 requires support for only one envelop format, PLAIN. This simple, unencrypted envelop format is the "lowest common denominator" for all clients and servers and ensures some degree of interoperability. Clients and servers may also support other formats, but this is strictly optional, and they may have to used PLAIN envelops initially while negotiating a different envelop format.
In PLAIN envelops, the second field is also a 0-terminated ASCII string. This field, called the subtype field, identifies the encoding subtype and must contain one of the three strings described below:
The third and last field of a PLAIN-encoded envelop, which is not 0-terminated, is the actual data field, encoded in the format named by the previous field. This field extends to the end of the encoded message and contains whatever data is appropriate for the client's objective.
Examples:
The following strings represent PLAIN-encoded envelops where the data field is the text "ABC":
- "PLAIN"-00-"ASCII"-00-"ABC"
- "PLAIN"-00-"UNICODE"-00-00"A"-00"B"-00"C"
- "PLAIN"-00-"ASCII"-00-41-42-43
- "PLAIN"-00-"UNICODE"-00-0041-0042-0043
- 504c41494e-00-4153434949-00-414243
- 504c41494e-00-554e49434f4445-00-004100420043
- 504C41494E00415343494900414243
- 504C41494E00554E49434F444500004100420043