RMT H. Mehta, ed. Internet-Draft R. Walsh Expires: August 16, 2004 Nokia V. Roca INRIA Rhone-Alpes J. Peltotalo S. Peltotalo Tampere University of Technology February 16, 2004 FLUTE Interoperabtility Testing Guidelines draft-mehta-rmt-flute-iop-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 16, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This memo describes a possible testing strategy for interoperability among implementations of the File Delivery over Unidirection Transport (FLUTE) protocol. Mehta, ed., et al. Expires August 16, 2004 [Page 1] Internet-Draft FLUTE Interoperabtility Testing Guidelines February 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Test Environment Setup . . . . . . . . . . . . . . . . . . . . 6 4.1 ALC/LCT Conformance and Minimum Feature Set . . . . . . . . . 6 4.2 Basic FLUTE Testing Architecture . . . . . . . . . . . . . . . 7 4.3 Preconditions for Testing . . . . . . . . . . . . . . . . . . 8 5. Basic FLUTE Tests . . . . . . . . . . . . . . . . . . . . . . 9 5.1 Single Small File, Single FDT Test . . . . . . . . . . . . . . 9 5.2 Single Large File, Single FDT Test . . . . . . . . . . . . . . 9 6. FLUTE Transport Tests . . . . . . . . . . . . . . . . . . . . 10 7. Multiple Files within a Session . . . . . . . . . . . . . . . 12 8. Testing Interoperability for Modified FDTs . . . . . . . . . . 14 9. Recommended Advanced FLUTE Tests . . . . . . . . . . . . . . . 15 9.1 Interoperability Across Simultaneous Multiple Sessions . . . . 15 9.2 Interoperability for Identical Files Across Multiple Sessions or Channels . . . . . . . . . . . . . . . . . . . . . 15 10. FDT Instance Interoperability Tests . . . . . . . . . . . . . 16 11. Interoperability Test Suite . . . . . . . . . . . . . . . . . 17 12. Security Considerations . . . . . . . . . . . . . . . . . . . 18 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . 22 Mehta, ed., et al. Expires August 16, 2004 [Page 2] Internet-Draft FLUTE Interoperabtility Testing Guidelines February 2004 1. Introduction This memo describes a possible testing strategy for FLUTE [1] implementations. The tests are intended to help demonstrate interoperability of multiple implementations, and to illustrate common implementation errors. They are not intended to be an exhaustive set of tests and passing these tests does not necessarily imply conformance to the complete FLUTE specification. Mehta, ed., et al. Expires August 16, 2004 [Page 3] Internet-Draft FLUTE Interoperabtility Testing Guidelines February 2004 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. Mehta, ed., et al. Expires August 16, 2004 [Page 4] Internet-Draft FLUTE Interoperabtility Testing Guidelines February 2004 3. Terminology ALC/LCT session: Logically grouped ALC/LCT channels associated with a single sender sending packets with ALC/LCT headers for one or more channels. FLUTE session: The flow of data between a sender and receivers within a defined context and time over an ALC/LCT session using FLUTE headers. ALC/LCT implementation: The implementation of the ALC protocol used by the FLUTE implementation. FLUTE implementation: The tool implementing the FLUTE and ALC/LCT specifications. Mehta, ed., et al. Expires August 16, 2004 [Page 5] Internet-Draft FLUTE Interoperabtility Testing Guidelines February 2004 4. Test Environment Setup Neither ALC/LCT [3][4] nor FLUTE specify any transport mechanism. Therefore FLUTE sessions (and ALC/LCT sessions) can operate on many different transport mechanisms, like unicast connections, multicast connections, application level multicast connections, broadcast connections, using either UDP/IPv4 or UDP/IPv6. All of these possibilities are valid from an ALC/LCT and FLUTE perspective. Therefore FLUTE operators must first agree on an appropriate transport mechanism, supported by both FLUTE implementations. Many external tools can be used during interoperability testing. Some of these are: o diff: This tool is used to identify the differences between two file instances when both file instances are available locally. o md5sum: This tool is used to check that two file instances are identical. It is useful when the two file instances are not available locally. It is also recommended that the optional field in the FDT be used for the md5 digest of transmitted files. o ping: This tool is used to check the unicast connectivity of the two testing hosts. However, this tool only tests the ICMP connectivity. This is a limitation since ICMP packets may be filtered by firewalls. It is recommended that the users of the FLUTE implementations begin the testing process by running the ping mechanism to test the connection to the other FLUTE implementation. 4.1 ALC/LCT Conformance and Minimum Feature Set FLUTE is based on ALC/LCT. Therefore FLUTE interoperability testing requires that ALC/LCT conformance be tested. However, since this is outside the scope of this document, and since ALC/LCT leaves open several possibilities, we first define a recommended minimum ALC/LCT feature set. It is highly recommended that a FLUTE application supports the following minimum ALC/LCT feature set in order to simplify FLUTE conformance tests. This feature set presents some of the available options and the minimum required features for meaningful interoperability testing. However, a FLUTE application may make other choices while being fully compliant to the FLUTE specification. Feature/Feature set Options Minimum Mehta, ed., et al. Expires August 16, 2004 [Page 6] Internet-Draft FLUTE Interoperabtility Testing Guidelines February 2004 CCI field 32*(C+1) bits 32 bits TSI field 32*S+16*H bits 32 bits TOI field 32*O+16*H bits 32 bits SCT field present if T==1 none ERT field present if R==1 none Congestion Control protocol none, WEBRC none FEC Codec NULL, Open codecs, NULL proprietary codecs FEC Encoding ID 0, 128, 129, 130 0(NULL codec) Using a NULL FEC code [5] avoids testing for FEC codec of the ALC/LCT implementations. Since this is outside the scope of the present document, it is recommended that NULL FEC be used. The FEC encoding ID for this case is 0. Using no congestion control protocol avoids testing for congestion control protocol implementations. Since this is outside the scope of this document, it is recommended that that no congestion control is used. This minimum feature set is only intended to simplify FLUTE interoperability testing. However, ALC/LCT compliance tests should not restrict themselves to this minimum feature set. 4.2 Basic FLUTE Testing Architecture The architecture for testing the basic functioning of the FLUTE implementations is shown in Figure 1. +-----------------+ +-----------------+ | First FLUTE | | Second FLUTE | | Test setup | | Test setup | | +-------------+ | | +-------------+ | | | Sender | |--------->| | Receiver | | | +-------------+ | | +-------------+ | | +-------------+ | | +-------------+ | | | Receiver | |<---------| | Sender | | | +-------------+ | | +-------------+ | +-----------------+ +-----------------+ Figure 1: Basic FLUTE testing architecture The test architecture comprises of two connected FLUTE senders and receivers. The sender and receiver MAY be on the same physical machine or on different physical machines. The receiver may be a unidirectional receiver. It is also possible to have just a receiver implementation at one end to check receiver interoperability only. Mehta, ed., et al. Expires August 16, 2004 [Page 7] Internet-Draft FLUTE Interoperabtility Testing Guidelines February 2004 4.3 Preconditions for Testing The following tests assume that the channel for transmission of FLUTE data and files has been appropriately configured and that connectivity has been established between the sending and receiving implementations. It is recommended testing procedure that the sender uses a value of 0 for the Transport Object Identifier (TOI) for the File Delivery Table (FDT). The use of non-zero values for the TOI in FDT Instances is out of the scope of this document. Further, the tests assume that a mechanism for snooping packets at the receiver is available. However, such a mechanism is beyond the scope of this document and will not be discussed here. Mehta, ed., et al. Expires August 16, 2004 [Page 8] Internet-Draft FLUTE Interoperabtility Testing Guidelines February 2004 5. Basic FLUTE Tests These tests are meant to assess the basic conformance of the FLUTE application in simple operating situations. In these cases, a single file is sent using the FLUTE transport mechanism. In all the following elementary tests, the test architecture outlined in section 4.2 SHOULD be used. The tests MUST be carried out on both the sending and receiving implementations of each FLUTE application. 5.1 Single Small File, Single FDT Test This test is meant to test the FDT mechanism. The FDT object MUST be sufficiently small so that it is contained within a single ALC/LCT packet. The file MUST be sufficiently small so that it is encoded as a single block. As this test is the most elementary test for the FLUTE transport mechanism, no special FDT feature should be used. The sending implementation sends the object using FLUTE to the receiver. Upon receiving the object, the receiving implementation checks that there is no difference between the object sent and the object received. 5.2 Single Large File, Single FDT Test The goal of this test is to check basic FLUTE exchanges with an object that is sufficiently large so that the functioning of the blocking scheme can be checked. It complements the "Single small file, single FDT test" described in section 5.1. This test SHOULD be repeated with several object sizes in order to test the blocking functionality in several situations. The sending implementation sends the object using FLUTE. Upon receiving it, the receiving implementation checks that there is no difference between the object sent and the object received. Mehta, ed., et al. Expires August 16, 2004 [Page 9] Internet-Draft FLUTE Interoperabtility Testing Guidelines February 2004 6. FLUTE Transport Tests The aim of this test is to verify that FLUTE data can be exchanged between the two FLUTE implementations using an ALC session and that the FLUTE and ALC data is correctly transmitted. The test architecture outlined in section 4.2 SHOULD be used. The initial test is for the first FLUTE implementation to transmit and the second to receive. The process is then reversed, with the second implementation sending and the first receiving. Each sending implementation transmits a single complete file with a complete File Description Table. For the first test, the FDT MUST be delivered before the transmission of the file begins. Later sections in this document describe other tests that verify operation in scenarios where the FDT is multiplexed with the file. These tests SHOULD be carried out for various file sizes. The following tests form a minimum set of conditions for FLUTE interoperability. These tests MUST be carried out both with and without the use of A-flags and B-flags in the ALC/LCT header. The A-flag may be used in an empty packet as defined by ALC or by inclusion within the last packet of the transmission. In both cases, it is recommended that the packet containing the A-flag be transmitted multiple times. The transmitting implementation is required to verify the following: o At least one complete FDT MUST be transmitted during the session by the sender implementation. o A valid Transport Session Identifier (TSI) MUST be transmitted so as to uniquely identify the session along with the IP address of the sender. o The value of the TOI MUST be 0 for all the packets containing FDT Instances. Although this is not a limitation set down by FLUTE, it is the recommended testing procedure. The receiving implementation is required to verify the following: o A TSI MUST be present and MUST be the same as transmitted by the sender for the session: The (source IP address, TSI) pair identifies the session. This pair MUST be tested for all packets received to avoid session corruption between several simultaneous sessions. o The TOI MUST be present in each packet received other than packets signaling the end of a session using the A-flag: The Transport Mehta, ed., et al. Expires August 16, 2004 [Page 10] Internet-Draft FLUTE Interoperabtility Testing Guidelines February 2004 Object Identifier identifies the object within the session that the packet is a part of. o The TOI MUST have a value of 0 for the FDT: The receiver identifies a packet containing a part (or all) of the FDT by the value of the TOI for the packet being 0. It is recommended that each packet containing a part of the FDT be checked for the TOI value. o Every FDT Instance packet MUST contain a valid TOI: Each packet with a part of an FDT Instance MUST have a valid TOI in its header. o End of session or file: The receiver MUST be able to recognize the end of a session by the presence of the A-flag and the end of a particular file by the presence of the B-flag. The A-flag may be received in an empty packet or in the last packet of the transmission, which MAY be transmitted multiple times. The receiver MUST be able to handle both cases. o At least one complete FDT MUST be received during the session: The File Description Table contains the attributes of the file that are required by the receiver. At minimum, the complete FDT consists of a valid TOI attribute and Content-Location attribute. The FDT MAY also contain the FEC encoding scheme that has been used by the sender. o The FDT received MUST conform to the schema defined in [1]. All the above conditions MUST also be verified for the following cases of operation: o The receiver joins the session prior to the beginning of transmission of the first packet in the session. o The case when the sender uses a carousel to transmit. It is recommended that the sender transmit the files 3 to 10 times. The receiver joins the session any time after the first packet in the session has been transmitted. Mehta, ed., et al. Expires August 16, 2004 [Page 11] Internet-Draft FLUTE Interoperabtility Testing Guidelines February 2004 7. Multiple Files within a Session The aim of this test is to verify the interoperability of FLUTE implementations wherein multiple files are transmitted by the sender implementation during a session. The system architecture used is the same as used for the tests described in section 4.2. In this test, the sender transmits more that one file during a session. The files are transmitted as separate objects. However, the sender transmits a single complete File Description Table during the entire session. This means that the attributes of all the files are contained within a single FDT. This FDT MUST be complete and MUST contain attributes of all the files transmitted during the session. At the minimum, the FDT MUST contain the TOI and Content-Location attributes for all the files. However, the complete FDT MAY be compiled from a number of FDT Instances. At the sender, the following cases of operation SHOULD be verified: o The sender MUST verify the conditions for interoperability described in section 6. o The sender transmits the complete FDT in a single FDT Instance. However the FDT Instance may be split into several ALC packets. The transmission of the FDT is not multiplexed with the transmission of the files. o The sender transmits multiple FDT Instances, so that the complete set of attributes describing a particular file are transmitted before the transmission of the file itself. Further, FDT Instances and files are sent alternately. The complete set of attributes for a file may be contained within a single FDT Instance, or may be contained in multiple FDT Instances. Again the FDT Instances may be split into several ALC packets. At the receiver, the conditions described in section 6 MUST be verified. Apart from this, the following SHOULD be verified at the receiving implementation: o The receiver MUST be able to map the attributes of different files to the respective file. At the minimum, this involves mapping the TOI and Content-Location to the respective file. o The XML schema described in [1] MUST be verified. o The file SHOULD be verified for its attributes, that is, the information received as part of the FDT should be compared with the actual file itself to verify correctness of interpretation. Mehta, ed., et al. Expires August 16, 2004 [Page 12] Internet-Draft FLUTE Interoperabtility Testing Guidelines February 2004 The file MAY also be compared with the original copy of the file at the sender by using utilities such as 'diff' and 'md5sum'. All the above conditions SHOULD be verified for the following cases: o The receiver joins prior to the beginning of transmission of the first packet in the session. o The receiver joins the session after the first packet in the session has been transmitted. o The receiver joins prior to the beginning of transmission of the first packet in the session, with the sending implementation using carousel for transmission. o The receiver joins the session after the first packet in the session has been transmitted, with the sending implementation using carousel for transmission. It is recommended that the sender carousel the files 3 to 10 times. It is important to note that the sender may not be required to transmit multiple files within a session. However, it is important that all receivers possess the capability to receive one or more files during a session. Mehta, ed., et al. Expires August 16, 2004 [Page 13] Internet-Draft FLUTE Interoperabtility Testing Guidelines February 2004 8. Testing Interoperability for Modified FDTs This section outlines some tests that can be used to verify the interoperability operation of FLUTE implementations in the scenario where the FDT is modified within a session. The modification of the FDT may include several scenarios. Some of the possible scenarios for instance are: o When a file is added to the transmission that was not previously to be transmitted. o When a file that was previously to be transmitted is removed from transmission. o When one or more of the attributes of one or more files, such as Content-Location, Content-Encoding etc. change. o The contents of a file are modified. This is not an exhaustive list and there may be several other scenarios that warrant changes to the FDT. To verify interoperability under these tests, the sender and the receiver MUST satisfy the tests described in section 6. Further, the following SHOULD be verified at the receiver: o That the receiver is able to map the TOIs and Content-Locations obtained from the FDT for each file correctly. Mehta, ed., et al. Expires August 16, 2004 [Page 14] Internet-Draft FLUTE Interoperabtility Testing Guidelines February 2004 9. Recommended Advanced FLUTE Tests This section details tests to determine interoperability under advanced or potentially difficult operating conditions. 9.1 Interoperability Across Simultaneous Multiple Sessions The sender MAY not be required to operate simultaneous multiple sessions of FLUTE, however, it is important that the receiver implementation MUST be able to handle simultaneous multiple sessions of FLUTE. This section outlines some tests that are recommended to be verified to establish interoperability during multiple simultaneous sessions at the receiver. The test architecture is the same as that described in section 4.2. However, the transmission occurs with multiple (at least two) channels and a multiple-rate congestion control protocol. To begin receiving the transmission on multiple sessions, the receiver MUST know the sender's IP address, the number of channels in each session, the destination IP address and port number of each of the channels in the sessions, the TSI of each of the sessions and an indication of whether or not the sessions carry packets for more than one object. Within each session, the receiver SHOULD be able to de-multiplex packets and buffer them, if required, suitably based on the information from the FDT Instances, the EXT_FTI information and possibly out of band information. Across multiple sessions, the receiver SHOULD be able to demultiplex packets and buffer them, if required, suitably based on the information from the FDT Instance, the EXT_FTI information and possibly out of band information. 9.2 Interoperability for Identical Files Across Multiple Sessions or Channels The receiver SHOULD be able to deal with identical files received over different sessions as well as over different channels within a session. The receiver SHOULD be able to identify the files as coming over different sessions and demultiplex and possibly buffer them suitably. Methods of dealing with identical files once they have been received are left to implementations. Mehta, ed., et al. Expires August 16, 2004 [Page 15] Internet-Draft FLUTE Interoperabtility Testing Guidelines February 2004 10. FDT Instance Interoperability Tests This section details tests that need to be verified to ensure that the transmission of the FDT Instance packets and the syntax of the FDT Instance are correct. The test architecture is the same as that outlined in section 4.2. As FDTs contain critical information with regard to file delivery, it is recommended that the following tests be conducted on every FDT Instance packet within a session: o Checking the validity of the EXT_FDT LCT extension: The HET (Header Extension Type) of the FDT Instance Header is 192. o The FDT Instance Header MUST be identical for all ALC/LCT packets carrying parts of a particular FDT Instance. o All packets carrying a part or all of the FDT Instance MUST have the FDT Instance Header. o FDT Instance ID wrap-around MUST be tested. The FDT Instance ID wraps around to 0 after (2^24-1). o The FDT Instance payload MUST contain an 'Expires' attribute with a valid Network Time Protocol (NTP) time value. o Each 'File' element declared under the root element 'FDT-Instance' in the FDT Instance Payload MUST contain at least the attributes 'TOI' and 'Content-Location'. Mehta, ed., et al. Expires August 16, 2004 [Page 16] Internet-Draft FLUTE Interoperabtility Testing Guidelines February 2004 11. Interoperability Test Suite This section describes a test suite that can be used for interoperability testing among FLUTE implementations. To be decided. Mehta, ed., et al. Expires August 16, 2004 [Page 17] Internet-Draft FLUTE Interoperabtility Testing Guidelines February 2004 12. Security Considerations FLUTE implementations are subject to security considerations mentioned in [1]. There are no additional security considerations resulting from the testing guidelines mentioned in this draft. Mehta, ed., et al. Expires August 16, 2004 [Page 18] Internet-Draft FLUTE Interoperabtility Testing Guidelines February 2004 13. Acknowledgements The authors would like to thank Pasi Matilainen and Juha-Pekka Luoma for their contributions and feedback on this document. Mehta, ed., et al. Expires August 16, 2004 [Page 19] Internet-Draft FLUTE Interoperabtility Testing Guidelines February 2004 References [1] Paila, T., Luby, M., Lehtonen, R. and V. Roca, "FLUTE - File Delivery over Unidirectional Transport", draft-ietf-rmt-flute-07 (work in progress), December 2003. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCD 14, March 1997. [3] Luby, M., Gemmel, J., Vicisano, L., Rizzo, L. and J. Crowcroft, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 3450, December 2002. [4] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M. and J. Crowcroft, "Layered Coding Transport (LCT) Building Block", RFC 3451, December 2002. [5] Vicisano, L. and M. Luby, "Compact Forward Error Correction (FEC) Schemes", draft-ietf-rmt-bb-fec-supp-compact-01 (work in progress), May 2003. Authors' Addresses Harsh Mehta Nokia P.O. Box 100 (Visiokatu 1) Tampere FIN-33721 Finland EMail: harsh.mehta@nokia.com Rod Walsh Nokia P.O. Box 100 (Visiokatu 1) Tampere FIN-33721 Finland EMail: rod.walsh@nokia.com Mehta, ed., et al. Expires August 16, 2004 [Page 20] Internet-Draft FLUTE Interoperabtility Testing Guidelines February 2004 Vincent Roca INRIA Rhone-Alpes 655, av. de l'Europe; Montonnot St Ismier cedex 38334 France EMail: vincent.roca@inrialpes.fr Jani Peltotalo Tampere University of Technology P.O. Box 553 (Korkeakoulunkatu 1) Tampere FIN-33101 Finland EMail: jani.peltotalo@tut.fi Sami Peltotalo Tampere University of Technology P.O. Box 553 (Korkeakoulunkatu 1) Tampere FIN-33101 Finland EMail: sami.peltotalo@tut.fi Mehta, ed., et al. Expires August 16, 2004 [Page 21] Internet-Draft FLUTE Interoperabtility Testing Guidelines February 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Mehta, ed., et al. Expires August 16, 2004 [Page 22] Internet-Draft FLUTE Interoperabtility Testing Guidelines February 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Mehta, ed., et al. Expires August 16, 2004 [Page 23]