Re: TIP - node rules

Tom Freund <tjfreund@uk.ibm.com> Fri, 08 August 1997 10:28 UTC

Received: from cnri by ietf.org id aa04065; 8 Aug 97 6:28 EDT
Received: from suntan.tandem.com (suntan.tandem.com [192.216.221.8]) by cnri.reston.va.us (8.8.5/8.7.3) with SMTPid GAA21261 for <ietf-archive@cnri.reston.va.us>; Fri, 8 Aug 1997 06:26:48 -0400 (EDT)
Received: by suntan.tandem.com (8.6.12/suntan5.970212) for tip-relay id CAA16767; Fri, 8 Aug 1997 02:58:28 -0700
Received: from d06lmsgate.uk.ibm.com by suntan.tandem.com (8.6.12/suntan5.970212) for <tip@tandem.com> id CAA16764; Fri, 8 Aug 1997 02:58:25 -0700
Received: from d06lms01.emea.ibm.com by d06lmsgate.uk.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA34320; Fri, 8 Aug 1997 10:55:11 +0100
Received: by UK.IBM.COM (Soft-Switch LMS 2.0) with snapi via D06AU009 id 5060100004788417; Fri, 8 Aug 1997 09:59:07 +0000
From: Tom Freund <tjfreund@uk.ibm.com>
To: p.furniss@ulcc.ac.uk
MMDF-Warning: Parse error in original version of preceding line at ietf.org
Cc: tip@tandem.com
MMDF-Warning: Parse error in original version of preceding line at ietf.org
Subject: Re: TIP - node rules
Message-Id: <5060100004788417000002L072*@MHS>
Date: Fri, 08 Aug 1997 09:59:07 +0000
Mime-Version: 1.0
Content-Type: text/plain

Peter,


> There might also need to be something about the relation between the
> and the particulars would be in the TIP + application protocol P spec
> (which I agree will be bilateral in the first instances), but there are
> some rules that it might be useful to state for guidance.

> One kind of rule, essential because of the two-pipe mechanism, is making
> sure the top-node (the travel agent in the requirements example) does not
> initiate commitment until all the subordinates have registered.
> Generalising this precisely may not be that easy. A particular might be:

      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?

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

Tom Freund