> 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.
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 --
----------------------------------------------------------------------