Internet Engineering Task Force Robert Herriot Internet-Draft Xerox Corp. Expires: September 23, 2001 March 23, 2001 The MIME Application/BatchBeep Content-type draft-herriot-application-batchbeep-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. (If this document becomes part of an IETF working group activity, then it will be brought into full compliance with 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 September 16, 2000. Copyright Notice Copyright c The Internet Society (2000). All Rights Reserved. Abstract The Application/BatchBeep content-type, like the Multipart/Related content-type, provides a mechanism for representing objects that consist of multiple components. An Application/BatchBeep entity contains the wire representation of the client-to-server part of a BEEP (Blocks Extensible Exchange Protocol) session, which consists of sequence of frames. Each frame contains a message or a part of a message. Each message (other than channel 0 messages) represents a component of the compound object, just as a body part of a Multipart/Related entity represents a component. With a Herriot Expires: September 23, 2001 [page 1] INTERNET-DRAFT Application/BatchBeep March 23, 2001 Multipart/Related entity, a body part and its reference in some other body part may be separated by many octets -- more octets than a memory-constrained device can deal with. With an Application/BatchBeep entity, a frame can contain part of a message. This allows a message and its reference in some other message to be made quite close -- close enough for a memory-constrained device to deal with. This document defines the Application/BatchBeep content- type. It also provides examples of its use. Table of Contents 1 Introduction....................................................3 2 Terminology.....................................................3 3 Details.........................................................4 3.1 Parameters for Application/BatchBeep.........................7 3.1.1The "type" Parameter .........................................7 3.1.2Syntax .......................................................7 4 Handling Application/BatchBeep Entities.........................7 5 Examples........................................................8 5.1 Example With Multipart/Related...............................9 5.2 Example Where Each Frame Has a Complete Message.............10 5.3 Example of Chunking the Root Body Part......................11 5.4 Example of Chunking the Several Body Parts..................13 6 Receiving User Agent Requirements..............................14 6.1 Data Requirements...........................................14 6.2 Storing Application/BatchBeep Entities......................15 6.3 Recursion...................................................15 6.4 Configuration Considerations................................15 7 Security Considerations........................................15 8 Registration Information for Application/BatchBeep.............15 9 Acknowledgments................................................16 10 References.....................................................16 11 Author's Address...............................................17 12 Full Copyright Statement.......................................17 Herriot Expires: September 23, 2001 [page 2] INTERNET-DRAFT Application/BatchBeep March 23, 2001 1 Introduction The simple MIME content-types, such as "text/plain" provide a mechanism for representing a simple object, such as a text document. The Multipart/Related [RFC2387] content-type provides a mechanism for representing a compound object, such as a text document with two gif images. A compound object consists of a root component, which contains references to other components of the compound object. These components may, in turn, contain references to other components of the compound object. For example, a compound object could consist of a root html text component and two gif components -- each referenced by the root component. A compound object and a component are both abstractions. For transmission over the wire, each needs a representation. A "Multipart/Related entity" is one possible representation of a compound object, and a "body part" is one possible representation of a component. Within a Multipart/Related entity, the number of octets separating a body part from its reference in some other body part is arbitrarily long. For a memory constrained Receiving User Agent, there is a need to keep the number of octets between a body part and its reference below some maximum number. This requirement implies the need to define some unit that represents a part of a component and to be able to interleave these units among those from other components. This document defines a new MIME content-type Application/BatchBeep that solves this problem. The Application/BatchBeep content-type, like the Multipart/Related content-type, provides a common mechanism for representing a compound object. A Multipart/Related entity consists of sequence of body parts separated by boundary strings, and each body part represents a component of the compound object. An Application/BatchBeep entity contains the wire representation of the client-to-server part of a BEEP (Blocks Extensible Exchange Protocol) session, which consists of sequence of frames, each of whose length is specified in the frame header. Each frame contains a message or a part of a message. Each message (other than channel 0 messages) represents a component of the compound object. Frames from different messages can be interleaved. 2 Terminology This document uses some of the MIME terms that are defined in [RFC2045]. The following are the terms used in this document: Herriot Expires: September 23, 2001 [page 3] INTERNET-DRAFT Application/BatchBeep March 23, 2001 Entity: the headers and the content. In this document "entity" is used to describe all the octets used to represent a compound object. Body Part: an entity inside a multipart. That is, a body part is the headers and content (i.e. octets) between the multipart boundary strings not including the CRLF at the beginning and end. This document never uses "entity" to mean "body part". Headers: the initial lines of an entity or body part. An empty line (i.e. two adjacent CRLFs) terminates the headers. Sometimes the term "MIME header" is used instead of just "header". Content: the part of an entity or body part that follows the headers (i.e. follows the two adjacent CRLFs). The content of a body part ends at the octet preceding the CRLF before the multipart boundary string. Receiving User Agent: the software that receives and processes a MIME entity. This document uses the following terms from BEEP [RFC3080]. Message: an entity as in [RFC2045]. That is, it has MIME headers and content. Frame: a chunk of data, consisting of a frame header, a frame payload and a frame trailer. Frame Header: the first line of a frame. It has information, such as the keyword (e.g. "MSG"), the channel number, the message number, the continuation indicator, the sequence number and the length. This document uses the term "frame header" where [RFC3080] would use the term "header", and it uses the term "header" to mean MIME ([RFC2045]) header. Frame Payload: the octets between the frame header and frame trailer. The length field in the header's length field specifies the octets. The frame payload is either a complete message or a part of a message. Frame Trailer: the last line of a frame. It has only the keyword "END". For symmetry with "frame header", this document uses the term "frame trailer" where [RFC3080] would use the term "trailer". 3 Details The Application/BatchBeep content-type, like Multipart/Related, is intended to represent a compound object consisting of several inter- Herriot Expires: September 23, 2001 [page 4] INTERNET-DRAFT Application/BatchBeep March 23, 2001 related components. This document does not specify the representation of these relationships, but [RFC2557] contains examples of Multipart/Related entities that use the Content-ID and Content-Location headers to identify body parts and URLs (including the "cid" URL) to reference body parts. It is expected that Application/BatchBeep entities would use the patterns described in [RFC2557]. For an Application/BatchBeep entity, there is one parameter for the Content-Type header. It is a "type" parameter, and it is like the "type" parameter for the Multipart/Related content-type. The value of the "type" parameter must be the content-type of the root body part and it effectively specifies the type of the compound object. An Application/BatchBeep entity contains the wire representation of the client-to-server part of a BEEP (Blocks Extensible Exchange Protocol) session, which consists of a sequence of frames. Each frame consists of a frame header, a frame payload and a frame trailer. - The frame header is a subset of the frame header of [RFC3080]. Only the "MSG" keyword is allowed. As a reminder, the frame header specifies the channel number, the message number, the frame payload length and whether the frame is the last of a message. The length field removes the need for boundary strings that Multipart uses. - The frame payload is either a message or a part of a message. - The frame trailer is a line with keyword "END". Each message (other than channel 0 messages) represents a component of the compound object, and a message is intended to have exactly the same representation, octet for octet, as a body part of a Multipart/Related entity that represents the same component. When a message is split across multiple frames, the frames need not be contiguous. Channel 0 contains control messages. The first message is a greeting message. The second message is a start message which initiates channel 1. The first message on channel 1 represents the root component. There are additional start messages if the Application/BatchBeep content uses other channels. The additional channels are all odd numbered, cf. [RFC3080]. The last message is a close message on channel 0 that closes channel 0. This message signifies the end of the Application/BatchBeep entity. The "RPY", "ERR" and "ANS" messages that a server would send to a client in a BEEP session are not a part of the Application/BatchBeep entity. Herriot Expires: September 23, 2001 [page 5] INTERNET-DRAFT Application/BatchBeep March 23, 2001 The contents of an Application/BatchBeep entity have the following properties: 1) An Application/BatchBeep entity contains the wire representation of a BEEP (Blocks Extensible Exchange Protocol) session. 2) The first frame contains a greeting message on channel 0. 3) The second frame contains a start message on channel 0 that opens channel 1. 4) If additional channels are used, there must be a start message on channel 0 before the channel is used 5) The final frame contains a close message on channel 0 that closes channel 0. There are no frames after this message. 6) There may be close messages that close other channels when they are no longer needed. Otherwise, such channels are implicitly closed when channel 0 is closed. 7) Every frame header has the keyword "MSG". Any other keyword is an error. 8) The first message on channel 1 represents the root component of the compound object. 9) An additional message on channel 1 or a message on another odd- numbered channels represents some other component of the compound object. 10) A message can be broken into multiple parts and each break can occur anywhere within the message. Each part of the message is the contents of its own frame. The order of the frames within the Application/BatchBeep entity must be the same as the order of the parts within the message. 11) According to [RFC 3080] a frame of a message can be interleaved with the frames of other messages on other channels, but the frames of two messages on the same channel cannot be interleaved. 12) A message represents a component of a compound object, and it is intended that it be exactly the same representation, octet for octet, as a body part of a Multipart/Related entity that represents the same component. In particular, the body part may contain a Content-Type header to specify the content-type of the message content. Also, the body part may contain a Content- Herriot Expires: September 23, 2001 [page 6] INTERNET-DRAFT Application/BatchBeep March 23, 2001 ID header to identify a message that is referenced from within another message. See section 3.1 for a discussion displaying a Application/BatchBeep entity. 3.1 Parameters for Application/BatchBeep This section defines additional parameters for Application/BatchBeep. 3.1.1The "type" Parameter The type parameter must be specified and its value is the content- type of the "root" body part. It permits a MIME Receiving User Agent to determine the content-type without reference to the enclosed body part. If the value of the type parameter differs from the content- type of the root body part, the Receiving User Agent's behavior is undefined. 3.1.2Syntax The syntax for the "parameter" of the Multipart/Interleaved content- type (in addition to the parameters specified for multipart) is: parameter := "type" "=" type "/" subtype ; cf. [RFC2045] 4 Handling Application/BatchBeep Entities The application that handles the Application/BatchBeep entity has the responsibility for displaying the entity. However, Application/BatchBeep body parts may contain Content-Disposition headers that provide suggestions for the display and storage of a body part, and in some cases the application may pay attention to such headers. As a reminder, Content-Disposition headers [RFC1806] allow the sender to suggest presentation styles for MIME body parts. There are two presentation styles, 'inline' and 'attachment'. Content-Disposition headers have a parameter for specifying a suggested file name for storage. There are three cases to consider for handling Application/BatchBeep entities: a) The Receiving User Agent recognizes Application/BatchBeep and the content-type of the root. The Receiving User Agent determines the Herriot Expires: September 23, 2001 [page 7] INTERNET-DRAFT Application/BatchBeep March 23, 2001 presentation style for the compound object; it handles the display of the components of the compound object in the context of the compound object. In this case, the Content-Disposition header information is redundant or even misleading, and the Receiving User Agent shall ignore them for purposes of display. The Receiving User Agent may use the suggested file name if the entity is stored. b) The Receiving User Agent recognizes Application/BatchBeep, but not the content-type of the root. The Receiving User Agent will give the user the choice of suppressing the entire Application/BatchBeep entity or treating the Application/BatchBeep entity as a Multipart/Mixed entity where each message is a body part of the Multipart/Mixed entity. In this case (where the entity is not suppressed), the Receiving User Agent may find the Content- Disposition information useful for displaying each body part of the resulting Multipart/Mixed entity. If a body part has no Content-Disposition header, the Receiving User Agent should display the body part as an attachment. c) The Receiving User Agent does not recognize Application/BatchBeep. The Receiving User Agent treats the Application/BatchBeep entity as opaque and can do nothing with it. 5 Examples This section contains four examples. Each example is a different representation of the same compound object. The compound object has four components: an XHTML text component and three image components. One image is encoded in base64, and the other two images are encoded in binary (for sake of example). Two of the images are potentially side by side, and the third image is displayed later in the document. The first example shows a Multipart/Related representation of the compound object. The remaining examples show Application/BatchBeep representations of the same compound object. In the second example, each frame contains a whole message. In the third example, the XHTML message is split across 3 frames, and these frames are interleaved among the three image messages. In the fourth example, the XHTML message is split across 4 frames, and the two side-by-side images are each split across two frames. The XHTML frames are interleaved among the image frames. Each body part contains a content-disposition, which the Receiving User Agent uses according to the rules in section 3.1. Note the location of the content-disposition headers in the examples. Herriot Expires: September 23, 2001 [page 8] INTERNET-DRAFT Application/BatchBeep March 23, 2001 5.1 Example With Multipart/Related In this example, the compound object is represented as a Multipart/Related entity so that the reader can compare it with the Application/Batch entities. Content-Type: multipart/related; boundary="boundary-example"; type="text/xhtml+xml" --boundary-example Content-ID: <49568.44343xxx@foo.com> Content-Type: text/xhtml+xml;charset="us-ascii" Content-Disposition: inline

