Subject: PWG-ANNOUNCE> MFD Specifications for Face to Face meeting

From: "Zehler, Peter" <[email-masked]>
Date: Sat, 14 Feb 2009 08:08:43 -0500

All,

I have updated the MFD page with all of the latest specifications.  Note
that both the Scan Service and Resource Service specifications have been
refreshed.  It is expected that an updated overall MFD document will be
available by the end of the weekend and used in discussions on Tuesday.

 The first day of the Face to Face meeting we will be discussing the
State issue that has recently been resolved.  Please read through
sections 7.6.1.10 and 10 of the Scan Service specification and be
prepared to discuss them on Monday.  The text from section 10 is
included below.  The specification is available at
<ftp://ftp.pwg.org/pub/pwg/mfd/wd/lcrc-mfdscanmodel10-20090213.pdf>. 

Pete

Peter Zehler

Xerox Research Center Webster
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 

The Scan Service operates autonomously through three phases:
initialization, online, and offline.

At start-up the Scan Service enters its initialization phase that
initializes all its service attributes and connected subunits. This
phase may include tests of the associated Subunits and self-testing of
the Scan Service itself.  After the initialization and tests are
successful, the Scan Service enters the online phase with a state of
"Idle".  The Scan Service is ready for service discovery and accepting
service requests from Scan Clients.  The Scan Service may authenticate
and register itself with a service directory or announces its service to
the network domain in which it resides. 

The Scan Service accepts new requests as long as it's not disabled and
is in one of the three states: Idle, Processing or Stopped.  Performing
an administrative Disable() operation while in any state will stop the
Scan Service from accepting new jobs. Performing an Enable() operation
in any state while the Scan Service is disabled will enable new jobs to
be accepted again.

A user submits a Scan Job through a local (via MFD UI) or remote (via
local network or Internet) Scan Client to a selected target Scan Service
that has the desired scan capabilities. While the service is enabled, a
Scan Client can request any Scan Service operations specified in
Sections 11.1 and 11.1.8.1. A Scan Client uses the CreateScanJob
operation to submit a Scan Job on behalf of a user. The Scan Service
places all submitted jobs in the ActiveJobs queue and schedules jobs for
processing immediately or when a StartJob event is signaled based on job
priority. A user may specify a JobHoldUntilTime in the Scan Job's Ticket
for a remotely submitted Scan Job to allow ample time for user to walk
up to the scanner for placing his/her Hardcopy originals on the scanner.
An administrator can also put a Scan Job in the ActiveJobs queue on hold
via a HoldScanJob() operation preventing it being scheduled and a
ReleaseJob() operation will release the Scan Job for scheduling again.

When a Scan Job is released for scheduling and reaches the top of
ActiveJobs queue, the Scan Service enters or remains in its Processing
state. During job processing, the Scan Service can be interrupted by a
"PauseScanService()" operation to enter the "Stopped" state. This allows
a user to submit and process an urgent Scan Job or a job for another
service, and a Resume() operation resumes previous Scan Job processing
afterwards.  Upon completion of a Scan Job the Scan Service moves the
Scan Job from the ActiveJobs queue to the JobHistory queue.

When there are critical conditions impacting Scan Serviceability during
"Idle" or "Processing" state, either a E.Critical event is generated or
an Administrative PauseScanService() is performed to bring the service
to the Stopped state. From there the condition can be fixed by user's
intervention. Then either the Scan Service generates a E.CriticalCleared
event or an administrator performs a Resume() operation to bring the
Scan Service back to "Idle" or "Processing" state. Otherwise, if the
Scan Service needs a ShutdownScanService() operation followed by a
restart or ShutdownScanService() for testing, both will require a
StartupScanService() operation to bring the service back to "Idle" state
and then job processing may continue.

