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

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

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

Ira McDonald blueroofmusic at gmail.com
Thu Jul 31 19:55:54 EDT 2008

Hi Mike,

I concede that we should add required document formats to IPP/2.0.

I just re-read your note at the start of this thread and I realized
that you said
"MUST support *one* of the following [four] document formats", which works
just fine, since document-format-supported is a REQUIRED attribute for all
IPP Printers.

I agree you've picked the right four formats for best simple printing

As you say, this gives much more meat than PWG MSN names and (supposedly)
correct protocol implementation to IPP/2.0 - the customer has a simple reason
to look for the new conformance claim.

- Ira

On Thu, Jul 31, 2008 at 5:07 PM, Michael R Sweet <msweet at apple.com> wrote:
> Ira McDonald wrote:
>> Hi,
>> I agree with Dave Whitehead that required document formats (or any other
>> new IPP requirements) belong in a separate standards-track PWG spec.
> Again, we're already changing the ipp-versions-supported and the IPP
> header to have 2.x version numbers.  Doing a separate spec that is
> literally 8 pages of boilerplate and 1 page of real content seems like
> a lot of overhead for this!
>> Prototyping in the PWG Process does NOT require any interoperability
>> testing
>> at all.  It's just a partial implementation (no minimum content) by a
>> single vendor.
> Keep in mind that CUPS already supports 3 out of the 4 formats I've
> proposed.  However, I'd argue that we need at least one printer
> vendor to implement it as well...
> Also, given the mess we have today, I think we really (really!) need
> to do interop testing and come up with a standard test suite that
> vendors can use to self-validate.  (CUPS already has much of this in
> its "make check" automated tests to validate its IPP/1.1 conformance)
>> ...
>> If we need new IPP projects, then so be it.  But please let's not destroy
>> the
>> chance of IPP2x by introducing new content and breaking the concensus
>> to proceed that was based on no new content.
> IPP/2.x with no required document formats is no better than IPP/1.1.
>> IPP/1.0 implementations DO NOT conform to IPP/1.1 and WILL NOT conform
>> to IPP/2.0 - end of story.
> True.  The question is, who will upgrade to IPP/2.0 if there is no
> compelling reason to do so?
> --
> ______________________________________________________________________
> Michael R Sweet                        Senior Printing System Engineer

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music/High North Inc
email: blueroofmusic at gmail.com
 579 Park Place Saline, MI 48176
 PO Box 221 Grand Marais, MI 49839

More information about the Ipp mailing list