Subject: [IPP] IPP Scan question.

From: "Manchala, Daniel" <[email-masked]>
Date: Wed, 17 Sep 2014 00:41:08 +0000

Section 3.5 (Design Requirements) Item 3. says:

* Push Scan and Pull Scan are required.

This statement (...are required...) states that the Push Scan is required.

However, Section 8.2 Job Template attributes: destination-uris says:

* Scan Services that support Push Scanning MUST support this attribute.

This statement (...that support ...) states that the Push Scan is optional.

Again, Section 8.3.2 destination-uri-schemes-supported says:

* Scan Services that support Push Scan MUST support this attribute.

This statement (...that support ...) states that the Push Scan is optional.

Section 11.1 mentioned "Scan Services MUST support Pull Scan and SHOULD support Push Scan" in an older version of the document (20140725), but the current version does not mention that.

Can you clarify this?

Thanks,

Daniel.

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

---

From: Ira McDonald <[email-masked]>
Date: Tue, 16 Sep 2014 21:15:38 -0400

Hi Daniel,

I'll try to answer this one.  Mike and Pete can chime in of course.

Section 3.5 Design Requirements simply requires that the *spec*
defines methods and attributes for both Push and Pull scan - NOT
that any Printer or Client has to implement them.

Sections 8.x are correct that Push Scan is OPTIONAL - this was
always intended.

The old section 11.1 requirement (SHOULD) was redundant and
removed in the clarification of sections 11.x in general.

Does that help?

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

On Tue, Sep 16, 2014 at 8:41 PM, Manchala, Daniel <[email-masked]
> wrote:

>  Section 11.1 mentioned "Scan Services MUST support Pull Scan and SHOULD
> support Push Scan" in an older version of the document (20140725), but the
> current version does not mention that.
>
>
>  Can you clarify this?
>
>
>  Thanks,
>
> Daniel.
>
>

---

From: "Zehler, Peter" <[email-masked]>
Date: Wed, 17 Sep 2014 11:25:19 +0000

Daniel,

I agree with Ira.  Section 3.5 are design requirements.  Also note that no conformance terminology is used in the design requirements.  My preference would be to leave the specification as currently written.

If it must be changed, perhaps the “Push Scan and Pull Scan are required” could be changed to “Push Scan and Pull Scan must be included in the definition”.
Pete

Peter Zehler

PARC, A Xerox Company
800 Phillips Rd, 128-27E
Webster NY, 14580-9701
Email: [email-masked]<mailto:[email-masked]>
Office: +1 (585) 265-8755
Mobile: +1 (585) 329-9508
FAX: +1 (585) 265-7441

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ira McDonald
Sent: Tuesday, September 16, 2014 9:16 PM
To: Manchala, Daniel; Ira McDonald
Cc: [email-masked]
Subject: Re: [IPP] IPP Scan question.

Hi Daniel,

mailto: [email-masked]<mailto:[email-masked]>

On Tue, Sep 16, 2014 at 8:41 PM, Manchala, Daniel <[email-masked]<mailto:[email-masked]>> wrote:
Section 3.5 (Design Requirements) Item 3. says:

Can you clarify this?

Thanks,

Daniel.

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

---

From: Michael Sweet <[email-masked]>
Date: Wed, 17 Sep 2014 07:50:26 -0400

Pete,

> If it must be changed, perhaps the “Push Scan and Pull Scan are required” could be changed to “Push Scan and Pull Scan must be included in the definition”.

I think some editorial changes to remove conformance-like words would be appropriate and useful. In the process we can normalize the text so that is reads consistently, e.g.:

    The design requirements for this specification are:

    1. Follow the PWG Semantic Model for the Network Scan Service.
    2. Follow the naming conventions defined in IPP/1.1: Model and Semantics [RFC2911], including keyword value case (lower) and hyphenation requirements
    3. Re-use existing IPP operations, attributes, and values when possible.
    4. Define IPP attributes, values, and operations necessary for Push Scan.
    5. Define IPP attributes, values, and operations necessary for Pull Scan.
    6. Define a minimum set of required document formats for interoperability.
    7. Define security requirements necessary to support privacy, integrity, and auditing policies
    8. Define sections to register all attributes, values, and operations with IANA

    (not sure if these are "design requirements" or just "functional requirements driven by use cases")

    9. Support one or more destinations for Push Scan.
    10. Support monitoring of the status of transmission to each destination.
    11. Support streaming of basic page-based raster data.
    12. Support identification of the Imaging Device.

> Pete
>  
> Peter Zehler
> 
> PARC, A Xerox Company
> 800 Phillips Rd, 128-27E
> Webster NY, 14580-9701
> Email: [email-masked]
> On Tue, Sep 16, 2014 at 8:41 PM, Manchala, Daniel <[email-masked]> wrote:

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: "Zehler, Peter" <[email-masked]>
Date: Wed, 17 Sep 2014 12:47:48 +0000

Small edit on number 7.  If this is acceptable, I'll post an update for Formal Vote.

1.    Follow the naming conventions defined in IPP/1.1: Model and Semantics [RFC2911], including keyword value case (lower) and hyphenation requirements

2.    Re-use existing IPP operations, attributes, and values when possible.

3.    Define IPP attributes, values, and operations necessary for Push Scan.

4.    Define IPP attributes, values, and operations necessary for Pull Scan.

5.    Define a minimum set of required document formats for interoperability.

6.    Define security requirements necessary to support privacy, integrity, and auditing policies

7.    Define sections to register all attributes, values, and operations with IANA and PWG Semantic Model

8.    Support one or more destinations for Push Scan.

9.    Support monitoring of the status of transmission to each destination.

10.  Support streaming of basic page-based raster data.

11.  Support identification of the Imaging Device.

Peter Zehler

PARC, A Xerox Company
800 Phillips Rd, 128-27E
Webster NY, 14580-9701

