Subject: [IPP] Epson Request for PWG/IPP Raster

From: "Petrie, Glen" <[email-masked]>
Date: Tue, 8 Feb 2011 07:23:15 -0800

Epson would like in endorse the IPP working group's fast tracking of the
PWG/IPP raster specification / standard.  Epson would like to further
encourage and endorse the PWG Steering committee in approving a (very)
fast tracking of the of PWG/IPP Raster specification / standard. 

Epson supports the currently proposed format of the raster format
provided that the format is "streamable" in order to eliminate the need
for printers to provide buffering of full pages.

If the format has a REQUIRED color space, and Epson is not proposing
that there should be a REQUIRED color space; then Epson would like to
propose and support 24-bit sRGB 

Glen

 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Ira McDonald <[email-masked]>
Date: Tue, 8 Feb 2011 11:48:34 -0500

Hi Glen,

With respect to 'fast tracking' of PWG Raster spec, note
that the status phases Initial/Interim/Protoype/Stable must
occur, per PWG Process/3.0.

Except for waiving the PWG Process/3.0 requirement
for a PWG Last Call to span a PWG face-to-face, there
is little the PWG Steering Committee can do to 'fast
track' this spec.

And during the Prototype phase an actual prototype of
substantial amounts of the base spec must be performed,
reported on, and reviewed by the IPP WG.

For comparison, PDF/is had *every* required and
optional field prototyped.  Wire formats need to be
very stable before adopting them.

I can't speak to Mike Sweet's editing priorities, but the
main IPP Everywhere (profiles) and IPP JPS3 specs
are high priority for their Cloud Imaging WG and MFD
WG impacts.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:[email-masked]
Christmas through April:
  579 Park Place  Saline, MI  48176
  734-944-0094
May to Christmas:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434

On Tue, Feb 8, 2011 at 10:23 AM, Petrie, Glen <[email-masked]>wrote:

>  Epson would like in endorse the IPP working group’s fast tracking of the
> encourage and endorse the PWG Steering committee in approving a (very) fast
> tracking of the of PWG/IPP Raster specification / standard.
>
>
>
> Epson supports the currently proposed format of the raster format provided
> that the format is “streamable” in order to eliminate the need for printers
> to provide buffering of full pages.
>
>
>
> If the format has a REQUIRED color space, and Epson is not proposing that
> there should be a REQUIRED color space; then Epson would like to propose and
> support 24-bit sRGB
>
>
>
> Glen
>
>
>
>
>
>
>
>
>
> --
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>

---

From: "Petrie, Glen" <[email-masked]>
Date: Tue, 8 Feb 2011 10:42:07 -0800

While I understand your comments on fast tracking, is there a "specific"
duration to each phase / process?  So, I did not mean to change the
process but to encourage shortening it.

Can you help me understand the "scope of a prototype"?  In this case,
the scope of the technical content is very small but I still assume that
the process steps can not be dropped.

Having just a source provider of the PWG raster is not interoperability.
I personally do not know of a printer that can read CUPS raster xxx or
one that could be modified to read a subset.  So is emulation of a
printer ok?  I also assume for interoperability, there must be two
independent developments.

Glen

 

________________________________

From: Ira McDonald [mailto:[email-masked]] 
Sent: Tuesday, February 08, 2011 8:49 AM
To: Petrie, Glen; Ira McDonald
Cc: [email-masked]
Subject: Re: [IPP] Epson Request for PWG/IPP Raster

Hi Glen,

Cheers,
- Ira

<http://sites.google.com/site/highnorthinc> 

On Tue, Feb 8, 2011 at 10:23 AM, Petrie, Glen
<[email-masked]> wrote:

Glen

 

-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is

believed to be clean.

---

From: Ira McDonald <[email-masked]>
Date: Tue, 8 Feb 2011 13:55:51 -0500

Hi Glen,

There is no specific duration for the document status phases.

