Subject: [IPP] Initial version of IPP Scan posted

From: "Zehler, Peter" <[email-masked]>
Date: Tue, 5 Nov 2013 17:51:30 +0000

All,
I have posted an initial version of "IPP Scan Service" .  Please add IPP Scan to the agenda of the next IPP teleconference.

ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippscan10-201301105.pdf
http://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippscan10-201301105.pdf

ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippscan10-201301105.docx
http://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippscan10-201301105.docx

Peter Zehler

Xerox Research Center Webster
Email: [email-masked]<mailto:[email-masked]>
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701

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

---

From: Ira McDonald <[email-masked]>
Date: Tue, 5 Nov 2013 12:57:58 -0500

Hi Pete,

Thanks!

Did you take a look at Andrew's 2011 initial draft of IPP Scan Service?
Or start from a clean page?

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
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]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

On Tue, Nov 5, 2013 at 12:51 PM, Zehler, Peter <[email-masked]>wrote:

>  All,
>
> I have posted an initial version of “IPP Scan Service” .  Please add IPP
> Scan to the agenda of the next IPP teleconference.
>
>
>
> Email: [email-masked]
> Voice: (585) 265-8755
> FAX: (585) 265-7441
> US Mail: Peter Zehler
> Xerox Corp.
> 800 Phillips Rd.
> M/S 128-25E
> Webster NY, 14580-9701
>
>
>
>
>

---

From: Michael Sweet <[email-masked]>
Date: Tue, 05 Nov 2013 12:59:35 -0500

Pete,

Thanks!

On Nov 5, 2013, at 12:51 PM, Zehler, Peter <[email-masked]> wrote:

> All,
> I have posted an initial version of “IPP Scan Service” .  Please add IPP Scan to the agenda of the next IPP teleconference.
>  

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Michael Sweet <[email-masked]>
Date: Tue, 05 Nov 2013 14:30:48 -0500

Pete,

I like the direction of this draft, some quick comments (we can go into detail at the next concall, Nov 18th):

- (Editorial) All of the tables seem to be using the IEEE paragraph style; just re-style using Normal to get the proper row spacing…

- I think we want a new operation code for Get-Next-Scan-Document rather than re-using the Send-Document op code.  Op codes are cheap and these operations have completely different semantics (different direction of data flow, etc.)  Also, given our renaming of AddHardcopyDocument to AddDocumentImages for SM 3.0 and IPP FaxOut, I suggest the name Get-Document-Images for IPP Scan.

- For Get-Next-Scan-Document/Get-Document-Images, I think we want the document-format-accepted attribute from IPPSIX in the request - that will allow the Client to specify the formats it is able to consume, and the scanner can (re)package the document images up as appropriate. The document-format should be part of the response as well. The order of document-format-accepted values specifies the Client’s preferred format… Alternately we could add document-format-accepted to the Create-[Scan-]Job request - that might be more consistent and allow a spooling service to pre-fetch the document images in the preferred format. (I’d still put the document-format in the Get response…)

- Regarding note 1 on page 20, we deprecated Restart-Job, Purge-Jobs, and Reprocess-Job because of the accounting issues; I think the “Resubmit-Job” operation here is a typo (the operation is listed in the table, and 0x002c is “Reprocess-Job” - same bug is in IPP FaxOut...)

- Create[-Scan]-Job: Should add (optional) destination-uris to the operation attributes group; if omitted, creating a pull job…

- We should sync up input-attributes from FaxOut with this spec; in particular:

— None of the input-xxx attributes are defined in RFC 2911…

— input-color-entry was simplified to input-color-mode in FaxOut.  If we want to provide greater control over the representation of colors then I suggest we re-use the pwg-raster-document-type-supported keywords; we certainly can’t use the old SM Scan keywords as-is since IPP keywords are hyphenated-lowercase instead of TitleCase.  However, I personally feel that input-quality + input-color-mode are enough to cover 1-bit, 8-bit, and 16-bit grayscale and 24-bit or 48-bit RGB color; I’m not aware of any scanners that can produce an actual CMYK separation image (all of them convert from RGB) so there seems little point in supporting CMYK explicitly.

— input-compression-quality-factor is very JPEG-specific. While I understand the motivation for such an attribute, I question whether we need/want a JPEG quality control vs. providing guidance on using input-quality to set baseline JPEG quality factor values (or use it to choose between JPEG/JBIG vs. Flate compression) (alternately maybe we could use MIME media type parameters to specify the file format options?)

> Email: [email-masked]

_______________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair