Network Working Group E. Burger Internet Draft SnowShore Networks Document: draft-ietf-vpim-hint-01.txt E. Candell Category: Standards Track Comverse Network Systems Expires May 2001 C. Eliot Microsoft Corporation G. Klyne Content Technologies November 24, 2000 Message Context for Internet Mail Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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 document is a work product of the IETF Voice Profile for Internet Mail (vpim) Work Group. The URL for the VPIM website is . 1. Abstract This memo describes a new RFC822 message header, "Message-Context". This header provides information about the context and presentation characteristics of a message. A receiving user agent (UA) may use this information as a hint to optimally present the message. Expires 5/13/01 [Page 1] Message Context for Internet Mail November 2000 Table of Contents 1. ABSTRACT...........................................................1 2. INTRODUCTION.......................................................3 3. CONVENTIONS USED IN THIS DOCUMENT..................................3 4. MOTIVATION.........................................................4 5. FUNCTIONAL REQUIREMENTS............................................5 6. DETERMINING THE MESSAGE CONTEXT....................................6 7. MESSAGE-CONTEXT REFERENCE FIELD....................................6 7.1. Message-Context Syntax...........................................7 7.2. message-context-class Syntax.....................................7 7.2.1. voice-message..................................................7 7.2.2. fax-message....................................................7 7.2.3. video-message..................................................7 7.2.4. short-message..................................................7 7.2.5. mail-message...................................................8 7.2.6. none...........................................................8 8. SECURITY CONSIDERATIONS............................................8 9. IANA CONSIDERATIONS................................................8 9.1. Message-Context Registration.....................................8 9.2. Primary Context Class Registrations..............................9 9.2.1. Registration Template..........................................9 9.2.2. voice-message.................................................10 9.2.3. fax-message...................................................11 9.2.4. video-message.................................................11 9.2.5. short-message.................................................12 9.2.6. video-message.................................................13 9.2.7. mail-message..................................................13 9.2.8. video-message.................................................14 9.2.9. none..........................................................14 10. APPENDIX: SOME MESSAGING SCENARIOS...............................15 10.1. Internet e-mail................................................15 10.2. Short text messaging service...................................16 10.3. Facsimile......................................................16 10.4. Voice mail.....................................................17 10.5. Multimedia message.............................................17 11. REFERENCES.......................................................18 12. ACKNOWLEDGMENTS..................................................18 13. AUTHOR'S ADDRESSES...............................................19 14. FULL COPYRIGHT STATEMENT.........................................20 Burger et. al. Expires 5/24/01 [Page 2] Message Context for Internet Mail November 2000 2. Introduction This document describes a mechanism to allow senders of a multi-part Internet mail message to convey presentational information of the message as a whole. This information specifies the context of the message. With this information, the user agent (UA) can optimally present the message to the user in the context she expects. In this document, the "message context" is the context the user expects to interact with the message. For example, a message may be e-mail, voice mail, fax mail, etc. A smart UA may have specialized behavior based on the context of the message. This document specifies a RFC 822 header called "Message-Context". The mechanism is in some ways similar to the use of the Content- Disposition MIME entity described in [2]. Content-Disposition gives clues to the receiving User Agent (UA) for how to display a given body part. Message-Context gives clues to the receiving UA for the context of the message display as a whole. This allows the receiving UA to present the message in a meaningful and helpful way to the recipient. Typical uses for this mechanism include: o Selecting a special viewer for a given message. o Selecting an icon indicating the kind of message in a displayed list of messages. o Arraigning messages in an inbox display. o Filtering messages the UA presents when the user has limited access. 3. Conventions used in this document This document refers generically to the sender of a message in the masculine (he/him/his) and the recipient of the message in the feminine (she/her/hers). This convention is purely for convenience and makes no assumption about the gender of a message sender or recipient. 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 [3]. FORMATTING NOTE: Notes, such at this one, provide additional nonessential information that the reader may skip without missing anything essential. The primary purpose of these non-essential notes is to convey information about the rationale of this document, or to place this document in the proper historical or evolutionary context. Readers whose sole purpose is to construct a conformant implementation may skip such information. However, it may be of use to those who wish to understand why we made certain design choices. Burger et. al. Expires 5/24/01 [Page 3] Message Context for Internet Mail November 2000 4. Motivation Multimedia messaging systems receive messages that a UA may present in variety of ways. For example, traditional e-mail uses simple text messages that the recipient displays and edits. One UA may automatically print Fax images. Another UA may play voice messages through a telephone handset. Likewise, a receiving desktop computer may process or present documents transferred over e-mail using a local application. Emerging and future developments may deliver other forms of information that have their own characteristics for user presentation, such as video messages and short text messages. An often-requested characteristic for multimedia messaging systems is to collect received messages in a "universal inbox", and to offer them to the user as a combined list. In the context of "unified messaging", different message contexts may have different implied semantics. For example, some users may perceive voicemail to have an implicit assumption of urgency. Thus they may wish to gather them together and process them before other messages. This results in the end-user receiving agent needing to be able to identify voicemail and distinguish it from other messages. The uses of this kind of presentation characteristic for each message is multi-fold: o Display an indication to the user (e.g., by a suitably evocative icon along with other summary fields), o Auto-forward a given message type into another messaging environment (e.g., short text to a mobile short message service), o Prioritize and group messages in an inbox display list, o Suggest appropriate default handling for presentation, o Suggest appropriate default handling for reply, forward, etc., and o Filter the message list for presentation via limited-capability user interfaces (e.g., there is no point in offering images when the user is connected by a voice-only telephone user interface). A problem faced by multimedia messaging systems is that it is not always easy to decide the context of a received message. For example, consider the following scenarios. Burger et. al. Expires 5/24/01 [Page 4] Message Context for Internet Mail November 2000 o A message that contains audio and image data: Is this a fax message that happens to have some voice commentary? Is it a voice message that is accompanied by some supplementary diagrams? Is it a fully multimedia message, in which all parts are expected to carry equal significance? o A message containing text and audio data: Is this e-mail with an MP3 music attachment? Is it a voice message that happens to have been generated with an initial text header for the benefit of non-voice-enabled e-mail receivers? The message context does relate to the message media content. However, it is not the same thing. As shown above, the media type used in a message is not sufficient to indicate the message context. One cannot determine a priori which media types to use in alternative (gateway) message. Also, what if the user cares about distinguishing traditional e-mail text from SMS messages? They are both the same media type, text, but they have different user contexts. 5. Functional Requirements The goals stated above lead to the following functional requirements. For receivers: o Identify a message as belonging to a message class. o Incorrect or invalid message classification must not result in failure to transfer or inability to present a message. For senders: o Specify message classes by the originating user's choice of authoring tool or simple user interaction. For both: o Specify a well-defined set of message classes to make interoperability between mail user agents (UAs) possible. o Message classification information has to be interpretable in reasonable fashion by many different user agent systems. o The mechanism should be extensible to allow for the introduction of new kinds of messages. Burger et. al. Expires 5/24/01 [Page 5] Message Context for Internet Mail November 2000 6. Determining the Message Context One method of indicating the interpretation context of a message is to examine the media types in the message. However, this requires the UA to scan the entire message before it can make this determination. This approach is particularly burdensome for the multi-media mail situation, as voice and especially video mail objects are quite large. We considered indicating the message context by registering a multipart/* MIME subtype (Content-Type). For example, the VPIM Work Group has registered multipart/voice-message to indicate that a message is primarily voice mail [4]. However, multipart/voice- message is identical in syntax to multipart/mixed. The only difference is that VPIM mail transfer agents and user agents recognize that they can perform special handling of the message based on it being a voice mail message. Moreover, Content-Type refers to a given MIME body part, not to the message as a whole. We wish to avoid scanning the entire message. In addition, we wish to avoid having to create multiple aliases for multipart/mixed every time someone identifies a new primary content type. Multiple aliases for multipart/mixed are not desirable as they remove the possibility for specifying a message as multipart/alternate, multipart/parallel, or multipart/encrypted, for example. Since the message context is an attribute of the entire message, it is logical to define a new top-level (RFC 822 [5]) message attribute. To this end, this document introduces the message attribute "Message-Context". The values for Message-Context MUST be either IANA registered values or experimental, X- tokens. This ensures that user agents from different vendors will interoperate and perform in a uniform manner without an undue burden on the vendors. Message-Context only serves to identify the message context. It does not provide any indication of content that the UA must be capable of delivering. It does not imply any message disposition or delivery notification. There is a related effort to define Critical Content of Internet Mail [6] that one might use to perform these tasks. Message-Context is only an indicator. One can conceive of goofy situations, such as a message marked "voice-message" but without an audio body part. In this case, the fact that the contents of a message don't match its context MUST NOT generate an error report or fail to deliver or process the message. 7. Message-Context Reference Field Burger et. al. Expires 5/24/01 [Page 6] Message Context for Internet Mail November 2000 The Message-Context reference field is a top-level header inserted by the sending UA to indicate the context of the message. 7.1. Message-Context Syntax The syntax of the Message-Context field, formatted according to the ABNF [7] is as follows. Note that "Message-Context" is case insensitive, per RFC 822. "Message-Context" ":" message-context-class CRLF 7.2. message-context-class Syntax The message-context-class indicates the context of the message. This is an IANA registered value. Current values for message- context-class are as follows. message-context-class = 1 *( [ "voice-message"] [ "fax-message" ] [ "video-message" ] [ "short-message" ] [ "mail-message" ] [ "none" ] extension-type ) extension-type = token ; Defined and registered per Section 8 / x-token ; Experimental, private use token = x-token = 7.2.1. voice-message The voice-message class states the message is a voice message. 7.2.2. fax-message The fax-message class states the message is a facsimile message. 7.2.3. video-message The video-message class states the message is a video message. 7.2.4. short-message The short-message class states the message is a short text message, such as a short text message service (SMS) message or text pager message. Burger et. al. Expires 5/24/01 [Page 7] Message Context for Internet Mail November 2000 7.2.5. mail-message The mail-message class states the message is a normal internet mail message, with or without attachments. 7.2.6. none The none class states there is no context information for this message. This class is functionally identical to the mail-message class. If a message has no Message-Context reference field, "none" MUST be the default value. 8. Security Considerations The intention for this header is to indicate message context only. One can imagine someone creating an "Application" Message-Context. A poorly designed user agent could blindly execute a mailed program based on the Message-Context. Don't do that! One can envision a denial of service attack by bombing a receiver with a message that has a Message-Context that doesn't fit the profile of the actual body parts. This is why the receiver MUST consider the Message-Context to be a hint only. The receiver SHOULD NOT rely on the Message-Context exclusively for presentation processing. 9. IANA Considerations Following the policies outlined in [9] as "Specification Required", IANA assigns values for Message-Context. 9.1. Message-Context Registration To: ietf-types@iana.org Subject: Registration of New Top-Level Header Field Message-Context Header name: Message-Context Required parameters: Single 7bit text value Parameter value: The parameter value specifies the message context for the message. Security considerations: The intention for this header is to indicate media content type only. One can imagine one creating an "Application" primary content Burger et. al. Expires 5/24/01 [Page 8] Message Context for Internet Mail November 2000 type, and have a poorly designed user agent blindly execute a mailed program. Published specification: draft-ietf-vpim-hint-01.txt Applications that use this context class: Mail VPIM FPIM Additional information: none Person & email address to contact for further information: Eric Burger e.burger@ieee.org Intended usage: COMMON 9.2. Primary Context Class Registrations 9.2.1. Registration Template NOTE: Is ietf-types the appropriate address? Do we need to set up another address with IANA? NOTE: What is the appropriate discussion list to socialize new tags on? Is it imc822? In the following template, a pipe symbol, "|", precedes instructions or other helpful material. Be sure to replace "" with the class name you are defining. To: ietf-types@iana.org Subject: Registration of New Message-Context class Message-Context class name: Summary of the message class: | Include a short (no longer than 4 lines) description or summary | Examples: | "Palmtop devices have a 320x160 pixel display, so we can..." | "Color fax is so different than black & white that..." Security considerations: | Describe issues related to security. Examples include privacy | concerns, denial of service concerns, malicious behavior, etc. Burger et. al. Expires 5/24/01 [Page 9] Message Context for Internet Mail November 2000 Interoperability considerations: | Describe issues with existing RFC's or BCP's, if any. Published specification: | List the document(s) that define the context this | class represents NOTE: Since classes are pretty straight-forward, can we use the registration mechanism for including a full description of the class behavior? Applications that use this context class: | List known applications that use this context class NOTE: Do we need to include the Applications enumeration? Additional information: | Any other relevant information that might be useful, such | as related class definitions, etc. Person & email address to contact for further information: | Name & e-mail! Intended usage: | pick one of COMMON, LIMITED USE, or OBSOLETE 9.2.2. voice-message To: ietf-types@iana.org Subject: Registration of New Message-Context class voice-message Message-Context class name: voice-message Security considerations: none Interoperability considerations: User agents declaring the primary context to be voice-message SHOULD conform to VPIMv2. Published specification: draft-ietf-vpim-hint-01.txt RFC 2421, Voice Profile for Internet Mail - version 2 Applications that use this context class: VPIM Additional information: none Burger et. al. Expires 5/24/01 [Page 10] Message Context for Internet Mail November 2000 Person & email address to contact for further information: Eric Burger e.burger@ieee.org Intended usage: COMMON 9.2.3. fax-message To: ietf-types@iana.org Subject: Registration of New Message-Context class fax-message Message-Context class name: fax-message Security considerations: none Interoperability considerations: none Published specification: draft-ietf-vpim-hint-01.txt Applications that use this context class: FPIM Additional information: none Person & email address to contact for further information: Eric Burger e.burger@ieee.org Intended usage: COMMON 9.2.4. video-message To: ietf-types@iana.org Subject: Registration of New Message-Context class video-message Message-Context class name: voice-message Security considerations: none Interoperability considerations: none Burger et. al. Expires 5/24/01 [Page 11] Message Context for Internet Mail November 2000 Published specification: draft-ietf-vpim-hint-01.txt Applications that use this context class: VPIM, FPIM Additional information: none Person & email address to contact for further information: Eric Burger e.burger@ieee.org Intended usage: COMMON 9.2.5. short-message To: ietf-types@iana.org Subject: Registration of New Message-Context class short-message Message-Context class name: short-message Security considerations: none Interoperability considerations: none Published specification: draft-ietf-vpim-hint-01.txt Applications that use this context class: Mail VPIM FPIM Additional information: none Person & email address to contact for further information: Eric Burger e.burger@ieee.org Intended usage: COMMON Burger et. al. Expires 5/24/01 [Page 12] Message Context for Internet Mail November 2000 9.2.6. video-message To: ietf-types@iana.org Subject: Registration of New Message-Context class video-message Message-Context class name: voice-message Security considerations: none Interoperability considerations: none Published specification: draft-ietf-vpim-hint-01.txt Applications that use this context class: VPIM, FPIM Additional information: none Person & email address to contact for further information: Eric Burger e.burger@ieee.org Intended usage: COMMON 9.2.7. mail-message To: ietf-types@iana.org Subject: Registration of New Message-Context class mail-message Message-Context class name: mail-message Security considerations: none Interoperability considerations: none Published specification: draft-ietf-vpim-hint-01.txt Applications that use this context class: Mail VPIM FPIM Burger et. al. Expires 5/24/01 [Page 13] Message Context for Internet Mail November 2000 Additional information: none Person & email address to contact for further information: Eric Burger e.burger@ieee.org Intended usage: COMMON 9.2.8. video-message To: ietf-types@iana.org Subject: Registration of New Message-Context class video-message Message-Context class name: voice-message Security considerations: none Interoperability considerations: none Published specification: draft-ietf-vpim-hint-01.txt Applications that use this context class: VPIM, FPIM Additional information: none Person & email address to contact for further information: Eric Burger e.burger@ieee.org Intended usage: COMMON 9.2.9. none To: ietf-types@iana.org Subject: Registration of New Message-Context class none Message-Context class name: none Security considerations: none Interoperability considerations: none Burger et. al. Expires 5/24/01 [Page 14] Message Context for Internet Mail November 2000 Published specification: draft-ietf-vpim-hint-01.txt Applications that use this context class: Mail VPIM FPIM Additional information: none Person & email address to contact for further information: Eric Burger e.burger@ieee.org Intended usage: COMMON 10. APPENDIX: Some messaging scenarios This section is not a normative part of this document. We include it here as a historical perspective on the issue of multimedia message types. These scenarios are neither comprehensive nor fixed. For example, e-mails being typically text-based do not mean that they cannot convey a voice-message. This very mutability serves to underline the desirability of providing some explicit message context hint. 10.1. Internet e-mail Internet e-mail carries textual information. Sometimes it conveys computer application data of arbitrary size. Typically, one uses e-mail for non-urgent messages, which the recipient will retrieve and process at a time convenient to her. The normal device for receiving and processing e-mail messages is some kind of personal computer. Modern personal computers usually come with a reasonably large display and an alphanumeric keyboard. Audio, video, and printing capabilities are not necessarily available. One can use E-mail for communication between two parties (one-to- one), a small number of known parties (one-to-few) or, via an e-mail distribution list, between larger numbers of unknown parties (one- to-many). One of the endearing characteristics of e-mail is the way that it allows the recipient to forward all or part of the message a to another party, with or without additional comments. It is quite Burger et. al. Expires 5/24/01 [Page 15] Message Context for Internet Mail November 2000 common for an e-mail to contain snippets of content from several previous messages. Similar features apply when replying to e-mail. 10.2. Short text messaging service One can use a short text message to convey textual information of limited size. The typical limit is 160 characters. The short text messaging service (SMS) is a facility that has evolved for use with mobile telephones, and has an associated per- message transmission charge. People use SMS for relatively urgent messages, which the sender wishes the receiver to see and possibly respond to within a short time period. The normal device for sending and receiving a short text message is a mobile telephone with a small character display and a numeric-only keyboard. Personal computers and personal digital assistants (PDAs) can also participate in short text messaging. Currently, the most common use of short text messages are between just two parties (one-to-one). Users often send short text messages in isolation, rather than as part of a longer exchange. One use for them is as a prompt or invitation to communicate by some more convenient and content-rich method, such as a telephone call. 10.3. Facsimile People use facsimile to convey image information of moderate size, typically a small number of pages. Sometimes people use facsimile for larger documents. Facsimile is a facility that usually uses circuit-switched telephone circuits, with connection-time charges. Message transfer takes place in real-time. Thus, people often use facsimile for urgent communication. The normal device for sending and receiving a facsimile is a self- contained scanning and printing device connected to a telephone line or a desktop computer. Most facsimiles are between just two parties (one-to-one). However, a significant portion of facsimile service is broadcast between multiple parties (one-to-many). Most facsimile exchanges are in isolation, rather than as part of a longer exchange. Facsimile data is typically not suitable for further processing by computer. Burger et. al. Expires 5/24/01 [Page 16] Message Context for Internet Mail November 2000 10.4. Voice mail People use voice mail to convey audio information, almost exclusively human speech. Voice mail is a facility that usually uses circuit-switched telephone circuits, with modest connection-time charges, often used for moderately urgent messages. A common use for them is as a prompt or invitation to communicate by some more convenient method, such as a telephone call. In most, but not all cases, the sender of a voice message does not want to send a message at all. Rather, they wished to engage in a real-time conversation. The normal device for sending and receiving a voice mail is a telephone handset. Voice messages are usually sent between just two parties (one-to- one). Voice mail data is not generally suitable for further processing by computer. 10.5. Multimedia message We define a multimedia message as a message containing more than one basic media type (text, image, audio, video, model, application). The following are some characteristics of a multimedia message. In some cases, a multimedia message is just e-mail with an attachment that a multimedia display application presents. For example, I can send you an MP3 of something I recorded in my garage today. In other cases, a multimedia message represents a convergence between two or more of the scenarios described above. For example, a voice message with an accompanying diagram or a talking head video message is a multimedia message. The characteristics will vary somewhat with the intent of the sender. This in turn may affect the user agent or application used to render the message. Burger et. al. Expires 5/24/01 [Page 17] Message Context for Internet Mail November 2000 11. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Troost, R., Dorner, S., and Moore, K., "Communicating Presentation Information in Internet Messages: The Content- Disposition Header Field", RFC 2183, New Century Systems, QUALCOMM Incorporated, and University of Tennessee, August 1997. 3 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 4 Vaudreuil, G. and Parsons, G., "VPIM Voice Message MIME Sub-type Registration", RFC 2423, Lucent Technologies and Northern Telecom, September 1998. 5 Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982. 6 Burger, E. and Candell, E., "Critical Content of Internet Mail", draft-ietf-vpim-cc-01.txt, Work in Progress. 7 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. 8 Freed, N. and Borenstein, N., "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, Innosoft and First Virtual, November 1996. 9 Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 12. Acknowledgments Many of the ideas here arose originally from a discussion with Jutta Degener. We'd also like to thank Keith Moore for helping us tighten-up our explanations. Burger et. al. Expires 5/24/01 [Page 18] Message Context for Internet Mail November 2000 13. Author's Addresses Eric Burger SnowShore Networks, Inc. c/o CRV 1000 Winter St. Suite 3300 Waltham, MA 02451-1448 USA Phone: +1 781 487 5406 Fax: +1 781 895 9809 Email: e.burger@ieee.org Emily Candell Comverse Network Systems 200 Quannapowitt Pkwy. Wakefield, MA 01880 USA Phone: +1 781 213 2324 Email: emily@comversens.com Graham Klyne Content Technologies Ltd. 1220 Parkview, Arlington Business Park Theale Reading, RG7 4SA United Kingdom. Telephone: +44 118 930 1300 Facsimile: +44 118 930 1301 E-mail: GK@ACM.ORG Charles Eliot Microsoft Corporation One Microsoft Way Redmond WA 98052 USA Telephone: +1 425 936 9760 E-Mail: charle@Microsoft.com Burger et. al. Expires 5/24/01 [Page 19] Message Context for Internet Mail November 2000 14. Full Copyright 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 implementers 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 that may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Copyright (C) 2000 The Internet Society. 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 assigns. 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Burger et. al. Expires 5/24/01 [Page 20]