[585] in Enterprise Print Delivery Team
Re: Enterprise Printing Delivery, Meeting Notes, 10/11/2000
daemon@ATHENA.MIT.EDU (David F Lambert)
Thu Oct 12 08:19:08 2000
Message-Id: <10010121219.AA27323@MIT.EDU>
Date: Thu, 12 Oct 00 07:50:30 EDT
From: David F Lambert <LAMBERT@MITVMA.MIT.Edu>
To: Enterprise Printing Delivery Project Team <printdel@MIT.EDU>
In-Reply-To: Your message of Wed, 11 Oct 2000 17:06:31 -0400
On Wed, 11 Oct 2000 17:06:31 -0400 MEB said:
>Attending: Dave, Lynne, Rocklyn, MEB
>
>Today's meeting was prompted by issues raised by SMAzary and TRegan with
>regard to rolling out IPM service (for central printing) to the desktop.
>Susan's objection seems to focus on the notion that this is still mainframe
>based, even though it isn't. Theresa's objects to adding yet more software
>(client or printer driver) to the desktop.
>
>First we listed the options for submitting print jobs. For all options the
>user can view job status via the web browser. Zephyr could be made to tell
>the user that the print job had been received (?). In a mid-meeting
>teleconference between Dave and Theresa, Theresa pretty much dismissed the
>need for the Zephyr service. We then developed a chart of options for
>submitting print jobs to IPM with advantages and disadvantages.
>
>This chart reflects this morning's discussion. I think it could use more
>specifics.
>
>http://web.mit.edu/is/delivery/enterprint/submitoptions.html
I gotta agree with Lynne. You captured the discussion/issues well, Mary
Ellen. I was hoping you could attend the meeting because I knew you
would organize the information well!
Here are some follow up thoughts/suggestions for consideration...
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)
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)
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?
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?
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
