Re: RFCS

Bill Kelly <kellywh@mail.auburn.edu> Wed, 06 April 1994 13:06 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02788; 6 Apr 94 9:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02784; 6 Apr 94 9:06 EDT
Received: from list.nih.gov by CNRI.Reston.VA.US id aa07402; 6 Apr 94 9:06 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (IBM VM SMTP V2R2) with BSMTP id 1341; Wed, 06 Apr 94 09:04:13 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (Mailer R2.10 ptf000) with BSMTP id 1339; Wed, 06 Apr 94 09:02:40 EDT
Date: Wed, 6 Apr 1994 07:57:44 -0500
Reply-To: IETF TN3270E Working Group List <TN3270E@list.nih.gov>
X-Orig-Sender: IETF TN3270E Working Group List <TN3270E@list.nih.gov>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Bill Kelly <kellywh@mail.auburn.edu>
Subject: Re: RFCS
X-To: TN3270E list <tn3270e@list.nih.gov>
To: Multiple recipients of list TN3270E <TN3270E@list.nih.gov>
In-Reply-To: <9403301630.AA01755@mail.auburn.edu>
Message-ID: <9404060906.aa07402@CNRI.Reston.VA.US>

Hi,

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?

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

Bill Kelly               phone: (205) 844-4512
Auburn University     Internet: kellywh@mail.auburn.edu