Re: RFCS

[Bill Kelly <[e-mail]>]

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: [phone]
Auburn University     Internet: [e-mail]