[586] in Enterprise Print Delivery Team
Re: Enterprise Printing Delivery, Meeting Notes, 10/11/2000
daemon@ATHENA.MIT.EDU (Lynne E. Durland)
Thu Oct 12 11:04:23 2000
Message-Id: <4.3.2.7.2.20001012104504.00c2f620@hesiod>
Date: Thu, 12 Oct 2000 11:07:57 -0400
To: David F Lambert <LAMBERT@MITVMA.MIT.Edu>,
Enterprise Printing Delivery Project Team <printdel@MIT.EDU>
From: "Lynne E. Durland" <durland@MIT.EDU>
In-Reply-To: <10010121219.AA27323@MIT.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Stuff deleted......
>1) enhance the chart at the URL above by including the other two
> user functions we identified - view/manage one's own print queue and
> event notification (job printed)
>2) document our decisions for how we provide these functions to the
> desktop; would suggest doing this right in the chart document itself
>3) where you say that klpr can authenticate between the user and
> printer, I think it's more accurate to say between the user and
> print server (Rocklyn & Lynne please confirm)
Rocklyn is the expert in this one...I believe he did say to the printer not
the server...and it is a limited number of printers that actually use the
authentication.
>4) in the browser option for submit, I'd suggest moving the bullet referencing
> looking at the whole queue vs an individual's queue from the disadvantages
> column to the advantages column since we can have IBM code the browser
> interface to do what we desire (look at one's own queues only)
Please don't lose sight of the fact that the "submit through the browser"
option requires the extra step in the print process....from your
application print to a file, then go to browser, find file, send to
IPM. This is the advantage of the port monitor, it eliminates the step of
saving to file, but with the apparent elimination of the mac development
work to make the port monitor for the mac.....it will not be available for
the mac. One of the advantages of the port monitor is that it would use
kerberos tickets to authenticate use so the nt problem would not happen.
>5) I would add some additional words under the disadvantage for select
> which references the need for DCE for securing the interface - something
> like "would require code modification to use select with our Kerberos
> environment".
>6) Is the last disadvantage listed with the browser option accurately
> stated? Isn't the problem really reversed - a user logged into NT
> as administrator submits a print but then can't view it from the
> browser because the certificate used is associated with the user's
> personal kerberos principle? Do users ever get a certificate based
> on an NT administrator's kerberos principle - is there such a scenario?
Good catch Dave,
I was so glad to see the issue presented I didn't read it closely
enough. With LPR in nt, the userid associated with the print file is how
you logged into nt, the browser using certificates, (and the certificates
are based on the kerberos principal), would not be able to see the print
file since it would appear in the queue as owned/submitted by
administrator. This is assuming that the browser interface for end users
would be only allowing you to view your own print files, not everything
waiting to print.
I was thinking I would try to talk to Jonathan Hunt about the KLPR for
windows, for several reasons:
to find out when KLPR is planned to be released
to find out if KLPR in nt would prevent the problem we have been
discussing, namely would it use the kerberos ticket for submission name on
a print file or if it would still rely on the nt login.
How it would interact with choosing printers
and generally to just understand the whole of KLPR more fully.
>If we didn't really agree to it yesterday, I propose we use/allow both K/LPR
>and the browser interface for submitting files to IPM. Neither option
>introduces a new desktop application. Do we have agreement on this?
I fully support the KLPR/LPR decision. I have a few reservations about the
browser submission. I am not worried about power users, but question how
many people would use the option because of the extra steps, and the added
work of getting that information communicated effectively.
>A reminder that we need to wrap up the desktop decisions & recommendations
>with clear documentation before my meeting with Ferrara next Thursday.
>
>I wasn't able to talk to Susan yesterday to confirm her issues/concerns.
>I'll try again today...
>
>-Dave
Lynne E. Durland
Information Systems
Database Services
W91-109
O: 617-258-5857
C: 617-293-8091
B: 617-430-8762
H: KB1FEM
"The main dangers in this life are the people who want to change
everything.....or nothing."
Lady Nancy
Astor
