Hi,
I was recently asked a question about RFC 2707 (Job MIB 1.0) and when I
pulled up the document, I found the following text on the first page:
"IESG Note
This MIB module uses an unconventional scheme for modeling management
information (on top of the SNMP model) which is unique to this MIB. The IESG
recommends against using this document as an example for the
design of future MIBs.
The "Printer Working Group" industry consortium is not an IETF working
group, and the IETF does not recognize the Printer Working Group as a
standards-setting body. This document is being published solely to provide
information to the Internet community regarding a MIB that might be
deployed in the marketplace. Publication of this document as an RFC is not
an endorsement of this MIB."
I think that Pete makes a good observation in his point #1 that as an
IEEE-ISTO standards body, the PWG does need to consider carefully the
potential deprecation of an existing PWG standard in favor of handling the
same task in a totally new way rather than a deprecation due to the
publishing of a new updated version of a specification that obsoletes the
previous version.
Best Regards,
/Paul
--
Paul Tykodi
Principal Consultant
TCS - Tykodi Consulting Services LLC
Tel/Fax: 603-343-1820
Mobile: 603-866-0712
E-mail: ptykodi at tykodi.com
WWW: <http://www.tykodi.com/> http://www.tykodi.com
From: mfd-bounces at pwg.org [mailto:mfd-bounces at pwg.org] On Behalf Of Zehler,
Peter
Sent: Wednesday, July 03, 2013 2:08 PM
To: Michael Sweet
Cc: mfd at pwg.org; Manchala, Daniel
Subject: RE: [MFD] Meeting Minutes: IEEE/ISTO - PWG/Semantic Model Working
Group, 1 July 2013
All,
My position on the Copy Service is
1) The PWG has published a standard specification for the Copy Service
(PWG 5108.04). As a standards organization I believe it is not in the best
interest of the PWG to decide that a specification approved more than two
years ago is no longer relevant and that furthermore there is a completely
new way to implement the feature.
2) The PWG published a standard specification for Imaging System
Counters (PWG5106.1 - 2007) and an associated MIB (PWG5106.3 - 2008) include
the Copy Service.
3) From the beginning of the SMv2( aka MFD) work the goal was to model
user facing services of MFDs. Copy is a distinct user facing feature of an
MFD.
4) There was a need for remote service, device, and job management
capabilities so that administrators, operators, and end users can monitor
their health and status. In addition, there is a need for remote job
submission capabilities so that operators and end users can create
sophisticated jobs (e.g., with image enhancement, image transformation,
etc.) without necessarily depending entirely on local console interfaces
(which may have limited functionality).
5) These objectives above are of particular importance in light of
today's move towards mobile device centric network interactions.
6) There are still companies out there that have products that allow
very complex copy job construction in a production/demand-print environment.
Simply specifying a document to be sourced from a scanner instead of passing
it by value (i.e., AddDocument) or reference (i.e., SendUri) is not
sufficient.
7) AddHardCopyDocument initiates an immediate document data transfer
(i.e., "MUST be prepared to add Document Data from the identified input to
the identified Job"). The operation is analogous to SendUri operation in
that the data is not appended to the network operation.
8) AddHardCopyDocument can only be used on a Job that has not been
closed. Only closed Jobs are available for scheduling and allowed to move
to the processing state.
9) There are real world use cases that require site specific policy to
be applied to Copy, Scan, Print and Fax. The existing PWG model is
structured to facilitate this service level control.
10) Customers in managed environments want to the usage counters from a
MIB, a Service Interface and an invoice all agree with regards to what they
are being charged.
11) There are deployments that charge differently for Copy Jobs then they
do for Print Jobs. Separate services keeps this simple.
12) In managed environments queues need to be run out before another queue
is allowed to be processed. In those environments a Print Service is Paused
until the printing completes. The Copy Service can then be Resumed allowing
those jobs to be handled. Then the Copy Service is Paused and a Print
Service is Resumed. This is a real world scenario that is extremely
complicated by mashing together Copy and Print into a single service.
13) All Services that have hardcopy input should be normalized before SMv2
is published.
14) There are optimizations that are available to an implementation of a
Copy Service that is not available to and implementation of a Print Service
in some environments. The effect of merging these two services could be
accomplished by hiding the internal Print and Copy queues behind a network
Print Service. I do not think that complexity should be forced on an MFD in
exchange for reduced control and monitoring and abandoning a standard that
is being used in products today.
15) I personally don't like AddHardCopyDocument as a Print Service
operation. I view Print as images in and impressions out. The submission
is always an electronic document or a reference to one. I prefer copy as
its own service and not a modified Print Job or a composite job modeled as
Scan to Print. I may not like AddHardCopyDocument as a Print Service
operation but I would not strenuously object to its optional inclusion. But
that operation would be used during Job Creation just as the other Add
operations are now.
Peter Zehler
Xerox Research Center Webster
Email: <mailto:Peter.Zehler at Xerox.com> 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: Michael Sweet [mailto:msweet at apple.com]
Sent: Wednesday, July 03, 2013 12:03 PM
To: Zehler, Peter
Cc: Manchala, Daniel; mfd at pwg.org
Subject: Re: [MFD] Meeting Minutes: IEEE/ISTO - PWG/Semantic Model Working
Group, 1 July 2013
Pete,
On Jul 3, 2013, at 10:55 AM, Zehler, Peter <Peter.Zehler at xerox.com> wrote:
...
On Jul 2, 2013, at 7:45 PM, Manchala, Daniel <Daniel.Manchala at xerox.com>
wrote:
...
1. Do we need to have a separate Copy Service? The reason to have a
separate Copy Service is that there are hardware optimizations that take
place in a copy job that are not available to print.
Such as?
<PZ>Scanning image into a proprietary format that is device specific.
Vendors may wish to keep details of such a format private. There are
optimizations that might be used for the transfer channel between the
scanning subunit and the marker subunit. Several steps in the print service
can be eliminated.</PZ>
How does adding a hardcopy document to a print job prevent any of those
optimizations from happening?
The hardcopy document can be represented internally in any format by the
implementation - this is part of the existing model.
The implementation controls the transfer channel between the scanning
subunit and the marker subunit. Nothing in the model (or my proposed
addition to Print to support the copy use case) would prevent the imaging
device from using a proprietary format, optimized transfer channel, or magic
pixie dust to optimize that imaging path, even on devices that support
spooling of multiple jobs.
So which steps are we eliminating by using a Copy service vs. a Print
service that supports hardcopy documents?
Modeling copy as print requires intermediate image storage from the
AddHardCopyDocument to the time the print job is scheduled.
Why? For a Printer that only allows a single job at a time (the vast
majority of printers), AddHardcopyDocument could stream the image data from
the scanner to the print engine just as if a Client was streaming via
Send-Document. No intermediate storage is required.
<PZ>There are many printers that support queuing multiple jobs at a time.
There are printers capable of processing multiple jobs at a time. Don't
take a proven scalable model and protocol and constrain its capability based
on a subset of the market. Adding a Hard Copy Document to a job does not
require streaming the image data to the print engine. I see nothing in the
model or protocol from allowing the addition of documents to a pending or
pending-held job. Keep in mind that an open job (i.e., no CloseJob
operation received) cannot be the scheduled or be the currently active job.
Also keep in mind that AddHardCopyDocument is an illegal operation on a
closed job.</PZ>
OK, so going back to my last point about defining what a hardcopy job is,
what is wrong with defining a document object that has a reference to an
internal resource (the scanner) that is resolved (scanned) when it goes into
the processing state? This matches what we do for printing with URIs,
doesn't require a document to be added to a closed job, and allows the
implementation to determine when the hardcopy document is scanned and either
stored or streamed to the marker subunit?
I am by no means trying to constrain the model - I actually want printers to
be MORE capable, not less - but am rather trying to simplify and unify
support for hardcopy documents in the model, something that we have (thus
far) shoved off into the corner as an edge case that effectively needs
special software and works in slightly different and incompatible ways.
So please consider the following: rather than assuming the only way to
support the copy use case is with a first class Copy service, let's revisit
hardcopy documents *first* and come up with a consistent model to support
them for all services that can use them.
That will yield a more consistent and feature-rich interface for Scan,
FaxOut, and EmailOut. It may also make the decision of whether we need a
first-class Copy service more clear.
And certainly if a Printer *does* support spooling of multiple jobs a Copy
service job will wait in queue just as effectively as a Print service job -
again, I don't see the need to force intermediate storage of the scanned
document, it would just be an implementation choice. <PZ>A Copy Service Job
does not wait as effectively in a print Service queue. A copy job is
constructed at the device meaning the documents within the job are added
during the construction of the job. There are MFDs that provide a very rich
set of document assembly choices for copy jobs. It is not always just
putting a page on the platen and pressing copy. Even if intermediate
storage is not required there are reasons stated above and below to treat a
copy job as a copy job and not some modified print job. />
Again, I haven't read anything that would preclude the Print service
performing all of the functions of the Copy service.
A copyjob does not suffer that sub-optimal image flow construct. Users are
very familiar with copy and would be confused with a copy job showing up in
a print queue.
More confused than seeing their print job wait for an unknown reason? Both
Print and Copy use the marker, but if somebody is making 100 copies of a 50
page presentation the user sending a print job could be waiting for a long
time wondering why their job isn't printing. If instead they see a print
job in the queue (for the copy) they will understand why their job isn't
printing.
<PZ>Why would a JobStateReason of 'JobQueueForMarker' be any more confusing
than 'PrinterStopped' when there is a paper jam. Naturally the Client
software would present that to the user in an understandable format. Sooner
or later there will have to be a service to show user's the unified view of
the MFD. Why shouldn't a user be able to see a unified queue of all the
jobs on an MFD?</PZ>
No reason, it is just that much more work for the Client to do if there is
this extra service that sort-of works like the others, puts things in
different places, and has no documents. Copy has been as a special-case
service that has to do things differently, yet when you look at what the
Copy service does it isn't clear why this has to be so.
The normal use case for a copy job is the walk up user who is physically
present on the device.
Right, and that user doesn't care how the printer performs the copy, just
that they get the copies they want.
<PZ>Printers don't perform copies, MFDs or Copiers do. The workflow at the
device may be quite different when trying to copy on an inactive device or
on a device that is currently printing a job. There may also be differences
when trying to print pictures from a SD memory card versus copying a
picture. User's don't care how an MFD does anything, they just want their
output. But service provider do care how the jobs and services are
represented in the model.
A user *might* call it a copier. I don't know that anyone makes the
distinction of "MFD" or "MFP" - I'm in the printing engineering department
of Apple and *we* just say "I'll make a copy at the printer."
So my use of casual terminology aside, you are very effectively making MY
point - hardcopy documents are not currently represented in the model. In
FaxOut we added Add<service>HardcopyDocument to represent hardcopy documents
in FaxOut jobs, and in Copy we waved our hand and said "these are not the
documents you are looking for".
We absolutely need to be able to represent hardcopy documents in the model.
They are not currently represented. Once we *do* represent them we can
support directly them in the Print, Scan, FaxOut, and EmailOut services - at
that point does it still make sense to have a separate Copy service? Maybe
so, maybe not. I just don't think it is a foregone conclusion that one *is*
absolutely required. And if we *do* end up with a Copy service, it should
have jobs with one or more (hardcopy) document objects, just like the other
services.
A related issue is that lumping copy in with print diminishes the ability to
monitor, manage and charge for copies.
Why? Can't we provide Job History for Print Jobs that have a hardcopy
document?
<PZ>It certainly complicates the ability to pause/resume and enable/disable
individual services.
How?
If you are using the Copy service as a way to provide access control
(disable copy service, nobody can copy from the Imaging Device?) then I
suggest that we work in IDS to define proper access control mechanisms.
It makes it more complicated to check to see if a service is available.
Again, are you trying to query an access control policy? Or supported
operations (copy disabled means Add<service>HardcopyDocument is not
supported)?
It makes it more difficult to establish policy for users a specific service.
There are real world needs to independently control printing and copying and
faxing on an installed MFD.
Agreed. But having implemented arbitrarily complex ACLs for CUPS, I don't
think separate functional services are necessarily the answer. But I *do*
think that the current Copy service model isn't the answer.
It will break the existing Standardized Imaging System Counters and
associated MIB standards.</PZ>
How so? The system-level (SystemTotals) counters don't break out Copy
counts, just total impressions and so forth. The Job MIB and various
counters are broken out by service types (and not necessarily services - for
example FaxIn vs. NetworkFaxIn, which are both supported by the single FaxIn
service).
More over additional IPP FaxOut and EmailOut (scan elements / aspects) are
presently adhoc and could be brought into a Copy Service.
I'm not sure I understand this comment.
<PZ>Adding a hardcopy document should be consistent across the services that
deal with hard copy input (e.g., scan, faxout, copy).</PZ>
I'm in 100% agreement.
The current CopyInTicket and CopyOutTicket try to overload the processing
intent for both input and output. This makes it impossible for a generic
print client to initiate a copy - fairly extensive modifications are
necessary. FaxOut and EmailOut, in comparison, require only modest changes
to add UI to specify the destination of the fax or email, and optionally UI
to support selection of a hardcopy document instead of a local document or
accessible URL.
<PZ>A generic Print Client should not be initiating a copy.
Because???
(how many smart phone/tablet applications are there from every printer
vendor that allow you to print, scan, fax, copy, etc.?)
Print Job certainly cover the output side (i.e., Print), but it does not
cover the input side (i.e., Scan). I disagree that the only changes to
print for fax or email are limited to the selection of the hardcopy
document. Certainly a low-end implementation could do that. Higher end
clients would want the ability to correct things like brightness, contrast,
and sharpness.</PZ>
Sure, but that is all common to scanning - something that a client will
likely want to do with a multifunction Imaging Device. And something that
presumably will be done using common code in the client to support Imaging
Devices.
If we implement Copy through the Print service with AddHardcopyDocument, the
same print client and UI for Print, FaxOut, and EMailOut can be reused, the
user can monitor both print and copy jobs in one place/queue, and the
Imaging Device has one less service to maintain separately with slightly
different semantics from the others.
<PZ>Print, Scan, Copy, FaxIn, and FaxOut are different and should be handled
separately. EmailIn and EmailOut are an awful lot like FaxIn and FaxOut
and since I have seen no strong pull for them I'll ignore them for now. If
the objective is to have an MFD client then one solution would be to
implement a unifying view into the services. Another solution would be to
extend 5108.06 to provide a unified queue with the usual queue operations.
I see no reason to abandon the model or to try and shoehorn separate
services into one. The Service, Job, and Document objects are similar
enough to provide a unified view.
We can argue whether the same UI gets used for print, fax, email, etc., but
that's not my specific focus. Underneath the UI, the same code ends up
getting used (to generate the paged data, to talk to the local service(s),
to talk to the Imaging Device), and generally the HI guys want to present a
similar user experience for dealing with documents and Imaging Devices.
I'm not arguing for a single meta service that does everything. Nor am I
arguing for a single UI to support all functions of an Imaging Device.
Rather, I am arguing for a consistent, well-defined model of Imaging Devices
that can be implemented and interoperable, without a lot of special casing.
Maybe we need a Copy service, maybe we don't. But if we do, it should be
consistent with the rest of the job-based services.
There *are* some elements from CopyInTicket that are not present in
InputElements/input-attributes - this I noted in the current IPP FaxOut
specification. But the current SM FaxOut specification only allows
specification of InputSource, which is clearly deficient.
<PZ>This is a good opportunity to normalize the specification of hard copy
input document processing.</PZ>
Again, we're in 100% agreement here.
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
--
This message has been scanned for viruses and
dangerous content by <http://www.mailscanner.info/> MailScanner, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/mfd/attachments/20130703/9300375a/attachment-0002.html>