From: Michael Sweet [mailto:[email-masked]]
Sent: Wednesday, September 17, 2014 7:50 AM
To: Zehler, Peter
Cc: Ira McDonald; Manchala, Daniel; [email-masked]
Subject: Re: [IPP] IPP Scan question.

Pete,

On Sep 17, 2014, at 7:25 AM, Zehler, Peter <[email-masked]<mailto:[email-masked]>> wrote:
Daniel,

If it must be changed, perhaps the "Push Scan and Pull Scan are required" could be changed to "Push Scan and Pull Scan must be included in the definition".

Pete

Peter Zehler

PARC, A Xerox Company
800 Phillips Rd, 128-27E
Webster NY, 14580-9701

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Ira McDonald
Sent: Tuesday, September 16, 2014 9:16 PM
To: Manchala, Daniel; Ira McDonald
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [IPP] IPP Scan question.

Hi Daniel,

Can you clarify this?

Thanks,

Daniel.

---

From: Michael Sweet <[email-masked]>
Date: Wed, 17 Sep 2014 09:29:53 -0400

Works for me.

On Sep 17, 2014, at 8:47 AM, Zehler, Peter <[email-masked]> wrote:

> Small edit on number 7.  If this is acceptable, I’ll post an update for Formal Vote.
>

---

From: Ira McDonald <[email-masked]>
Date: Wed, 17 Sep 2014 10:18:04 -0400

Hi,

Works for me too.  Thanks for the cleaned up design requirements
list Mike and Pete.

Cheers,
- Ira

On Wed, Sep 17, 2014 at 9:29 AM, Michael Sweet <[email-masked]> wrote:

> 1.    Follow the naming conventions defined in IPP/1.1: Model and
> Semantics [RFC2911], including keyword value case (lower) and hyphenation
> requirements
>
> *From:* Michael Sweet [mailto:[email-masked] <[email-masked]>]
> *Sent:* Wednesday, September 17, 2014 7:50 AM
> *To:* Zehler, Peter
> *Cc:* Ira McDonald; Manchala, Daniel; [email-masked]
> *Subject:* Re: [IPP] IPP Scan question.
>
>
>
> Pete,
>
>
>
> I agree with Ira.  Section 3.5 are design requirements.  Also note that no
> conformance terminology is used in the design requirements.  My preference
> would be to leave the specification as currently written.
>
>
>
> If it must be changed, perhaps the “Push Scan and Pull Scan are required”
> could be changed to “Push Scan and Pull Scan must be included in the
> definition”.
>
>
>
> I think some editorial changes to remove conformance-like words would be
> appropriate and useful. In the process we can normalize the text so that is
> reads consistently, e.g.:
>
>
>
>     2. Follow the naming conventions defined in IPP/1.1: Model and
> Semantics [RFC2911], including keyword value case (lower) and hyphenation
> requirements
>
> *From:* [email-masked] [mailto:[email-masked]
> <[email-masked]>] *On Behalf Of *Ira McDonald
> *Sent:* Tuesday, September 16, 2014 9:16 PM
> *To:* Manchala, Daniel; Ira McDonald
> *Cc:* [email-masked]
> *Subject:* Re: [IPP] IPP Scan question.
>
>
>
> Hi Daniel,
>

---

From: "William A Wagner" <[email-masked]>
Date: Sun, 21 Sep 2014 12:50:04 -0400

A few questions in looking at the comments on Cloud Scan Model relative to
the MFD Scan Model and  IPP Scan.

The SM Scan Model identified Single Document Single File Jobs, Single
Document Multiple File Jobs, Multiple Document Single File Jobs, and
Multiple Document Multiple File Jobs, where in this context, Document refers
to the hardcopy document and File refers to the Digital Data file resulting
from scanning, which is related to Destination. This relationship allows the
Scan Service User to define a Job with  multiple documents and  " Each
Document can have a different set of processing parameters". There can be
multiple files for each document and different files for multiple documents,
with each file having its own URI. 

It is also clear from the IPP Scan specification GetNextDocumentImages
operation that a scan job can have multiple documents. 

The Cloud conference call comment is that  FetchJob (corresponding to
CreateJob)  contains the Destination,  DestinationAccesses, and
InputElements for Scan with no need to have a FetchDocument operation.  This
suggests that there is but one document (possibly with multiple
destinations) in a Scan Job. Alternatively,  it may be that the Input
Parameters and Destinations for each one of multiple documents are defined
in the CreateJob.  This seemes inconsistent with the general Imaging Service
model. 

The IPP Scan specification definitely refers to multiple documents in one
scan job.  However, Figure 1 can be interpreted to mean that  the only
operation necessary for Scan is a CreateJob, with GetNextDocumentImages
necessary if it is a Pull Scan Job. Indeed, InputAttributes is defined to be
in the CreateJob request as well as are the Job Template attributes defining
destination; but it does not appear that different InputAttributes and/or
destinations can be specified for different documents.

[Also,  Compression Accepted and Document Format Accepted are defined in
CreateJob, but also in GetNextDocumentImages for Pull Scans. Can it be
assumed that requests in GetNextDocumentImages takes precedence?]

Do I correctly understand that, although there may be multiple documents in
a scan job, they must all have the same InputAttributes and the same
destination(s)?  An alternate approach might have been to send  a
SetDocumentAttributes sent for each document to be scanned, which contained
the input parameters and destination for each specific document/image file;
that would have been consistent with the Model. 

For Cloud, we need to decide whether we should reflect the Semantic Model
(with which we should bet be consistent) or the IPP Scan Binding. Or do we
need to change the semantic model?

Also, a few minor editorial comments/questions I had while looking up stuff.

1.                          Table 1 lists Get-Next-Document-Images and
refers to PWG 5100.SCAN.  I take it that this  means to have the
specification refer to itself, but it is confusing even if the proper number
is inserted. Better to refer to the internal paragraph.

