ietf-openproxy
[Top] [All Lists]

Re: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-re qs-00.txt

2002-05-30 10:43:05

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