From: Dave Whitehead (david@lexmark.com)
Date: Thu Jul 31 2008 - 13:29:43 EDT
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"
owner-ipp@pwg.org <msweet@apple.com>, "Ira McDonald"
<blueroofmusic@gmail.com>
cc
07/31/2008 01:15 "Farrell, Lee"
PM <Lee.Farrell@cda.canon.com>,
ptykodi@tykodi.com, ipp@pwg.org
Subject
Re: IPP> RFC: Add required
document-format values for IPP v2?
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 <msweet@apple.com> wrote:
> Farrell, Lee wrote:
>>
>> 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".
>
> 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...
>
>> lee
>>
>> -----Original Message-----
>> From: owner-ipp@pwg.org [mailto:owner-ipp@pwg.org] On Behalf Of Michael
>> R Sweet
>> Sent: Monday, July 28, 2008 6:52 PM
>> To: ptykodi@tykodi.com
>> Cc: ipp@pwg.org
>> 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.
>>
>> In short, let's make IPP more than just a replacement for LPD.
>>
>>
>>> Best Regards,
>>>
>>> /Paul
>>> --
>>> Paul Tykodi
>>> Principal Consultant
>>> TCS - Tykodi Consulting Services LLC
>>>
>>> Tel/Fax: 603-343-1820
>>> Mobile: 603-866-0712
>>> E-mail: ptykodi@tykodi.com
>>> WWW: http://www.tykodi.com
>>>
>>>> -----Original Message-----
>>>> From: owner-ipp@pwg.org [mailto:owner-ipp@pwg.org] On Behalf Of
Michael
>>>> R Sweet
>>>> Sent: Monday, July 21, 2008 5:26 PM
>>>> To: ipp@pwg.org
>>>> Subject: IPP> RFC: Add required document-format values for IPP v2?
>>>>
>>>> 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
>>
>>
>> --
>> ______________________________________________________________________
>> Michael R Sweet Senior Printing System Engineer
>
>
> --
> ______________________________________________________________________
> 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@gmail.com winter: 579 Park Place Saline, MI 48176 734-944-0094 summer: PO Box 221 Grand Marais, MI 49839 906-494-2434
This archive was generated by hypermail 2.1.4 : Thu Jul 31 2008 - 13:29:52 EDT