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, 8 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