Network Working Group                                           E. Burger
Internet Draft                                         SnowShore Networks
Document: draft-ietf-vpim-cc-02.txt                            E. Candell
Category: Standards Track                        Comverse Network Systems
Expires May 2001                                        November 24, 2000

                   Critical Content of 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

   One can access the list of current Internet-Drafts at

   One can access the list of Internet-Draft Shadow Directories at

   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 document describes a mechanism for identifying the body parts
   that the sender deems critical in a multi-part Internet mail

   By knowing what parts of a message the sender deems critical, a MTA
   or UA can intelligently handle multi-part messages when gatewaying
   (MTA) or presenting (UA) to systems of lesser capability. Critical
   content can help a smart gateway decide what parts to forward.  It
   can indicate how hard a gateway should try to deliver a body part.
   It can help an MTA to select body parts to silently delete when a
   system of lesser capability receives a message.  In addition,
   critical content can help indicate the notification strategy of the
   receiving system.

                           Expires 5/24/01                    [Page 1]

                  Critical Content of Internet Mail      November 2000

Table of Contents

1.  ABSTRACT .........................................................1
2.  CONVENTIONS USED IN THIS DOCUMENT ................................2
3.  INTRODUCTION .....................................................3
4.  CONTENT-CRITICALITY ENTITY .......................................5
4.1.  CRITICAL .......................................................6
4.2.  IGNORE .........................................................6
4.3.  Other Values ...................................................6
4.4.  Summary ........................................................7
5.  STATUS CODE ......................................................7
6.  BACKWARD COMPATIBILITY CONSIDERATIONS ............................8
7.  MIME INTERACTIONS ................................................8
7.1.  multipart/alternative ..........................................8
7.2.  multipart/related ..............................................9
7.3.  message/rfc822 .................................................9
8.  IMPLEMENTATION EXAMPLES ..........................................9
8.1.  Content Gateways ...............................................9
8.2.  Non-Traditional UA ............................................10
9.  SECURITY CONSIDERATIONS .........................................11
10. COLLECTED SYNTAX ................................................11
11. REFERENCES ......................................................11
12. ACKNOWLEDGMENTS .................................................12
13. AUTHOR'S ADDRESSES ..............................................13

2. 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

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   this document are to be interpreted as described in RFC-2119 [2].

   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 and Candell         Expires 5/24/01                    [Page 2]

                  Critical Content of Internet Mail      November 2000

3. Introduction

   This document describes the Critical Content identification for
   multi-part Internet mail.

   The need for a critical content identification mechanism comes about
   because of the internetworking of Internet mail systems with legacy
   messaging systems that do not fulfil all of the semantics of
   Internet mail.  Such legacy systems have a limited ability to render
   all parts of a given message.  This document will use the case of an
   Internet mail system exchanging electronic messages with a legacy
   voice messaging system for illustrative purposes.

   Electronic mail has historically been text-centric.  Extensions such
   as MIME [3] enable the desktop to send and receive multi-part,
   multimedia messages.  Popular multimedia data types include binary
   word processing documents, binary business presentation graphics,
   voice, and video.

   Voice mail has historically been audio-centric.  Many voice-
   messaging systems only render voice.  Extensions such as fax enable
   the voice mail system to send and receive fax images as well as
   create multi-part voice and fax messages.  A few voice mail systems
   can render text using text-to-speech or text-to-fax technology.
   Although theoretically possible, none can today render video.

   An important aspect of the interchange between voice messaging
   services and desktop e-mail client applications is that the
   rendering capability of the voice-messaging platform is often much
   less than the rendering capability of a desktop e-mail client.  In
   the e-mail case, the sender has the expectation that the recipient
   receives all components of a multimedia message.  This is so even if
   the recipient cannot render all body parts.  In most cases, the
   recipient can either find the appropriate rendering tool or tell the
   sender that she cannot read the particular attachment.

   This is an important issue.  By definition, a MIME-enabled user
   agent, conforming to [4] will present or make available all of the
   body parts to the recipient.  However, a voice mail system may not
   be capable of storing non-voice objects.  Moreover, the voice mail
   system may not be capable of notifying the recipient that there were
   undeliverable message parts.

   The inability of the receiving system to render a body part is
   usually a permanent failure.  Retransmission of the message will not
   improve the likelihood of a future successful delivery.  Contrast
   this to the case with normal data delivery.  Traditional message
   failures, such as a garbled message or disabled link will benefit
   from retransmission.

   This situation is fundamentally different from normal Internet mail.
   In the Internet mail case, either the system delivered the message,

