CURRENT_MEETING_REPORT_
Reported by Ned Freed/Innosoft International
Minutes of the Notifications and Acknowledgements Requirements
Working Group (NOTARY)
The NOTARY Working Group met on Monday 25 July and again on Tuesday 26
July in Toronto.
The meeting began with a presentation by Keith Moore of the new delivery
status notification format specification
(draft-ietf-notary-mime-delivery-01.txt) that combines elements of both
Keith Moore's and Greg Vaudreuil's earlier efforts. In brief, the
format consists of a new MIME multipart subtype called multipart/report.
This multipart object always contains three parts:
1. An initial part containing human readable text describing the
delivery status notification.
2. A second, machine-readable part containing the specifics of the
recipients and their respective delivery status values.
3. A third part containing either the entire content of the original
message the report applies to or just the headers of that message.
After the presentation, discussion focused on various outstanding issues
in the new document.
o The requirement that the second part be encoded using only 7-bit
characters was discussed and found to be acceptable. The use of
RFC 1522 encoded words in comment fields was recommended as a means
of working around this limitation and the specification will be
altered to allow for this.
o The text describing the distinction between a final MTA and the
remote MTA was thought to be somewhat unclear. Input from the
working group to clarify this text was sought.
o Currently the message-id of the original message is present in the
third part of the status notification. The idea of providing it as
a field in in the second part was discussed but there was no
consensus to support such a change.
o Case sensitivity, whitespace handling, and line continuation issues
were discussed and the specification will be clarified accordingly.
o The specification makes use of an assortment of abbreviations, and
excessive use of abbreviations presents a problem for novice users.
The abbreviation ``MTA'' was found to be quite acceptable and a
better choice than either their expanded form or a less precise
term (e.g. mailer, switch). The abbreviation ``MTS'' was found to
be less acceptable but no acceptable alternative was found.
Others, such as ``rcpt'' for ``recipient,'' will be expanded in the
next draft of the specification.
o There is no place for arrival time information in the second part
at present. An optional field will be added to store this
information.
o The scope of a single status notification (multiple messages,
multiple recipients, neither, or both) was unclear. Additional
prose was crafted to clarify matters so that a single notification
can readily be seen to apply to only a single message but possibly
multiple recipients.
o The list of delivery actions (failed, delayed, delivered, relayed)
is not expandable. The idea of making this list expandable was
raised but rejected.
o The handling of missing or unknown MTS types was discussed. The
group agreed that X- values should be allowed as valid MTS types.
o Security and confidentiality issues were discussed and Gregory
Sheehan provided some additional prose clarifying some of the
concerns in this area.
o Currently there is no field in a delay report that indicates how
long the message can continue to wait before being returned. A
field for this information will be added.
o The first part can optionally be a multipart/alternative object,
allowing for readable status notifications in multiple languages.
The idea of allowing the second part to be a multipart structure as
well was discussed but rejected.
o The handling of status notification requests by mailing list
software was discussed and it was agreed that additional prose
detailing the various available options is needed.
o The insertion of original recipient address information at an
intermediate transfer point is not allowed by the present
specification. There was some agreement that such insertions
should be allowed on the grounds that any earlier address
information is better than nothing, but no agreement as to the
specifics of this was reached.
Discussion of the delivery status notification format specification
concluded with a protracted discussion of error codes. The current
document uses an extended SMTP error code model. Greg Vaudreuil did
some fairly exhaustive cataloguing work to try to come up with a more
comprehensive error code scheme. Greg presented a preliminary version
of this work at the meeting and it was agreed that a more complete
specification would be sent to the list as soon as possible.
There was no consensus as to the best way to handle error codes. It is
generally recognized that the SMTP error codes are being stretched to,
if not past, the breaking point by this work and that some extension
scheme will be needed eventually. However, there was also some
agreement that defining a completely new error code model would be a
major piece of work, possibly beyond the purview of the group, and quite
likely taking far longer than the group would be prepared to wait.
The group concluded with a discussion of future work items. The
notification request SMTP extension was discussed briefly and a new
methodology for controlling return of content was outlined. (No new
draft of this document was available at the time of this meeting.)
The use of this format for read receipts is a definite possibility, and
Greg agreed to put together an initial draft of a specification for read
receipts. It was agreed that standardizing a way to handle read
recipients is a good idea, even though their use in practice is a very
inflammatory matter in some circles.
The handling of so-called ``vacation'' and ``change of address''
messages were discussed, but not extensively due to lack of time. Some
group members saw vacation notices as a subtype of delay notifications,
while some did not. John Myers agreed to begin work on a document
describing vacation messages.