2.                          Figure 1 refers to the operation as
GetNextDocumentImage rather than GetNextDocumentImages

3.                          In para 7.1.1, under Group 2: Job Template
Attributes is a reference to section 8.28.1.7.2.  There is no such section
(should it be 8.2?)

4.                          Although the text makes a distinction between
Print Jobs and Scan Jobs, section 8.2.1.1 refers to a Print Job.

Thanks,

Bill Wagner

---

From: Michael Sweet <[email-masked]>
Date: Thu, 25 Sep 2014 06:11:49 -0700

Bill,

> On Sep 21, 2014, at 9:50 AM, William A Wagner <[email-masked]> wrote:
> ...
> It is also clear from the IPP Scan specification GetNextDocumentImages operation that a scan job can have multiple documents.

I don't think these are multiple document objects, however.  Get-Next-Document-Images is a convenient way to pull one or more images/pages from the scanner, but from the point of view of the model they are part of one document object and would be delivered (in the case of push scan) as a single file.
 
> Destination,  DestinationAccesses, and  InputElements for Scan with no need to have a FetchDocument operation.  This  suggests that there is but one document (possibly with multiple destinations) in a Scan Job. Alternatively,  it may be that the Input Parameters and Destinations for each one of multiple documents are defined in the CreateJob.  This seemes inconsistent with the general Imaging Service model.

In the case of Scan, the CreateScanJob operation is instantiating a single scan job containing a single document object that may have multiple digital representations (e.g. PDF, TIFF, etc.) of the same images.  Figure 3 on page 22 of the MFD Scan spec seems pretty clear on that point.  This is similar to how the Copy and FaxIn services work (single document jobs).

Print, FaxOut, and Transform can support multiple digital document inputs (and thus multiple document objects).

I think the only inconsistency here is that some job services support multiple document objects and some don't.  But I don't think that hurts the overall model - just something worth pointing out.

(and perhaps as well worth considering/mentioning that most Print and FaxOut service implementations only support single document jobs...)

> The IPP Scan specification definitely refers to multiple documents in one scan job.  However, Figure 1 can be interpreted to mean that  the only operation necessary for Scan is a CreateJob, with GetNextDocumentImages necessary if it is a Pull Scan Job. Indeed, InputAttributes is defined to be in the CreateJob request as well as are the Job Template attributes defining destination; but it does not appear that different InputAttributes and/or destinations can be specified for different documents.

I think the choice of reusing the "last-document" operation attribute in the response of Get-Next-Document-Images operation is causing confusion here. It really is (semantically) "last-document-image".

Pete, do you think this is worth an editorial change before publication, either the attribute name or the description ("indicating that the last document IMAGE has been reached")?

> [Also,  Compression Accepted and Document Format Accepted are defined in CreateJob, but also in GetNextDocumentImages for Pull Scans. Can it be assumed that requests in GetNextDocumentImages takes precedence?]

I think this needs some clarification - you put those in Create-Job for a Push Scan and in Get-Document-Images for a Pull Scan.
 
> Do I correctly understand that, although there may be multiple documents in a scan job, they must all have the same InputAttributes and the same destination(s)?  An alternate approach might have been to send  a SetDocumentAttributes sent for each document to be scanned, which contained the input parameters and destination for each specific document/image file; that would have been consistent with the Model.

Currently you scan whatever is at the input source and send it to the destination(s) or pull the images with Get-Next-Document-Images.  The only way to break things up is to create multiple jobs and specify the number of images for each job in the "input-images-to-transfer" member attribute.
 
> For Cloud, we need to decide whether we should reflect the Semantic Model (with which we should bet be consistent) or the IPP Scan Binding. Or do we need to change the semantic model?

The intent is that IPP Scan would update the SM definition of SM Scan, since SM Scan doesn't deal with Pull Scan.
 
> 1.                          Table 1 lists Get-Next-Document-Images and refers to PWG 5100.SCAN.  I take it that this  means to have the specification refer to itself, but it is confusing even if the proper number is inserted. Better to refer to the internal paragraph.

Agreed.

> 2.                          Figure 1 refers to the operation as GetNextDocumentImage rather than GetNextDocumentImages
> 
> 3.                          In para 7.1.1, under Group 2: Job Template Attributes is a reference to section 8.28.1.7.2.  There is no such section (should it be 8.2?)
> 
> 4.                          Although the text makes a distinction between Print Jobs and Scan Jobs, section 8.2.1.1 refers to a Print Job.

Thanks for catching these!

---

From: "William A Wagner" <[email-masked]>
Date: Thu, 25 Sep 2014 14:15:14 -0400

Michael,

Thank you for your response.

1. I agree that Figure 3 of the MFD Scan spec definitely indicates that
there can be multiple images in one scan document; I do not see where it
indicates that there cannot be multiple documents is a job. Furthermore,
Figure 4 of that same document (with the associated text) definitely states
that, for a multi-document Job,  " Job object contains multiple Document
objects. Each Document can have a different set of processing parameters."
And further that the Scan Service semantic model may allow the End User to
specify a multi-document Job as a service output. If we have intentionally
decided to not consider multi-document jobs in IPP, that should be made
clear. I think it is to be determined if we decide to eliminate them from
the SM3. (Incidentally, I do not see a compelling Use Case for
multi-document Scan Jobs, although some may exist.)

2. I get your explanation that Get-Next-Document-Images refers to multiple
images of a document, and that "last-document" refers to the last image of a
document. But these are names are misleading. Do we use 'Images' to refer to
anything other than 'Document Images'?

I apologize for not commenting on the IPP Scan document earlier, but I think
the one document per job characteristic, despite what one might expect from
the names, should be made more clear. Also, as you suggest, the fact that
for Pull Scan,  the GetNextDocumentImages can redefine Compression Accepted
and Document Format Accepted for each image of potentially multiple images
document.
Thanks,
Bill Wagner 

