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

From: Michael R Sweet <[email-masked]>
Date: Mon, 21 Jul 2008 14:25:46 -0700

All,

In today's telecon I brought up a question about whether it would be
a benefit to define a set of document formats that devices must
support.  This would have large benefits for interoperability and
the ability for clients of all shapes and sizes to print without
specialized printer drivers.

The wording I am thinking of is:

      REQUIRED DOCUMENT FORMATS

      IPP v2 devices MUST support one of the following document
      formats:

          document-format          Details
          ----------------------------------------------------
          application/pdf          ISO 32000-1:2008,
                                   ISO 19005-1:2005 (PDF/A),
                                   or PDF/IS?
          application/xhtml+xml    XHTML-Print
          image/jpeg               W3C JFIF* encapsulation
          image/png                ISO 15948, RFC 2083
          ----------------------------------------------------
          * http://www.w3.org/Graphics/JPEG/jfif3.pdf

I have not included application/postscript in the list because it
isn't standardized beyond simple page descriptions, both in the
official and real-world senses, and in many cases PostScript
printers require some level of device-dependent commands to be
used (think PPD files).

Likewise, I have not included image/tiff since TIFF is a catch-all
for thousands of sub-formats, and the most common sub-formats
(TIFF-G3 and TIFF-G4) are limited to reproduction of monochrome
graphics which make them less useful as a general printing format.

Comments?

-- 
______________________________________________________________________
Michael R Sweet                        Senior Printing System Engineer

---

From: "Paul Tykodi" <[email-masked]>
Date: Mon, 28 Jul 2008 10:06:01 -0400

Hi Michael,

As far as I know, IPP support is slowly working its way into network printer
interfaces for the label printing niche (both impact and direct
thermal/thermal transfer print technologies) and into some of the dot matrix
printer NIC's as well.

These types of printers do not support the same document formats as the
inkjet and laser technology based printers.

If IPP were to become involved with specifying document formats, I think it
would be a good idea to create a separate IPP document formats track with
its own RFC or PWG based specification that could be referenced by the ippv2
documents.

Best Regards,

/Paul
--
Paul Tykodi
Principal Consultant
TCS - Tykodi Consulting Services LLC

Tel/Fax: 603-343-1820
Mobile:  603-866-0712
E-mail:  [email-masked]
WWW:  http://www.tykodi.com

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael R
> Sweet
> Sent: Monday, July 21, 2008 5:26 PM
> To: [email-masked]
> Subject: IPP> RFC: Add required document-format values for IPP v2?
> 
> All,
>

---

From: Michael R Sweet <[email-masked]>
Date: Mon, 28 Jul 2008 10:52:29 -0700

> its own RFC or PWG based specification that could be referenced by the ippv2

Well, the PWG already had done a lot of work in this area, including
XHTML-Print.  There are other groups that have standardized on JPEG
for consumer devices (PictBridge and others), the ISO and IETF have
standards for PNG, and of course the ISO has defined PDF profiles.
I don't think the problem is having a standard or referencing other
standards!

These formats are already supported by a wide variety of devices in
different ways - it would be nice to guarantee support for at least
one common format in every IPP 2.x printer, as it solves a major
(IMHO) problem with IPP that the PWG hasn't yet tackled - all
printers require a device-specific client-side printer driver to do
even basic printing.

If IPP 2.x printers did support one (or all) of the formats I've
listed, then a customer would know they could print from any client.
Obviously there would still be a use for device-specific drivers,
e.g. higher speed print modes and support for complex jobs, but
*basic* printing (email, web pages, photos) could be done without
all of that.

IMHO, adding a (short) list of required document-formats to IPP 2.x
will just make it *more* compelling as a standard.  Right now we are
just stapling all of the different IPP specs together to make
profiles - chances are most vendors will look at their product and
say "we already conform to IPP 2.0, just add 2.0 to our supported
versions and move on".  That doesn't ultimately help us promote IPP
2.x, since nothing will have really changed.  However, if we can
make IPP really useful by requiring support for at least one common
document format, then IPP can truly be marketed as an enabling
technology rather than being listed along side AppSocket, LPD, and
50 other "supported" printing protocols.

In short, let's make IPP more than just a replacement for LPD.

---

From: "Farrell, Lee" <[email-masked]>
Date: Tue, 29 Jul 2008 02:23:53 -0700

Before we get too far afield with this discussion topic, let me remind
everyone of the recently approved update to the IPPv2 Statement of Work
in which the following is identified:

