Subject: MIB & Associated pairs

From: "Greg Rickard" <[email-masked]>
Date: Thu, 25 Jun 1998 12:32:18 -0500

The TN3270E-MIB does not allow associated terminal-printer pairs or differentiate between generic and specific devices.  Both concepts are discussed in section 7.1.1 of RFC 2355.

We brought these deficiencies to the attention of the group on Monday, 22 June, but have not gotten any response.  While I understand the reluctance to modify the draft during its final call, ignoring these shortcomings will not make them go away.

We came across these problems implementing the MIB on our server, which has always supported associated printing.  If not addressed, they will prevent the MIB from being fully capable of managing a TN3270E server.

Greg Rickard
Director of Product Development
Data Interface Systems Corporation
(512) 335-8200

---

From: Michael Boe <[email-masked]>
Date: Thu, 25 Jun 1998 15:29:29 -0700 (PDT)

On 25-Jun-98 at 15:27, Greg Rickard ([email-masked]) wrote:
> >In making this case, understand that the server need not store or be
> >cognizant of such associations before client connect-time.
>
> The server MUST know of the association before client connect time.  How
> else is the server to fill the ASSOCIATE request?

Not to rain on anybody's future server designs :-), but a-priori knowledge by
the server of the association is not necessary.  Consider the possible server
design where the TN Server has a side-channel to the host whereby the
association is done when the printer is requested: the TN Server queries the MF
as to what what the association is, and then picks the device. The only
a-priori knowledge the server must have here is that a certain group of LUs
must be eligible for association.  This is can be considered "late-binding."
Indeed, it might be very late-binding at the MF itself:  the association might
not be made until after the security/authorization checks have been passed and
appropriate information retrieved from the MF or MF-application authorization
database.

Not quite so late a binding, but still so late as to be unusable by "static
configuration" scanners is where the association is known only from the time
the first screen in the associated group is allocated to the time where the the
last screen in the group is deallocated by a particular TN3270E client.

That's a "host-hugger" server example.  It's pretty easy to imagine
branch-office servers using network-directory-access methods such as
NT/lan-manager/NetWare/NIS+ to do the same thing. MS SNA Server, for instance,
already does this.

But that's not to say that such a table shouldn't exist in the MIB as an
optional table indicating some a-priori configuration for those servers that
use such. Nor is it arguing against adding row-elements to connections that
"point" to the associated printer connections during the lifetime of the
associated printer connection.

Comments from the wider community, please.

>
> Abbreviated from a 2355 example:
>
>    Client:  IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-2 CONNECT
>                    termxyz IAC SE
>    Server:  IAC SB TN3270E DEVICE-TYPE IS IBM-3278-2 CONNECT
>                    termxyz IAC SE
>
>    Client:  IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3287-1
>                    ASSOCIATE termxyz IAC SE
>    Server:  IAC SB TN3270E DEVICE-TYPE IS IBM-3287-1 CONNECT
>                    termxyz's-prt IAC SE
>
> The only way the server knows to fill the "ASSOCIATE termxyz" request with
> device "termxyz's-prt" is an association between "termxyz" and
"termsxyz's-prt" established before the connect.  "There should be a unique,
one-to-one mapping between a terminal and its associated printer."  I don't
think anyone proposes that the "'s-prt" extension on the device-name is the
magic that associates these two devices.
>
> Likewise for the generic/specific indicator.  The server must know if a
> device is eligible for a generic attach request:
>
>    If a TN3270E server wishes to support traditional tn3270 clients, it
>    must maintain a set of terminal device-names that can be used to
>    satisfy requests from such clients for terminal sessions.  This same
>    pool could be used to satisfy generic requests for terminal sessions
>    from TN3270E clients.
>
> Once again, I don't think that the format or keywords contained in the
> device-name or pool name of the device is strong indication that any given
device is generic or specific.

Yes, that's true. It's certainly an area that was skipped over. But why is
that?  Either nobody cared, or it was (silently) put in the too-hard basket. I
think probably the latter. Why? Again, authorization issues make it difficult
to see how such an indicator could be useful.  An LU might be eligible to fill
a "generic" request from a client, but the pool of clients allowed such a
privilege might be very restricted. So what would such a "generic-eligibility"
indicator mean? I don't think that's quite good enough, but perhaps there's a
set of descriptors that can (a) meaningfully describe how an LU can be
allocated, (b) isn't overlapping in definition, and (c) is known prior to
client connect time.

Here's a stab at it:  two independent sets of descriptors indicate the methods
by which an LU may be allocated. The first set is a single bit:

Allocation Authorization Type:
   [auth-further]:     LU may only be allocated by clients authorized beyond
the authorization normally required.  If this bit is set to zero, then the LU
can be allocated by any client authorized to request any device of this LUs
allocation-type (see below).

Allocation Type:
   [generic-eligible]  LU may be allocated by the server to fulfill a generic
LU request.

   [specific]          LU may only be allocated via a REQUEST DEVICE-NAME or
ASSOCIATE subnegotiation by the client.

   [associate]         LU may only be allocated via an ASSOCIATE subnegotiation
by the client.

Is this simple enough? Does it completely (and usefully!) describe how an LU
can be allocated?  And is do servers know this information well before a client
has actually attempted to connect to the LU in question?

[...snip]

/msb

>
> Greg Rickard
>
>
> *********** REPLY PARTITION ***********
>
> On 6/25/98, at 10:58 AM, Michael Boe wrote:
>
> >I've not had time to look at any of the "hard" mail yet; have been out of
> >town. I'll look soon. In the meantime, can you make a case for why
> >distinguishing generic & specific devices in the MIB is useful?  Ditto for
> >terminal-printer pairs.  In making this case, understand that the server
> >need not store or be cognizant of such associations before client
> >connect-time.
> >/msb
> >
> >On 25-Jun-98 at 13:34, Greg Rickard ([email-masked]) wrote:
> >> The TN3270E-MIB does not allow associated terminal-printer pairs or
> >> differentiate between generic and specific devices.  Both concepts are
> >discussed in section 7.1.1 of RFC 2355.
> >>
> >> We brought these deficiencies to the attention of the group on Monday,
> >> 22 June, but have not gotten any response.  While I understand the
> >> reluctance to
> >modify the draft during its final call, ignoring these shortcomings will
> >not make them go away.
> >>
> >> We came across these problems implementing the MIB on our server, which
> >> has always supported associated printing.  If not addressed, they will
> >> prevent
> >the MIB from being fully capable of managing a TN3270E server.
> >>
> >> Greg Rickard