The Microsoft proposal addresses two issues:
1) Use a new method instead of POST
2) Use XML instead of the current protocol
However, the major issue here is not, I believe, a technical one.
It is a matter of timing, of process, and principle. Let me explain.
A year ago as we started down the path of developing a new
standard for printing on the Internet, we agreed to pursue that
path which would allow us to deploy the standard as quickly as
possible. This meant, for one thing, basing our work on existing,
well established protocols, and products. We stopped dead in our
tracks last spring to deal with Microsoft's SWP proposal and after
much soul searching and negotiation, we reached a compromise
that accomodated Microsoft's views and got the standard back on
track. The Post vs. new method debate was not a Microsoft issue
until just a few weeks ago. Nevertheless, We have argued the firewall
and POST vs. new method over and over again, and our decisions
to go with POST reviewed at every IETF meeting.
Now here we are a month after the last call on the standard, with
Microsoft once again asking us to stop and reset the standard.
It is our belief that if we agree to this change, it will be at least 4=
-6
months before we are ready to do a last call again. This is evidenced
by the many issues raised in Bob Herriot's fine analysis of mapping
IPP to XML. This has some serious implications ...
o Much of the prototyping work will have to be reset
o The standard will be at least six months late in being approved
o We lose credibility with the consultants and analysists we've talked =
to
o We lose credibility with the IETF
o We bind ourselves (I believe) too closely to one company's
strategy and their view of how Browsers and the web play in the desk=
top.
o We open the door for consideration of the NEXT cool technology to
come along six months from now, or Microsoft's next O/S change.
We can debate the technical issues ad nauseum (and probably will),
but I believe we need to take a stand on what we have done and say
"It is good enough".
Roger K deBry
Senior Technical Staff Member
Architecture and Technology
IBM Printing Systems
email: rdebry@us.ibm.com
phone: 1-303-924-4080
=