[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: OPES protocol, pre-draft 01
> -----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
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?