Given the current "culture" that has seemingly developed within
the IPP group, Jim should be commended on being so brave as to
suggest some of the views that some may describe as "nay-saying".
I must admit that I am a member of the group Jim refers to in:
> "We know that this draft will get rejected anyways, so
> why don't we send it in, collect all of the comments at
> one time, and in the meantime we can think some more
> about XML".
While I had strongly proposed that the current drafts be submitted
as-is for IETF review, the fact is, I really don't like the
IPP protocol as it is currently defined. (Wow, I said it.
Now I feel better... ;-)
One final note: whether IPP (as currently defined) is better or
worse than XML is really a useless discussion, IMHO.
Without Microsoft's aggressive support, any *pervasive* deployment
of an Internet-like printing protocol will likely fail within the
general domain. If Microsoft balks at IPP v1.0 (and they surely
have made this comment, repeatedly!), then does anyone actually
believe they will deploy it?
I have longed for the day in which the Printer Industry as a whole
would stand up, band together, and produce something in concert
with the sum of the industry's players. But, after waiting some
five years for this act to occur, I now find that this belief is
but a pipe dream.
Let's face it. As long as the printer industry continues to gate
itself on the progress and initiative of Microsoft and HP, then
true innovation deployed on a global scale--in which the efforts
are conducted on an honestly "level playing field"--is likely
to NEVER happen, at least not in our lifetime. (Of course, the
Department of Justice could change all of that... ;-)
I would like to publicly challenge Microsoft to put forth an
"Internet printing" proposal in which it can demonstrate true
openness for allowing the printer industry to participate in
it's development and deployment.
I, for one, have no problem in working within an environment
that has a "benevolent dictator". After all, my company exists
to make products and profit from that effort. Having a single
"Master" of a given effort is fine...so long as the Master is
open and honest with its "serfs".
Thanks for letting me get this off my chest.
...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 --
----------------------------------------------------------------------
James Walker wrote:
>
> Roger K Debry wrote:
> >
> > Not having been in Maui, I'd be interested in what
> > you believe the "many other" issues are.
>
> Sorry about the delay in the response...
>
> There were several other issues that were discussed, some of which
> I thought came up during the phone conference (alas, we all know
> how well that technology worked :-).
>
> At any rate here are some that I remember (not meant to be an
> exhaustive list)...
>
> o Using a new HTTP method rather than overloading POST.
> Nuff said.
>
> o Concern over using HTTP at all... there was a rumor going
> around that the IESG was poised to reject the current
> IPP drafts because HTTP was being used as the protocol.
> In fact, part of the discussion was along the lines of
> "We know that this draft will get rejected anyways, so
> why don't we send it in, collect all of the comments at
> one time, and in the meantime we can think some more
> about XML".
>
> There also seemed to be some underriding current of
> uneasiness from some of the group regarding HTTP.
> This is just a subjective opinion of mine, but there
> were comments made like "now, if we had just used a
> simple socket-level protocol..."
>
> o IPP as an embedded printer protocol versus a print server
> protocol. There was a lot of discussion about whether
> we are trying to accomplish too much by having one
> protocol for both the embedded printer and the print
> server. For example, there is a natural tension between
> the space requirements that the embedded printer crowd
> (rightfully) defends, and the "elegance" and
> "extensibility" arguments that the print server crowd
> espouses. I think that the XML discussion, as well as
> the original text versus binary protocol discussion from
> over a year ago, are valid examples of this tension.
>
> o IPP versus SNMP. Along the same lines of some of the issues
> above were discussions about overlap between IPP and SNMP.
> There was at least one suggestion that IPP should perhaps
> just be a job submission (and cancellation?) protocol,
> and use the existing Printer and Job Monitoring MIBs for
> determining printer and job status.
>
> I was also concerned about comments from at least one
> representative from a large printer vendor that indicated
> very little interest in IPP as a whole. "If we already
> have a way to get jobs in the printer (using, say, a
> simple bi-directional TCP connection) and a way to monitor
> those jobs, as well as the printer (SNMP), what good does
> IPP do for us?"
>
> These are just some random recollections. I do not mean to be
> a gloom-and-doom'er, but I did want to document some of the
> observations that I made from my seat.
>
> ...walker
>
> --
> Jim Walker <walker@dazel.com>
> System Architect/DAZEL Wizard
> DAZEL Corporation, Austin, TX