Paul Moore wrote:
> I concur completely. This observation is in diametric
opposition to
> the position stated by Paul Moore, namely, that IPP is being
> targeted
> as the "all-in-one" protocol for network printing in the
future,
> whether it be INTERnet or INTRAnet.
>
> You misunderstand me (Or I misunderstand you). I completely agree with
this
> thread about needing a robust host-to-device protocol. My main
complaint
> from day one has been that people are trying to make IPP into 'all
things
> for all people' and have failed because this cannot be done. This is
still
> my position and one that I still continue to make. I think that the
group as
> a whole IS targetting it as the 'all-in-one' solution (it re-affirmed
this
> at the last WG) - but I dont think it should be.
>
> I.e dont confuse my analysis of what the WG as a whole has decided IPP
> should be with what I think is the right thing to do - they are
> diametrically opposed.
>
> This ' all-in-one' approach has several bad effects
>
> 1. People are trying to cram stuff in that does not really fit
>
> 2. The is a lack of focus on what real value the IPP could have in its
core
> space (printing over the public internet)
>
> 3. Nobody will look at a device level protocol because 'we can make
IPP do
> that'. Hence we get into the wierd suggestion that device alerts
should be
> sent via email!
>
> Regarding the 'value' or otherwise of IPP. I can see some scenarios
where it
> will be genuinley useful
>
> - printing to service shops that have faster/more functional printers
> - printing to your neighbors printer (simpler than sneakernet)
> - printing when on the road (hotel business centre for example)
>
> But this is less value than the need I have for a protocol that
addresses
> the real, actual, support desk pain in the *ssing, end user confusing,
money
> draining problems that exist in corporates, small businesses and soon
in
> homes. I doubt that IPP can do it, but (and this is the one change of
stance
> here) I have decided to see if IPP COULD be pushed into doing it.
Having
> spent some cycles I am 40/60 (yes/no) on this. Even if it could do it
it
> would be a huge kludge but something is better than nothing. The other
> alternative is to do a different protocol - which I am totally in
favor of.
>
> This sounds like a topic for an Austin BOF.
>
> > -----Original Message-----
> > From: Jay Martin [SMTP:jkm@underscore.com]
> > Sent: Wednesday, February 11, 1998 8:23 AM
> > To: Philip Thambidurai
> > Cc: ipp@pwg.org
> > Subject: Re: IPP> Does the world need a robust host-to-device
network
> >
> > Philip,
> >
> > Many thanks for your supporting comments.
> >
> > > In summary, two issues stand out to me:
> > >
> > > 1. It does not appear that IPP will have much or any impact
on the
> > > multitude of printing solutions in use today (for the
Intranet).
> >
> > I concur completely. This observation is in diametric opposition to
> > the position stated by Paul Moore, namely, that IPP is being
targeted
> > as the "all-in-one" protocol for network printing in the future,
> > whether it be INTERnet or INTRAnet.
> >
> > Over the last few weeks, several people have contacted me privately
> > asking me the same sort of question:
> >
> > "What (or who) on earth is IPP really good for, anyway?"
> >
> > This is a question that really needs to be answered, given the
> > many people who believe IPP adds very, very little value in the
> > Intranet (aka, enterprise) environment. Someone is supposed to
> > be starting a thread for this kind of discussion Real Soon Now.
> >
> >
> > > 2. Lack of a ***complete*** standard printing solution
within the
> > LAN
> > > environment (Intranets included). Today we have to use
proprietary
> > > solutions.
> >
> > Exactly. Again, people's comments to me come out as:
> >
> > "When compared to existing (proprietary/defacto) network printing
> > protocols, IPP adds so little that it does not provide the
impetus
> > to change existing infrastructures in the Intranet environment."
> >
> > Sure, we can certainly extend IPP in the future (and extend it,
> > and extend it...), but one critical design flaw exists in IPP (IMHO)
> > that prevents a clean and simple design:
> >
> > IPP is based on HTTP
> >
> > In the early days of IPP, these assumptions made HTTP the obvious
> > choice for an INTERnet printing protocol:
> >
> > 1. We get a free "hole" through the firewall
> >
> > 2. We get to leverage external work on security models and related
> > infrastructure so that we didn't have to do that ourselves
> >
> > 3. With support from browser vendors, "native" support for IPP
> > could be shipped with all standard browsers, thereby offering
> > the holy grail of "no client-side software installation"
> >
> > Sadly, one by one, these critical core assumptions have fallen.
> >
> > So, why did we stick with HTTP? Momentum within the group?
> > (ie, "I already have time and code invested, and I don't
> > want to throw it away")
> >
> > IMHO, the only real redeeming value of using HTTP at all
> > is the ability to leverage common server-side program
> > invocation services (ie, CGI). This appears, though, to
> > only help server-side developers coding for "general purpose"
> > servers, and not embedded environments.
> >
> > Comments are welcome and encouraged here. Feel free to flame
> > as necessary... ;-)
> >
> > ...jay
> >
> > PS: I realize these comments should be directed to the IESG
> > as part of the Last Call period, but I don't know how to
> > post comments to the IESG. :-(
> >
> >
----------------------------------------------------------------------
> > -- JK Martin | Email: jkm@underscore.com
-- > > -- Underscore, Inc. | Voice: (603) 889-7000-- > > -- 41C Sagamore Park Road | Fax: (603) 889-2699-- > > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com-- > > ----------------------------------------------------------------------