Re: RFCS Wed, 06 April 1994 15:40 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa05188; 6 Apr 94 11:40 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05184; 6 Apr 94 11:40 EDT
Received: from by CNRI.Reston.VA.US id aa14430; 6 Apr 94 11:40 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (IBM VM SMTP V2R2) with BSMTP id 2065; Wed, 06 Apr 94 11:37:57 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (Mailer R2.10 ptf000) with BSMTP id 2064; Wed, 06 Apr 94 11:00:42 EDT
Date: Wed, 06 Apr 1994 11:03:10 -0400
Reply-To: IETF TN3270E Working Group List <>
X-Orig-Sender: IETF TN3270E Working Group List <>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
Subject: Re: RFCS
To: Multiple recipients of list TN3270E <>
Message-ID: <9404061140.aa14430@CNRI.Reston.VA.US>

> On Wed, 30 Mar 1994, Tom Butts wrote:
> > Section 10.3
> >
> >   "When establishing an SNA session on behalf of a client, the
> >    server will receive a Bind RU from the host application.  It
> >    will also receive a Start Data Traffic RU.  Once both of these
> >    have been responded to positively by the server, it must then
> >    inform the client of the presence of this session by sending it
> >    a data message with the DATA-TYPE flag set to BIND-IMAGE.  The
> >    data portion of this message must contain the bind image exactly
> >    as it was received in the Bind RU that the server accepted on
> >    behalf of the client."
> >
> >   Why not allow the client to see the BIND-IMAGE and respond to it
> >   (positively or negatively)?
> Doesn't that just add a level of complication though?  In either case,
> the server is going to have to examine the Bind to make sure that it's
> acceptable (RU sizes, LU type, etc.).  Is there anything gained by having
> the client also examine the Bind, and then having the client and server
> negotiate to come to agreement on whether to accept or reject the Bind?

I agree that this adds another level of complexity which we do not want nor
This was discussed early in TN3270E discussions and rejected.  Refer to the

> >   ...Also why require the server to keep
> >   a BIND-IMAGE around for each session -- just send it when the server
> >   is going to positively respond to the BIND.
> I'm not sure I understand what you're getting at here.  By "keep a
> BIND-IMAGE around for each session" do you mean for the entire life of a
> given session?  The draft simply says that the server must send a copy of
> the Bind image to the client as soon as an SNA session is established;
> whether or not the server hangs on to a given session's associated Bind
> image after that is, I suppose, up to the server.  Or am I missing your
> point?
> Thanks,
> Bill

I think his point was that you have to hold the BIND-IMAGE around until the
Start-Data-Traffic flows.  I suppose it means that the client cannot send
data traffic to the server until the server can send that data to Vtam.  It
is a tradeoff of whether to buffer the data traffic or to buffer the BIND-IMAGE.
At least the BIND-IMAGE is of a known, finite size, compared to data traffic.

Is that right Tom?