s makes it independent of the underlying transport protocol and suited for situations where an extensible lean transport protocol is required. One of the focuses of the XML protocol work group (WG) was to ensure the transport protocol independence. XML-Based Protocols XML is well suited for distributed environments where there are inbuilt mechanisms for usage scenarios on involving multiple data readers, multiple data writers, and other control entities. XMLP provides flexible linkages between managed object and management application. This is again a projection of the distributed nature of XMLP. XML protocol provides a strong security paradigm with capabilities for auto- matic and centralized validation. The intent of defining requirements on XML protocol (XMLP) was to create a foun- dation protocol whose definition will remain simple and stable over time. The design based on this foundation that explicitly used modularity and layering will assure longevity and subsequent extension of the design keeping the foundation intact. XMLP inherently supports the following: Message encryption: This means that the message header and the associated payload can be encrypted when using XML protocol. Multiple intermediaries: The protocol support third-party intermediary com- munication 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 info