Re: operator-visible goals?

> 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.