Out-of-scope:
*	OSS-1  New IPP functionality or features  MUST NOT be included
in this IPP/2.x specification.
*	OSS-2  Details of IPP commands, attributes, or other features
MUST NOT be included in this IPP/2.x specification, except as needed
(e.g., references to attributes REQUIRED by newly REQUIRED operations.

I think defining a mandatory document format would qualify as a "New IPP
functionality".  

lee

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael
R Sweet
Sent: Monday, July 28, 2008 6:52 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: IPP> RFC: Add required document-format values for IPP v2?

Paul Tykodi wrote:
> Hi Michael,
> 
> As far as I know, IPP support is slowly working its way into network 
> printer interfaces for the label printing niche (both impact and 
> direct thermal/thermal transfer print technologies) and into some of 
> the dot matrix printer NIC's as well.
> 
> These types of printers do not support the same document formats as 
> the inkjet and laser technology based printers.
> 
> If IPP were to become involved with specifying document formats, I 
> think it would be a good idea to create a separate IPP document 
> formats track with its own RFC or PWG based specification that could 
> be referenced by the ippv2 documents.

Well, the PWG already had done a lot of work in this area, including
XHTML-Print.  There are other groups that have standardized on JPEG for
consumer devices (PictBridge and others), the ISO and IETF have
standards for PNG, and of course the ISO has defined PDF profiles.
I don't think the problem is having a standard or referencing other
standards!

These formats are already supported by a wide variety of devices in
different ways - it would be nice to guarantee support for at least one
common format in every IPP 2.x printer, as it solves a major
(IMHO) problem with IPP that the PWG hasn't yet tackled - all printers
require a device-specific client-side printer driver to do even basic
printing.

If IPP 2.x printers did support one (or all) of the formats I've listed,
then a customer would know they could print from any client.
Obviously there would still be a use for device-specific drivers, e.g.
higher speed print modes and support for complex jobs, but
*basic* printing (email, web pages, photos) could be done without all of
that.

IMHO, adding a (short) list of required document-formats to IPP 2.x will
just make it *more* compelling as a standard.  Right now we are just
stapling all of the different IPP specs together to make profiles -
chances are most vendors will look at their product and say "we already
conform to IPP 2.0, just add 2.0 to our supported versions and move on".
That doesn't ultimately help us promote IPP 2.x, since nothing will have
really changed.  However, if we can make IPP really useful by requiring
support for at least one common document format, then IPP can truly be
marketed as an enabling technology rather than being listed along side
AppSocket, LPD, and 50 other "supported" printing protocols.

>> From: [email-masked] [mailto:[email-masked]] On Behalf Of 
>> Michael R Sweet
>> support.  This would have large benefits for interoperability and the

>> ability for clients of all shapes and sizes to print without 
>> official and real-world senses, and in many cases PostScript printers

>> require some level of device-dependent commands to be used (think PPD

>> files).

---

From: Dave Whitehead <[email-masked]>
Date: Tue, 29 Jul 2008 08:40:32 -0400

I agree with Lee -- adding a mandatory document format is out-of-scope
under our current charter.  However, I also think it's a good idea.

dhw

             "Farrell, Lee"                                                
             <Lee.Farrell@cda.                                             
             canon.com>                                                 To 
             Sent by:                  "Michael R Sweet"                   
             [email-masked]         <[email-masked]>,                 
                                       <[email-masked]>                
                                                                        cc 
             07/29/2008 05:23          <[email-masked]>                       
             AM                                                    Subject 
                                       RE: IPP> RFC: Add required          
                                       document-format values for IPP v2?  

                                                                           

Out-of-scope:

lee

---

From: Michael R Sweet <[email-masked]>
Date: Tue, 29 Jul 2008 06:42:29 -0700

> I think defining a mandatory document format would qualify as a "New IPP

While I agree that it is out-of-scope for the current SOW, I'd also
propose that we change the SOW.

Right now we are putting together a wonderful combination of the
IPP/1.1 specs to make new "unified" 2.x specs, but the main problem
is that either vendors will ignore 2.x (why add media standardized
names when we only support our proprietary PDL with no overrides)
or have already implemented everything needed for 2.x.  IPP will
remain only as an "LPD replacement" and be no more useful than LPD.

However, if we tackle adding required document formats, then we
have effectively "raised the bar" to make IPP something more
compelling.  More importantly, it will be something marketable,
both in the home/small office and corporate spaces.

Multi-function devices already outsell regular printers by a
significant margin, and most come with support for direct-connect
printing from embedded devices (cameras, phones, etc.) via
PictBridge.  There is no equivalent for networked printers, and
since smart phones and other embedded devices are in wide use it
would be nice to support printing from them...

---

From: "Ira McDonald" <[email-masked]>
Date: Thu, 31 Jul 2008 13:15:16 -0400

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

(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

Cheers,
- Ira

On Tue, Jul 29, 2008 at 9:42 AM, Michael R Sweet <[email-masked]> wrote:
>>> printer interfaces for the label printing niche (both impact and direct
>>> If IPP were to become involved with specifying document formats, I think
>>> it would be a good idea to create a separate IPP document formats track with
>>>> In today's telecon I brought up a question about whether it would be a
>>>> benefit to define a set of document formats that devices must support.  This
>>>> would have large benefits for interoperability and the
>>
>>>> ability for clients of all shapes and sizes to print without specialized
>>>> printer drivers.
>>>>
>>>> I have not included application/postscript in the list because it isn't
>>>> standardized beyond simple page descriptions, both in the official and
>>>> real-world senses, and in many cases PostScript printers
>>
>>>> Likewise, I have not included image/tiff since TIFF is a catch-all for
>>>> thousands of sub-formats, and the most common sub-formats
>>>> (TIFF-G3 and TIFF-G4) are limited to reproduction of monochrome graphics
>>>> which make them less useful as a general printing format.
>>>>
>>>> Comments?
>>>>
>>>> --
>>>>
>>>> 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: [email-masked]
winter:
 579 Park Place Saline, MI 48176
 734-944-0094
summer:
 PO Box 221 Grand Marais, MI 49839
 906-494-2434

---

From: Dave Whitehead <[email-masked]>
Date: Thu, 31 Jul 2008 13:29:43 -0400

I think option 1 may be the way to proceed (if that's what we want to do!)
since it would then be just another document we reference in the IPPv2x
document.

dhw

             "Ira McDonald"                                                
             <blueroofmusic@gm                                             
             ail.com>                                                   To 
             Sent by:                  "Michael R Sweet"                   
             [email-masked]         <[email-masked]>, "Ira McDonald"  
                                       <[email-masked]>           
                                                                        cc 
             07/31/2008 01:15          "Farrell, Lee"                      
             PM                        <[email-masked]>,        
                                       [email-masked], [email-masked]     
                                                                   Subject 
                                       Re: IPP> RFC: Add required          
                                       document-format values for IPP v2?  

                                                                           

Hi,

(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

Cheers,
- Ira

>>> If IPP were to become involved with specifying document formats, I
think
>> In short, let's make IPP more than just a replacement for LPD.
Michael
>>>> ability for clients of all shapes and sizes to print without
specialized
>>>>      IPP v2 devices MUST support one of the following document
isn't
>>>> (TIFF-G3 and TIFF-G4) are limited to reproduction of monochrome
graphics

---

From: Michael R Sweet <[email-masked]>
Date: Thu, 31 Jul 2008 10:57:39 -0700

>      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!

>       - waving PWG Process and adopting untested new IPP content is NOT

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.

---

From: Michael R Sweet <[email-masked]>
Date: Thu, 31 Jul 2008 11:02:18 -0700

> since it would then be just another document we reference in the IPPv2x

But won't option 1 (write a new standard, reference it in IPP/2.x)
still require prototyping, etc?

Plus, I don't see how we are getting around the prototype requirements
for 2.x - we *are* adding new content WRT version numbers, and that
requires prototyping to do any kind of testing/validation between
implementations.

---

From: Dave Whitehead <[email-masked]>
Date: Thu, 31 Jul 2008 14:22:20 -0400

If we can agree to the correct document format, prototyping could be a
matter of minutes.

dhw

             Michael R Sweet                                               
             <[email-masked]                                             
             >                                                          To 
                                       Dave Whitehead <[email-masked]>  
             07/31/2008 02:02                                           cc 
             PM                        Ira McDonald                        
                                       <[email-masked]>,          
                                       [email-masked], "Farrell, Lee"         
                                       <[email-masked]>,        
                                       [email-masked],                  
                                       [email-masked]                  
                                                                   Subject 
                                       Re: IPP> RFC: Add required          
                                       document-format values for IPP v2?

---

From: "Ira McDonald" <[email-masked]>
Date: Thu, 31 Jul 2008 15:31:25 -0400

Hi,

I agree with Dave Whitehead that required document formats (or any other
new IPP requirements) belong in a separate standards-track PWG spec.

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.

Interoperability testing (AFTER approval of specs) is also part of the PWG
Process but is NOT required to bring a document to Formal Approval vote
as a Candidate Standard (unlike IETF and many other standards bodies).

For IPP2x versions, a prototype could be one printer in a lab with a
test client.

I also agree that prototyping *some* required IPP document formats could
be trivially accomplished.

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/1.0 implementations DO NOT conform to IPP/1.1 and WILL NOT conform
to IPP/2.0 - end of story.

Cheers,
- Ira

---

From: Michael R Sweet <[email-masked]>
Date: Thu, 31 Jul 2008 14:07:38 -0700

> 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!

> at all.  It's just a partial implementation (no minimum content) by a

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)

> ...

IPP/2.x with no required document formats is no better than IPP/1.1.

> 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?

---

From: "Ira McDonald" <[email-masked]>
Date: Thu, 31 Jul 2008 19:55:54 -0400

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