Standard For Internet Printing ... - Printer Working Group



March 24, 2008

wd-mfdscanreq01-2008 Working Draft

The Printer Working Group

Network Scan Service

Use Cases and Requirements

Status: Interim

Abstract: Network print devices have evolved to support additional multifunction services, in particular Scan Service. When network Scan Devices are installed in local office or enterprise networks, they need remote service, device, and job management capabilities so that administrators, operators, and end users can monitor their health and status. In addition, such network Scan Devices need remote job submission capabilities so that operators and end users can create Scan Jobs without depending entirely on local console interfaces. This document specifies the use cases and requirements for the PWG abstract scan service model of these network Scan Devices.

Copyright (C) 2007, The Printer Working Group. All rights reserved.

This document may be copied and furnished to others, and derivative works that comment on, or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice, this paragraph and the title of the Document as referenced below are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Printer Working Group, a program of the IEEE-ISTO.

Title: Network Scan Service Use Cases and Requirements

The IEEE-ISTO and the Printer Working Group DISCLAIM ANY AND ALL WARRANTIES, WHETHER EXPRESS OR IMPLIED INCLUDING (WITHOUT LIMITATION) ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

The Printer Working Group, a program of the IEEE-ISTO, reserves the right to make changes to the document without further notice. The document may be updated, replaced or made obsolete by other documents at any time.

The IEEE-ISTO and the Printer Working Group, a program of the IEEE-ISTO take no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights.

The IEEE-ISTO and the Printer Working Group, a program of the IEEE-ISTO invite any interested party to bring to its attention any copyrights, patents, or patent applications, or other proprietary rights, which may cover technology that may be required to implement the contents of this document. The IEEE-ISTO and its programs shall not be responsible for identifying patents for which a license may be required by a document and/or IEEE-ISTO Industry Group Standard or for conducting inquiries into the legal validity or scope of those patents that are brought to its attention. Inquiries may be submitted to the IEEE-ISTO by e-mail at:

info@ieee-

The Printer Working Group acknowledges that the IEEE-ISTO (acting itself or through its designees) is, and shall at all times, be the sole entity that may authorize the use of certification marks, trademarks, or other special designations to indicate compliance with these materials.

Use of this document is wholly voluntary. The existence of this document does not imply that there are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to its scope.

About the IEEE-ISTO

The IEEE-ISTO is a not-for-profit corporation offering industry groups an innovative and flexible operational forum and support services. The IEEE Industry Standards and Technology Organization member organizations include printer manufacturers, print server developers, operating system providers, network operating systems providers, network connectivity vendors, and print management application developers. The IEEE-ISTO provides a forum not only to develop standards, but also to facilitate activities that support the implementation and acceptance of standards in the marketplace. The organization is affiliated with the IEEE () and the IEEE Standards Association ().

For additional information regarding the IEEE-ISTO and its industry programs visit:

.

About the Printer Working Group

The Printer Working Group (or PWG) is a Program of the IEEE-ISTO. All references to the PWG in this document implicitly mean “The Printer Working Group, a Program of the IEEE ISTO.” The PWG is chartered to make printers and the applications and operating systems supporting them work together better. In order to meet this objective, the PWG will document the results of their work as open standards that define print related protocols, interfaces, data models, procedures and conventions. Printer manufacturers and vendors of printer related software would benefit from the interoperability provided by voluntary conformance to these standards.

In general, a PWG standard is a specification that is stable, well understood, and is technically competent, has multiple, independent and interoperable implementations with substantial operational experience, and enjoys significant public support.

Contact information:

The Printer Working Group

c/o The IEEE Industry Standards and Technology Organization

445 Hoes Lane

Piscataway, NJ 08854

USA

MFD Web Page: MFD Mailing List: mfd@

Instructions for subscribing to the MFD mailing list can be found at the following link:



Members of the PWG and interested parties are encouraged to join the PWG and MFD WG mailing lists in order to participate in discussions, clarifications and review of the WG product.

Contents

1 Introduction 6

2 Summary 6

3 Terminology 7

3.1 Conformance Terminology 7

3.2 Content Specific Terminology 8

4 Rationale 10

4.1 Rationale for this Scanning Service Specification 10

5 Out of Scope for Scan Service 11

6 Use Cases 12

6.1 Use Case 1: Create Scan Job Template from a Remote Network Scanning Client Application 12

6.1.1 Processing Flow Requirements 12

6.1.2 Use Case Design Requirements 13

6.2 Use Case 2: Walk Up Scanning from an Existing Scan Job Template 14

6.2.1 Processing Flow Steps 14

6.2.2 Design Requirements 15

6.3 Use Case 3: Scan from a Computer, Multiple Sets of Originals 16

6.3.1 Processing Flow Steps 16

6.3.2 Design Requirements 18

6.4 Use Case 4: Walk-Up Batch Scan 18

6.4.1 Processing Flow Steps 19

6.4.2 Design Requirements 20

6.5 Use Case 5: Finding a Previously Scanned Document Location 20

6.5.1 Processing Flow Steps 20

6.5.2 Design Requirements 21

6.6 Use Case 6: Pause Scan Service for Copying 21

6.6.1 Processing Steps 21

6.6.2 Design Requirements 22

6.7 Use Case 7: Scan Service Discovery 22

6.7.1 Processing Flow Steps 23

6.7.2 Design Requirements 23

6.8 Use Case 8: Scan Service Capability Discovery 24

6.8.1 Processing Flow Steps 24

6.8.2 Design Requirements 25

7 Conformance Requirements 25

8 PWG and IANA Registration Considerations 25

9 Internalization Considerations 25

10 Security Considerations 25

10.1 Storing Scan Documents in a Document Repository 25

10.2 Protection of End User’s Scan Documents 25

10.3 Protection of a “Restricted Use” Scan Job Template 26

10.4 Restricted Use of Scan Service Features 26

10.5 Preventing DoS Attack Through High Priority Job 26

10.6 Security for Service Discovery 26

11 References 26

11.1 Normative References 27

11.2 Informative References 27

12 Author’s Address 27

Figures

Figure 1 Create Template from Remote Client 12

Figure 2 Walk-up Scanning from an existing Scan Job Template 15

Figure 3 Scan from a Computer, Multiple Set of Originals 17

Figure 4 Walk-up Batch Scan 19

Figure 5 Finding a Previously Scanned Document Location 20

Figure 6 Disable Scan Service for Copying 21

Figure 7 Scan Service Discovery via Service Directory 22

Figure 8 Scan Service Discovery via Discovery Protocol 23

Figure 9 Scan Service Capability Discovery 24

Introduction

This document specifies the use cases and the requirements for the PWG abstract scan service model of a MultiFunction Device (MFD). Included in this document is the content specific terminology, the design and processing requirements, the internationization requirements and the security considerations. These use cases and requirements help define the PWG MFD scanning service abstract models that include the functional models and interfaces of the associated scanning services for a local or enterprise network connected multifunction device. The abstract models are specified in a separate document entitled: “Network Scan Service Semantic Model and Service Interface”.

Summary

The MFD scanning services addressed in this specification are, specifically, the Scan Service and the

Template Manager Service. The Scan Service responds to queries about its capabilities, configuration and descriptive information. It responds to queries for information about the Scan Jobs and their associated

Documents. It manages and processes Scan Jobs with its associated Scan Job Ticket and stores the digital

output. The Scan Template Manager Service is an instance of the Template Manager, allows clients to store, retrieve and manage Scan Job Templates. A network scanning client application contains a Scan Client and optionally a Scan Template Manager Client. A network scanning client application interacts with the end user to obtain the end user’s Scan Intent and uses a Scan Client to communicate with the Scan Service that will execute the end user’s Scan Intent. A network scanning client application may contain a Scan Template Manager Client that obtains Scan Templates from the Scan Template Manager Service. Scan Templates contain instructions representing preconfigured scan intent that can be used as is or modified by the end user. Once the end user is satisfied with the Scan Template the network scanning client application passes the Scan Job Template to the Scan Job Client for submission to the Scan Service.

The scanning scenarios being addressed in this document ranges from walk-up scanning using the MFD’s front panel to remote scanning from an end user’s computer to support for document on-ramp scanning using enterprise workflow applications. When shared by a workgroup using different functions of the MFD, the model supports interruption of a large Scan Job to perform other MFD functions including a different Scan Job. For batch job scanning of either single or multiple documents, the model supports automated scanning of a stack of documents separated by an individual Scan Instruction Sheet. The model also supports external security services that protects against unauthorized use of the scanning services and access of scanned digital data.

Terminology

1 Conformance Terminology

Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, MAY, RECOMMENDED and OPTIONAL, have special meaning relating to conformance as defined in RFC 2119 [RFC2119].

|Term |Definition |

|MUST |This word means that the definition is an absolute requirement of the specification. |

|REQUIRED |This word means that the definition is an absolute requirement of the specification. |

|SHALL |This word means that the definition is an absolute requirement of the specification. |

|MUST NOT |This phrase means that the definition is an absolute prohibition of the specification. |

|SHALL NOT |This phrase means that the definition is an absolute prohibition of the specification. |

|SHOULD |This word means that there may exist valid reasons in particular circumstances to ignore a particular item, but the |

| |full implications must be understood and carefully weighed before choosing a different course. |

|SHOULD NOT |This phrase mean that there may exist valid reasons in particular circumstances when the particular behavior is |

| |acceptable or even useful, but the full implications should be understood and the case carefully weighed before |

| |implementing any behavior described with this label. |

|RECOMMENDED |This word means that there may exist valid reasons in particular circumstances to ignore a particular item, but the |

| |full implications must be understood and carefully weighed before choosing a different course. |

|NOT RECOMMENDED |This phrase mean that there may exist valid reasons in particular circumstances when the particular behavior is |

| |acceptable or even useful, but the full implications should be understood and the case carefully weighed before |

| |implementing any behavior described with this label. |

|MAY |This word means that an item is truly optional. One vendor may choose to include the item because a particular |

| |marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the |

| |same item. An implementation which does not include a particular option MUST be prepared to interoperate with |

| |another implementation which does include the option, though perhaps with reduced functionality. In the same vein an |

| |implementation which does include a particular option MUST be prepared to interoperate with another implementation |

| |which does not include the option (except, of course, for the feature the option provides.) |

|OPTIONAL |This word means that an item is truly optional. One vendor may choose to include the item because a particular |

| |marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the |

| |same item. An implementation which does not include a particular option MUST be prepared to interoperate with |

| |another implementation which does include the option, though perhaps with reduced functionality. In the same vein an |

| |implementation which does include a particular option MUST be prepared to interoperate with another implementation |

| |which does not include the option (except, of course, for the feature the option provides.) |

2 Content Specific Terminology

|Term |Definition |

|Attribute |A property or characteristic of an abject. |

|Default Scan Job Ticket |A Scan Job Ticekt data object that is bound to an instance of a Scan |

| |Service. The values contained in the Default Scan Job Ticket are the |

| |values that will be used by the Scan Service when processing a |

| |Scan Job whose Scan Job Ticket does not specify a different value. |

|Destination URL |Alternative term for Scan Destination. (See Scan Destination below) |