some text some more text after the images

some more text without images

some more text

some final text

--boundary-example Content-ID: <49568.45876xxx @foo.com> Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Disposition: attachment R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A etc... --boundary-example Content-ID: <49568.46000xxx@foo.com> Content-Type: image/gif Content-Transfer-Encoding: binary Content-Disposition: attachment --boundary-example Herriot Expires: September 23, 2001 [page 9] INTERNET-DRAFT Application/BatchBeep March 23, 2001 Content-ID: <49568.47333xxx@foo.com> Content-Type: image/gif Content-Transfer-Encoding: binary Content-Disposition: attachment --boundary-example-- 5.2 Example Where Each Frame Has a Complete Message In this example, the compound object is represented as an Application/BatchBeep entity. Each frame contains an entire message, i.e. none of the messages is split across multiple frames. Content-Type: application/batchbeep; type="text/xhtml+xml" MSG 1 1 . 1 550 Content-ID: <49568.44343xxx@foo.com> Content-Type: text/xhtml+xml;charset="us-ascii" Content-Disposition: inline

some text some more text after the images

some more text without images

some more text

some final text

END MSG 1 2 . 551 6346 Content-ID: <49568.45876xxx @foo.com> Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Disposition: attachment R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A Herriot Expires: September 23, 2001 [page 10] INTERNET-DRAFT Application/BatchBeep March 23, 2001 etc... END MSG 1 3 . 6897 6401 Content-ID: <49568.46000xxx@foo.com> Content-Type: image/gif Content-Transfer-Encoding: binary Content-Disposition: attachment END MSG 1 4 . 13298 7603 Content-ID: <49568.47333xxx@foo.com> Content-Type: image/gif Content-Transfer-Encoding: binary Content-Disposition: attachment END 5.3 Example of Chunking the Root Body Part In this example, the compound object is represented as an Application/BatchBeep. The message that represents the XHTML (root) component is split across multiple frames. The messages that contain the image components are not split across multiple frames. In this example, the compound object is represented as an Application/BatchBeep entity. The message containing the XHTML component is split into 3 pieces so that the reference to an image is as close as possible to the beginning of the frame. The frame containing the referenced image message occurs just before the frame with the reference. This minimizes the distance between reference and referenced message. Note that there are other possible arrangements (see the third example in section 5.4). For example, a sender could split the XHTML message so that the reference to an image is as close as possible to the end of the frame. Then the frame containing the referenced image message should occur just after the frame with the reference. The sender could mix this strategy with the one use in this example. Content-Type: application/batchbeep; type="text/xhtml+xml" MSG 1 1 * 1 267 Content-ID: <49568.44343xxx@foo.com> Content-Type: text/xhtml+xml;charset="us-ascii" Content-Disposition: inline Herriot Expires: September 23, 2001 [page 11] INTERNET-DRAFT Application/BatchBeep March 23, 2001