Burger and Candell         Expires 5/24/01                    [Page 3]

                  Critical Content of Internet Mail      November 2000

   or it didn't.  There is no concept of a system partially delivering
   a message.

   In addition, the sender would not mind if the system did not deliver
   non-critical parts of a message.  In fact, the sender's user agent
   may be silently adding body parts to a message unbeknownst to the
   sender.  For example, take Microsoft Outlook as a user agent.
   Outlook often will attach a TNEF section or other body parts. If the
   receiving system rejected the message because it could not render
   TNEF, the sender would be understandably confused and upset.

   Thus, there is a need for a method of indicating to a Mail Transfer
   Agent (MTA) or User Agent (UA) that the sender considers parts of a
   message to be critical.  From the sender's perspective, he would not
   consider the message delivered if the system did not deliver the
   critical parts.

   One method of indicating critical content of a message is to define
   a profile.  The profile defines discard rules based on knowledge of
   the user population for silently deleting body parts.  Citing the
   example above, a voice profile can easily declare that MTAs or UAs
   can silently delete TNEF data and yet consider the message
   successfully delivered.  This is, in fact, the approach taken by
   VPIMv2 [5].

   Since one aspect of the issue is deciding when to notify the sender
   that the system cannot deliver part of a message, one could use a
   partial non-delivery notification mechanism [6] to indicate a
   problem with delivering a given body part.  However, this requires
   the user request a MDN.  Moreover, the sender will receive PNDN
   failures for objects the sender may not be aware he is sending.  An
   example would be the TNEF part.

   Summarizing the needs, we need a mechanism that will let the sender
   or sender's UA mark body parts he considers critical to the message
   that the system must deliver.  The mechanism MUST NOT burden the
   sender with failure notifications for non-critical body parts.  The
   mechanism MUST conform to the general notification status request
   mechanism for positive or negative notification.  When requested,
   the mechanism MUST indicate to the sender when a receiving system
   cannot deliver a critical body part.

   In short, we need a method of letting the sender indicate what body-
   parts he considers to be critical.

   This document describes a Critical Content marking mechanism that
   satisfies these needs.  Following the format for Internet message
   bodies [3], this document introduces the Content-Criticality body
   part header.  Values for this header are CRITICAL, NOTIFY, or
   IGNORE.  The receiving MTA or UA will generate a delivery status
   notification (DSN) [7] or Message Disposition Notification (MDN) [8]
   at delivery time or reading time if it receives a request for

Burger and Candell         Expires 5/24/01                    [Page 4]

                  Critical Content of Internet Mail      November 2000

   notification and the (non-)delivery status of the parts marked
   NOTIFY meet the criteria for notification.

   NOTE: A straightforward alternative implementation method for
   marking a body part critical is to use a content-disposition
   parameter called "criticality".

   NOTE: We could have made the critical content indicator a parameter
   to content-disposition.  This has the benefit of being very easy for
   IMAP servers to implement.  In particular, IMAP servers
   automatically present the content-disposition entity when a UA
   requests information on a message.  On the other hand, the UA must
   explicitly request the presence and value of different entities,
   such as content-criticality.  However, implementing the critical
   content indicator as a parameter to content-disposition overloads
   the meaning of the entity.  Moreover, IMAP servers can present, in
   the future, content-criticality by default.  Lastly, most UA's that
   have interest in content-criticality will explicitly request the
   header in any event.

4. Content-Criticality Entity

   The Content-Criticality field is a MIME body part header inserted by
   the sending UA to indicate to the receiving MTA or UA whether to
   consider this body part critical.

   A CRITICAL body part is one the sender requires the receiving system
   to deliver for him to consider the message delivered.

   An IGNORE body part is one the sender doesn't care whether the
   receiving system delivers it or not.  The receiving system can
   silently delete such body parts if the receiving system cannot
   deliver the part.

   The terms "entity" and "body part" have the meanings defined in [3].

   One obvious application of critical content is generating a
   (non-)delivery message.  If the value of the field is IGNORE, the
   receiving MTA or UA MUST NOT generate a notification.  If the value
   of the field is CRTITICAL, the receiving MTA or UA will generate a
   notification, based on the normal notification request mechanisms.
   Normal notification request mechanisms include the SMTP RCPT NOTIFY
   command [9] and the Disposition-Notification-To header [8].

   For example, if the sending system requests a notification, and a
   CRITICAL part fails, the receiving system will generate a NDN for
   the whole message.  Conversely, if only an IGNORE part fails, the
   receiving system will not generate a NDN.

   The next sections examine the actions taken by an MTA or UA given
   the different values of Content-Criticality.

