By: Jim the Cactus <jtc@nqig.net>
Sections
- Problem
- Proposed Solution
- Terms
- Protocol Definition
- State Flow
- Control Messages
- Contibuters
- Revision History
Problem
At present, instant message communications occur with little or no flow control. This can lead to misunderstandings and awkward moments that could be avoided by a commonly understood flow control system.
Proposed Solution
To address these issues, a deterministic flow control and signaling method could be used to better deal with terminated conversations, as well as allow for peer queries for status, etc.
Terms
- Peer
- Instant messaging is used for communications between two individuals, called peers.
- Originator
- The peer that sent the first message.
- Respondent
- The peer that received the first message.
- WILL
- This must be implemented.
- WILL NOT
- This must not be implemented and care should be taken that this never occurs.
- SHOULD
- Although this can be ignored, it is highly recommended and should only be removed when making an ultra-lite implementation of the protocol.
- SHOULD NOT
- Although this might be tolerable, it is best if this doesn't happen.
- MAY
- Anything marked MAY can be implemented at the user's discretion.
Protocol Definition
The protocol defines 4 states: UNCONNECTED, HANDSHAKE, CONNECTED, and CLOSING.
Normal Communication which at present has some weak social definitions for the 4 states, will typically continue unaffected.
State Flow
All communications begin in the UNCONNECTED state. The initial message will move the connection into the HANDSHAKE state and SHOULD contain a greeting. While in the HANDSHAKE state, the originator SHOULD wait for a responding greeting. The respondent WILL reply with an appropriate response greeting or the [BYE] control message. The connection is now in the CONNECTED state. While in the CONNECTED state the peers may send any standard messages, as well control messages. When the [BYE] control message is sent in any state other than the UNCONNECTED and CLOSING state, the connection enters the CLOSING state. In the CLOSING state, only the [BYE] control message may be sent. When a [BYE] is received, the other peer WILL send a [BYE] message and then both peers return to the UNCONNECTED state.
Control Messages
[BYE]
This marks the intent to terminate a connection. The other peer WILL respond with [BYE] and then end the connection.
[PING] or [pi
This is a line verification echo request. The other peer SHOULD respond with a [PONG] (or [po) message.
[ACK] or [a
When a message does not need a formulated response, but needs acknowledgement of receipt, this can be used. This has the social equivalence of a nod. No action should be taken.
[?] or [?
If a message was sent that expected a response, and none was given, or [ACK] was given, this can be used to clarify that a response was expected. This can also be included at the end of any message that was intended to solicit a response.
[+/- PT] or [+/-pt
This can be used at the beginning of any message (other than a [BYE] command) or as a stand alone message to indicate that one is only watching "Part Time". [+ PT] indicates that they have begun part time observation and [- PT] indicated that they are now watching "Full Time". During Part Time operation, peers should expect possible long delays between messages.
[+/- BURST] or [+/-b
This can be used at the beginning of any message (other than a [BYE] command) or as a stand alone message to indicate that the peer expects to be transmitting a burst of messages. When a peer is in burst mode, it should be expected that 3 or more messages may come in a row. This is useful for situations where a large answer may be required, or multiple smaller messages would be better used for communication. (Such as giving driving directions using 1 message per step.
[DONE] or [d
This optional control message can be used at the end of any standard message to indicate that the peer has nothing further to say, and although they are keeping the connection open, they do not, in the immediate future, plan to send any more messages. They may, however, resume the session later, but this can be used to help make better understanding of the long gaps in IM communications found today.
[CONT] or [c
Any message that is will be continued in a following message should have [CONT] at the end of it. While in BURST mode, it is assumed that CONT is at the end of every message until [- BURST] is sent. When [CONT] is present, the peer SHOULD NOT send any responses until a message without [CONT] is recieved, unless it is nessicary to interrupt the sender. If [CONT] is sent by itself in a message, this indicates that the peer is in the process of composing a large message.
[DCONN] or [dc
This indicates that the peer is about to attempt a direct connection through the link.
[FILE] or [f
This indicated that the peer is about to attempt a file transfer.
*
Placed at the beginning of a new message, *, followed by a word or phrase, represents a replacement for an errornious word in a preceding message.
*<word>*
A word, wrapped in asterisks, represents an action done by the speaker.
Contributors
Special thanks to OniAkki for helping me develop and refine this document. And thanks to NightDraco for giving me a good reason to even bother in the first place.
Revision History
Jan 2, 2004 Version 1.0.1 was released.
Jan 1, 2004 Inital Version 1.0.0 was released.