-----Original Message-----
From: Michael Sweet [mailto:[email-masked]] 
Sent: Thursday, September 25, 2014 9:12 AM
To: William A Wagner
Cc: Zehler, Peter; [email-masked]; [email-masked]
Subject: Re: IPP Scan question.

Bill,

I don't think these are multiple document objects, however.
Get-Next-Document-Images is a convenient way to pull one or more
images/pages from the scanner, but from the point of view of the model they
are part of one document object and would be delivered (in the case of push
scan) as a single file.
 
> Destination,  DestinationAccesses, and  InputElements for Scan with no
need to have a FetchDocument operation.  This  suggests that there is but
one document (possibly with multiple destinations) in a Scan Job.
Alternatively,  it may be that the Input Parameters and Destinations for
each one of multiple documents are defined in the CreateJob.  This seemes
inconsistent with the general Imaging Service model.

In the case of Scan, the CreateScanJob operation is instantiating a single
scan job containing a single document object that may have multiple digital
representations (e.g. PDF, TIFF, etc.) of the same images.  Figure 3 on page
22 of the MFD Scan spec seems pretty clear on that point.  This is similar
to how the Copy and FaxIn services work (single document jobs).

Print, FaxOut, and Transform can support multiple digital document inputs
(and thus multiple document objects).

I think the only inconsistency here is that some job services support
multiple document objects and some don't.  But I don't think that hurts the
overall model - just something worth pointing out.

(and perhaps as well worth considering/mentioning that most Print and FaxOut
service implementations only support single document jobs...)

I think the choice of reusing the "last-document" operation attribute in the
response of Get-Next-Document-Images operation is causing confusion here. It
really is (semantically) "last-document-image".

