Graham, Markus,
see my comments inline.
> I'm a little confused by terminology. The term "data processor" is
> not one I recall from the architecture document. I do recall the
> term "data dispatcher" (or something like that) which seems to be
> what is meant there.
Previous discussions already showed that we need to clarify these terms
in the architecture document - point taken.
I agree that terminology needs be aligned across WG drafts. The
architecture draft defines an "OPES processor" as a network element in
the path between data provider and data consumer. The OPES entities
"data dispatcher" and (local) "OPES services" reside inside the OPES
processor. The protocol requirements draft uses the term "OPES data
processor" in exactly this sense.
> How far is asynchrony to be taken? In particular, I'm wondering if
> it is to be possible for a response to be received on a channel
> different from the request. (E.g. suppose a channel between data
> dispatcher and callout processor fails, and is re-established - can
> an outstanding response arrive on the re-established channel?)
Hm, good question, anybody any opinions on that?
Our main motivation for requiring support for asynchronous message
exchange was to allow for parallel callout transactions over a single
callout channel. I am not yet convinced that we need to extend the
asynchrony requirement to include scenarios like the one you described,
but if there are good arguments for it, then we can certainly do so.
> I think section 5 or section 6 should say something about honouring
> the security/privacy requirements of the endpoints of the
> "original" transfer (the provider and/or consumer). In particular,
> if either party has provided authority for limited kinds of
> processing to be performed, the extent of that authority should be
> communicated to the callout processor.
Isn't that rather a requirement for "endpoint authorization and
enforcement" rather than for the callout protocol?
Yes, IMO the data dispatcher on the OPES processor is responsible for
the enforcement of endpoint authorization and uses the callout protocol
as a means to request the execution of specific OPES services on a
remote callout server. So I don't think there is a need to communicate
endpoint authorizations to callout servers.
-Andre