RE: TIP - node rules

Peter Furniss <> Fri, 08 August 1997 12:30 UTC

Received: from cnri by id aa05917; 8 Aug 97 8:30 EDT
Received: from ( []) by (8.8.5/8.7.3) with SMTPid IAA21516 for <>; Fri, 8 Aug 1997 08:28:37 -0400 (EDT)
Received: by (8.6.12/suntan5.970212) for tip-relay id FAA27033; Fri, 8 Aug 1997 05:01:47 -0700
Received: from by (8.6.12/suntan5.970212) for <> id FAA27022; Fri, 8 Aug 1997 05:01:42 -0700
Received: from (actually host by with SMTP (PP); Fri, 8 Aug 1997 13:01:20 +0100
Received: by with Microsoft Mail id <>; Fri, 8 Aug 1997 12:57:18 +0100
Message-ID: <>
From: Peter Furniss <>
To: 'Tom Freund' <>
Cc: tip <>
Subject: RE: TIP - node rules
Date: Fri, 8 Aug 1997 12:55:52 +0100
Encoding: 73 TEXT


> > One kind of rule, essential because of the two-pipe mechanism, is 
> > sure the top-node (the travel agent in the requirements example) does 
> > initiate commitment until all the subordinates have registered.
> > Generalising this precisely may not be that easy. A particular might 
>       Doesn't the general rule need to also state that all applications
> messages must have been
> received by a server ... this would be the equivalent of the
> OTS/implicit/checked behavior?

Yes, there has to be a rule corresponding to the one I gave to say "don't 
initiate commitment until all the replies are in, and yes this is the same 
as OTS (or X/Open) checked behaviour. (and the need for it in those shows 
that they are semanticaly two-pipe, by the way)

But the general rule appropriate to the TIP specification (as opposed to 
TIP + P spec) ought to permit cases beyond the request/response paradigm. A 
spec that allowed:  [ P(stuff) means "stuff" is sent as fields of an 
application message ]

A->B:   P(start negotiation, TIP URL (at TM A))
B->A : P (started, price list)
A->B : P( buy N of item X as quoted)
Ap A requests TM to initiate commitment

is safe, because Ap B won't let TM B allow the commitment (and thus send 
PREPARED) until and unless it has purchase secured. There may be another 
application message from B->A, but that could come after the whole 
commitment exchange is over.

I know that is not a client-server example ( Ap B can't be run as simple 
server that exits with ok/not-ok before the commitment starts), but the TIP 
protocol at present would allow it, and I don't think we would want to 
*forbid* it in stating guidance rules for TIP + P specs.  Or would we ?

>      Another case, not specifically on this point but related is
> out-of-sequence messages ... i.e. a failure
> in the server causes the server to restart at some random point in the
> application message flow (btw a
> point which is not covered in the OMG/OTS specification).

(I assume "server" here means the top transactional node, not the leaf 

A server that isn't sure where it is in the transaction surely ought not 
request/allow commitment.

Otherwise, there is a general problem of being sure both sides agree on 
what they are committing to. I think this is probably a TIP + P matter, 
though it links to the security issue (especially the non-repudiation 
needed for e-commerce). A problem I can see is that can be different 
application protocols on the branches (as in the requirements example - the 
airline and hotel booking may use different protocols, or at least 
different URL-in-HTTP specs).  Using the undefined space at the end of TIP 
statement, as Keith suggested, sounds like a good approach.


Peter Furniss Consultants
58 Alexandra Crescent, Bromley, Kent BR1 4EX, UK
Phone & fax : +44 (0)181 313 1833 (or 0181 460 8553 if busy)
Email           :