Burger and Candell         Expires 5/24/01                    [Page 5]

                  Critical Content of Internet Mail      November 2000

   NOTE: This implies that the MTA must examine the entire message on
   receipt to determine whether it needs to generate a notification.
   However, the MTA need not examine the message if it knows it can
   store and forward all media types.  Said differently, Internet e-
   mail MTA can, by default, handle any arbitrary MIME-encapsulated
   type.  Some voice mail systems, on the other hand, cannot store
   binary attachments at all, such as application/ms-word.  The voice
   mail MTA, in this example, would be scanning for non-renderable body
   parts in any event.


   "Content-Criticality: CRITICAL" signifies that this body part is
   critical to the sender.

   If the receiving system cannot render or store a body part marked
   CRITICAL, then the entire message has failed.  In this case, the
   receiving system MUST take the appropriate failure action.

   NOTE: We say "appropriate action", because the sender may have
   suppressed all notifications.  In this case, the appropriate action
   is to simply discard the message.

  4.2. IGNORE

   "Content-Criticality: IGNORE" signifies that the sender does not
   care about notification reports for this body part.

   If the receiving system cannot render or store a body part marked
   IGNORE, the receiving system may silently delete the body part.  The
   receiving system MUST NOT return a delivery failure, unless parts
   marked IMPORTANT or CRITICAL have also failed.

  4.3. Other Values

   The receiving system MUST treat unrecognized values as CRITICAL.
   This is to provide backward compatibility with future uses of the
   Content-Criticality entity.

   The most likely new value is IMPORTANT.  An IMPORTANT body part is
   something the sender wants the receiver to get, but would not want
   the message rejected outright if the IMPORTANT body part fails.  A
   receiving system that does not understand IMPORTANT MUST take the
   default value of CRITICAL.  In this case, the MTA or UA MUST take
   the conservative action of rejecting the message.

Burger and Candell         Expires 5/24/01                    [Page 6]

                  Critical Content of Internet Mail      November 2000

  4.4. Summary

   The following table summarizes the actions expected of a conforming
   MTA or UA.

   NOTE: This section is normative: it suggests what to put into the
   DSN or MDN.
                            |    Sending UA Has Marked Body Part   |
                            |      CRITICAL       |     IGNORE     |
       | Body Part is       |                     |                |
       | Deliverable/read   | Appropriate Action  |     ignore     |
       | Body Part is       |                     |                |
       | Undeliverable /    |                     |                |
       |  Unreadable        | Fail Entire Message |     ignore     |

   The distinction between deliverable/read is as follows.  A MTA can
   determine if a body part is deliverable.  If the body part is not
   deliverable and is critical, the MTA could generate a DSN.  An
   example of such a MTA is a content-converting gateway.

   An UA can determine if a body part is readable.  If the body part is
   not readable and is critical the UA could generate a MDN.

   The "Appropriate Action" is the action the MTA or UA would take
   given the context of execution.  For example, if a sender requests
   return receipt and the receiver reads a CRITICAL body part, the
   receiving UA must generate the appropriate MDN (following the rules
   for MDN).  Likewise, if the MTA or UA cannot deliver the body part
   and the body part is critical, the MTA or UA MUST generate the
   appropriate DSN or MDN.

   "Ignore" means the MTA or UA MUST ignore the operation on the body
   part.  The MTA or UA MUST treat the message as if the body part was
   not present in the message.

5. Status Code

   The critical content indication, in itself, does not guarantee any
   notification.  Notification follows the rules described in [7] and

   NOTE: The content of actual DSNs or MDNs are beyond the scope of
   this document.  This document only specifies how to mark a critical
   body part.  On the other hand, we do envision sensible DSN and MDN
   contents.  For example, DSNs should include the appropriate failure

Burger and Candell         Expires 5/24/01                    [Page 7]

                  Critical Content of Internet Mail      November 2000

   code as enumerated in [10].  Likewise, MDNs should include the
   failure code in the MDN "Failure:" field.

   If the receiving system is to generate a notification based on its
   inability to render or store the media type, the notification MUST
   include the status code 5.6.1, "Media not supported", from [10].