some text END MSG 3 1 . 1 6346 Content-ID: <49568.45876xxx @foo.com> Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Disposition: attachment R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A etc... END MSG 3 2 . 6347 6401 Content-ID: <49568.46000xxx@foo.com> Content-Type: image/gif Content-Transfer-Encoding: binary Content-Disposition: attachment END MSG 1 1 * 268 166 some more text after the images

some more text without images

some more text END MSG 3 3 . 12748 7603 Content-ID: <49568.47333xxx@foo.com> Content-Type: image/gif Content-Transfer-Encoding: binary Content-Disposition: attachment END MSG 1 1 . 434 80

some final text

END Herriot Expires: September 23, 2001 [page 12] INTERNET-DRAFT Application/BatchBeep March 23, 2001 5.4 Example of Chunking the Several Body Parts In this example, the compound object is represented as an Application/BatchBeep. The message that represents the XHTML (root) component is split across multiple frames. The messages that contain the image components are not split across multiple frames. In this example, the compound object is represented as an Application/BatchBeep entity. The message containing the XHTML component is split into 4 pieces so that the reference to an image is as close as possible to either the beginning or the end of the frame. In the former case, the frame containing the referenced image message occurs just before the frame with the reference (see the first two images in this example). In the later case, the frame containing the referenced image message occurs just after the frame with the reference (see the third image in this example). This minimizes the distance between reference and referenced message. In addition, the first two image messages are split into two frames each. Content-Type: application/batchbeep; type="text/xhtml+xml" MSG 1 1 * 1 303 Content-ID: <49568.44343xxx@foo.com> Content-Type: text/xhtml+xml;charset="us-ascii" Content-Disposition: inline

