n where the message can be collected, parsed, and worked with. There would be transport and processing intermediaries. Non-XML data handling: This means the protocol can handle sending of non-XML data, which may be a required functionality when working with certain legacy systems. Asynchronous messaging and caching with expiration rules that will improve efficiency due to latency or bandwidth. Before we get into the details of message encapsulation, let us quickly check some of the usage scenarios for use of XML protocol. Fire-and-forget to single receiver and multiple receivers: The sender wants to send an acknowledgment message to a single receiver or broadcast it to multiple receivers. Request-response: This involves one entity requesting information and the receiver processing the request and sending a response. Request with acknowledgment: Here the sender expects an acknowledgment from the receiver on the status of data delivery. Request with encrypted: Here an encryption methodology is agreed between sender and receiver and this is followed in the message exchange where the payload, and in some cases the header also, will be encrypted. Single and multiple intermediaries: Here an intermediary is present between the sender and ultimately the receiver. Asynchronous messaging: Here the sender does not expect an immediate response from the receiver. The sender will tag the request with an identifier to correlate with the response when it arrives. Fundamentals of EMS, NMS and OSS/BSS 18.3 XML Protocol Message Envelope The XMLP message envelope is the data encapsulation component of XMLP protocol. The message envelope is a key component of the XMLP protocol that allows it to be extremely versatile and adaptable for use in carrying management information. The envelope is a syntactical construct that contains: XMLP header block: There is only one header block for multiple body blocks. The header block consists of: Routing information for the message envelope. - Data describing the content of the body blocks. - Authe