6. Backward Compatibility Considerations

   If there are no Content-Criticality entities in the message, the
   default value for Content-Criticality is CRITICAL.  The standard
   notification mechanisms work for sending user agents (UA) that do
   not know about the content notification entity.  All body parts are
   critical, because they have the default marking of CRITICAL.

   If there is at least one Content-Criticality entity in the message,
   the default value for unspecified body parts is IGNORE.  The
   philosophy is that UAs, especially manually constructed messages,
   will explicitly mark the critical body parts.

   NOTE: We could choose the default value for Content-Criticality to
   be IGNORE.  This would make VPIMv2 automatically compliant with this
   document, as VPIMv2 has provision to silently delete undeliverable
   parts.  However, VPIMv2 systems should not be receiving arbitrary e-
   mail from the Internet.  If they do, they should be compliant with
   this series of documents.  By defaulting to CRITICAL, this draft is
   compliant with the rest of the Internet infrastructure.

   NOTE: Some VPIMv2 implementations can receive arbitrary e-mail from
   the Internet.  However, these systems are really acting in the
   capacity of an Internet Voice Mail system.  In this case, one would
   expect the implementation to provide Internet Voice Mail semantics
   to Internet Voice Mail messages.

7. MIME Interactions

  7.1. multipart/alternative

   Content-Criticality is only in effect for the selected alternative.
   If the selected alternative has the critical content indicator, then
   the entire alternative takes on the criticality indicated.  That is,
   if the alternative selected has Content-Criticality: IGNORE, then
   the receiving system MUST NOT generate any delivery notifications
   (MDN, NDN, return-receipt, etc.).

   It is unlikely for a selected alternative to fail, as the receiving
   UA presumably picks the alternative specifically because it can
   render it.

Burger and Candell         Expires 5/24/01                    [Page 8]

                  Critical Content of Internet Mail      November 2000

   If the selected alternative is a message/rfc822 that encloses a
   multipart MIME message or the selected alternative is itself a
   multipart MIME type, the individual top-level body parts follow the
   Content-Criticality mechanism described in this document.

  7.2. multipart/related

   Content-Criticality fits in rather well with the multipart/related
   construction.  For example, consider a multipart/related message
   consisting of a Macintosh data fork and a Macintosh resource fork.
   For a Microsoft Word document, the data fork is likely to be
   critical.  The receiving system can safely ignore the resource fork.

  7.3. message/rfc822

   Content-Criticality only affects the outermost level of the message
   or, in the case of multipart/alternative, the outermost level of the
   selected alternative.  Specifically, the receiving system ignores
   Content-Criticality indicators in embedded body parts.  This avoids
   the situation of a forwarded message triggering or suppressing
   undesired or desired reporting.

8. Implementation Examples

   This section is not a normative part of the definition of Content-
   Criticality.  However, we hope it helps implementers to understand
   the mechanics of the Content-Criticality mechanism.

   We will examine two cases.  They are how a content gateway processes
   a message and how a UA processes a message.

  8.1. Content Gateways

   Content gateways examine the contents of a message from a first
   network before the gateway forwards the message to a second network.
   For the purposes of this example, we assume the second network has
   less capability than the first network.  In particular, we expect
   there will be certain message body types that the gateway cannot
   pass onto the second network.

   Consider a gateway between the Internet and a text-only short
   message service.  A message comes through the gateway containing a
   text part and a tnef part.  The sender marks the text part CRITICAL.
   The gateway, knowing the capability of the short message service,
   silently deletes the non-critical, tnef part, passing the critical
   content to the shore message service network.  Any subsequent
   notifications, such as failure notices or delivery notices, follow
   the normal rules for notification.

   Note the gateway, by silently deleting non-critical content, may
   affect proprietary message correlation schemes.  One can envision