|Digital Document |The output of a scan service containing the digitized data resulting from the scanning of Hardcopy |

| |Document(s). The images scanned are encoded in an image or document format and stored at a Scan Destination.|

|Directory Service |A software application or a set of applications that stores and organizes information about a computer |

| |network’s users and resources, and that allows network administrators to manage user’s accesses to the |

| |resources. |

|Discovery Client |A software application that performs service or resource discovery on a computer network. |

|Document Repository |A local or remote data store where Digital Documents are stored by the Scan Service. |

|Hardcopy Document |A physical document in the form of paper, transparency, film, etc. that is the input source for a Scan Job. |

| |The Hardcopy Document is scanned by the Scan Device and the images transformed by the Scan Service into a |

| |Digital Document and stored in at the Scan Destination within a Document Repository. |

|Local Client |Alternative term for Local Scan Client. (See Local Scan Client and Scan Client below.) |

|Local Scan Client |The Scan Client application within the MFD. (See Scan Client below.) |

|Physical Scan Document Ticket |A encoded Hardcopy Scan Document Ticket, directly marked by the end user, that becomes a Scan Document Ticket|

| |data object after being scanned and processed. |

|Physical Scan Job Ticket |An encoded Hardcopy Scan Job Ticket, directly marked by the end user, that becomes a Scan Job Ticket data |

| |object after being scanned and processed. |

|Remote Scan Client |The Scan Client application external to the MFD. (See Scan Client below.) |

|Scan Client |The local or remote software entity that interfaces with the end user and interacts with a Scan Service. |

|Scan Destination |The end point network address (i.e. URL) of a storage location for the Digital Document of a Scan Job. |

|Scan Device |The MFD subsystem that is responsible for image acquisition and media handling (i.e. the scanner). |

|Scan Document |The data object managed by a Scan Service that contains document level description, processing, status |

| |information of a document within a Scan Job. |

|Scan Document Data |This term is used interchangeable with Digital Document throughout this specification. (See Digital Document |

| |above) |

|Scan Document Ticket |A data object that contains document processing and descriptive |

| |properties of a Scan Document. Any document processing properties |

| |in the Scan Document Ticket will override the values specified in the |

| |Scan Job Ticket’s document processing properties. The content of a |

| |Scan Job Ticket is configured by end user through a Scan Client. |

|Scan Intent |The end user’s preferences for the processing and description properties of a Scan Job. |

|Scan Job |A data object, created and managed by a Scan Service, that contains the description, processing, and status |

| |information of a job submitted by a user. The Scan Job can contain one or more document objects. The |

| |purpose of a Scan Job is to acquire the digital content (images) of scanned Hardcopy Documents and store them|

| |at a specified destination in a specified document format |

|Scan Job Receipt |An attribute of the Scan Service that contains information on the actual values of processing attributes used|

| |by the Scan Service for processing a Scan Job. The content of a Scan Job Receipt is populated by the Scan |

| |Service when a Scan Job is processed. |

|Scan Job Ticket |A data object that contains document processing, job processing and |

| |descriptive job properties of a Scan Job. The job elements apply to |

| |the entire JScan Job. The document processing elements will be |

| |used for all the documents within the Scan Job unless overridden at |

| |the document level (See Scan Document Ticket). The content of a |

| |Scan Job Ticket is configured by end user through a Scan Client. |

|Scan Job Template |A Scan Job Ticket data object that is not bound to a Scan Job. Scan Job Template can be stored or retrieved |

| |from the Scan Template Manager Service collocated on the MFD or hosted on a remote system. |

|Scan Service |A software service that accepts and processes requests to create, monitor and manage Scan Jobs. The software |

| |service accepts and processes requests to monitor and control the status of the service itself and its |

| |associated resources.. A Scan Service is hosted either locally or remotely to the MFD, |

|Scan Service Discovery |A method that enables a Scan Client to locate a transport endpoint of a Scan Service. The method can be |

| |static (i.e. lookup in a directory or database) or dynamic (i.e. through the use of protocols designed for |

| |service discovery). |

|Scan Template Manager Client |The local or remote software entity that interfaces with the end user and interacts with a Scan Template |

| |Manager Service. |

|Scan Template Manager Service |An instance of the Template Manager Service that specifically provides storage, and retrieval of Scan Job |

| |Templates. |

|Template Manager Client |The local or remote software entity that interfaces with the end user and interacts with a Template Manager |

| |Service. |

|Template Manager Service |A software service that provides storage, and retrieval of Job Templates of a MFD service. |

| | |

|Template Repository |A persistent storage for storing Scan Job Templates. |

Rationale

1 Rationale for this Scanning Service Specification

In order to support common functionality for scanning using network multifunction devices, there is a clear need to develop a semantic model and a set of objects, attributes and abstract operations for scanning related services. In order to implement an abstract model of the operations and attributes for scanning related services, there is need to map them onto implementable applications and communication protocols that support interactions between Scan Clients and Scan Services. There is a clear need to define a binding of the abstract model into Web Service Schema and Web Service protocol stack.

Out of Scope for Scan Service

The basic scanning service model defined in this document is targeted to support enterprise scan applications. However this document does not specify any application specific semantics. The MFD Working Group charter defines the following as out of scope:

1. Semantics of any compound service such as Scan-To-Email, Scan-To-Fax, Scan-To-Mailbox, or Scan-To-Print of which the additional semantics associated with accessing the specific document repositories SHALL be defined in other services, not included in the scanning services.

2. Semantics of any workflow protocol, i.e., sequencing and coordination of scanning jobs across multiple services.

3. Semantics of any scanning service management operations for MFDs that are not network connected.

