My responses are inline below.
Peter Zehler
Xerox Research Center Webster
Email: Peter.Zehler at Xerox.com<mailto:Peter.Zehler at Xerox.com>
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: ipp-bounces at pwg.org [mailto:ipp-bounces at pwg.org] On Behalf Of Michael Sweet
Sent: Tuesday, August 06, 2013 11:35 AM
To: Zehler, Peter
Cc: IPP at pwg.org; mfd at pwg.org
Subject: Re: [IPP] Don't redefine Hardcopy Document
Pete,
The point of the discussion in the SM and IPP WGs is not to redefine what a hardcopy document is (although I would like to generalize what was put in 5108.01 since it ties them to specific services), but to include the definition of it and the corresponding (Hardcopy) Document Object (the digital representation of the hardcopy document) in the SM and IPP specifications.
Comments inline, but I'll make sure we include this in our discussions on Thursday...
On 2013-08-06, at 9:26 AM, "Zehler, Peter" <Peter.Zehler at xerox.com<mailto:Peter.Zehler at xerox.com>> wrote:
All,
A Hardcopy document is not an electronic format. The industry, and the PWG, have existing definitions that are in agreement (See below). A hardcopy document is physical media. In the PWG Semantic Model Documents are objects with references to document content that is an electronic document representation (e.g. PDF, JPEG, PCL, vendor specific). These representations have a type using MIME media types (See rfc2911 section 3.2.1.1).
This is the difference between a Hardcopy Document and a Hardcopy Document /Object/. We need to define the latter and not the former.
<PZ>I see no subclasses of Documents in the PWG Semantic Model or IPP. Whether a document is added to a Job by value, by reference, or by reference to the output of the scanner subunit, it is still just a Document object. There are differences in the operations that add a Document to a Job in how the Document Data (aka Digital Document) is transferred. The AddHardcopyDocument instructs the MFD to obtain the document content from its scanner subunit. A mobile device that takes a picture of a document with its camera would not issue an AddHardcopyDocument to the MFD. It would use AddDocument or AddUri.</PZ>
In IPP document content was either pass by value (i.e. via Print-Job or Send-Document) or by reference (i.e., Print-URI or Send-URI). For a FAX service we needed to represent the historical FAX paradigm of FAXing a hardcopy document. It is similar to a Send-URI but constrained to a reference to document content being obtained via the MFD's scanner subunit. Note that a mobile device that acquires an image from a hardcopy document would not issue an Add-Hardcopy-Document to the MFD. The mobile device would use the Send-Document or Send-URI based on how the document content would be transferred to the target MFD.
I disagree - mobile devices can and are used as a front-end to the MFD today. The hardcopy document may, in fact, be loaded in the MFD. The mobile device can scan and then send the scanned data to the MFD /or/ it can simple create a job that references the loaded hardcopy document to avoid the intermediate data transfers. And given that the scan destination semantics require some form of intermediate storage, I would argue that mobile devices would prefer to use Send/Add-Hardcopy-Document over scanning and submitting the scan.
<PZ>I don't understand what the disagreement is. Mobile devices can be used as a front end to MFDs. They can offer the AddHardcopyDocument operation to Clients. I would say that the Hardcopy Document MUST be loaded in the MFD's ADF or platen though. The mobile device front end would simply pass the operation through if the MFD supports IPP or other PWG compliant protocol. If the MFD is not PWG compliant, the mobile device would have to interact with the MFD to insure the Hardcopy Documents are scanned at the appropriate time and included correctly in the MFD's output. There would be nothing preventing an implementation of AddHardcopyDocument on the mobile device from using the MFDs Scan Service, or functional equivalent, to obtain the Digital Document from the scanning the hardcopy. But then the mobile device would be using SendDocument/SendUri with the MFD to add the document content it obtained from the Scan Service. I agree that mobile devices would prefer to use Send/Add-Hardcopy-Document over scanning and submitting the scan.</PZ>
I have no objection to normalizing the parameters for Adding a Hardcopy Document to a job. The ScanDocumentProcessing/CopyDocumentProcessing.CopyInput could easily be applied to AddHardcopyDocument and would apply to a number of services.
Right, that is the point of our discussions - how do we model Hardcopy Document /Objects/ (digital representations of Hardcopy Documents) in the SM and IPP? Aside from generalizing the Send/Add-Hardcopy-Document operation for multiple services, we need this for Cloud/IPPSIX to support indirect access to MFD scanners.
<PZ>Why wouldn't the ScanDocumentProcessing attribute be optional for documents receive via an Add/Add-Hardcopy-Document and an error if included in other operations. This would be similar to the document-uri attribute that is conditionally mandatory based on support for the Send-Uri operation. The ScanDocumentProcessing attribute, just like the document-uri attribute identified the source location of the document data. The ScanDocumentProcessing goes beyond that since it controls the document data acquisition processing as well.</PZ>
Pete
Existing definitions of Hardcopy Document:
>From Federal Standard 1037C (Telecommunications: Glossary of Telecommunication Terms): "hard copy: In computer graphics and in telecommunications, a permanent reproduction, on any media suitable for direct use by a person, of displayed or transmitted data. (188) Note 1: Examples of hard copy include teletypewriter pages, continuous printed tapes, facsimile pages, computer printouts, and radiophoto prints. Note 2: Magnetic tapes, diskettes, and nonprinted punched paper tapes are not hard copy."
>From Alliance for Telecommunications Industry Solutions Telecom Glossary: "In computer graphics and in telecommunications, a permanent reproduction, on any media suitable for direct use by a person, of displayed or transmitted data. Note 1: Examples of hard copy include teletypewriter pages, continuous printed tapes, facsimile pages, computer printouts, and radiophoto prints. Note 2: Magnetic tapes, diskettes, and nonprinted punched paper tapes are not hard copy."
>From Printer Working Group (PWG 5108.01): "Hardcopy Document: A Document on physical media such as paper, transparency or film that is the input source to Scan, Copy and FaxOut Services and the output from Print, Copy and FaxIn Services"
Peter Zehler
Xerox Research Center Webster
Email: Peter.Zehler at Xerox.com<mailto:Peter.Zehler at Xerox.com>
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
ipp at pwg.org<mailto:ipp at pwg.org>
https://www.pwg.org/mailman/listinfo/ipp
_____________
Michael Sweet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20130806/8806e8c1/attachment.html>