Burger and Candell         Expires 5/24/01                    [Page 9]

                  Critical Content of Internet Mail      November 2000

   the sending UA inserting a body part for tracking purposes.  By
   deleting non-critical content, the content gateway will break such a
   scheme.  If a sending UA understands how to mark critical content,
   it should use Internet standard mechanisms for tracking messages,
   such as Message-ID [11].

   What if no body parts have critical content indicators?  In this
   case, the entire message is critical.  Thus, when the gateway sees
   the tnef part, it will reject the entire message, generating a DSN
   with a status code 5.6.1, "Media not supported".

   Likewise, consider a three part message with a text annotation (part
   1) to a voice message (part 2) with a vCard [12] (part 3).  The
   sender marks the first two parts CRITICAL.  Now, let us assume the
   receiving MTA (gateway) is a voice mail only system, without even
   the capability to store text.  In this case, the gateway (receiving
   MTA) will reject the message, generating a DSN with a status code
   5.6.1, "Media not supported".

  8.2. Non-Traditional UA

   For this example, we will examine the processing of a three-part
   message.  The first part is a text annotation of the second part, an
   audio message.  The third part is the sender's vCard.  The sender
   marks the first and second parts CRITICAL.  In addition, the sender
   marks the message for read receipt.

   For the purposes of example, the telephone user interface (TUI) does
   not perform text-to-speech conversion.  A TUI is a mail user agent
   (UA) that uses DTMF touch-tone digits for input and audio for output

   The TUI is unable to render the first part of the message, the text
   part.  In addition, it is unable to render the third part of the
   message, the vCard part.  Since the sender did not mark the third
   part of the message CRITICAL, the system ignores the failure of the
   TUI to render the third part of the message.  However, since the
   sender did mark the first part CRITICAL, and the TUI is unable to
   render text, the message fails.

   What happens next is implementation dependent.  If the TUI is part
   of a unified messaging system, a reasonable action is to hold the
   message for the user.  The user can access the message at a later
   time from a terminal that can render all of the critical body parts.
   It would be reasonable for the TUI to notify the user about the

   If the TUI is part of a voice messaging system, or if the user does
   not subscribe to a text-to-speech service, a reasonable action is
   for the TUI to return a MDN with the disposition "failed" and the
   failure modifier "5.6.1 (Media not supported)".

Burger and Candell         Expires 5/24/01                   [Page 10]

                  Critical Content of Internet Mail      November 2000

9. Security Considerations

   Receiving systems and users should not place any authentication
   value on the Content-Criticality entity.  Just because a message has
   a particular Content-Criticality value doesn't mean that the message
   really originated at a given type of system.

10. Collected Syntax

   The format of the collected syntax is in accordance with the ABNF of
   [13].  Note that per RFC 2045, none of the strings are case

        "Content-Criticality" ":" notification-type CRLF

        notification-type = "CRITICAL" / "IGNORE"

11. References

   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
      9, RFC 2026, October 1996.

   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.

   3  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.

   4  Freed, N. and Borenstein, N., "Multipurpose Internet Mail
      Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft and
      First Virtual, November 1996.

   5  Vaudreuil, G. and Parsons, G., "Voice Profile for Internet Mail -
      version 2", RFC 2321, Lucent Technologies and Nortel Networks,
      September 1998.

   6  Burger, E., "Partial Non-Delivery Notification", Work in
      Progress, draft-ema-burger-pndn-01.txt, March 2000.

   7  Moore, K. and Vaudreuil, G., "An Extensible Message Format for
      Delivery Status Notifications", RFC 1894, University of Tennessee
      and Octel Network Services, January 1996.

Burger and Candell         Expires 5/24/01                   [Page 11]

                  Critical Content of Internet Mail      November 2000

   8  Fajman, R., "An Extensible Message Format for Message Disposition
      Notifications", RFC 2298, National Institutes of Health, March

   9  Moore, K., "SMTP Service Extension for Delivery Status
      Notifications", RFC 1981, University of Tennessee, January 1996.

   10 Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893,
      Octel Network Services, January 1996.

   11 Crocker, D., "Standard for the Format of ARPA Internet Text
      Messages", RFC 822, University of Delaware, August 1982.

   12 Dawson, F. and Howes, T., "vCard MIME Directory Profile", RFC
      2426, Lotus Development Corporation and Netscape Communications,
      September 1998.

   13 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
      Specifications: ABNF", RFC 2234, Internet Mail Consortium and
      Demon Internet Ltd., November 1997.

12. Acknowledgments

   We'd like to thank Ned Freed for pointing out that this mechanism
   was about criticality, not notification per se.  That insight made
   the concept and descriptions infinitely more straightforward.  If
   it's still confusing, it's our fault!

   We'd also like to thank Keith Moore for helping us tighten-up our

   Dropping the IMPORTANT critical content type took away one of the
   reasons for partial non-delivery notification.  That makes Jutta
   Degener very happy!

   Harald Alvestrand and Chris Newman suggested we add implementation
   examples, which we did.

Burger and Candell         Expires 5/24/01                   [Page 12]

                  Critical Content of Internet Mail      November 2000

13. Author's Addresses

   Eric Burger
   SnowShore Networks
   c/o CRV
   1000 Winter St.
   Waltham, MA  02451

   Phone: +1 703/304-3883

   Emily Candell
   Comverse Network Systems
   200 Quannapowitt Pkwy.
   Wakefield, MA  01880

   Phone: +1 781/213-2324

Burger and Candell         Expires 5/24/01                   [Page 13]

                  Critical Content of Internet Mail      November 2000

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

   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

   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

Burger and Candell         Expires 5/24/01                   [Page 14]