4. Semantics for the creation of new document or file formats.

Use Cases

1 Use Case 1: Create Scan Job Template from a Remote Network Scanning Client Application

Nancy, working in the human resource department, has distributed a new employee survey that will have to be scanned and processed for summarizing the survey. Nancy wants to use the group MFD to scan then store the scanned survey forms in the survey project directory. Nancy launches her network scanning client application and requests the creation of a new Scan Job Template. Nancy sets up her Scan Job Template with her Scan Intent and repository location for the Scan Documents associated with this new activity. Finally, Nancy requests that her Scan Job Template be stored on the group MFD under her account. Nancy closes her network scanning client application.

[pic]

Figure 1 Create Template from Remote Client

1 Processing Flow Requirements

Listed below are processing flow requirements for the scenarios.

1. The end user invokes the remote network scanning client application.

2. The end user selects the scanner to use for their Scan Intent.

3. The end user requests the creation of a new Scan Job Template.

4. The remote network scanning client application requests from the user’s specified Scan Service the associated description attribute and the range of values for each attribute of the Scan Service.

5. The remote network scanning client application presents the Scan Job Template to the end user.

6. The end user modifies the Scan Job Template attributes to meet their Scan Intent.

7. The remote network scanning client application validates the modified Scan Job Template.

8. The end user designates storage of the modified Scan Job Template at the specified Template Repository.

9. The remote network scanning client application requests the Template Manager Service to store the modified Scan Job Template for the specified end user.

10. The Template Manager Service validates the Scan Job Template to ensure the template is well-formed.

11. The Template Manager Service stores the modified Scan Job Template in the specified Template Repository (local or remote).

12. The remote network scanning client application informs the end user that their modified Scan Job Template has been stored.

13. The end user exits the remote network scanning client application.

2 Use Case Design Requirements

Below are scanning service requirements indicated by the flow steps required in this use case.

Design Req 1.1 A network scanning client application SHOULD contain a Scan Client that is responsible for interface with a Scan Service in order to obtain data about the Scan Service.

Design Req 1.2 A network scanning client application SHOULD contain a Scan Template Manager Client that is responsible for interfacing with a Scan Template Manager Service in order to store a Scan Job Template on behalf of an end user.

Design Req 1.3 A Scan Service SHALL respond to a Scan Client’s query for service descriptive attributes and the range of each attribute.

Design Req 1.4  In response to a Scan Client’s query for service attributes and the range of each attribute, data attributes provided by a Scan Service SHALL contain the default values of descriptive and processing attributes of a Scan Job Ticket.

Design Req 1.5  In response to a Scan Client’s query for service attributes and the range of each attribute, data attributes provided by a Scan Service SHALL contain the capabilities supported by the Scan Service.

Design Req 1.6 A Scan Job Template SHALL be a copy of a Scan Job Ticket.

Design Req 1.7  A network scanning client application SHOULD validate that a modified Scan Job Template is well formed.

Design Req 1.8  A network scanning client application SHOULD validate that a modified Scan Job Template has attribute values with the specified range of the attributes.

Design Req 1.9 A Scan Template Manager Client is an instance of Template Manager Client, SHOULD support storage of new, or modified Scan Job Template for a network scanning client application.

Design Req 1.10  A Scan Template Manager Service is an instance of Template Manager Service, SHALL support storage of new, or modified Scan Job Template for a specified Scan Template Manager Client.

Design Req 1.11  A Scan Template Manager Service SHALL validate that a received new, or modified Scan Job Template is well formed before storing the Scan Job Template.

Design Req 1.12 A Scan Template Manager Service SHALL support storage of a specified Scan Job Template in a specified Template Repository.

Design Req 1.12 A Scan Template Manager Service SHALL notify a specified Scan Template Manager Client the status of storing a Scan Job Template.

Design Req 1.13 The network scanning client application SHOULD notify the end user the status of storing their created Scan Job Template.

--

2 Use Case 2: Walk Up Scanning from an Existing Scan Job Template

An accounting firm’s IT administrator has created mono and color Scan Job Templates filled with company’s preferred settings such as document format, image resolution, and the remote repository location. These templates are stored in the designated Template Repository(ies). The administrator also has created access control policies to restrict the group of users who are allowed to use these templates.

Pete, as the employee of the accounting firm, walks up to a MFD, places his document on platen or ADF. From the Local Scan Client, Pete enters his username and password to get a list of Scan Services and Template Manager Service he is authorized to use. He selects the target Scan Service and the Template Management Service he wants to use from the list. He then requests a list of Scan Job Templates he is allowed to use and selects one that matches best to his Scan Intent. He wants his hardcopy originals scanned into several documents, and each image of a document is stored in a separate file. He sets up scan parameters for scanning the originals. Finally he pushes the start button. When Pete sees the Scan Job completion notification, he returns to his desk and uses another application to retrieve his Scan Documents from the Document Repository.

1 Processing Flow Steps

The following processing flow steps have been identified for this usage scenario.

Preconditions:

At initialization or installation, a network scanning client application either automatically discovers all reachable Scan Services and Template Manager Services in its network domain, or is configured to use specific Scan Services and Template Manager Services. For the following processing steps, it is assumed that the local network scanning client application of the MFD has been configured to use the Local Scan Service and a designated Template Manager Service.

1. The end user places Hardcopy Document on platen or ADF (automatic document feeder).

2. From the local network scanning client the end user requests a list of templates.

Step 2a The local network scanning client application requests a list of the end user’s templates from the designated Template Manager Service.

3. The Template Manager Service authenticates the end user.

4. The Template Manager Service returns the list of Scan Job Templates to which the end user is authorized to use.

