ter the appropriate standards organization's committees formal- ize standards, those standards might lack sufficient definition to ensure com- patibility, and vendors might interpret guidelines differently. As a result, two products can comply fully with the same set of standards but fail to interop- erate (Figure 8.3) [10]. Compliance testing is able to show that a particular implementation com- plies with all of the protocol requirements specified in the associated base standard. However, it is difficult for such testing to be able to prove that the implementation will interoperate with similar implementations in other prod- ucts. On the other hand, interoperability testing can clearly demonstrate that two implementations will cooperate to provide the specified end-to-end func- tions but cannot easily prove that either of them complies with the detailed requirements of the protocol specification. The compliance testing tends to verify basic protocol features, while inter- operability testing is designed to replicate real-life scenarios. Thus, interoperability testing is not better than compliance testing or vice versa. The approaches are complementary and not mutually exclusive. Com- plex technologies, the cost of getting things wrong, and a renewed interest in branding and certification programs encourage a combined approach. Compliance and interoperability are both important and useful approaches to the testing of standardized protocol implementations although it is unlikely that one will ever fully replace the other. 8.2 Protocol Testing Methods Protocol testing is carried out with the help of a test sequence generated from a protocol specification. Communication protocol specifications can be represented in the form of a finite state machine (FSM). Then the common approach in protocol testing is to cover the whole FSM and verify each state and transition. This method is suitable for protocols that have a short FSM. In other cases, knowledge of the protocol's weaknesses and vulnerable areas C 2009 by Taylor 