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. Elements of this type are used to form a unique identification for channels. The pair of a channel name and a channelID builds a globally unique channel identification. How the channelID is actually built is an implementation issue. The channelID MUST differ from other known IDs. Is consists of two parts sperarated by an "@". The first part SHOULD be generated randomly on the basis of UUIDs. The second part is the name of the local host. 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. The name "Anonymous" is reserved for the anonymous channel and MUST NOT be used for other channels. 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 message attachment. The applicationtype states the MIME Type of the attached file. The application data MUST always be Base64 encoded. 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 content of all elements MUST be de-/encrypted individually. 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 element 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. A HELLO message MAY contain more than one sender if a node serves more than one user. The "ack" message is sent by a peer that receives a multicasted message from another peer in order to inform the sender that this message reached the next hop. It always includes the ID of the received message. The "Nack" message is sent by a peer that receives a multicasted message from another peer and is not able to forward it towards its destination. The "Nack" message is always sent to the original source of that message and informs the sender that its message has not received its destination. The original message has to be attached to the "Nack". 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 "getcertificate" message to request a certificate for a given user ID. A node 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 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 to 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.