5. The end user selects the Scan Job Template for their Scan Intent.

6. The local network scanning client application retrieves a copy of the Template from the Template Manager Service for the local network scanning client application.

7. From the local network scanning application the end user modifies the scan parameters, including the instructions for storing images of each document.

8. The end user pushes start button.

9. The local network scanning client application sends the end user's modified Scan Job Template to the Scan Service.

10. The Scan Service validates that the modified Scan Job Template is well-formed and the validity of the processing attributes in the modified Scan Job Template (i.e. whether they are supported).

11. The Scan Service instantiates a Scan Job.

12. The Scan Service creates a Scan Job Ticket from the modified Scan Job Template.

13. The Scan Service schedules the Scan Job.

14. The Scan Service executes the Scan Job.

15. The Scan Service stores the Scan Document(s) at the specified Document Repository.

16. The Scan Service notifies the local network scanning client application that the Scan Job is complete.

17. The local network scanning client application notifies the end user the Scan Job is complete.

18. From the local network scanning client application the end user retrieves the completed job information based on the Scan Job Identifier.

19. From the completed job information the end user finds the storage location where the documents are stored.

20. The end user uses another document application to retrieve their Scan Documents from the Document Repository.

[pic]

Figure 2 Walk-up Scanning from an existing Scan Job Template

2 Design Requirements

Below are scanning service requirements indicated by the flow steps required in this use case, in addition to those have been identified in 6.1.2.

Design Req 2.1  See design requirements in section 6.7 for dynamic or static service discovery if supported by the local scanning client application to automatically or manually locate available Scan Services and Template Manager Services in order to establish the pre-conditions.

Design Req 2.2  The local or remote scanning client application, Local Scan Service and Template Manager Service SHOULD support secure communication for security considerations of service discovery.  (See Section 15 for discussion and considerations.)

Design Req 2.3  The Scan Template Manager Service, an instance of Template Manager Service, SHALL provide a List of Scan Job Templates authorized to the end user..

Design Req 2.4  The Scan Template Manager Service MAY provide authentication of the end user.

Design Req 2.5  The Scan Template Manager Service SHALL validate that a submitted Scan Job Template is well formed.

Design Req 2.6  The Scan Service SHALL support a “Must Honor” specification by validating that all the specified attributes and values in the submitted Scan Job Ticket are support by the Scan Service before creating the Scan Job instance.

Design Req 2.7  The Scan Service SHALL use its best effort to process attributes and values specified in the submitted Scan Job Template. Attributes and/or values that are not supported by the Scan Service may be ignored or substituted with an implementation specific alternative.

Design Req 2.8  The Scan Service SHALL instantiate a Configured Scan Job Template to a Scan Job Ticket.

Design Req 2.9  A Scan Job Ticket SHALL be a copy of the submitted Scan Job Template.

Design Req 2.10  The Scan Service SHALL create a Scan Job.

Design Req 2.11  The Scan Service SHALL bind the Scan Job Ticket to the Scan Job.

Design Req 2.12  The Scan Service SHALL assign the Scan Job a Scan Job Identifier

Design Req 2.13  The Scan Service SHALL schedule the Scan Job as soon as it is successfully created. (Note: It is possible an end user can indicate JobHoldUntilTime in job ticket so that multiple jobs can be created and scheduled but on hold until the end user walks up to scanner to release them for processing.)

Design Req 2.14  The Scan Service SHALL allow job level and document level processing attributes for end user to specify “Single” or “Multiple” document objects per job or the output of “Single” or “Multiple” files per document for the captured Scan Document Data.

Design Req 2.15  The Scan Service SHALL support storage of an individual Scan Document in a single file.

Design Req 2.16  The Scan Service SHALL support storage of an individual Scan Document by storing each page (or image) within the Scan Document in a separate file.

Design Req 2.17  The stored Scan Document Data files SHALL be in MIME type for interoperable transportation of the file(s) over the network among a large variety of systems.

Design Req 2.18  The Scan Service SHALL record in the Scan Job Ticket the location and name (URL) of all associate files.

Design Req 2.19  The Scan Service SHALL create a Scan Job Receipt at the completion of a Scan Job.

Design Req 2.20  A Scan Job Receipt SHALL contain a list of all attributes and attributes used for the Scan Job.

Design Req 2.21  The Scan Service SHALL notify the Scan Client at the completion of a Scan Job.

Design Req 2.22  The Scan Service MAY notify the Scan Client at the completion of a Scan Job by means of an event.

Design Req 2.23  The Scan Service MAY notify the Scan Client at the completion of a Scan Job by means of a request from the Scan Client.

Design Req 2.24  The Scan Service SHALL make the Scan Document Data available to the end user by automatically “PUSHing” the document data to a scan Destination URL specified by the end user.

3 Use Case 3: Scan from a Computer, Multiple Sets of Originals

After the Hardcopy Document is placed on the platen or in the ADF, a user controls all scanning operations using the Remote Scan Client from the user’s desktop computer. No start button needs to be pushed at the MFD local UI. The end user continues to place the next set of hardcopy originals, and repeats the process until all sets of the user’s Hardcopy Documents have been scanned and stored in the designated repository.

The following processing steps required for this scenario have been identified.

1 Processing Flow Steps

Step 1: From the remote network scanning client application, the end user selects the Scan Job Template to use for their Scan Job intent.

Step 2: The end user, modifies the local copy of the Scan Job Template for their Scan Job intent. This includes noting there are multiple documents with the same or different destinations.

Step 3: The remote network scanning client application sends the Scan Job Template to the Scan Service.

Step 4: The Scan Service creates a Scan Job.

Step 5: The Scan Service populates the Scan Job Ticket with information from the Scan Job Template.

