Oskar,
great input, thanks. Just some quick, minor comments:
1. Tracing information has to be provided in-band, I see no
other way to satisfy current architecture requirements. The
OPES architecture states that:
I agree with that. The question is, though, whether the callout
protocol itself will also carry some tracing information, or whether
the callout server will embedd possible tracing information directly
into the application message.
2. We have to decide on the in-band - out-of-band balance for tracing
facilities. Two extreme approaches are:
- in-band data provides only a reference to the point to the facility where
the tracing information may be obtained;
- include all information in-band.
Advantage of the first approach: a) Tracing information may be provided
in application protocol independent manner. b) Level of details is
determined by direct request, lengthy descriptions may be provided
without an impact on the application protocol efficiency.
Disadvantages: a complex identification mechanism is needed to retrieve
application message specific information (like "virus checking applied"), and
getting such simple notification will involve overhead of creating or
keeping an additional connection.
Nice comments. I was tempted to lean towards the first approach with a
refrence to a point for retrieval, but.... Where would such point of
tracing information retrieval be? Would you assume that, for example,
I can retrieve detailed tracing information about a provided OPES
service directly from the callout server the service has been
executed? Such a callout server might very well sit behind a NAT and
might have a non-routable IP adress... If it's not directly on the
callout server, how would the callout server provide the required
tracing information to the other entity?
The second approach provides a kind of opposite advantages and disadvantages:
simple per-message information binding but application protocol may be
cluttered
with excess information that is not relevant to the current session (may be
due to the lack of interest of the participants).
An additional advantage of in-band approach is end-to-end coverage: tracing
information and related directives are available to all OPES flow
participants,
no topology knowledge is required.
Yup, good point, have to agree.
A reasonable combination may include message-related information in band and
a reference to the session-related information. To adjust in-band information
level to the needs of session participants some trace control directives
should
be defined (as an application protocol extensions).
Could you provide a specific example for session-related information
(as opposed to message-related)?
The purpose of identification (exposure) should be defined by the
intended use. Only the information points (where some participant
may call for additional information) and reference points (those that should
be identified in related request, e.g. to the center of authority) should be
exposed. If there are points that may accept directives (e.g. privacy
directives) - they should be exposed.
>
Also session participants should be notified about the center of
authority for the OPES server.
> [...]
Can we develop a few example scenarios that illustrate the various
concepts of "information points", "reference points", "identifier",
etc., and how they play together?
Any such explicitly identified point may be on the path or out of the path,
this should not be a factor. Points on the path are exposed by IP,
as according to IAB requirements connections are terminated at these points.
The IAB considerations state that "the OPES intermediary must be
explicitly addressed at the IP layer by the end user", which
translates that (only) the first "hop", i.e. the first OPES
intermediary on the path, has to be addreessable explicitely. Others
might very well sit behind a NAT or so.
Information about services should be provided in-band and should uniquely
identify the service provider and service type, but not the service point
(OPES
server). This makes service information location independent and facilitates
system reconfiguration, including failover and recovery: agreements and
parameters
may be transferred to another OPES server (within the same trust domain)
without
renegotiation with end-point.
If we don't identify the exact server, how would a service provider
trace a problem I report to him? How would he know whichserver to
check, if I tell him that something went wrong and check him to ask
this? With email, for example, I know exactly which mail servers have
been o nthe path, thus being able to trace down to the exact server.
Direct point exposure (let's say by inclusion of URL into the tracing
information)
raises a question about out-of-band protocol used to access this point.
SOAP looks like a good candidate for that.
Do we have to decide on a specific protocol to be used for this
purpose, or can we leave this open and just indicated the protocol to
be used (e.g. withing the embedded URI).
-Markus