RE: OPES protocol, pre-draft 01

["Oskar Batuner" <batuner@xxxxxxxxx>]

> -----Original Message-----
> From: owner-ietf-openproxy@xxxxxxxxxxxx
> [mailto:owner-ietf-openproxy@xxxxxxxxxxxx]On Behalf Of Alex Rousskov
> Sent: Monday, February 24, 2003 5:54 PM
> To: OPES WG
> Subject: RE: OPES protocol, pre-draft 01
>
>
>
> On Mon, 24 Feb 2003, Oskar Batuner wrote:
>
> > Here I'm looking at transaction boundaries that are defined by
> > <xaction-start> and <xaction-end>. You are right that in general
> > it is not necessary to limit the right to terminate transactions to
> > the server. But in the OPES case
> >
> > > > ... processing is initiated by incoming
> > > > OPES processor messages (from producer or from consumer) ...
> >
> > In such context OPES server has no apparent reason to terminate
> > message processing - there are no possible events associated with
> > this transaction coming from the OPES flow. After initial message is
> > received and service is initiated only service application (in this
> > case callout server) knows that transaction processing is finished.
> > At least for the normal processing. There may be abnormal situations
> > (e.g. OPES data consumer has closed the connection) when OPES
> > processor becomes not interested in processing results and may wish
> > to stop request processing to avoid resource wasting.
> >
> > Maybe we should have a special message for abnormal transaction
> > termination?
>
> Abnormal termination is exactly what motivated me to allow
> <xaction-end> messages to be sent by OPES processor. We could have a
> special <xaction-abnormal-end> message, but
>
> 	- the recipient (callout server) most likely does not
> 	  really care why the transaction is suddenly ended; the
> 	  reason field can be used for detailed logging/debugging
> 	  if desired
>
> 	- the reason field(s) can already be used to indicate
> 	  the kind of termination through application-specific
> 	  status codes (normal, client errors, internal errors,
> 	  overload, etc.)
>
> 	- there might be application protocols where "normal"
> 	  termination can be detected by OPES processor;
> 	  the notion of "normal termination" is, after all,
> 	  application [protocol] specific.
>
> Overall, a more general <xaction-end> message seems to cause no
> problems while having possibly desirable side-effects. Any objections?

Abnormal termination is different from normal termination (and
all other normal messages) in the sense that it switches context from
message processing to termination and cleanup. I think this difference
justifies presence of a separate message. In some sense it is a
question of preferences - as you have correctly pointed out
difference between normal and abnormal termination messages
can be determined by some additional reason code in the same
message. I prefer to keep an explicit difference. Another
difference is that abnormal termination message may arrive
at any moment, other messages are limited by the processing
context (protocol state machine).

>
> > In the architecture draft we are always separating OPES flow from
> > the metadata exchange. We state that metadata transfers are
> > out-of-scope for the OPES architecture. Of cause this statement does
> > not preclude using the same callout protocol - or any other - for
> > the metadata transfer. But if we permit mixing OPES data and
> > metadata (like preferences, etc.) on the same channel - well, this
> > looks at least inconsistent.
>
> I understand the intent -- keep OPES focused and small. Is there a
> precise definition of "metadata" or "OPES flow" though? For example,
> most will probably agree that service ID(s) should be attached to
> <xaction-start> messages, but many will consider a service ID to be
> METAdata because the application protocol does not carry those.
>
> Another example: transferring a static set of preferences and rules
> should probably be out of OPES protocol scope. On the other hand,
> sending transaction-specific rules that affect, say, service
> application order may be in OPES scope. Same for specific user
> preferences and/or credentials? It seems to me that metadata specific
> to application transaction may be in scope and may be transmitted
> in-band.

Yes, these is why I'm asking this question. We may go both ways.
In many cases it may be very natural to transfer in-band metadata related
to the current processing context. But as soon as you allow in-band metadata
transfer you may not set a clear border - what is specific to the transaction
and what is not. If we are allowed to send user preferences when message
to/from that user is processed - why not send to remember these preferences
on callout processor? And if callout processor keeps user's data - why not
to send it them just once, in advance?

Real decision is either yes (allow metadata transfer in-band) or no. Metadata
transfer in a limited context is not a consistent architectural decision: all
related protection measures mandated by the architecture MUST be implemented,
but if they are - why to limit the context?

Oskar