Dave,
Acking delivery is a UA-MTA (final MTA) request and may possibly be
viewed as involuntary (a point for discussion) by the recipient.
Agreed.
Acking reading is very much by the receiving UA and is almost certainly
entirely at the discretion of the receiver.
Yes, it is done by the receiving UA (or its agent), but different existing
implimentations have different ideas of whether this is at the discretion
of the receiver or automatic. I completely agree with your statement, and
it also corresponds with what is referenced in X.400. Other mail systems
however, deviate from this and automatically generate return receipts with
no way for the recipient to stop the return message. Microsoft Mail and
some of the mainframe mail systems come to mind here.
This was an area that generated a lot of debate (bordering on religous
discussions) last year.
So I suggest that we split the discussion into:
Sending UA and Receiving UA;
This should correspond to the X.400 return receipt element of service.
Sending UA and Mail Transport Service; and
This would correspond to the X.400 delivery notification element of service.
Mail Relay to Mail Relay.
Not sure if this has a parallel in the X.400 world. One suggested method
of implimenting this in the 822 world would be to require enhancements to
SMTP. This was another area that generated a lot of debate last year.
In other words, I'm suggesting that we attack these issues in a somewhat
systematic fashion, rather than entirely piecemeal. This need not delay
the specification of the pieces, but would, I think, be more inclined to
make them fit together better.
I think that this suggestion makes a lot of sense. I don't see any reason
that the three areas described above cannot be dealt with independently
from one another, and hopefully brought to a resolution in a relatively
short period of time.
Question: Is it better to dribble such specs out or to issue an integrated
set, as long as it does not take too long to create a set?
I don't see this as being that difficult a set of items to flush out. One
of the points that was raised many times before was that we should look at
what is defined in X.400 at least as a starting point for our efforts. No
reason to come up with something completely different, just for the sake of
being different.
Back in January when we decided to put the discussion on hold for a while,
I was voluntered to provide a summary of the the previous discussions. That
was not done to avoid further lowering the existing signal to noise ratio on
the ietf-822 list when MIME was being pushed through. If there is an interest
now, I would be happy now to review the archive as well as some private
messages (primarily from Stef and Bob Smart) and report back to the list.
In addition, I can use the previous as well as current discussions as the
basis for a new document, that I will volunteer to write if there is an
interest in the group for doing this.
Best Regards,
Tim Kehres