ietf-openproxy
[Top] [All Lists]

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

2002-05-29 06:38:46

This mostly looks pretty reasonable to me.  A couple of comments below.

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.


3.12 Asynchronous Message Exchange

   The OPES callout protocol MUST support an asynchronous message
   exchange between an OPES data processor and a callout server.

   In order to allow asynchronous processing on the OPES data processor
   and callout server, it MUST be possible to separate request issuance
   from response processing.  The protocol MUST therefore allow multiple
   outstanding requests and provide a method to correlate responses to
   requests.

   Additionally, the callout protocol MUST enable a callout server to
   respond to a callout request before it has received the entire
   request.

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?)

4.1 Protocol Efficiency

   The OPES callout protocol SHOULD be efficient in that it minimizes
   the additionally introduced latency, for example by minimizing the
   protocol overhead.  At a minimum, the callout protocol SHOULD satisfy
   the performance requirements of the application-layer protocol whose
   messages are forwarded from the OPES data processor to the callout
   server.

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.

6. Security Considerations

   The security requirements for the OPES callout protocol are discussed
   in Section 5.

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.

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.

#g


-------------------
Graham Klyne
<GK(_at_)NineByNine(_dot_)org>