There are, perhaps, multiple agenda to be resolved. But the need for a
capable, readily implementable and expandable IP printing system is, I
think, rather clear.
1. IP appears to be becoming the predominant protocol, not just for
things concerned with the popular concept of the Internet, but for the
work-horse networking in business and commerce as well as education
and scientific areas.
2. the new IP clientele include a large non-Unix oriented, non
workstation oriented population. They are PC and Intel-box Windows
people accustomed to expecting plug and play, non technically
demanding, 'user friendly' capabilities that still provide them with
the perception of control.
3. Printing, in meeting the demands of the market, has become very
complicated in imaging, paper handling. marking processes, etc. Those
same technically unsophisticated users want to be able to take
advantage of these features (which, of course, is the reason they
bought the new printers with those features). I would suggest that
many classical IP clientele have similar desires and expectations.
A standardized protocol for a IP printing system is needed. LPD does
not provide a sufficient base for the existing printer capabilities
let alone for the coming ones. DPA has defined perhaps too broad and
inclusive a capability; as Novell has pointed out, there are several
non compatible implementations. Non compatible implementations are
not in keeping with internetworking.
Although presented as an approach to "Internet Printing" (which means
different things to different people and has a certain panache to it)
the objective of Novell's LDPA was to provide a subset of the
advantages of DPA in a standardized from to the community of Internet
Protocol users. Although there have been certain changes, that remains
the core of the IPP document. I suggest we return to that core
objective, which is not insubstantial and may need some trimming,
keeping in mind that what is established will have to act as the base
for the grander printing schemes we envision.
______________________________ Reply Separator _________________________________
Subject: Re: IPP> Proposed Summary of IPP Feature Set -Reply
Author: rturner at sharplabs.com at Internet
Date: 1/3/97 1:53 PM
I concur with Jay and Scott's comments (and have echoed this in past
messages)
For now, just submit a print job and check status on the job submitted.
In my opinion, this should be the core of our first draft.
Things like how we find a printer, and IPP-enabling drivers should come
later.
Randy
Scott A. Isaacson wrote:
>> I share Jay's concern/confusion/frustration about the scope of this
> "protocol".
>> I am still strongly against trying to solve the "automatic driver download
> and install problem right now."
>> I do agree that it is an important feature to think about, but it is not
critical
> right now. The clear objective that we just received from the area
> director (s) is to "KEEP IT SIMPLE". Simple things are implemented and
> hence accepted. Complex things are not. We have enough on our
> plates as it is. Let's save dessert for later.
>> Scott
>> ************************************************************
> Scott A. Isaacson
> Print Services Consulting Engineer
> Novell Inc., 122 E 1700 S, Provo, UT 84606
> V: (801) 861-7366, (800) 453-1267 x17366
> F: (801) 861-4025, E: scott_isaacson at novell.com> W: http://www.novell.com> ************************************************************
>
--
Randy Turner
Network Architect
Sharp Laboratories of America
rturner at sharplabs.com