Pete, do you think this is worth an editorial change before publication,
either the attribute name or the description ("indicating that the last
document IMAGE has been reached")?

> [Also,  Compression Accepted and Document Format Accepted are defined 
> in CreateJob, but also in GetNextDocumentImages for Pull Scans. Can it 
> be assumed that requests in GetNextDocumentImages takes precedence?]

I think this needs some clarification - you put those in Create-Job for a
Push Scan and in Get-Document-Images for a Pull Scan.
 
> Do I correctly understand that, although there may be multiple documents
in a scan job, they must all have the same InputAttributes and the same

Currently you scan whatever is at the input source and send it to the
destination(s) or pull the images with Get-Next-Document-Images.  The only
way to break things up is to create multiple jobs and specify the number of
images for each job in the "input-images-to-transfer" member attribute.

The intent is that IPP Scan would update the SM definition of SM Scan, since
SM Scan doesn't deal with Pull Scan.

Agreed.

---

From: "Zehler, Peter" <[email-masked]>
Date: Fri, 26 Sep 2014 13:20:22 +0000

All,

IPP Scan can support multiple document jobs.  There are attributes that allow the printer to declare that capability ( "multiple-document-jobs-supported") as well as operational attributes ("document-number", "last-document") to segment the data pulled from the scan service into multiple files (i.e. one file per document, number of images in a file is format and implementation specific).  During the prototype I used a scanner that emitted JPG or PDF.  When loading a stack of media into the ADF each image acquisition resulted in an image.  The number of documents objects generated was dictated by output file type.  In the IPP binding I limited the file to document object association to 1 to 1.  I did not want to deal with the complexities of associating multiple files with a single document object.    The abstract MFD Scan model did allow multiple files per document.

Running a stack of paper using JPG as the " document-format-accepted" resulted in a multiple files each of which was associated with a single document.  Running that same stack of paper using PDF as the "document-format-accepted" resulted in a single multipage file associated with a single document.  From the client perspective using Get-Next-Document-Images behaved a bit different for each job.  With the JPG output the responses had a document number that changed throughout the scan job retrieval.  The number of responses with the same document number varied based on the complexity of the image.  Each time the document number changed, the output file is closed and a new one is opened.  The last Get-Next-Document-Images for the last document in the job set the "last-document" to true.  In a push job version of this scan job, the same number of files are created at the destination. With the PDF output the responses had a document number remained the same throughout the scan jo
 b retrieval.    When the last Get-Next-Document-Images for the job had the "last-document" to true, the output file was closed.  In a push job version of this scan job, one file was created at the destination.

The MFD Scan model was created with the idea that the same protocol would be used locally or remotely.  Therefore the was considerable more control over the behavior of the scanner itself.  The IPP Scan service simplified a number of aspects to address the 98% needs for network scanning in a mobile environment.  I expect the MFD Scan service would be adjusted to better reflect implementation experience within the PWG (i.e., IPP Scan) and in the industry (e.g., WS-Scan, UPnP Scan, vendor specific scan).

Peter Zehler

PARC, A Xerox Company
800 Phillips Rd, 128-27E
Webster NY, 14580-9701

-----Original Message-----
From: William A Wagner [mailto:[email-masked]] 
Sent: Thursday, September 25, 2014 2:15 PM
To: 'Michael Sweet'
Cc: Zehler, Peter; [email-masked]; [email-masked]
Subject: RE: IPP Scan question.

Michael,

1. I agree that Figure 3 of the MFD Scan spec definitely indicates that there can be multiple images in one scan document; I do not see where it indicates that there cannot be multiple documents is a job. Furthermore, Figure 4 of that same document (with the associated text) definitely states that, for a multi-document Job,  " Job object contains multiple Document objects. Each Document can have a different set of processing parameters."
And further that the Scan Service semantic model may allow the End User to specify a multi-document Job as a service output. If we have intentionally decided to not consider multi-document jobs in IPP, that should be made clear. I think it is to be determined if we decide to eliminate them from the SM3. (Incidentally, I do not see a compelling Use Case for multi-document Scan Jobs, although some may exist.)

2. I get your explanation that Get-Next-Document-Images refers to multiple images of a document, and that "last-document" refers to the last image of a document. But these are names are misleading. Do we use 'Images' to refer to anything other than 'Document Images'?

I apologize for not commenting on the IPP Scan document earlier, but I think the one document per job characteristic, despite what one might expect from the names, should be made more clear. Also, as you suggest, the fact that for Pull Scan,  the GetNextDocumentImages can redefine Compression Accepted and Document Format Accepted for each image of potentially multiple images document.
Thanks,
Bill Wagner 

-----Original Message-----
From: Michael Sweet [mailto:[email-masked]]
Sent: Thursday, September 25, 2014 9:12 AM
To: William A Wagner
Cc: Zehler, Peter; [email-masked]; [email-masked]
Subject: Re: IPP Scan question.

Bill,

I don't think these are multiple document objects, however.
Get-Next-Document-Images is a convenient way to pull one or more images/pages from the scanner, but from the point of view of the model they are part of one document object and would be delivered (in the case of push
scan) as a single file.
 
> Destination,  DestinationAccesses, and  InputElements for Scan with no
need to have a FetchDocument operation.  This  suggests that there is but one document (possibly with multiple destinations) in a Scan Job.
Alternatively,  it may be that the Input Parameters and Destinations for each one of multiple documents are defined in the CreateJob.  This seemes inconsistent with the general Imaging Service model.

In the case of Scan, the CreateScanJob operation is instantiating a single scan job containing a single document object that may have multiple digital representations (e.g. PDF, TIFF, etc.) of the same images.  Figure 3 on page
22 of the MFD Scan spec seems pretty clear on that point.  This is similar to how the Copy and FaxIn services work (single document jobs).

> The IPP Scan specification definitely refers to multiple documents in 
scan job.  However, Figure 1 can be interpreted to mean that  the only operation necessary for Scan is a CreateJob, with GetNextDocumentImages necessary if it is a Pull Scan Job. Indeed, InputAttributes is defined to be in the CreateJob request as well as are the Job Template attributes defining destination; but it does not appear that different InputAttributes and/or destinations can be specified for different documents.

 
> Do I correctly understand that, although there may be multiple 
in a scan job, they must all have the same InputAttributes and the same destination(s)?  An alternate approach might have been to send  a SetDocumentAttributes sent for each document to be scanned, which contained the input parameters and destination for each specific document/image file; that would have been consistent with the Model.

Currently you scan whatever is at the input source and send it to the
destination(s) or pull the images with Get-Next-Document-Images.  The only way to break things up is to create multiple jobs and specify the number of images for each job in the "input-images-to-transfer" member attribute.
 
> For Cloud, we need to decide whether we should reflect the Semantic 
(with which we should bet be consistent) or the IPP Scan Binding. Or do we need to change the semantic model?

> 1.                          Table 1 lists Get-Next-Document-Images and
refers to PWG 5100.SCAN.  I take it that this  means to have the specification refer to itself, but it is confusing even if the proper number is inserted. Better to refer to the internal paragraph.

Agreed.

> 3.                          In para 7.1.1, under Group 2: Job Template
Attributes is a reference to section 8.28.1.7.2.  There is no such section (should it be 8.2?)

---

From: "William A Wagner" <[email-masked]>
Date: Fri, 26 Sep 2014 17:19:17 -0400

Pete,

Thanks for the correction. A few items for clarification to see if I got it
right. I would very much appreciate either agreement with or correction of
my interpretation.

      1. Hardcopy document refers just to the material that is being scanned
and has no other correlation to Digital Document. For example, conceivably,
a set of pages from multiple books could be scanned with the image data
ultimately appearing in a single document. Alternatively, multiple pages for
a single hardcopy document could be scanned and appear as multiple Digital
Documents.

      2. Image refers to the content in a specified scan region of a
hardcopy document. Unless the scanner is set up to combine the data from
multiple scanned images, an image cannot refer to more than the content of
one sheet side. Therefore, for example, a scan job concerned with multiple
pages of a hardcopy document will contain multiple images.

      3. There is a 1:1 relationship between Digital Documents and files, in
that each Digital Document is formatted and stored as a separatefile.

      4. In general, the relationship of images to digital documents is
format (and perhaps implementation) specific. If the
'document-format-accepted' is a document format such as PDF, there may be
multiple images per document. If 'document-format-accepted' is an image
format such as JPEG or GIF, each image is more likely a separate digital
document.

      5. In IPP Scan Push mode, all Digital Documents produced in a Job are
scanned and formatted  in the same way and stored to the same
destination(s), as specified in the CreateJob.

            a. If the job produces multiple digital documents, the
destination is a directory with each Digital Document being a separate file
in that directory. 

            b. If the job produces a single document, the specified
destination is of the file.

      6. In IPP Scan Push mode, the client may  specify multiple
destinations.

      7. In IPP Scan Pull mode, each digital document produced by a job is
sent back to the client in response to a GetNextDocumentImage request from
the Client. Each document may contain data from a single image or from
multiple images. There may be multiple documents as part of a single job. 

            a. Unlike in Push mode, the Compression Accepted and Document
Format Accepted may be separately specified in each GetNextDocumentImage
request. (I find this rather odd - especially since each such request does
not necessarily correspond to either a Document or an image. )

            b. The mode of operation of GetNextDocumentImage depends upon
whether Wait Mode is agreed upon. In Wait mode, data is sent as it becomes
available and can be accepted. If not in Wait mode (or if Wait mode is
interrupted or timed out) , the client must issue a GetNextDocumentImage for
each buffer's-worth of data.

      8. This mode of transfer suggests that GetNextDocumentImage does not
refer either to getting an Image or getting a Document, it just pulls data
in a mode determined by the Wait mode. That data may be formatted into one
or more Digital Documents, depending on format and contents.

I also understand that you suggest that the Scan Service in SM3 be changed
to agree with IPP Scan.

Many thanks,

Bill Wagner

-----Original Message-----
From: Zehler, Peter [mailto:[email-masked]] 
Sent: Friday, September 26, 2014 9:20 AM
To: William A Wagner; 'Michael Sweet'
Cc: [email-masked]; [email-masked]
Subject: RE: IPP Scan question.

All,

IPP Scan can support multiple document jobs.  There are attributes that
allow the printer to declare that capability (
"multiple-document-jobs-supported") as well as operational attributes
("document-number", "last-document") to segment the data pulled from the
scan service into multiple files (i.e. one file per document, number of
images in a file is format and implementation specific).  During the
prototype I used a scanner that emitted JPG or PDF.  When loading a stack of
media into the ADF each image acquisition resulted in an image.  The number
of documents objects generated was dictated by output file type.  In the IPP
binding I limited the file to document object association to 1 to 1.  I did
not want to deal with the complexities of associating multiple files with a
single document object.    The abstract MFD Scan model did allow multiple
files per document.

Running a stack of paper using JPG as the " document-format-accepted"
resulted in a multiple files each of which was associated with a single
document.  Running that same stack of paper using PDF as the
"document-format-accepted" resulted in a single multipage file associated
with a single document.  From the client perspective using
Get-Next-Document-Images behaved a bit different for each job.  With the JPG
output the responses had a document number that changed throughout the scan
job retrieval.  The number of responses with the same document number varied
based on the complexity of the image.  Each time the document number
changed, the output file is closed and a new one is opened.  The last
Get-Next-Document-Images for the last document in the job set the
"last-document" to true.  In a push job version of this scan job, the same
number of files are created at the destination. With the PDF output the
responses had a document number remained the same throughout the scan job
retrieval.    When the last Get-Next-Document-Images for the job had the
"last-document" to true, the output file was closed.  In a push job version
of this scan job, one file was created at the destination.

The MFD Scan model was created with the idea that the same protocol would be
used locally or remotely.  Therefore the was considerable more control over
the behavior of the scanner itself.  The IPP Scan service simplified a
number of aspects to address the 98% needs for network scanning in a mobile
environment.  I expect the MFD Scan service would be adjusted to better
reflect implementation experience within the PWG (i.e., IPP Scan) and in the
industry (e.g., WS-Scan, UPnP Scan, vendor specific scan).

Peter Zehler

PARC, A Xerox Company

800 Phillips Rd, 128-27E

Webster NY, 14580-9701

Email:  <mailto:[email-masked]> [email-masked]

FAX: +1 (585) 265-7441

-----Original Message-----

From: William A Wagner [ <mailto:[email-masked]>
mailto:[email-masked]]

To: 'Michael Sweet'

Cc: Zehler, Peter;  <mailto:[email-masked]> [email-masked];
<mailto:[email-masked]> [email-masked]

Michael,

Thanks,

Bill Wagner 

-----Original Message-----

From: Michael Sweet [ <mailto:[email-masked]> mailto:[email-masked]]

To: William A Wagner

Cc: Zehler, Peter;  <mailto:[email-masked]> [email-masked];
<mailto:[email-masked]> [email-masked]

Bill,

> On Sep 21, 2014, at 9:50 AM, William A Wagner <
<mailto:[email-masked]> [email-masked]>

scan) as a single file.

