Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!lll-tis!CUNYVM.CUNY.EDU!pv%sun
From: pv%sun@CUNYVM.CUNY.EDU
Newsgroups: comp.protocols.iso.x400
Subject: Is P3 implementable?
Message-ID: <8811142313.AA00822@polya.sun.com>
Date: 15 Nov 88 13:52:00 GMT
Sender: root@tis.llnl.gov
Distribution: inet
Organization: The Internet
Lines: 46
Approved: post-x400@tis.llnl.gov

>Posted-Date: Mon, 14 Nov 88 15:13:22 PST

I've been looking at 1988 P3.  Are there any co-ordinating rules for
P3?  May both ends of a P3 association be acting as masters
simultaneously?  Must each end act as both master and slave
simultaneously?

For example, can an MTS user invoke a DeliveryControl operation on an
association created by an MTA?  Can it do so at any time?  Must the MTA
be prepared to handle a DeliveryControl operation at any time?  In
fact, must the MTA be prepared to handle the whole range of operations
such as MessageSubmission, CancelDeferredDelivery and Register?

Similarly, may an MTA invoke operations like MessageDelivery on an
association created by the MTS user?  Must all MTS user programs be
written to handle SubmissionControl, MessageDelivery and
ChangeCredentials at any time even on associations initiated by it?

There are two issues here that make implementation tricky.  First, the
initiator may not be equiped to handle the operations invoked by the
responder.  For example, consider a program doing ChangeCredentials.
This MTS user would want to bind to the MTS, do its operation and
unbind.  But once the bind has happened, it appears legal for the MTA
to do MessageDelivery or any of its other operations which this poor
MTS user would have to handle.  While some of these operations can be
blocked by using control operations, not all can.

Second, the dual master-slave relationship implies that a program must
be prepared to handle incoming invoke indication at any time even while
one of its own operations is in progress.  For example, if a MTA has a
message for some MTS user, the MTA has to be prepared to handle a
DeliveryControl operation before, during or after its MessageDelivery
operation.  A simple, "send message and wait for response" paradigm
won't hack it.

The use of RTS turn management allows for synchronization of a half
duplex session but provides no help above ROSE.  An entity cannot
postpone responding to an invoke until its own invoke is completed
because, if both entities did so, deadlock would result.

So what are people doing?  Has anybody implemented full P3?

BTW, does P3 use ROS Operation Class 1 or 2?  E.g. must the MTA wait
for one MessageDelivery operation to complete before invoking another?

Pete