Jim,
I don't think that any of the discussion points that you mention was new to
the group.
We have been over that ground earlier and done our compromises and decisions.
What happened in the meeting was that some people who have been in and out of
the group raised them for discussion again. This does not mean that we have
to back track everything again.
Carl-Uno
At 09:41 AM 2/6/98 PST, 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 at dazel.com>
>System
Architect/DAZEL Wizard
>DAZEL Corporation, Austin, TX
>>Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros at cp10.es.xerox.com