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