some text END MSG 3 1 * 1 184 Content-ID: <49568.45876xxx @foo.com> Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Disposition: attachment R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 END MSG 5 1 * 1 200 Content-ID: <49568.46000xxx@foo.com> Content-Type: image/gif Content-Transfer-Encoding: binary Content-Disposition: attachment END Herriot Expires: September 23, 2001 [page 13] INTERNET-DRAFT Application/BatchBeep March 23, 2001 MSG 1 1 . 304 78 END MSG 3 1 . 185 6162 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A etc... END MSG 5 1 . 201 6201 END MSG 1 1 . 382 127 some more text after the images

some more text without images

some more text END MSG 3 2 . 6347 7603 Content-ID: <49568.47333xxx@foo.com> Content-Type: image/gif Content-Transfer-Encoding: binary Content-Disposition: attachment END MSG 1 1 . 509 41

some final text

END 6 Receiving User Agent Requirements See section 3.1 for details about how a Receiving User Agent processes a Application/BatchBeep entity. 6.1 Data Requirements ISSUE: what should be in this section: MIME-capable mail user agents (MUAs) are required to provide the application: Herriot Expires: September 23, 2001 [page 14] INTERNET-DRAFT Application/BatchBeep March 23, 2001 a) the contents of the MIME entities and the entity Content-* headers, b) the parameters of the Application/BatchBeep Content-type header, c) the correspondence between each body part's local file name, that body part's header data, and, if present, the body part's content- ID 6.2 Storing Application/BatchBeep Entities The Application/BatchBeep content-type will be used for objects that have internal linkages between the body parts. When the objects are stored the linkages may require processing by the application or its receiving user agent. 6.3 Recursion MIME is a recursive structure. Hence, it is possible for an Application/BatchBeep entity to contain other Application/BatchBeep entities. 6.4 Configuration Considerations It is suggested that MUAs that use configuration mechanisms of [RFC1524]. For an example, refer to Application/BatchBeep as Application/BatchBeep/, where is the value of the "type" parameter. 7 Security Considerations Security considerations relevant to Application/BatchBeep are identical to those of the underlying content-type. 8 Registration Information for Application/BatchBeep The following form is copied from RFC 1590, Appendix A. To: IANA@isi.edu Subject: Registration of new Media Type content- type/subtype Media Type name: Application Media subtype name: BatchBeep Required parameters: Type, a media type/subtype. Herriot Expires: September 23, 2001 [page 15] INTERNET-DRAFT Application/BatchBeep March 23, 2001 Optional parameters: No optional parameters Encoding considerations: Application/BatchBeep content-types cannot have encodings. But the individual messages do have encodings. Security considerations: Depends solely on the referenced type. Published specification: RFC-REL (this document). Person & email address to contact for further information: Robert Herriot Xerox Corp. 3400 Hillview Ave, Bldg #1 Palo Alto, CA 94304 USA Phone: 1-650-813-7696 Email: rherriot@pahv.xerox.com 9 Acknowledgments The author gratefully acknowledges the contributions of: Ugo Corda, Dave Crocker, Graham Klyne, Carl-Uno Manros, Larry Masinter, Chris Newman and Henrik Frystyk Nielsen. In particular, Chris Newman provided invaluable help. 10 References [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982. [RFC1524] Borenstein, N., "A User Agent Configuration Mechanism For Multimedia Mail Format Information", RFC 1524, September 1993. [RFC1806] Troost, R., and S. Dorner, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header", RFC 1806, June 1995. [RFC1873] Levinson, E., and J. Clark, "Message/External-Body Content- ID Access Type", RFC 1873, December 1995, Levinson, E., "Message/External-Body Content-ID Access Type", Work in Progress. [RFC2045] Freed, N. et al., "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2046, November 1996. [RFC2046] Freed, N. et al., "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. Herriot Expires: September 23, 2001 [page 16] INTERNET-DRAFT Application/BatchBeep March 23, 2001 [RFC2387] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998. [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998. [RFC2557] Palme, J., "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML", RFC 2557, March 1999. [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001. 11 Author's Address Robert Herriot Xerox Corp. 3400 Hillview Ave, Bldg #1 Palo Alto, CA 94304 USA Phone: 1-650-813-7696 Email: rherriot@pahv.xerox.com 12 Full Copyright Statement Copyright c The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative work 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 assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING Herriot Expires: September 23, 2001 [page 17] INTERNET-DRAFT Application/BatchBeep March 23, 2001 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Herriot Expires: September 23, 2001 [page 18]