Subject: draft-burger-vpim-cc-00.txt

From: [email-masked]
Date: Tue, 6 Jun 2000 08:37:39 -0400

Network Working Group                                           E. Burger
Internet Draft                                   Centigram Communications
Document: draft-burger-vpim-cc-00.txt                          E. Candell
Category: Standards Track                        Comverse Network Systems
Expires in six Months                                        June 6, 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
   progress."

   One can access the list of current Internet-Drafts at
   http://www.ietf.org/ietf/1id-abstracts.txt

   One can access the list of Internet-Draft Shadow Directories at
   http://www.ietf.org/shadow.html.

1.
  Abstract

   This document describes a mechanism for identifying the critical
   content body parts of a multi-part Internet mail message.

                           Expires 12/6/00                    [Page 1]

                  Critical Content of Internet Mail          June 2000

Table of Contents

1.ABSTRACT ...........................................................1
2.CONVENTIONS USED IN THIS DOCUMENT ..................................2
3.INTRODUCTION .......................................................2

4.CONTENT-NOTIFICATION ENTITY ........................................5
4.1. NOTIFY ..........................................................5
4.2. PARTIAL .........................................................5
4.3. IGNORE ..........................................................6
4.4. Other Values ....................................................6
4.5. Notification Precedence .........................................6
5.BACKWARD COMPATIBILITY CONSIDERATIONS ..............................6
6.SECURITY CONSIDERATIONS ............................................7

7.COLLECTED SYNTAX ...................................................7
8.REFERENCES .........................................................7
9.ACKNOWLEDGMENTS ....................................................8
10. AUTHOR'S ADDRESSES ...............................................8

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

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

Burger and Candell         Expires 12/6/00                    [Page 2]

                  Critical Content of Internet Mail          June 2000

   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,
   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