> The IPP Scan specification definitely refers to multiple documents in 

> one

> Do I correctly understand that, although there may be multiple 

> documents

> For Cloud, we need to decide whether we should reflect the Semantic 

> Model

> Also, a few minor editorial comments/questions I had while looking up

stuff.

Agreed.

---

From: "Zehler, Peter" <[email-masked]>
Date: Mon, 29 Sep 2014 11:24:58 +0000

Bill,
My responses are in-line below.
Pete

Peter Zehler

PARC, A Xerox Company
800 Phillips Rd, 128-27E
Webster NY, 14580-9701

From: William A Wagner [mailto:[email-masked]]
Sent: Friday, September 26, 2014 5:19 PM
To: Zehler, Peter
Cc: [email-masked]
Subject: RE: IPP Scan question.

Pete,

Thanks for the correction. A few items for clarification to see if I got it right. I would very much appreciate either agreement with or correction of my interpretation.

1.  Hardcopy document refers just to the material that is being scanned and has no other correlation to Digital Document. For example, conceivably, a set of pages from multiple books could be scanned with the image data ultimately appearing in a single document. Alternatively, multiple pages for a single hardcopy document could be scanned and appear as multiple Digital Documents.

2.  <PZ>Correct</PZ>

3.  Image refers to the content in a specified scan region of a hardcopy document. Unless the scanner is set up to combine the data from multiple scanned images, an image cannot refer to more than the content of one sheet side. Therefore, for example, a scan job concerned with multiple pages of a hardcopy document will contain multiple images.

4.  <PZ>Correct</PZ>

      3. There is a 1:1 relationship between Digital Documents and files, in that each Digital Document is formatted and stored as a separate file.

<PZ>That is true of the IPP binding for Network Scanning.  The MFD Network Scan model permitted more than one file to be associated with a Digital Document.  We never discussed the packaging of a multi-file Digital Document.  We could add a "run list" that referenced all the files or we could, as I did in an early prototype, collect all the image files for a Digital Document into a folder and the Document Object would reference the folder.   It will be up to the SM 3 group to determine what will be done with the SM3 Network Scan specification.  The SM3 model can be simplified or there could be an "IPP Production Scanning Set 1" drafted. :)</PZ>

5.  In general, the relationship of images to digital documents is format (and perhaps implementation) specific. If the 'document-format-accepted' is a document format such as PDF, there may be multiple images per document. If 'document-format-accepted' is an image format such as JPEG or GIF, each image is more likely a separate digital document.

6.  <PZ>That is correct, I think.  As far as I know there is no multipage JPEG format.</PZ>

      5. In IPP Scan Push mode, all Digital Documents produced in a Job are scanned and formatted  in the same way and stored to the same destination(s), as specified in the CreateJob.

