mail-ng
[Top] [All Lists]

Re: operator-visible goals?

2004-02-08 13:25:26

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.  


<Prev in Thread] Current Thread [Next in Thread>