IPP> RFC: Add required document-format values for IPP v2?

IPP> RFC: Add required document-format values for IPP v2?

Michael R Sweet msweet at apple.com
Thu Jul 31 13:57:39 EDT 2008


Ira McDonald wrote:
> Hi,
> 
> I sympathize with Mike Sweet's point and Dave Whitehead's comments.
> However:
> 
> (1) The IPP WG can charter a new project (e.g., "IPP Required Document
>       Formats") for a new PWG standards-track spec anytime
> 
> (2) If the IPPv2 project adds ANY new content, then our whole schedule will
>      fall apart completely, because we'll have to show actual prototyping before
>      taking the IPPv2 spec to Formal Vote

Ira: Change the schedule. Putting out useless specs that nobody
will use is a waste of time.

We're already adding new content - new version numbers - and there
is significant effort needed for interoperability and conformance
testing.  Adding requirements for supported document formats (all
of which are already in ISO, IETF, PWG, or W3C approved standards)
will actually make that testing *easier* since then we won't need
to use vendor-specific drivers to create content suitable for the
device to the tested!

> (3) The PWG Steering Committee remembers all too well the structural error
>       in the Abstract Counters (PWG 5106.1) and Counter MIB (PWG 5106.3)
>       - waving PWG Process and adopting untested new IPP content is NOT
>       going to happen

Then IMHO IPP/2.x will be as much of a failure as IPP/1.1 has.

I say that IPP/1.1 is a failure because few vendors provide full
support for it, and even then it is only for a handful of devices.
Even fewer support "generic" document formats like PDF, making it
impossible to realize the dream of universal network printing.

Interoperability is a serious problem, in part because some vendors
never went beyond IPP/1.0 (Microsoft, Linksys, others), only support
HTTP/1.0 (HP), or have serious bugs in their IPP implementations
causing printers and network cards to hang (every vendor).

I am convinced that if we put out another IPP standard that does
nothing to address supporting standard/generic document formats, then
there will be no compelling reason for any vendor to adopt IPP/2.x
because it will not significantly improve interoperability or open up
new markets/opportunities.

Put simply, I think we need to provide an IPP/2.x spec that will help
vendors sell more printers.

-- 
______________________________________________________________________
Michael R Sweet                        Senior Printing System Engineer



More information about the Ipp mailing list