This is a draft document proposal. Please do not consider any part of this as an actual specification for an extension to the IM Service while this comment exists. If you are interested in this document and would like to discuss it, please join the "meanwhile-devel" list on the Contact page
The IM Service provides for an IM Client ID to be specified by a client when establishing a conversation Channel. This identifier can indicate an implicit feature-set beyond the normal text/typing features of the Lotus Sametime Connect client. For example, use of the NotesBuddy identifier indicates support of HTML, MIME, multi-segment, and subject messages in addition to the text and typing messages of the standard client.
When creating a channel, the initiating client will select its most favorable identifier and specify it in the Channel Create Message. The recipient client can either accept or reject this channel based on that identifier. If the channel is rejected, the initiating client may attempt to create another channel with a different identifier, and continue doing this until the channel is accepted. Normally the very last identifier offered would be that of the standard client, which should be acceptable to all clients.
A problem with this approach is that it's all-or-nothing support for each set of features; eg. handling only HTML messages locally will not prevent the other client from sending MIME messages. Additionally, if a later revision of a client wished to add any features at all, the updated feature-set would require a whole new identifier. That is to say, if the feature set (A,B,C) was tied to an ID of 0x10, a feature set of (A,B,C,D) would require an all new ID, as would a feature of set of (B,C,D). Negotiation of supported identifiers would have to cascade through a large series of values before both sides of a conversation could agree on a set of features, even between different versions of the same client!
note: it would hypothetically be possible to specify up to 64 individual features using the bitset of the data type and data subtype fields of the IM Data Message, however the meaning of those 64 bits would have to be widely agreed-upon before-hand and recorded openly to prevent collisions.
- both clients can now safely use the features (A,C,D)
This information could be embedded in the "additional" Opaque of the Channel Create Message and the Channel Accept Message. However, the official Lotus libraries do not expose the actual "additional" block, and in order for this solution to become accepted it needs to be feasible for use with the official toolkits. A more functionally acceptable solution would be a type of IM Data Message dedicated to offering/accepting feature lists. Unfortunately, this approach would still require the creation of a new identifier value, just to indicate the "feature" of supporting explicit features.
note: I'd probably use an im client type of 0xffff
note: I'd use a data message type of 0xffff to mean 'feature negotiation', with subtypes 0x00 for 'offered features' and 0x01 for 'accepted features'. It would be the channel creator's job to offer features first, and the recipient would be required to accept features. No other messages could be sent on the channel before feature negotiation was complete!
Features would need to be identified uniquely. As such, a short heirarchial name, such as "st.html" or "st.autoreply" would be ideal.
The offer of features could be as a list of (key:name) pairs, prefixed with a count of features in the list. For example:
|uint32||0x0000ffff IM Data Message type (feature negotiation)|
|uint32||0x00000001 IM Data Message subtype (features offered)|
|Opaque||uint16||0x0002 (two features follow in list)|
|uint16||0x0001 feature number 1|
|String||"st.mime" name of feature number 1|
|uint16||0x0002 feature number 2|
|String||"st.html" name of feature number 2|
indicating the channel creator supports mime and html messages.
note: that when written to the actual opaque, each string would be prefixed with its own 16bit length header, in addition to the 16bit key value indicated above.
The accepted features could then simply be a list of keys, prefixed with a count of features in the list. Hence:
|uint32||0x0000ffff IM Data Message type (feature negotiation)|
|uint32||0x00000002 IM Data Message subtype (features accepted)|
|Opaque||uint16||0x0001 (one feature in the list)|
|uint16||0x0002 (accepted feature with key 0x02)|
indicating that the channel recipient can support html message. Both sides of the conversation can now safely use text, typing, and NotesBuddy-style HTML as their features.
In order to prevent collisions in IM Data Message sub-types, it is recommended to use the negotiation key as the subtype when sending data for a feature. For instance, in the examples above, when sending a message using the "st.html" feature, the appropriate subtype would be 0x02. These mappings could differ between channels, as the association is arbitrary.
note: the example used a proposed data message type 0xfffe to mean "feature message". The subtype of the feature message would be the key value of the feature associated with the data in the message itself.
Using the examples from before:
|uint32||0x0000fffe IM Data Message type (extended feature)|
|uint32||0x00000002 IM Data Message subtype|
|Opaque||String||"Some HTML-formatted text goes here."|
would indicate that a message for feature 0x02 (in this case, st.html) was being sent. The subtype value is the key used in the offer and accept messages previously.
Some initially defined features would help to get clients rolling, as such I'd suggest the following base feature set. It would not be necessary for a client to support all, or even any, of these features and still use is service extension method. These are simply offered as a good set of feature definitions to agree upon.
|st.html||an HTML-formatted message|
|st.mime||a multi-part MIME message, HTML with inline images|
|st.subject||sets the conversation topic/subject|
|st.autoreply||plaintext automated reply|
|st.autoreply.html||automated reply with HTML-formatting|
|st.pounce||a plaintext automated pounce|
|st.pounce.html||automated pounce with HTML-formatting|
|st.control.segment||boundary for multi-segment messages|
note: it may be worthwhile to specify multi-segment message control as a required message type, as it's a feature which should be utilized automatically by the API. Automatic breakup of large channel messages into smaller segments can save server resources.