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 destination is part of a routing message. It signals the number of hops to reach a user via the link on which the routing message is sent. 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. 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 "closed" flag denotes whether it is a closed channel. Each known subscriber is listed in a "member" child element. The "join" message signal the subscription of a user to a non-closed channel. The "leave" message signal the unsubscription of a user from a non-closed channel. A node may send a "getpeers" message to request a list of other node addresses in order to extend its own list of potential connection peers. A node can make its direct peer nodes aware of a list of peer addresses through a "peers" message. A user may send a "getcertificate" message to request a certificate for a given user ID. A user 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 user may request a channel key for a given closed channel through a "getkey" message. A user can send a channel key encapsulated in a "key" message. The actual data part of the key has to be encrypted with the according receiver's public key. It is the duty of the sender of a "key" message to ensure that the public key really belongs the the receiver and that the receiver is really a member of the channel. Routing messages are exchanged on links to form a converging knowledge on the network topology on every node. 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. The "obscure" is created by a user who intends to emit a "message" message but remain anonymous as the sender of the message. The "text" payload is in turn an "obscure" message or a "message" message after decryption.