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
interworking.
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.
Cheers,
- 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
winter:
579 Park Place Saline, MI 48176
734-944-0094
summer:
PO Box 221 Grand Marais, MI 49839
906-494-2434