FW: TIP - node rules
"Lele, Vishwas" <Vishwas_Lele@aisdevnet.com> Fri, 08 August 1997 12:21 UTC
Received: from cnri by ietf.org id aa05784; 8 Aug 97 8:21 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 IAA21489 for <ietf-archive@cnri.reston.va.us>; Fri, 8 Aug 1997 08:19:55 -0400 (EDT)
Received: by suntan.tandem.com (8.6.12/suntan5.970212) for tip-relay id EAA25596; Fri, 8 Aug 1997 04:46:27 -0700
Received: from hq1s0002.aisdevnet.com by suntan.tandem.com (8.6.12/suntan5.970212) for <tip@tandem.com> id EAA25591; Fri, 8 Aug 1997 04:46:26 -0700
Received: by hq1s0002.aisdevnet.com with Internet Mail Service (5.0.1458.49) id <Q35NY10K>; Fri, 8 Aug 1997 07:46:33 -0400
Message-ID: <F06EABD8E3DCD011981500805FCC7DFF1FF3@hq1s0002.aisdevnet.com>
From: "Lele, Vishwas" <Vishwas_Lele@aisdevnet.com>
To: "Lele, Vishwas" <Vishwas_Lele@aisdevnet.com>
Cc: "'tip@tandem.com'" <tip@tandem.com>
Subject: FW: TIP - node rules
Date: Fri, 08 Aug 1997 07:46:31 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
> -----Original Message----- > From: Tom Freund [SMTP:tjfreund@uk.ibm.com] > Sent: Friday, August 08, 1997 5:59 AM > To: p.furniss@ulcc.ac.uk > Cc: tip@tandem.com > Subject: Re: TIP - node rules > > 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