The lifecycle for a Scan Job begins when it is created by the Scan
Service on behalf of a user issuing a CreateScanJob request.  The newly
created Scan Job is placed on the ActiveJobs queue.  The state of the
Scan Job is either 'Pending' or, if the request contained a
JobHoldUntilTime in the Scan Job's Ticket, 'PendingHeld'.  When the
conditions are met to release a 'PendingHeld' Scan Job, its state
transitions to 'Pending'.  Scan Jobs may be held and released through
administrative operations.  When a Scan Job reaches the top of the
ActiveJobs queue it is scheduled and the state of the Scan Job
transitions to 'Processing'.  If for any reason the Scan Service becomes
'Stopped' the state of a processing Scan Job becomes
'ProcessingStopped'.  When the Scan Service state returns to
'Processing' the Scan Job state returns to 'Processing'.  Upon
completion the status of the Scan Job becomed 'Completed'.  It is also
possible for a Scan Job to fail.  This causes the Scan Job state to
transition to 'Aborted'. At any time all Scan Jobs in the ActiveJobs
queue, whether being held, pending for scheduling, in processing, or
being temporarily stopped from processing, can be canceled via a
CancelScanJob() operation by an authorized user.  The Scan Job state
will then transition to 'Canceled'  Any Scan Job reaching a terminating
state of 'Completed', Canceled' or 'Aborted' is moved from the
ActiveJobs queue to the JobHistory queue.

---

From: [email-masked]
Date: Sun, 15 Feb 2009 20:06:18 +0000 (UTC)

Greetings: 

A very preliminary overall MFD document is posted at 

ftp://ftp.pwg.org/pub/pwg/mfd/wd/wd-mfdoverallmod10-20090214.pdf  , doc. 

This is very much a work in progress, and it is posted more to get direction than to allow review of specifics. 

This effort was not originally intended, but in proceeding with the Scan, Resource and FaxOut service documents, two different ideas suggesting an overall document developed: 

   1. There is much commonality between the services, and it seemed unreasonable to replicate large portions of text in each specfiication. 

    2. An MDF does have  overall features beyond just a collection of the features of the constituent Services. Further, the relationships and interaction among services and between services and the overall MFD shoudl be discussed. 

Although the objectives of addressing these ideas are not incompatible, there are differences in stress and degree of detail. Particularly with regard to the common features issue, there are the two conflicting desires of keeping the specifications conpact but not requiring a user to constantly flip  back and forth between the general and the specific document. 

The document has several specific QUESTIONS highlighted in yellow which arose when considering how to deal and whether to deal with a subject. I look foward to being able to discuss teh issues in these questions, and any other thoughts you may have in this projected approach. 

Many thanks, 

Bill Wagner 

----- Original Message ----- 
From: "Peter Zehler" <[email-masked]> 
To: [email-masked] 
Cc: [email-masked] 
Sent: Saturday, February 14, 2009 6:08:43 AM GMT -07:00 US/Canada Mountain 
Subject: MFD> MFD Specifications for Face to Face meeting 

All, 

I have updated the MFD page with all of the latest specifications.  Note that both the Scan Service and Resource Service specifications have been refreshed.  It is expected that an updated overall MFD document will be available by the end of the weekend and used in discussions on Tuesday.  

 The first day of the Face to Face meeting we will be discussing the State issue that has recently been resolved.  Please read through sections 7.6.1.10 and 10 of the Scan Service specification and be prepared to discuss them on Monday.  The text from section 10 is included below.  The specification is available at < ftp://ftp.pwg.org/pub/pwg/mfd/wd/lcrc-mfdscanmodel10-20090213.pdf >. 

Pete 

Peter Zehler 

The Scan Service operates autonomously through three phases: initialization, online, and offline. 

At start-up the Scan Service enters its initialization phase that initializes all its service attributes and connected subunits. This phase may include tests of the associated Subunits and self-testing of the Scan Service itself.  After the initialization and tests are successful, the Scan Service enters the online phase with a state of  “Idle”.  The Scan Service is ready for service discovery and accepting service requests from Scan Clients.  The Scan Service may authenticate and register itself with a service directory or announces its service to the network domain in which it resides. 