Burger and Candell         Expires 12/6/00                    [Page 3]

                  Critical Content of Internet Mail          June 2000

   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 originally
   proposed for VPIMv3 [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 indicating what sort of delivery
   notification the sender requires on a per-body part basis.

   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-Notification body
   part header.  Values for this header are NOTIFY, PARTIAL, or IGNORE.
   The receiving MTA or UA will generate a DSN or PNDN if it receives a
   request for notification and the (non-)delivery status of the parts
   marked NOTIFY meet the criteria for notification.  Likewise, the
   receiving UA will generate a MDN or MNDN if it receives a request
   for notification and the (non-)delivery status of the parts marked
   NOTIFY meet the criteria for notification.

   <<<EDITOR'S NOTE: We don't have an ID for MNDN yet, but it will look
   like PNDN.  Stay tuned.>>>

Burger and Candell         Expires 12/6/00                    [Page 4]

                  Critical Content of Internet Mail          June 2000

4.
  Content-Notification Entity

   The Content-Notification 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 when 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 NOTIFY,
   the receiving MTA or UA MUST generate a notification, based on the
   normal notification request mechanisms.  Normal notification request
   mechanisms include the SMTP RCPT NOTIFY command [7] and the
   Disposition-Notification-To header [8].

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

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

   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, an Internet e-
   mail MTA can, by default, handle any arbitrary MIME-encapsulated
   type.  Some voice mail systems, on the other hand, cannot even store
   binary attachments, such as application/ms-word.  The voice mail
   MTA, in this example, would be scanning for non-renderable body
   parts anyway.

  4.1. NOTIFY

   "Content-Notification: NOTIFY" signifies that this body part is
   critical to the sender.  The sender wishes to receive notification
   reports for this body part.

   If the receiving system cannot render or store a body part marked
   NOTIFY, 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. PARTIAL

   "Content-Notification: PARTIAL" signifies that the sender wishes to
   receive notification reports for this body part.

   If the receiving system cannot render or store a body part marked
   PARTIAL, the receiving system MUST take the appropriate failure
   action.  It is important to note that if the system is successful in
   delivering other critical body parts, then the message delivery is

Burger and Candell         Expires 12/6/00                    [Page 5]

                  Critical Content of Internet Mail          June 2000

   successful.  In this situation, the receiving system MUST return a
   partial non-delivery notification [6].

  4.3. IGNORE

   "Content-Notification: 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 PARTIAL or NOTIFY have also failed.

  4.4. Other Values

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

   <<<ALTERNATIVES:

   IGNORE: If I don't recognize something, ignore it!

   NOTIFY: Future values are more likely to involve some sort of
   notification, rather than non-notification.  However, if the
   notifications are more sophisticated than NOTIFY, senders may be
   miffed they didn't get the processing they expected.

   Reject the Message: This would be too extreme!  Yes, it would weed
   out non-conformant sending UAs, but this would really piss off
   users.

   So far, we have one vote for IGNORE, as that would be compatible
   with VPIMv2.
   We have one vote for PARTIAL, as that would provide forward-
   compatibility with future uses of Content-Notification.
   We expect this to be a point of discussion on the list.

   End of ALTERNATIVES>>>

  4.5. Notification Precedence

   <<<We'll fill-in this in the next draft.>>>

5.
  Backward Compatibility Considerations

   If there are no Content-Notification entities in the message, the
   default value for Content-Notification is NOTIFY.  The standard
   notification mechanisms work for sending user agents (UA) that do

Burger and Candell         Expires 12/6/00                    [Page 6]

                  Critical Content of Internet Mail          June 2000

   not know about the content notification entity.  All body parts are
   critical, because they have the default marking of NOTIFY.

   If there is at least one Content-Notification 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-Notification 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 NOTIFY, this draft is
   compliant with the rest of the Internet infrastructure.

6.
  Security Considerations

   We anticipate no new security issues beyond those already addressed
   by the notification RFCs.

7.
  Collected Syntax

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

        "Content-Notification" ":" notification-type CRLF

        notification-type = "NOTIFY" / "PARTIAL" / "IGNORE"

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

Burger and Candell         Expires 12/6/00                    [Page 7]

                  Critical Content of Internet Mail          June 2000

   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 3", <draft-ema-vpimv3-00.txt>, Work in Progress, expired.

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

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

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

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

9.
  Acknowledgments

   Coming soon!

10.
   Author's Addresses

   Eric Burger
   Centigram Communications Corporation
   Maryland Technology Center
   1375 Piccard Dr., MS 150I
   Rockville, MD  20850-4311
   USA

   Phone: +1 301/212-3320
   Email: [email-masked]

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

   Phone: +1 781/213-2324
   Email: [email-masked]

Burger and Candell         Expires 12/6/00                    [Page 8]

                  Critical Content of Internet Mail          June 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 which 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 and Candell         Expires 12/6/00                    [Page 9]

---

From: Keith Moore <[email-masked]>
Date: Tue, 06 Jun 2000 19:38:59 -0400

immediate comments on the criticality flag:

1. I'd far rather see this as a content-disposition parameter, but
   this might be just a matter of taste.

2. for DSNs, the interactions between notify/partial/ignore and the 
   NOTIFY= SMTP parameter might need to be spelled out, preferably 
   in a table.  the current prose about this seems muddy.

3. "notify" and "partial" seem likely to invite confusion between
   SMTP NOTIFY and the "partial" message delivery status.

   something like "critical", "semi-critical", "not-critical"
   might work better...but these are not quite right either.
   (what did X.400 use?  I don't have it handy right now...)

4. when to issue a DSN vs. when to deliver an MDN needs to be 
   clarified - you send a DSN if the problem is detected at
   delivery time, you send an MDN if the problem is detected
   when the message is read.

5. there need to be DSN and MDN extensions to indicate which parts 
   could not be converted/presented.  this would presumably include 
   new DSN status codes and new per-recipient, per-body-part, DSN 
   fields to indicate the failure type and error message.

   (*please* don't invent new report types for these!)

Keith

p.s. both of these proposals really need to be reviewed by MIME folks -
the mailing list is [email-masked].

---

From: [email-masked]
Date: Tue, 06 Jun 2000 21:21:42 -0700 (PDT)

>    this might be just a matter of taste.

I agree, and it isn't simply a matter of taste. There is already machinery
deployed to handle content-disposition; using it is a real savings for
implementors.

>    in a table.  the current prose about this seems muddy.

Agreed as well.

>    SMTP NOTIFY and the "partial" message delivery status.

Yes, these aren't good choices. But IMO this goes even deeper -- this document
puts criticality solely on the axis of delivery notification generation. From
the Introduction:

I think this misses the point rather badly -- notifications aren't the
immediate issue,  the issue is whether or not the message should even be
delivered, with notifications only being a consequence of that choice.

I could also see a criticality flag of this sort affecting where a message is
or isn't auto-forwarded by a smart delivery system.

I would therefore suggest putting this along the axis of criticality, not along
the axis of notifications. One you do this all sorts of choices suggest
themselves (e.g., essential/useful/nonessential).

>    (what did X.400 use?  I don't have it handy right now...)

FWIW, I think you're confusing X.400's tri-state attributes (priority
nonurgent, normal, urgent and sensitivity personal, private,
company-confidential) with X.400's criticality flag. The former are attributes
of a message; the latter is a boolean attribute of envelope extensions. That
is, in X.400 you can mark an envelope extension as to whether or not
understanding it is critical for message processing, and it is a yes/no choice.
There's no way in X.400 to mark anything in the header or body in a similar
fashion, and no associated useful terms in any case.

>    when the message is read.

Right.

>    (*please* don't invent new report types for these!)

I believe this is already being done in draft-ema-vpim-pndn-01.txt, although I
think this document needs work. It doesn't define a new report type (although
there is an apparenent remnant of when it did so in the table of contents
referring to message/partial-delivery-status).

FYI, issues I see in draft-ema-vpim-pndn-01.txt include:

(1) Use of separate sections in the delivery status area for different
    parts as opposed to different recipients isn't backwards-compatible
    and is likely to cause trouble with existing handlers of these things.
    (The MIXER mapping to X.400 certainly breaks in this case, for example.)
    I'd rather see everything pertaining to a single recipient in a single
    section.

(2) The combination of a 5.x.y status with an action of "delivered" isn't
    good either, although I'm not sure how to resolve it.

(3) Content-ids have the same syntax as message-ids, more or less. This
    document presents them as simple strings.

(4) The dependency on content-ids is worrisome. Yes, any positional reference
    may be thrown off by conversions and who knows what else, but some
    indication may be better than nothing.

				Ned