<PZ>Not necessarily, the client could specify multiple acceptable formats.  I see no limitation preventing a smart scan service storing content that contains text in a pdf document and photos in jpeg files. The usual case would be to consistently store all the Digital Documents produced in the Job.</PZ>

a.  If the job produces multiple digital documents, the  destination is a directory with each Digital Document being a separate file in that directory.

<PZ>Correct, it would be an error to specify a file as a destination for a multi-paged Digital Document.  The error would something like "conflicting-attributes" or "document-access-error"</PZ>

b.  If the job produces a single document, the specified destination is of the file.

<PZ>If it is a file that is where the Digital Document is stored.  If it is a directory, a file would be created in that directory to hold the Digital Document.</PZ>

7.  In IPP Scan Push mode, the client may  specify multiple destinations.

<PZ>Yes.</PZ>

8.  In IPP Scan Pull mode, each digital document produced by a job is sent back to the client in response to a GetNextDocumentImage request from the Client. Each document may contain data from a single image or from multiple images. There may be multiple documents as part of a single job.

<PZ>Yes</PZ>

a.  Unlike in Push mode, the Compression Accepted and Document Format Accepted may be separately specified in each GetNextDocumentImage request. (I find this rather odd - especially since each such request does not necessarily correspond to either a Document or an image. )

<PZ>While this is true I would not expect the client to change the acceptable format/compression throughout the exchange.  I believe it is the Scan Service that is in control of the format/compression as the Digital Document is being delivered.  The acceptable format/compression operational attributes for the "Get-Next-Document-Images" Request could be deleted from the specification without any problems.  It would probably remove some confusion.  The format/compression attributes in the response and in the "Create-Job" request</PZ>

b.  The mode of operation of GetNextDocumentImage depends upon whether Wait Mode is agreed upon. In Wait mode, data is sent as it becomes available and can be accepted. If not in Wait mode (or if Wait mode is interrupted or timed out) , the client must issue a GetNextDocumentImage for each buffer's-worth of data.

<PZ>Yes, it is a choice between synchronous and asynchronous network operations.</PZ>

      8. This mode of transfer suggests that GetNextDocumentImage does not refer either to getting an Image or getting a Document, it just pulls data in a mode determined by the Wait mode. That data may be formatted into one or more Digital Documents, depending on format and contents.
<PZ>While that is true we had to call it something.  We went through a couple of name changes.  In IPP it's just "0x004A".  It is pulling the data for an image(s) within a document.  Subsequent responses may pull the data for an image(s) from within another document    I'd prefer not to entertain cosmetic changes at this time.</PZ>

I also understand that you suggest that the Scan Service in SM3 be changed to agree with IPP Scan.

<PZ>.As previously stated, it will be up to the SM 3 group to determine what will be done with the SM3 Network Scan specification.  The SM3 model can be simplified or there could be an "IPP Production Scanning Set 1" drafted. :)</PZ>

Many thanks,

Bill Wagner

-----Original Message-----
From: Zehler, Peter [mailto:[email-masked]]
Sent: Friday, September 26, 2014 9:20 AM
To: William A Wagner; 'Michael Sweet'
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: IPP Scan question.

All,

Running a stack of paper using JPG as the " document-format-accepted" resulted in a multiple files each of which was associated with a single document.  Running that same stack of paper using PDF as the "document-format-accepted" resulted in a single multipage file associated with a single document.  From the client perspective using Get-Next-Document-Images behaved a bit different for each job.  With the JPG output the responses had a document number that changed throughout the scan job retrieval.  The number of responses with the same document number varied based on the complexity of the image.  Each time the document number changed, the output file is closed and a new one is opened.  The last Get-Next-Document-Images for the last document in the job set the "last-document" to true.  In a push job version of this scan job, the same number of files are created at the destination. With the PDF output the responses had a document number remained the same throughout the scan job retrieval.    When the last Get-Next-Document-Images for the job had the "last-document" to true, the output file was closed.  In a push job version of this scan job, one file was created at the destination.

Peter Zehler

PARC, A Xerox Company

800 Phillips Rd, 128-27E

Webster NY, 14580-9701

FAX: +1 (585) 265-7441

-----Original Message-----

To: 'Michael Sweet'

Cc: Zehler, Peter; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Michael,

Thanks,

Bill Wagner

-----Original Message-----

To: William A Wagner

Cc: Zehler, Peter; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Bill,

> On Sep 21, 2014, at 9:50 AM, William A Wagner <[email-masked]<mailto:[email-masked]>>

scan) as a single file.

stuff.

Agreed.

---

From: "William A Wagner" <[email-masked]>
Date: Mon, 29 Sep 2014 12:55:08 -0400

Many thanks Pete. This has been a great help to me in understanding IPP
Scan.

Bill Wagner

From: Zehler, Peter [mailto:[email-masked]] 
Sent: Monday, September 29, 2014 7:25 AM
To: William A Wagner
Cc: [email-masked]
Subject: RE: IPP Scan question.

Bill,

Pete

Peter Zehler

PARC, A Xerox Company
800 Phillips Rd, 128-27E
Webster NY, 14580-9701

Pete,

1.  Hardcopy document refers just to the material that is being scanned and
has no other correlation to Digital Document. For example, conceivably, a
set of pages from multiple books could be scanned with the image data
ultimately appearing in a single document. Alternatively, multiple pages for
a single hardcopy document could be scanned and appear as multiple Digital
Documents.

2.  <PZ>Correct</PZ>

3.  Image refers to the content in a specified scan region of a hardcopy
document. Unless the scanner is set up to combine the data from multiple
scanned images, an image cannot refer to more than the content of one sheet
side. Therefore, for example, a scan job concerned with multiple pages of a
hardcopy document will contain multiple images.