Step 6: The Scan Service schedules the Scan Job.

Step 7: The Scan Service executes the end user's Scan Job.

Step 8: The Scan Service requests the end user to place the next page(s) of the Hardcopy Document on scanner platen (flatbed) or in the automatic document feeder.

Step 9: The end user presses the "Continue" button on the MFD.

Step 10: The Scan Service scans the individual pages of the Hardcopy Document; requesting the end user to put in the next page for the case the end user is using the MFD platen or the document is larger than the MFD's ADF capacity.

Step 11: The end user presses the "Stop" button when all of the Hardcopy Document's pages have been scanned.

Step 12: The Scan Service stores the Digital Document at the specific Scan Destination.

Step 13: Repeat Step 8 through 12 until the last document complete.

Step 14: The end user presses the "Stop" button to indicate that there are no more documents for this Scan Job.

Step 15: The Scan Service notifies the remote network scanning client application that the Scan Job is complete.

Step 16: The remote network scanning client application notifies the end user the Scan Job is complete based on the information in the Scan Job Ticket.

[pic]

Figure 3 Scan from a Computer, Multiple Set of Originals

2 Design Requirements

The following new design requirements have been identified from this use case in addition to the design requirements identified in the previous use cases:

1. The Scan Service SHALL support an operation mode selectable by a end user for scanning multiple sets of Hardcopy Documents in addition to its normal scan operation mode.

2. During the operation mode for scanning multiple sets of Hardcopy Documents the Scan Service shall continue to scan the next set of Hardcopy Document pages placed on the platen or the ADF until the Scan Service receives a ‘stop-scanning’ notification.

3. The Scan Service SHALL provide an attribute settable by Adminstrator to indicate the length of time the Scan Service will wait for the next set of Hardcopy Document pages being placed on the platen or ADF before it stops scanning more Hardcopy Document pages.

4 Use Case 4: Walk-Up Batch Scan

Glen needs to scan a stack of Hardcopy Documents. For each document to be scanned, Glen prepares the appropriate number of Physical Physical Scan Document Ticket and places one in front of each document. Glen prepares a Physical Scan Job Ticket and places it in front of the stack and places the stack in the MFD’s automatic document feeder. Glen selects “batched scan” and presses the green button.

[pic]

Figure 4 Walk-up Batch Scan

1 Processing Flow Steps

The following processing flow steps have been identified:

Step 1. Glen places the stack of Hardcopy Documents on the ADF.

Step 2. From the Local Scan Client, Glen selects the “batch scan” mode of the Scan Service.

Step 3. The Local Scan Client requests the Scan Service to switch to “batch scan” mode.

Step 4. Glen pushes the start scan button.

Step 5. The Local Scan Client requests the Scan Service to start “batch mode” operation.

Step 6. The Scan Service creates a “batch mode” Scan Job.

Step 7. The Scan Service creates a Scan Job Ticket from the Default Scan Job Ticket.

Step 8. The Scan Service schedules the Scan Job.

Step 9. The Scan Service executes the Scan Job.

Step 10. The Scan Service scans the Physical Scan Job Ticket and modifies the Scan Job Ticket based on the information obtained from the digital image data of the Physical Scan Job Ticket.

Step 11, The Scan Service detect and scan a Physical Document Ticket..

Step 12. The Scan Service creates a Scan Document within the Scan Job, creates and and fills in the Scan Document Ticket based on the information obtained from the digital image data of the physical Scan Document Ticket.

Step 13. The Scan Service scans the Hardcopy Document and stores the Digital Document at the specified Scan Destination until the end of the document is detected.

Step 14, If another Physical Scan Document Ticket is detected step 11 otherwise the stack of batch job of scanning a stack of Hardcopy Documents has been competed

Step 15. the Scan Service notifies the Local Scan Client that the Scan Job is complete.

Step 16. The Local Scan Client notifies the end user the Scan Job is complete based on the information in the Scan Job Ticket.

2 Design Requirements

List below are the new design requirements need to be added to the Scan Service for this use case:

Design Req 4.1  The Scan Service SHALL support a “batch scan” mode of operation that differs from the normal scan mode, processes Scan Jobs according to the Processing Flow Step specified in the previous section (6.4.1).

Design Req 4.2  The content of the Physical Scan Job Ticket of batch scan SHALL be consistent with the definition of the Scan Job Ticket specified herein.

Design Req 4.3  The content of the Physical Scan Document Ticket of batch scan SHALL be consistent with the definition of the Scan Document Ticket specified herein.

5 Use Case 5: Finding a Previously Scanned Document Location

Harry interfacing with the Scan Client, scrolls to the list of his Scan Job, selects the Scan Job and locates the destination(s) of his Scan Job.

[pic]

Figure 5 Finding a Previously Scanned Document Location

1 Processing Flow Steps

The following processing flow steps have been identified for this use case:

Step 1. From the Scan Client Harry requests a list of his recent Scan Jobs.

Step 2. The Scan Client requests the Scan Service to provide the list of Harry’s Scan Jobs in the job history.

Step 3. Harry selects the Scan Job he is looking for from the list.

Step 4. Harry requests the Scan Client for the detailed information of the selected Scan Job.

Step 5. The Scan Client requests the Scan Service for detailed information of the selected Scan Job.

Step 6. Harry obtains the document location(s) from the detailed information of the Scan Job,

2 Design Requirements

Listed below are new design requirements identified from this use case:

1. The Scan Service SHALL maintain a Scan Job history for the period of time that is settable by an Administrator.

2. The minimum period of time for keeping the job history SHALL comply with the Scan Service conformance requirement.

3. The Scan Job history SHALL maintain detailed information of each Scan Job.

