Skip to main content

Shepherd writeup
draft-ietf-appsawg-mdn-3798bis

1. Summary

Murray Kucherawy is the document shepherd.  Barry Leiba is the (outgoing)
responsible Area Director.

This is an update to an existing Standards Track document.  The Abstract:

   This memo defines a MIME content-type that may be used by a mail user
   agent (MUA) or electronic mail gateway to report the disposition of a
   message after it has been successfully delivered to a recipient.
   This content-type is intended to be machine-processable.  Additional
   message header fields are also defined to permit Message Disposition
   Notifications (MDNs) to be requested by the sender of a message.  The
   purpose is to extend Internet Mail to support functionality often
   found in other messaging systems, such as X.400 and the proprietary
   "LAN-based" systems, and often referred to as "read receipts,"
   "acknowledgements", or "receipt notifications."  The intention is to
   do this while respecting privacy concerns, which have often been
   expressed when such functions have been discussed in the past.

   Because many messages are sent between the Internet and other
   messaging systems (such as X.400 or the proprietary "LAN-based"
   systems), the MDN protocol is designed to be useful in a multi-
   protocol messaging environment.  To this end, the protocol described
   in this memo provides for the carriage of "foreign" addresses, in
   addition to those normally used in Internet Mail.  Additional
   attributes may also be defined to support "tunneling" of foreign
   notifications through Internet Mail.

2. Review and Consensus

The document received general "Yes, this should happen" support at WG meetings,
but unfortunately very little came in the way of active review.  The working
group appears to have trusted that the authors were doing good work and knew
what they were doing and, if there were any problems found, they were not
reported.  MAAWG was also solicited for comments, but none were received (that
I know of).  In any case, there was no objection to its adoption by and
publication through APPSAWG.

There were no significant points of controversy or other difficulty.

No directorate reviews were solicited, and none seem to be appropriate.

3. Intellectual Property

Of particular note is the following in Section 1:

   This memo is currently marked with the 'pre5378Trust200902' IPR
   statements until a release has been obtained from all previous
   authors and editors of this text.

The IESG may want to wait for this to be resolved before Last Call.  This
writeup is done with it still in the document; I can edit it later if that
condition changes.

4. Other Points

There are no downward references needing special attention during Last Call.

The IANA Considerations were reviewed and look good.  The only point of note
here is MUSTard in the section; there seem to be varying opinions among IESG
members over the years as to whether this is appropriate.

The first word of Appendix A is spelled incorrectly.

The IESG might want to suggest that existing errata against RFC3798 be
highlighted in Appendix A explicitly, by number, assuming they were addressed. 
Previous IESGs have found this useful with my own documents.
Back