I saw two problems with two , potentially different, soultions (hence my
double vote). I rolled with what I saw as the simple solution (HTTP -
interesting that you percieve them the opposite way round) and proposed
something called SIMPLE web printing based on what we were building - that
just did job submission. That eventually evolved into what we have today.
Now we move on to address the issues that were lurking in the background -
printer discovery, feature dicsovery , configuration discovery, managment,
notification, flow control, peer queuing,.... (things for s/w to printer
interface) and billing, quotas, access control, server managemnt, job
redirection, ... (things for client to print subsystem interface).
The WG is DETERMINED that this will be done by one protocol - I have
expressed (with you and others) my opionion that this is not acheiveable
(its desirability is understandable) many times. We are not listened to and
I do not wish to continue to bash my forehead against that wall forever. So
I have changed tactics and am now thinking 'how can I make IPP into all the
things I need?'. Hence the current apparent change of stance, XML
suggestions, questions about notification, etc.
I just want to get down and build good stuff for users - I am trying to
find the path of least resistance.
> -----Original Message-----
> From: Jay Martin [SMTP:jkm@underscore.com]
> Sent: Saturday, February 07, 1998 10:16 AM
> To: Paul Moore
> Cc: ipp@pwg.org
> Subject: Re: IPP> Consensus on sending our drafts to the IESG
>
> Paul,
>
> > MS & HP will state to the IESG our concerns with the current
> > design (just as anybody in the Internet comunity can).
>
> And rightly so. We all look forward to seeing your concerns posted
> to the IESG, where a larger domain of reviewers may be able to shed
> additional light on this situation.
>
>
> > Having said that - we will implement what the IESG
> > ratifies. It is our aim to have maximum interoperability,
> > not to divide the world into different camps - that would
> > be a war we can all do without.
>
> This is certainly good news. We all needed to hear these "official"
> words from Microsoft. Whether the protocol/model is good or bad is
> not nearly as important as solidarity, given the critical mass
> nature of our efforts.
>
> Are you able to speak on behalf of HP, or should a similar statement
> be made from an HP representative?
>
>
> > Our intent is purely to do the right thing both for the
> > short term and the long term. We saw IPP as an opportunity
> > for printing to 'do it right' from day 1 as opposed to
> > always having to compromise on other solutions (SNMP,
> > LPR/LPD, ...).
>
> Now this paragraph is totally confusing to me, Paul. I vividly
> recall back at the May '97 IPP meeting (San Diego) the group
> explicitly discussed the notion of "something quick vs. something
> long term" in terms of whether to go "Web/HTTP" vs. a "simple,
> socket-based approach".
>
> Recall that meeting? It was the meeting in which I was supposed
> to get up and make "one last pitch" for a simple, socket-based
> approach" using the CPAP protocol as an example starting point.
> Having sensed the group's strong desire to leverage HTTP server
> technology (based on assumptions that have since proven to be
> totally *false* and unworkable), I decided to be "politically
> correct" and not give a CPAP presentation, so as not to appear
> as if I were "rocking the boat". (I have since regretted that
> decision.)
>
> The official minutes for this meeting, however, did not detail
> some of the critical statements made during this discussion.
> (ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-0597.txt)
>
> What did happen was that Carl-Uno took a vote from the group
> as to the desired direction to proceed. The vote was in
> favor of an HTTP approach (by quite a large margin).
>
> Those who attended that meeting should recall that you
> surprised all those in attendance by voting for BOTH
> approaches! To say the least, I was quite shocked and
> asked you why you voted both ways.
>
> Your reply was something like this (not your exact words,
> but pretty close for all intents and purposes):
>
> If we wanted a real, long-term useful printing protocol,
> then we would of course design a protocol using a simple
> socket-based approach. Such a protocol would allow us to
> do much more than just job submission, but could also allow
> us to effect critical management functions using the same
> protocol. However, since the world appears to strongly
> desire some sort of Web-based interface, let's just develop
> a simple HTTP-based submission protocol. Afterwards, we
> can then address a more suitable protocol usable in the
> long-term.
>
> I LOVED THIS STATEMENT. It seemed so pragmatic and clearly
> thought out that I immediately jumped on the bandwagon to
> develop a *simple* HTTP-based protocol, hoping (of course)
> that the effort would not be long and drug out, and that
> we all could finish the effort in the originally intended
> schedule.
>
> From what I could see, it was in my best interest to help
> complete the HTTP-based effort as quickly as possible so
> as to be able to more quickly move on to the development
> of a REAL, long-term protocol.
>
> However, as time moved on, more and more people started
> to view IPP as both an INTERnet protocol *and* and INTRAnet
> protocol. And this is where the real disaster strikes, IMHO.
>
> So now, when you say:
>
> > Our intent is purely to do the right thing both for the
> > short term and the long term. We saw IPP as an opportunity
> > for printing to 'do it right' from day 1 as opposed to
> > always having to compromise on other solutions (SNMP,
> > LPR/LPD, ...).
>
> This appears to be a complete reversal of your great comments
> made to the group back in May in San Diego. In San Diego,
> you implied that IPP would serve as an interim protocol, as
> anything HTTP-based would not easily allow for the kind of
> long-term printing protocol the world really needs, at least
> not within enterprise environments.
>
> This is truly disappointing. And I know for a fact I am not
> alone in this belief.
>
> ...jay
>
> ----------------------------------------------------------------------
> -- 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 --
> ----------------------------------------------------------------------