Graham,
thanks for your comments. Let me offer some responses until the
co-authors get a chance to reply.
> 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.
The term "data processor" is used here in the sense as introduced in
Figure 2 of the architecture document. Looking at Figure 3 in the
architecture document, "data processor" refers to the box including
the "data dispatcher", i.e. the "data dispatcher" is part of a "data
processor". So, I believe the usage of "data processor" is correct here.
> 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?
> The sentence "At a minimum..." seems to be a bit vague, in the
> sense that it's not really possible to determine whether it is
> satisfied by any given callout protocol. Especially given that the
> callout protocol is required to be application protocol agnostic.
> I'm not sure that anything significant would be lost by deleting
> this sentence.
I agree that this is quite vague, we cannot really give any concrete
numbers. The feeling was that it would be nice to have some
comparison, trying to make the point that the callout protocol itself
should not slow down the interaction between client and server
significantly. Maybe that's already captured in the first sentence,
and we don't realy need the second one. But I believe it's important
that we have some requirement(s) about the expected performance of the
callout protocol - otherwise we could end up with a protocol that
slows down the communication so that's it's basically unusable.
> 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? The callout
protocol itself does not care about it, it simply does what the "data
processor" asks it to do. Of course, the data processor would have to
implement the kind of considerations you mention, probably in form of
policies/rules. This has to be written down in the ""endpoint
authorization and enforcement requirements". Or do you see a direct
impact on the callout protocol itself?
> Related to this, the callout processor should return an indication
> of the processing steps performed so that the OPES architectural
> requirements for tracing can be satisfied.
Yes, agreed. I believe this is covered in Section 3.11 when saying
"The OPES callout protocol MUST also allow OPES data processors to
comply with the tracing requirements of the OPES architecture as laid
out in [1] and [5]. This implies that the callout protocol MUST
enable a callout server to convey to the OPES data processor
information about the OPES service operations performed on the
forwarded application message."
Cheers,
Markus