Abbie,
I would remove the entire old text you quoted and replace it with
implementation requirements:
For a given trace, an OPES entity involved in handling the
corresponding application message is "traceable" or "traced" if
information about it appears in that trace. OPES entities have
different levels of traceability requirements. Specifically,
o An OPES system MUST add its entry to the trace.
o An OPES processor SHOULD add its entry to the trace.
o An OPES service MAY add its entry to the trace.
An OPES entity MAY manage trace entries of entities it
controls(?). For example, an OPES processor may add
and/or remove callout service entries.
The above needs further polishing of course. The main point is that we
should have specific implementation requirements in this draft, and
reduce abstract talk about what end points would like to see in the
trace. In other words, describe how to build the trace, spend less
time (and no RFC 2919 keywords!) on why we want the trace to look like
that. Make all rationale explanations clearly non-normative.
HTH,
Alex.
On Thu, 28 Aug 2003, Abbie Barbir wrote:
Hi,
I am working my way through the tracing draft.
The next issue is section 2.1 "What is traceable in an OPES Flow?"
The section is below
o The data consumer application end point MUST be able to identify
the OPES processors that have acted on an application message.
o The data consumer application end point SHOULD be able to identify
OPES services (including callout services) that were performed on
request/responses that are part of an application message.
o TBD
o TBD
For a given trace, an OPES entity involved in handling the
corresponding application message is "traceable" or "traced" if
information about it appears in that trace. OPES entities have
different levels of traceability requirements. Specifically,
o An OPES system MUST be traceable
o An OPES processor SHOULD be traceable
o An OPES service MAY be traceable
I need feedback from the WG on this issue. Please send your remark ASAP
Abbie