This XML Schema defines the p2p-chat protocol messages. Elements of this type represent a globally unique user identification. It has to contain a user name part followed by an @ character and a domain part. It is highly recommended to use the users valid Internet email address. Note that it has to be treated case-insensitive. Elements of this type are used to form a unique identification for messages per user. The pair of a UserID and a MessageID builds a globally unique message identification. How the MessageID is actually built is an implementation issue. It might be a persistent counter incremented with each message generation, or it might be based on a timestamp, for example. An integer time-to-live value. Note that the value range is restricted. The name of a channel. Note that it has to be treated case-insensitive. A fully qualified domain name of a listening endpoint. Note that it has to be treated case-insensitive. An IPv4 address of a listening endpoint. A TCP port number of a listening endpoint. A peer address consists of a hostname (or if a hostname is not available, an IPv4 address) and a TCP port number. This pair specifies a potential listening peer endpoint to which other peers might try to connect. A certificate consists of the user id to which the certificate belongs and the certificate itself encoded in Base64. A label to identify a symmetric cipher algorithm. So far, just one (reasonable) cipher is defined, but others may be added in future revision of the protocol. No encryption. 64(56) bit DES in Cipher Block Chaining mode with PKCS #5 padding. A label to identify a message digest algorithm. So far, just one algorithm is defined, but others may be added in future revision of the protocol. MD5 digest (encrypted with the senders private key). A Base64 encoded signature. It is calculated for the concatenated UTF-8 encoded values (without attributes) of all child elements of the chat-message element in depth-first order. A symmetric session key consists of the channel name to which the key belongs and an identification of the used cipher algorithm, and a number of key sub-elements each containing a channel member and the key data for that user encrypted with his/her public key and encoded in Base64. This is the root element. It represents a p2p-chat protocol message. The "hello" message is the first message sent by each peer of a newly established connection. The peer may send an informal greeting text. The "quit" message is sent by a peer as the last message before actively shutting down the connection. The peer SHOULD give an informal reason why the connection is shut down. The "channel" message announces an active channel. The existance of the members element denotes a closed channel. A peer may send a "getpeers" message to request a list of other peer addresses in order to extend its own list of potential connection peers. A node can make other nodes aware of a list of peer addresses through a "peers" message. A peer may send a "getcertificate" message to request a certificate for a given user ID. A peer can send a certificate encapsulated in a "certificate" message. It's not only the owner of the certificate who can send such a message. A node may request a channel key for a given closed channel through a "getkey" message. A node can send a channel key encapsulated in a "key" message. The actual data parts of the key have to be encrypted with the according receivers' public keys. Its the duty of the sender of a "key" message to ensure that the public keys really belong the the receivers and that the receivers are really members of the channel. The "message" message carries the actual content of the chat message in its text element. If the iv attribute is present it is a message of a closed channel and uses the initialization vector given by the iv attribute.