At 9:36 PM +0100 2/7/04, Hadmut Danisch wrote:
Sorry, but most of the items on your list were implementation
details...
Hadmut is correct here. Of all the ones listed, only one seems like
it would ever appear as a protocol element:
IMO, a protocol is more than data elements and state machines. It is a set of
constraints on implementations, which may or may not be visible on the wire.
All of the goals I mentioned can potentially affect protocol design, whether
or not they affect specific data elements or the way that they are passed on
the wire (and most of those goals at least potentially do that also).
- mail system operators want effective tracing and logging to aid in
problem diagnosis
Significantly, this is not only a goal of mail operators: it is a
requirement for them. The requirement is not only for operational
stability, it is probably a requirement for many legal reasons. It is
also a requirement for users who need to know where a mail got lost
or even delayed. It may be better worded as:
- A message must be able to be traced from the originator to the
intended recipient(s). This tracing is optional; that is, it does not
need to be turned on for every message. The tracing should be able to
be turned on by any entity in the transportation chain (the
originator, and any transmitting hosts).
I don't disagree, but that's only one possible aspect of "effective tracing
and logging". I can certainly imagine others.