The Scan Service accepts new requests as long as it’s not disabled and is in one of the three states: Idle, Processing or Stopped.  Performing an administrative Disable() operation while in any state will stop the Scan Service from accepting new jobs. Performing an Enable() operation in any state while the Scan Service is disabled will enable new jobs to be accepted again. 

A user submits a Scan Job through a local (via MFD UI) or remote (via local network or Internet) Scan Client to a selected target Scan Service that has the desired scan capabilities. While the service is enabled, a Scan Client can request any Scan Service operations specified in Sections 11.1 and 11.1.8.1. A Scan Client uses the CreateScanJob operation to submit a Scan Job on behalf of a user. The Scan Service places all submitted jobs in the ActiveJobs queue and schedules jobs for processing immediately or when a StartJob event is signaled based on job priority. A user may specify a JobHoldUntilTime in the Scan Job’s Ticket for a remotely submitted Scan Job to allow ample time for user to walk up to the scanner for placing his/her Hardcopy originals on the scanner. An administrator can also put a Scan Job in the ActiveJobs queue on hold via a HoldScanJob() operation preventing it being scheduled and a ReleaseJob() operation will release the Scan Job for scheduling again. 

When a Scan Job is released for scheduling and reaches the top of ActiveJobs queue, the Scan Service enters or remains in its Processing state. During job processing, the Scan Service can be interrupted by a “PauseScanService()” operation to enter the “Stopped” state. This allows a user to submit and process an urgent Scan Job or a job for another service, and a Resume() operation resumes previous Scan Job processing afterwards.  Upon completion of a Scan Job the Scan Service moves the Scan Job from the ActiveJobs queue to the JobHistory queue. 

When there are critical conditions impacting Scan Serviceability during “Idle” or “Processing” state, either a E.Critical event is generated or an Administrative PauseScanService() is performed to bring the service to the Stopped state. From there the condition can be fixed by user’s intervention. Then either the Scan Service generates a E.CriticalCleared event or an administrator performs a Resume() operation to bring the Scan Service back to “Idle” or “Processing” state. Otherwise, if the Scan Service needs a ShutdownScanService() operation followed by a restart or ShutdownScanService() for testing, both will require a StartupScanService() operation to bring the service back to “Idle” state and then job processing may continue. 

The lifecycle for a Scan Job begins when it is created by the Scan Service on behalf of a user issuing a CreateScanJob request.  The newly created Scan Job is placed on the ActiveJobs queue.  The state of the Scan Job is either ‘Pending’ or, if the request contained a JobHoldUntilTime in the Scan Job’s Ticket, ‘PendingHeld’.  When the conditions are met to release a ‘PendingHeld’ Scan Job, its state transitions to ‘Pending’.  Scan Jobs may be held and released through administrative operations.  When a Scan Job reaches the top of the ActiveJobs queue it is scheduled and the state of the Scan Job transitions to ‘Processing’.  If for any reason the Scan Service becomes ‘Stopped’ the state of a processing Scan Job becomes ‘ProcessingStopped’.  When the Scan Service state returns to ‘Processing’ the Scan Job state returns to ‘Processing’.  Upon completion the status of the Scan Job becomed ‘Completed’.  It is also possible for a Scan Job to fail.  This causes the Scan Job state to transition to ‘Aborted’. At any time all Scan Jobs in the ActiveJobs queue, whether being held, pending for scheduling, in processing, or being temporarily stopped from processing, can be canceled via a CancelScanJob() operation by an authorized user.  The Scan Job state will then transition to ‘Canceled’  Any Scan Job reaching a terminating state of ‘Completed’, Canceled’ or ‘Aborted’ is moved from the ActiveJobs queue to the JobHistory queue.