Both the WG last call and PWG Last Call can't reasonably be
shortened.  The time consumed is often *after* one or the other
last call, while the editors update the document and the WG
reviews those changes.

The scope of a SINGLE prototype (not an interoperability test)
is the choice of the implementation.  But the PWG SC took a
conservative view with PDF/is (prototype every field) and the
IPP Fax WG followed through on that.  In that case, Rick Seeler
(Adobe) tested that the sample PDF/is documents could be
correctly displayed by Adobe Reader as well.

A PWG Raster prototype could be fairly easily based on the
existing open source code for CUPS, I suspect.

The interoperability tests (between vendors) normally are only
*after* the PWG Candidate Standard is approved and required
for advancement to full PWG Standard document status.

Cheers,
- Ira

On Tue, Feb 8, 2011 at 1:42 PM, Petrie, Glen <[email-masked]>wrote:

>  While I understand your comments on fast tracking, is there a “specific”
> duration to each phase / process?  So, I did not mean to change the process
> but to encourage shortening it.
>
>
>
> Can you help me understand the “scope of a prototype”?  In this case, the
> scope of the technical content is very small but I still assume that the
> process steps can not be dropped.
>
>
>
> Having just a source provider of the PWG raster is not interoperability.  I
> personally do not know of a printer that can read CUPS raster xxx or one
> that could be modified to read a subset.  So is emulation of a printer ok?
> I also assume for interoperability, there must be two independent
> developments.
>
>
>
> Glen
>
>
>
>
>
>
>
>
>  ------------------------------
>
> *From:* Ira McDonald [mailto:[email-masked]]
> *Sent:* Tuesday, February 08, 2011 8:49 AM
> *To:* Petrie, Glen; Ira McDonald
> *Cc:* [email-masked]
> *Subject:* Re: [IPP] Epson Request for PWG/IPP Raster
>
>
>
> Hi Glen,
>

---

From: "Petrie, Glen" <[email-masked]>
Date: Tue, 8 Feb 2011 10:57:25 -0800

Thanks for the clarifications 

From: Ira McDonald [mailto:[email-masked]] 
Sent: Tuesday, February 08, 2011 10:56 AM
To: Petrie, Glen; Ira McDonald
Cc: [email-masked]
Subject: Re: [IPP] Epson Request for PWG/IPP Raster

Hi Glen,

Cheers,
- Ira

On Tue, Feb 8, 2011 at 1:42 PM, Petrie, Glen
<[email-masked]> wrote:

Glen

 

Hi Glen,

Cheers,
- Ira

Glen

 

believed to be clean.

---

From: Michael Sweet <[email-masked]>
Date: Tue, 8 Feb 2011 14:05:43 -0800

On Feb 8, 2011, at 8:48 AM, Ira McDonald wrote:
> ...

WRT to the PWG Raster specification, given that I have most of the necessary text available to publish another working draft I suspect it will get finished rather quickly. That said, given that sample code and documentation is already available there is no reason vendors have to delay their prototype implementations...

My editing priorities for the next few months (at least) are: PWG Raster, IPP JPS3 (first draft/outline), IPP Everywhere (first draft/outline), and PWG Common Log Format.

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Michael Sweet <[email-masked]>
Date: Tue, 8 Feb 2011 14:10:37 -0800

On Feb 8, 2011, at 10:42 AM, Petrie, Glen wrote:
> ...
> 
> Having just a source provider of the PWG raster is not interoperability.  I personally do not know of a printer that can read CUPS raster xxx or one that could be modified to read a subset.  So is emulation of a printer ok?  I also assume for interoperability, there must be two independent developments.
> 

WRT implementations, there is no differentiation between hardware, firmware, and software - anything that generates or consumes PWG Raster will be considered. As Ira points out, the multiple implementation argument doesn't come up until we advance from "PWG Candidate Standard" status to just "PWG Standard". Interoperability testing will be something that is included in the updated charter (just as we already have interop/bake-off milestones for IPP/2.0...)