4. The detailed information of a Scan Job SHALL include the Scan Destination(s) of the Scan Document(s) of the Scan Job

.

6 Use Case 6: Pause Scan Service for Copying

Anne needs to copy a lot of documents. She pauses the Scan Service until all documents are copied, then enables the Scan Service when she is done.

[pic]

Figure 6 Disable Scan Service for Copying

1 Processing Steps

The following processing flow steps have been identified for this use case:

Step 1. Anne walks up to the MFD and from the Scan Client, she brings up service configuration menu to

pause the Scan Service.

Step 2. The Scan Client requests the Scan Service to pause.

Step 3. The Scan Service performs ‘pause’ operation.

Step 4. The Scan Service notifies the Local Scan Client the ‘paused’ status.

Step 5. Anne puts the Hardcopy Documents on the platen or the ADF.

Step 6. Anne presses ‘COPY’ button on MFD to copy all her documents.

Step 7. From the Scan Client, Anne brings up service configuration menu to resume the Scan Service.

Step 9. The Local Scan Client requests the Scan Service to resume.

Step 10. The Scan Service performs ‘resume’ operation.

Step 11. The Scan Service notifies the Local Scan Client the ‘resumed’ status.

2 Design Requirements

The following design requirements SHALL be added to the Scan Service by this use case:

1. When a “pause” request is received, the Scan Service SHALL immediately stop processing or accepting all Scan Jobs.

2. When “pauses” request is received while the Scan Service is processing a Scan Job, the Scan Service SHALL suspend the Scan Job, and only resume when the interrupting copy job is completed or when the “resume” request has been received.

3. The Scan Service SHALL have a “Job Priority” attribute that allows an end user to specify the processing priority of a Scan Job.

4. Scan Job scheduling SHALL be priority based.

7 Use Case 7: Scan Service Discovery

Bill wants to discover the Scan Services available in his enterprise network, so that he can choose one in the future when he wants to submit a Scan Job. Bill wants to discover Scan Services both statically (via enterprise directories) and dynamically (via discovery protocols).

[pic]

Figure 7 Scan Service Discovery via Service Directory

[pic]

Figure 8 Scan Service Discovery via Discovery Protocol

1 Processing Flow Steps

For static discovery via a directory service, the following flow step requirements are identified:

1. At start-up the Scan Service authenticates with and connects (binds) to the Directory Service of the network domain of the MFD, then registers the Scan Service information with the Directory Service.

2. At any time, a Discovery Client sends the Directory Service a “lookup” search request for the specific Scan Service type in order to locate a Scan Service.

3. The Directory Service returns an appropriate list of Scan Services.

For dynamic discovery via a service discovery protocol, the following processing requirements are identified:

1. At start-up, the Scan Service announces its service type and location to the multicast group in which all services and discovery clients reside. Any listening Discovery Client will detect newly-available Scan Services automatically.

2. To initiate a discovery at any time, a Discovery Client sends a “search-by-service-type” query to this multicast group.

3. The Scan Service responds to a search query with a “service-type-matched” message.

4. In a network environment where a discovery proxy server is preferred, the proxy server listens to this multicast group for service announcements from all services and announces its service in response to each search query received.

5. If a discovery proxy server is preferred, the client sends a “search-by-type” message to this proxy server to discover all available Scan Services.

6. The discovery proxy server returns the list of Scan Services that match the specific Scan Service type to the client.

2 Design Requirements

The following design requirements SHALL be added to the Scan Service by this use case.

1. For supporting dynamic service discovery, the Scan Service SHALL announce its service type, service instance, and endpoint address information to the multicast group in which it resides at start-up time.

2. For supporting static service discovery, the Scan Service SHALL send an entry record to a specified Directory Service at start-up for registering its service information.

3. The Scan Service type announced by the Scan Service at start-up SHALL comply with what’s registered with IANA.

4. The Service type specified in the Service entry record sent to a Directory Service at start-up of the Scan Service SHALL comply with what’s registered with IANA.

5. The Service type of the PWG MFD Scan Service SHALL be defined and registered with IANA.

6. In response to a discovery or search query from a Discovery Client, the Scan Service SHALL provide its service type, service instance, and endpoint address information to the client.

7. The endpoint address reported by a Scan Service SHALL be a fully qualified URL (e.g. for WS-Discovery) or IP address (e.g. for discovery via DNS) including port number.

8. The Scan Service MAY support authentication of Discovery Client and protection of the discovered information replied by the Scan Service against disclosure or alteration depending on the security policy of the operating environment.

9. The Scan Service MAY provide Scan Service attributes that describe all service discovery methods or protocols supported by the Scan Service.

8 Use Case 8: Scan Service Capability Discovery

MFD with scan capabilities is setup on the network. MFD has been previously discovered and is known to the application software that will query the device for capabilities. Ira wants to learn if the Scan Service is capable of sending his document as a PDF file to his mailbox. He would also like to know if he can password encrypt the file to be sent. From the application on his computer, Ira is able to select scan options available knowing that these will be supported.

[pic]

Figure 9 Scan Service Capability Discovery

1 Processing Flow Steps

1. From the Remote Scan Client at end user’s computer, the end user selects a target Scan Service and requests the list of capabilities of the Scan Service.

2. The Remote Scan Client requests the Scan Service the list of capabilities of the Scan Service .

3. The Scan Service returns the Service Capabilities to the Remote Scan Client.

4. The Remote Scan Client requests the UI to display the list of Scan Service Capabilities to the end user.

2 Design Requirements

The following design requirements SHALL be added to the Scan Service by this use case:

1. The Scan Service SHALL maintain the list of supported Scan Service capabilities.

