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
- Re: TIP - node rules Tom Freund
- FW: TIP - node rules Lele, Vishwas
- RE: TIP - node rules Peter Furniss