4.  <PZ>Correct</PZ>

      3. There is a 1:1 relationship between Digital Documents and files, in
that each Digital Document is formatted and stored as a separate file.

<PZ>That is true of the IPP binding for Network Scanning.  The MFD Network
Scan model permitted more than one file to be associated with a Digital
Document.  We never discussed the packaging of a multi-file Digital
Document.  We could add a "run list" that referenced all the files or we
could, as I did in an early prototype, collect all the image files for a
Digital Document into a folder and the Document Object would reference the
folder.   It will be up to the SM 3 group to determine what will be done
with the SM3 Network Scan specification.  The SM3 model can be simplified or
there could be an "IPP Production Scanning Set 1" drafted. J</PZ>

5.  In general, the relationship of images to digital documents is format
(and perhaps implementation) specific. If the 'document-format-accepted' is
a document format such as PDF, there may be multiple images per document. If
'document-format-accepted' is an image format such as JPEG or GIF, each
image is more likely a separate digital document.

6.  <PZ>That is correct, I think.  As far as I know there is no multipage
JPEG format.</PZ>

<PZ>Not necessarily, the client could specify multiple acceptable formats.
I see no limitation preventing a smart scan service storing content that
contains text in a pdf document and photos in jpeg files. The usual case
would be to consistently store all the Digital Documents produced in the
Job.</PZ> 

a.  If the job produces multiple digital documents, the  destination is a
directory with each Digital Document being a separate file in that
directory. 

<PZ>Correct, it would be an error to specify a file as a destination for a
multi-paged Digital Document.  The error would something like
"conflicting-attributes" or "document-access-error"</PZ>

b.  If the job produces a single document, the specified destination is of
the file.

<PZ>If it is a file that is where the Digital Document is stored.  If it is
a directory, a file would be created in that directory to hold the Digital
Document.</PZ>

<PZ>Yes.</PZ>

8.  In IPP Scan Pull mode, each digital document produced by a job is sent
back to the client in response to a GetNextDocumentImage request from the
Client. Each document may contain data from a single image or from multiple
images. There may be multiple documents as part of a single job. 

<PZ>Yes</PZ>

a.  Unlike in Push mode, the Compression Accepted and Document Format
Accepted may be separately specified in each GetNextDocumentImage request.
(I find this rather odd - especially since each such request does not
necessarily correspond to either a Document or an image. )

<PZ>While this is true I would not expect the client to change the
acceptable format/compression throughout the exchange.  I believe it is the
Scan Service that is in control of the format/compression as the Digital
Document is being delivered.  The acceptable format/compression operational
attributes for the "Get-Next-Document-Images" Request could be deleted from
the specification without any problems.  It would probably remove some
confusion.  The format/compression attributes in the response and in the
"Create-Job" request</PZ>

b.  The mode of operation of GetNextDocumentImage depends upon whether Wait
Mode is agreed upon. In Wait mode, data is sent as it becomes available and
can be accepted. If not in Wait mode (or if Wait mode is interrupted or
timed out) , the client must issue a GetNextDocumentImage for each
buffer's-worth of data.

<PZ>Yes, it is a choice between synchronous and asynchronous network
operations.</PZ>

      8. This mode of transfer suggests that GetNextDocumentImage does not
refer either to getting an Image or getting a Document, it just pulls data
in a mode determined by the Wait mode. That data may be formatted into one
or more Digital Documents, depending on format and contents.
<PZ>While that is true we had to call it something.  We went through a
couple of name changes.  In IPP it's just "0x004A".  It is pulling the data
for an image(s) within a document.  Subsequent responses may pull the data
for an image(s) from within another document    I'd prefer not to entertain
cosmetic changes at this time.</PZ>

<PZ>.As previously stated, it will be up to the SM 3 group to determine what
will be done with the SM3 Network Scan specification.  The SM3 model can be
simplified or there could be an "IPP Production Scanning Set 1" drafted.
J</PZ>

Many thanks,

Bill Wagner

-----Original Message-----
From: Zehler, Peter [mailto:[email-masked]] 
Sent: Friday, September 26, 2014 9:20 AM
To: William A Wagner; 'Michael Sweet'
Cc: [email-masked]; [email-masked]
Subject: RE: IPP Scan question.

All,

Peter Zehler

PARC, A Xerox Company

800 Phillips Rd, 128-27E

Webster NY, 14580-9701

FAX: +1 (585) 265-7441

-----Original Message-----

To: 'Michael Sweet'

Michael,

Thanks,

Bill Wagner 

-----Original Message-----

To: William A Wagner

Bill,

scan) as a single file.

stuff.

Agreed.

---

From: Michael Sweet <[email-masked]>
Date: Mon, 29 Sep 2014 13:41:11 -0400

Pete,

I think we should clarify this in the scan spec - it wasn't clear at all to me that multiple scanned images mapped to multiple IPP document objects.  My suggestion is that you add a paragraph in section 4.1 explaining how you get multiple document objects.

> On Sep 26, 2014, at 9:20 AM, Zehler, Peter <[email-masked]> wrote:
> 
> All,
> 
> Running a stack of paper using JPG as the " document-format-accepted" resulted in a multiple files each of which was associated with a single document.  Running that same stack of paper using PDF as the "document-format-accepted" resulted in a single multipage file associated with a single document.  From the client perspective using Get-Next-Document-Images behaved a bit different for each job.  With the JPG output the responses had a document number that changed throughout the scan job retrieval.  The number of responses with the same document number varied based on the complexity of the image.  Each time the document number changed, the output file is closed and a new one is opened.  The last Get-Next-Document-Images for the last document in the job set the "last-document" to true.  In a push job version of this scan job, the same number of files are created at the destination. With the PDF output the responses had a document number remained the same throughout the scan 
 job retrieval.    When the last Get-Next-Document-Images for the job had the "last-document" to true, the output file was closed.  In a push job version of this scan job, one file was created at the destination.