2. The Scan Service SHALL support a “List of Capability” request interface from a Remote Scan Client that will return the list of supported Scan Service capabilities.

Conformance Requirements

All conformance requirements for the PWG scan service abstract model are deferred until the PWG scan service abstract model is fully specified, and will be documented in “Network Scan Service Semantic Model and Service Interfaces”.

PWG and IANA Registration Considerations

All considerations for PWG and IANA registration are deferred until the PWG san service abstract model is fully specified, and will be documented in “Network Scan Service Semantic Model and Service Interfaces”.

Internalization Considerations

Any operation and attribute in the PWG scan service model SHALL support internationalization.

Security Considerations

1 Storing Scan Documents in a Document Repository

Organizations with higher security requirements may require end users to store their documents only in the designated Document Repositories for which organizational document access control policies can easily be instrumented. It is the end user’s responsibility to ensure that their target document repositories have been administered to support the Scan Service writes user’s Scan Document Data into the repository as long as the requesting user has been authenticated in the same network domain of the Document Repository.

2 Protection of End User’s Scan Documents

An end user’s Scan Documents can be protected from disclosure by encrypting the content of the documents and protected from modification by signing the content of the documents when these documents are stored in a repository or being transmitted over a communication link.

Signing or encrypting documents stored in a Document Repository requires secure key management which includes the selection, generation, distribution, and destruction of effective signing or encryption of each end user’s keys. Signing or encrypting document stored in a Document Repository is outside the scope of the Scan Service. It is RECOMMENDED that the end user designates a Document Repository that has their desired level of signing or encryption capabilities if so required.

For protection of the documents transmitted over the network between a Scan Service and a Document Repository or a Scan Client, the Scan Service SHALL support the secure communication protocols required by the end user’s site policy, which may require signing and/or encryption of the transmitted document. The Scan Service SHALL have security attributes to indicate the signing or encryption support for the end user’s site policy. Different level of security requires different signing or encryption methods to be used. A site policy administrator SHOULD be responsible to manage the site security policy to ensure consistency with the site security requirements. The MFD implementer SHOULD ensure that a signing or encryption method consistent with the user’s site policy is used for transporting user’s Scan Document over a shared communication medium.

3 Protection of a “Restricted Use” Scan Job Template

An end user could create a template to which access is restricted. A template could be created for publicly unrestricted read access, or for restricted read access by the end users within a specific group, but nobody should be allowed to modify a stored template other than the owner or other authorized user(s) of the template. An end user who has read access to a template is allowed to make a copy of the template then modify the copy subsequently.

In order to restrict the access and use of template(s) stored in the Template Repository to authorized end users, the template has TemplateName and TemplateOriginatingUserName defined that allow a template site policy to be established to specify individual and group membership for accessing a specific, uniquely named template. A template site policy is to be specified by an authorized end user or administrator for association with a Template Management Service. A Template Management Service SHALL authenticate the end user’s access rights to the template(s) for GetTemplate, ListTemplate, or PutTemplate operations. Protection of a “restricted Use” Scan Job Template is outside the scope of a Scan Service.

4 Restricted Use of Scan Service Features

A company might want to restrict certain group(s) of users to use only part of supported feature(s) of a Scan Service. The “RequestingUserName” attribute of the Scan Service model specified herein is the end user identifying name that is used to request for processing the submitted Scan Job. This user name can be replaced with the most authenticated name if one available. A Scan Service SHALL authenticate a user’s rights for using the requested Scan Service features based on the “RequestingUserName” against the end user’s site policy, which maybe residing in the end user’s site security framework or locally in the security database associated with the Scan Service. Implementations are free to use a variety of security framework for the user authentication. The management of the site policy for the use of Scan Service features is outside the scope of this specification.

5 Preventing DoS Attack Through High Priority Job

A malicious user could submit a “non-interruptible job” that runs indefinitely or consumes MFD resources to eventually cause unavailability. The Scan Service SHALL authenticate the user who has submitted a “non-interruptible job” to ensure the user is trustable.

6 Security for Service Discovery

Security threats to Service discovery include unauthorized access to service endpoint and service interface information resulting in malicious exploitation of security vulnerabilities, eventually lead to disclosure or alteration of sensitive information. Thus security considerations for service discovery SHOULD encompass access control for service discovery and protection of confidentiality and integrity of the discovery request and response information. ,

References

[TBD]

1 Normative References

[RFC2119]

S. Bradner, “Key words for use in RFCs to Indicate Requirement Levels”, RFC 2119, March 1997.

[RFC 3712]

P. Fleming, I. McDonald, “Lightweight Directory Access Protocol (LDAP): Schema for Printer Services”, RFC 3712, February 2004.

[RFC 2782]

A. Gulbrandsen, P. Vixie, L. Esibov, ” A DNS RR for specifying the location of services (DNS SRV)”, RFC 2782, February 2000.

[Others TBD]

2 Informative References

[TBD]

Author’s Address

Nancy Chen

Solutions and Technology

Oki Data

2000 Bishops Gate Blvd.

Mt. Laurel, NJ 08003

Phone: 856 222 7006

Fax: 856 222 5130

Email: nchen@

Peter Zehler

Xerox Research Center Webster

Email: Peter.Zehler@

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

Additional contributors: (Still to be updated)

Mike Fenelon – Microsoft

Andrey Savov – Toshiba

Harry Lewis – IBM

Ira McDonald – High North

Walter Filbrich - Samsung

Glen Petrie – Epson

Kei Sando – Oki Data

Jerry Thrasher – Lexmark

David Whitehead - Lexmark

Craig Whittle – Sharp

-----------------------

[pic]

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download