Hello,
in case some people missed this :-), I wanted to remind you:
- A new IETF working group has been formed, called NOTARY, to start tackling
the problems of delivery notifications in the Internet Mail community
- Its mailing list is notifications(_at_)cs(_dot_)utk(_dot_)edu; E-mail to
notifications-request(_at_)cs(_dot_)utk(_dot_)edu to join.
I enclose the charter below.
I promise: I won't disturb those other lists again with postings abouth
this item!
Harald Tveit Alvestrand
Notifications and Acknowledgments Requirements (notary)
-------------------------------------------------------
Chair(s):
Harald Alvestrand <Harald(_dot_)T(_dot_)Alvestrand(_at_)uninett(_dot_)no>
Ned Freed <ned(_at_)innosoft(_dot_)com>
Applications Area Director(s)
John Klensin <Klensin(_at_)infoods(_dot_)unu(_dot_)edu>
Erik Huizer <Erik(_dot_)Huizer(_at_)SURFnet(_dot_)nl>
Mailing lists:
General Discussion:notifications(_at_)cs(_dot_)utk(_dot_)edu
To Subscribe: notifications-request(_at_)cs(_dot_)utk(_dot_)edu
Archive:
Description of Working Group:
To give the Internet E-mail user better tools to build a system where
the sender of a message can find out what happened to it.
Work items for this group:
- Specify a reporting format that can be used for delivery,
non-delivery and receipt reports. The format should conform to MIME,
and be at least as informative as current examples of non-standardized
non-delivery notifications. This format should be usable as-is in
current E-mail products to replace the current, non-standardized and
sometimes quite cryptic textual non-delivery reports. The drafts by
Keith Moore and Greg Vaudreil are taken as a working basis. (see
DOCUMENT LIST below for details)
- Specify a way for the sender to request that positive delivery
reports should be generated for a message sent via SMTP. The draft by
Keith Moore is taken as a working basis.
- Generate an informational document that gives advice on how to handle
delivery notifications (positive and negative) and requests for them at
boundaries to other mail systems, such as X.400 and PC LANs.
Relationship to X.400 and X.400 gateways:
While the intent of this work includes specification of an
acknowledgement system that can be translated to work across the
821/822/MIME to X.400 boundary, the effort will focus on design from
the former standpoint. That will be followed by changes in the
successor to RFC1327 to match these features, but those changes will be
made as part of the RFC1327 revision process, not by this WG. Of
course, if any features specified by this WG turn out to be impossible
to accomodate in the RFC1327 revision, that would be cause for
reviewing both sets of specifications.
Additional item not on the agenda of this WG:
- Specification of a way in which the sender can request that a receipt
notification ("the recipient has read this message") be sent upon
receipt of the message. The document should identify the controversial
aspects of such a function, and should attempt to specify the function
in a way that minimizes surprise at both the sending and receiving end,
even in the face of varying local policies.
However, the group will, as part of its work, make a recommendation to
the IESG where and how such work should be tackled.
Goals and Milestones:
Apr 94 Submit notification document to IESG for consideration as a Proposed
Standard
Apr 94 Release Request mechanism document as an Internet-Draft
Apr 94 Release Gateway Advice document as an Internet-Draft
Jul 94 Submit Request Mechanism document to IESG for consideration as a
Proposed Standard
Jul 94 Submit Gateway Advice document for publication as an Informational
RFC