On Wed, 13 Aug 2003, The Purple Streak, Hilarie Orman wrote:
An OPES processor MUST support tracing. You can set policy on who
has authorization to turn on tracing or to see the results, you can
set policy on granularity.
If a given OPES processor implementation is always used deep inside an
OPES system, the above MUST would be an overkill. Moreover, violating
that MUST may not affect interoperability if sufficient tracing is
provided by other entities in the system. I agree that a
general-purpose processor must support tracing (because it may be used
in isolation), but it is wrong to require that from any OPES
processor. Only OPES systems MUST be traceable.
But until this group has defined the tracing mechanism and told OPES
implementors that the facility MUST be present, the rest of it is
irrelevant.
The purpose of this thread is to identify what MUST be traceable. Some
(including myself) insist that only OPES system MUST be traceable
while smaller OPES entities SHOULD or MAY be traceable. Such approach
implies, of course, that a stand-alone, isolated OPES processor MUST
be traceable (because it represents an OPES system).
If you accept that point of view, we can move on to specific tracing
mechanisms (what should be included in the trace and how that
information should be encoded). Your comments regarding optional
tracing and tracing granularity make me thing that our positions are
not that different.
Alex.
P.S.
And I'd like to note that today it is all too common to have airline
baggage problems and be told that your problems are due to TSA and
there is NO way to either trace or complain about lost items.
The above is a self-contradictory statement. If somebody is telling
you that your baggage problems are "due to TSA", then you found
somebody to complain about lost items to! Whether your complaint is
going to be effective is not relevant in the context of this thread.
The mechanism we discuss is not going to eliminate problems; It is
going to identify the responsible party (or partIES, in your version).