Subject: [IPP] Don't redefine Hardcopy Document

From: "Zehler, Peter" <[email-masked]>
Date: Tue, 6 Aug 2013 13:26:16 +0000

All,

A Hardcopy document is not an electronic format.  The industry, and the PWG, have existing definitions that are in agreement (See below).  A hardcopy document is physical media.  In the PWG Semantic Model Documents are objects with references to document content that is an electronic document representation (e.g.  PDF, JPEG, PCL, vendor specific).  These representations have a type using MIME media types (See rfc2911 section 3.2.1.1).

In IPP document content was either pass by value (i.e. via Print-Job or Send-Document) or by reference (i.e., Print-URI or Send-URI).  For a FAX service we needed to represent the historical FAX paradigm of FAXing a hardcopy document.  It is similar to a Send-URI but constrained to a reference to document content being obtained via the MFD's scanner subunit.  Note that a mobile device that acquires an image from a hardcopy document would not issue an Add-Hardcopy-Document to the MFD.  The mobile device would use the Send-Document or Send-URI based on how the document content would be transferred to the target MFD.

I have no objection to normalizing the parameters for Adding a Hardcopy Document to a job.  The ScanDocumentProcessing/CopyDocumentProcessing.CopyInput could easily be applied to AddHardcopyDocument and would apply to a number of services.

Pete

Existing definitions of Hardcopy Document:
>From Federal Standard 1037C (Telecommunications: Glossary of Telecommunication Terms): "hard copy: In computer graphics and in telecommunications, a permanent reproduction, on any media suitable for direct use by a person, of displayed or transmitted data. (188) Note 1: Examples of hard copy include teletypewriter pages, continuous printed tapes, facsimile pages, computer printouts, and radiophoto prints. Note 2: Magnetic tapes, diskettes, and nonprinted punched paper tapes are not hard copy."

>From Alliance for Telecommunications Industry Solutions Telecom Glossary: "In computer graphics and in telecommunications, a permanent reproduction, on any media suitable for direct use by a person, of displayed or transmitted data. Note 1: Examples of hard copy include teletypewriter pages, continuous printed tapes, facsimile pages, computer printouts, and radiophoto prints. Note 2: Magnetic tapes, diskettes, and nonprinted punched paper tapes are not hard copy."

>From Printer Working Group (PWG 5108.01): "Hardcopy Document: A Document on physical media such as paper, transparency or film that is the input source to Scan, Copy and FaxOut Services and the output from Print, Copy and FaxIn Services"

Peter Zehler

Xerox Research Center Webster
Email: [email-masked]<mailto:[email-masked]>
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701

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

---

From: Michael Sweet <[email-masked]>
Date: Tue, 6 Aug 2013 11:34:48 -0400

Pete,

The point of the discussion in the SM and IPP WGs is not to redefine what a hardcopy document is (although I would like to generalize what was put in 5108.01 since it ties them to specific services), but to include the definition of it and the corresponding (Hardcopy) Document Object (the digital representation of the hardcopy document) in the SM and IPP specifications.

Comments inline, but I'll make sure we include this in our discussions on Thursday...

> A Hardcopy document is not an electronic format.  The industry, and the PWG, have existing definitions that are in agreement (See below).  A hardcopy document is physical media.  In the PWG Semanti…

This is the difference between a Hardcopy Document and a Hardcopy Document /Object/. We need to define the latter and not the former.

> In IPP document content was either pass by value (i.e. via Print-Job or Send-Document) or by reference (i.e., Print-URI or Send-URI).  For a FAX service we needed to represent the historical FAX paradigm of FAXing a hardcopy document.  It is similar to a Send-URI but constrained to a reference to document content being obtained via the MFD’s scanner subunit.  Note that a mobile device that acquires an image from a hardcopy document would not issue an Add-Hardcopy-Document to the MFD.  The mobile device would use the Send-Document or Send-URI based on how the document content would be transferred to the target MFD.

I disagree - mobile devices can and are used as a front-end to the MFD today. The hardcopy document may, in fact, be loaded in the MFD.  The mobile device can scan and then send the scanned data to the MFD /or/ it can simple create a job that references the loaded hardcopy document to avoid the intermediate data transfers.  And given that the scan destination semantics require some form of intermediate storage, I would argue that mobile devices would prefer to use Send/Add-Hardcopy-Document over scanning and submitting the scan.

> I have no objection to normalizing the parameters for Adding a Hardcopy Document to a job.  The ScanDocumentProcessing/CopyDocumentProcessing.CopyInput could easily be applied to AddHardcopyDocumen…

Right, that is the point of our discussions - how do we model Hardcopy Document /Objects/ (digital representations of Hardcopy Documents) in the SM and IPP?  Aside from generalizing the Send/Add-Hardcopy-Document operation for multiple services, we need this for Cloud/IPPSIX to support indirect access to MFD scanners.

> From Federal Standard 1037C (Telecommunications: Glossary of Telecommunication Terms): “hard copy: In computer graphics and in telecommunications, a permanent reproduction, on any media suitable for direct use by a person, of displayed or transmitted data. (188) Note 1: Examples of hard copy include teletypewriter pages, continuous printed tapes, facsimile pages, computer printouts, and radiophoto prints. Note 2: Magnetic tapes, diskettes, and nonprinted punched paper tapes are not hard copy.”
>  
> From Alliance for Telecommunications Industry Solutions Telecom Glossary: “In computer graphics and in telecommunications, a permanent reproduction, on any media suitable for direct use by a person, of displayed or transmitted data. Note 1: Examples of hard copy include teletypewriter pages, continuous printed tapes, facsimile pages, computer printouts, and radiophoto prints. Note 2: Magnetic tapes, diskettes, and nonprinted punched paper tapes are not hard copy.”
>  
> From Printer Working Group (PWG 5108.01): “Hardcopy Document: A Document on physical media such as paper, transparency or film that is the input source to Scan, Copy and FaxOut Services and the output from Print, Copy and FaxIn Services”
>  
>  
> Peter Zehler
> 
> Email: [email-masked]
> Voice: (585) 265-8755
> FAX: (585) 265-7441
> US Mail: Peter Zehler
> Xerox Corp.
> 800 Phillips Rd.
> M/S 128-25E
> Webster NY, 14580-9701
>  
>  

_____________
Michael Sweet

---

From: "Zehler, Peter" <[email-masked]>
Date: Tue, 6 Aug 2013 16:54:09 +0000

My responses are inline below.

Peter Zehler

From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Sweet
Sent: Tuesday, August 06, 2013 11:35 AM
To: Zehler, Peter
Cc: [email-masked]; [email-masked]
Subject: Re: [IPP] Don't redefine Hardcopy Document

Pete,

On 2013-08-06, at 9:26 AM, "Zehler, Peter" <[email-masked]<mailto:[email-masked]>> wrote:
All,

This is the difference between a Hardcopy Document and a Hardcopy Document /Object/. We need to define the latter and not the former.
<PZ>I see no subclasses of Documents in the PWG Semantic Model or IPP.  Whether a document is added to a Job by value, by reference, or by reference to the output of the scanner subunit, it is still just a Document object.  There are differences in the operations that add a Document to a Job in how the Document Data (aka Digital Document) is transferred.  The AddHardcopyDocument instructs the MFD to obtain the document content from its scanner subunit.  A mobile device that takes a picture of a document with its camera would not issue an AddHardcopyDocument to the MFD.  It would use AddDocument or AddUri.</PZ>

I disagree - mobile devices can and are used as a front-end to the MFD today. The hardcopy document may, in fact, be loaded in the MFD.  The mobile device can scan and then send the scanned data to the MFD /or/ it can simple create a job that references the loaded hardcopy document to avoid the intermediate data transfers.  And given that the scan destination semantics require some form of intermediate storage, I would argue that mobile devices would prefer to use Send/Add-Hardcopy-Document over scanning and submitting the scan.
<PZ>I don't understand what the disagreement is.  Mobile devices can be used as a front end to MFDs.  They can offer the AddHardcopyDocument operation to Clients.  I would say that the Hardcopy Document MUST be loaded in the MFD's ADF or platen though.  The mobile device front end would simply pass the operation through if the MFD supports IPP or other PWG compliant protocol.  If the MFD is not PWG compliant, the mobile device would have to interact with the MFD to insure the Hardcopy Documents are scanned at the appropriate time and included correctly in the MFD's output.  There would be nothing preventing an implementation of AddHardcopyDocument on the mobile device from using the MFDs Scan Service, or functional equivalent, to obtain the Digital Document from the scanning the hardcopy.  But then the mobile device would be using SendDocument/SendUri with the MFD to add the document content it obtained from the Scan Service.   I agree that mobile devices would prefer to use Send/Add-Hardcopy-Document over scanning and submitting the scan.</PZ>

Right, that is the point of our discussions - how do we model Hardcopy Document /Objects/ (digital representations of Hardcopy Documents) in the SM and IPP?  Aside from generalizing the Send/Add-Hardcopy-Document operation for multiple services, we need this for Cloud/IPPSIX to support indirect access to MFD scanners.
<PZ>Why wouldn't the ScanDocumentProcessing attribute be optional for documents receive via an Add/Add-Hardcopy-Document and an error if included in other operations.  This would be similar to the document-uri attribute that is conditionally mandatory based on support for the Send-Uri operation.  The ScanDocumentProcessing attribute, just like the document-uri attribute identified the source location of the document data.  The ScanDocumentProcessing goes beyond that since it controls the document data acquisition processing as well.</PZ>

Pete

Peter Zehler

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

_____________
Michael Sweet

---

From: Michael Sweet <[email-masked]>
Date: Tue, 6 Aug 2013 22:14:05 -0400

Pete,

I guess we are in violent agreement.  One comment below.

On 2013-08-06, at 12:54 PM, "Zehler, Peter" <[email-masked]> wrote:
> ...
> <PZ>I see no subclasses of Documents in the PWG Semantic Model or IPP.  Whether a document is added to a Job by value, by reference, or by reference to the output of the scanner subunit, it is still just a Document object. 

I am not suggesting a subclass of document.

We already categorize documents as "referenced" and "with attached document data". For hardcopy documents we would have a Document Object containing description attributes/elements that identify the source and properties of the hardcopy document.

I chose to call it a "Hardcopy Document Object" as opposed to a "Document Object with Associated Hardcopy Document Input Elements".  How the digital representation is stored and when exactly the document is scanned are, IMHO, implementation specific.

_____________
Michael Sweet

---

From: "Zehler, Peter" <[email-masked]>
Date: Wed, 7 Aug 2013 10:21:36 +0000

Mike,
Well, I guess I'll be quiet now except to say it would be a good time to describe the attributes and constraints on all three types of Documents. :)
Pete

Peter Zehler

From: Michael Sweet [mailto:[email-masked]]
Sent: Tuesday, August 06, 2013 10:14 PM
To: Zehler, Peter
Cc: [email-masked]; [email-masked]
Subject: Re: [IPP] Don't redefine Hardcopy Document

Pete,

On 2013-08-06, at 12:54 PM, "Zehler, Peter" <[email-masked]<mailto:[email-masked]>> wrote:
...
This is the difference between a Hardcopy Document and a Hardcopy Document /Object/. We need to define the latter and not the former.
<PZ>I see no subclasses of Documents in the PWG Semantic Model or IPP.  Whether a document is added to a Job by value, by reference, or by reference to the output of the scanner subunit, it is still just a Document object.

_____________
Michael Sweet

---

From: Ira McDonald <[email-masked]>
Date: Wed, 7 Aug 2013 11:14:19 -0400

Hi,

At the risk of adding confusion...

We speak of submitting Jobs with document data by reference (URI)
or by value (attached).

Why not just add "by scan (local scanner)".

What I don't like about the term "Hardcopy Document Object" is that
the word Scan or Scanner isn't there, but this is always the source.

Cheers,
- Ira

PS - I dislike putting titlecase prefixes on Document Object or Job
Object - it muddies readability.

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
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 Wed, Aug 7, 2013 at 6:21 AM, Zehler, Peter <[email-masked]>wrote:

>  Mike,****
>
> Well, I guess I’ll be quiet now except to say it would be a good time to
> describe the attributes and constraints on all three types of Documents. J
> ****
>
> Pete****
>
> ** **
>
> Peter Zehler
>
> Webster NY, 14580-9701 ****
>
> ** **
>
> ** **
>
> *From:* Michael Sweet [mailto:[email-masked]]
> *Sent:* Tuesday, August 06, 2013 10:14 PM
>
> *To:* Zehler, Peter
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [IPP] Don't redefine Hardcopy Document****
>
>  ** **
>
> Pete,****
>
> ** **
>
> I guess we are in violent agreement.  One comment below.****
>
> ** **
>
> On 2013-08-06, at 12:54 PM, "Zehler, Peter" <[email-masked]>
> wrote:****
>
>  ...****
>
> This is the difference between a Hardcopy Document and a Hardcopy Document
> /Object/. We need to define the latter and not the former.****
>
> <PZ>I see no subclasses of Documents in the PWG Semantic Model or IPP.
> Whether a document is added to a Job by value, by reference, or by
> reference to the output of the scanner subunit, it is still just a Document
> object. ****
>
>  ** **
>
> I am not suggesting a subclass of document.****
>
> ** **
>
> We already categorize documents as "referenced" and "with attached
> document data". For hardcopy documents we would have a Document Object
> containing description attributes/elements that identify the source and
> properties of the hardcopy document.****
>
> ** **
>
> I chose to call it a "Hardcopy Document Object" as opposed to a "Document
> Object with Associated Hardcopy Document Input Elements".  How the digital
> representation is stored and when exactly the document is scanned are,
> IMHO, implementation specific.****
>
> ** **
>
> _____________
> Michael Sweet****
>
> ** **
>

---

From: Ira McDonald <[email-masked]>
Date: Wed, 7 Aug 2013 11:16:22 -0400

Hi,

Which I think implies that I'd like to rename AddHardcopyDocument to
AddScanDocument.

Cheers,
- Ira

On Wed, Aug 7, 2013 at 11:14 AM, Ira McDonald <[email-masked]>wrote:

>> describe the attributes and constraints on all three types of Documents.
>> J****
>>
>> Pete****
>>
>> ** **
>>
>> Peter Zehler
>>
>> This is the difference between a Hardcopy Document and a Hardcopy
>> Document /Object/. We need to define the latter and not the former.****
>>

---

From: "Paul Tykodi" <[email-masked]>
Date: Wed, 7 Aug 2013 11:29:06 -0400

Hi Ira,

Following your logic, should we consider maintaining AddHardcopyDocument as
the top level in the SM tree and then expand the model with
Add<RelevantPWGDefinedService>Document at the next level in the model for
each service that can support hardcopy document input?

Best Regards,

/Paul

--

Paul Tykodi
Principal Consultant
TCS - Tykodi Consulting Services LLC

Tel/Fax: 603-343-1820
Mobile:  603-866-0712
E-mail:  [email-masked]
WWW:   <http://www.tykodi.com/> http://www.tykodi.com

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ira
McDonald
Sent: Wednesday, August 07, 2013 11:16 AM
To: Zehler, Peter; Ira McDonald
Cc: [email-masked]; [email-masked]; Michael Sweet
Subject: Re: [MFD] [IPP] Don't redefine Hardcopy Document

Hi,

AddScanDocument.

Cheers,

- Ira

 <http://sites.google.com/site/blueroofmusic>
 <http://sites.google.com/site/highnorthinc>

On Wed, Aug 7, 2013 at 11:14 AM, Ira McDonald <[email-masked]>
wrote:

Hi,

Cheers,

- Ira

 <http://sites.google.com/site/blueroofmusic>
 <http://sites.google.com/site/highnorthinc>

On Wed, Aug 7, 2013 at 6:21 AM, Zehler, Peter <[email-masked]>
wrote:

Mike,

Well, I guess I'll be quiet now except to say it would be a good time to
describe the attributes and constraints on all three types of Documents. J

Pete

Peter Zehler

Xerox Research Center Webster
Email: [email-masked]
Voice: (585) 265-8755 <tel:%28585%29%20265-8755> 
FAX: (585) 265-7441 <tel:%28585%29%20265-7441> 
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701 

To: Zehler, Peter

Pete,

...

This is the difference between a Hardcopy Document and a Hardcopy Document
/Object/. We need to define the latter and not the former.

<PZ>I see no subclasses of Documents in the PWG Semantic Model or IPP.
Whether a document is added to a Job by value, by reference, or by reference
to the output of the scanner subunit, it is still just a Document object. 

We already categorize documents as "referenced" and "with attached document
data". For hardcopy documents we would have a Document Object containing
description attributes/elements that identify the source and properties of
the hardcopy document.

I chose to call it a "Hardcopy Document Object" as opposed to a "Document
Object with Associated Hardcopy Document Input Elements".  How the digital
representation is stored and when exactly the document is scanned are, IMHO,
implementation specific.

_____________
Michael Sweet

---

From: Ira McDonald <[email-masked]>
Date: Wed, 7 Aug 2013 11:32:46 -0400

Hi Paul,

No - I object to AddHardcopyDocument.  The only NEW kind of document
(other than w/ data by value or w/ data by reference) is a scanned document.
No other service would ever be infixed in your proposal.

I much prefer AddScanDocument as parallel to [Add/Send]Document.

Cheers,
- Ira

On Wed, Aug 7, 2013 at 11:29 AM, Paul Tykodi <[email-masked]> wrote:

> Hi Ira,****
>
> ** **
>
> Following your logic, should we consider maintaining AddHardcopyDocument
> as the top level in the SM tree and then expand the model with
> each service that can support hardcopy document input?****
>
> ** **
>
> Best Regards,****
>
> ** **
>
> /Paul****
>
> --****
>
> Paul Tykodi
> Principal Consultant
> WWW:  http://www.tykodi.com****
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Ira
> McDonald
> *Sent:* Wednesday, August 07, 2013 11:16 AM
> *To:* Zehler, Peter; Ira McDonald
> *Cc:* [email-masked]; [email-masked]; Michael Sweet
> *Subject:* Re: [MFD] [IPP] Don't redefine Hardcopy Document****
>
> ** **
>
> Hi,****
>
> Which I think implies that I'd like to rename AddHardcopyDocument to****
>
> AddScanDocument.****
>
> Cheers,****
>
> - Ira****
>
>
> ****
>
> Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434****
>
> ** **
>
> Hi,****
> or by value (attached).  ****
>
>
> Why not just add "by scan (local scanner)".****
>
> the word Scan or Scanner isn't there, but this is always the source.****
>
> Cheers,****
>
> - Ira****
>
> PS - I dislike putting titlecase prefixes on Document Object or Job****
>
> Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434****
>
> ** **
>
> *Sent:* Tuesday, August 06, 2013 10:14 PM****
>
>
> *To:* Zehler, Peter
> ..****
> https://www.pwg.org/mailman/listinfo/ipp****
>
> ** **
>
> ** **
>

---

From: "Zehler, Peter" <[email-masked]>
Date: Wed, 7 Aug 2013 15:42:58 +0000

I thought that was the original intention.  We just needed to insure the operation parameters and the associated document attributes are consistent across all the services.

See PWG 5108.01-2011
Table 77 MFD Common Operations and Antecedents
Table 78 Basic MFD Interface Requests and Responses
section 7.3.1.1 Add<service>HardcopyDocument

Peter Zehler

From: Paul Tykodi [mailto:[email-masked]]
Sent: Wednesday, August 07, 2013 11:29 AM
To: 'Ira McDonald'
Cc: [email-masked]; [email-masked]; 'Michael Sweet'; Zehler, Peter
Subject: RE: [MFD] [IPP] Don't redefine Hardcopy Document

Hi Ira,

Following your logic, should we consider maintaining AddHardcopyDocument as the top level in the SM tree and then expand the model with Add<RelevantPWGDefinedService>Document at the next level in the model for each service that can support hardcopy document input?

Best Regards,

/Paul

Tel/Fax: 603-343-1820
Mobile:  603-866-0712
E-mail:  [email-masked]<mailto:[email-masked]>
WWW:  http://www.tykodi.com<http://www.tykodi.com/>
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Ira McDonald
Sent: Wednesday, August 07, 2013 11:16 AM
To: Zehler, Peter; Ira McDonald
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Michael Sweet
Subject: Re: [MFD] [IPP] Don't redefine Hardcopy Document

Hi,

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

On Wed, Aug 7, 2013 at 11:14 AM, Ira McDonald <[email-masked]<mailto:[email-masked]>> wrote:
Hi,
At the risk of adding confusion...

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
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]<mailto:[email-masked]>
Winter  579 Park Place  Saline, MI  48176  734-944-0094<tel:734-944-0094>
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434<tel:906-494-2434>

On Wed, Aug 7, 2013 at 6:21 AM, Zehler, Peter <[email-masked]<mailto:[email-masked]>> wrote:
Mike,
Well, I guess I'll be quiet now except to say it would be a good time to describe the attributes and constraints on all three types of Documents. :)
Pete

Peter Zehler

Xerox Research Center Webster
Email: [email-masked]<mailto:[email-masked]>
Voice: (585) 265-8755<tel:%28585%29%20265-8755>
FAX: (585) 265-7441<tel:%28585%29%20265-7441>
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701

From: Michael Sweet [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, August 06, 2013 10:14 PM

To: Zehler, Peter
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [IPP] Don't redefine Hardcopy Document

Pete,

..

_____________
Michael Sweet

---

From: Michael Sweet <[email-masked]>
Date: Wed, 7 Aug 2013 11:50:04 -0400

Ira,

IIRC, all of the SM operations use <service> in their names, currently Add<service>HardcopyDocument, Send<service>Document, and Send<service>Uri.

Using Add<service>ScanDocument might get confusing.  Add<service>DocumentFromScanner? Or Send<service>DocumentFromScanner to retain consistency with the other Send operations?

On 2013-08-07, at 11:32 AM, Ira McDonald <[email-masked]> wrote:

> WWW:  http://www.tykodi.com
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ira McDonald
> On Wed, Aug 7, 2013 at 11:14 AM, Ira McDonald <[email-masked]> wrote:
> 
> Hi,
> 
> On Wed, Aug 7, 2013 at 6:21 AM, Zehler, Peter <[email-masked]> wrote:
> 
> Mike,
> 
> Well, I guess I’ll be quiet now except to say it would be a good time to describe the attributes and constraints on all three types of Documents. J
> 
> Pete
> 
>  
> 
> Peter Zehler
> 

_____________
Michael Sweet

---

From: Ira McDonald <[email-masked]>
Date: Wed, 7 Aug 2013 11:50:57 -0400

Hi,

Never mind - I've gone into the weeds.

I didn't mean to infix the <service> at all.  I meant to infix the
property of Hardcopy (or Scanned).

I've run afoul of naming conventions in SM operations...

Cheers,
- Ira

On Wed, Aug 7, 2013 at 11:42 AM, Zehler, Peter <[email-masked]>wrote:

>  I thought that was the original intention.  We just needed to insure the
> operation parameters and the associated document attributes are consistent
> across all the services.****
>
> ** **
>
> See PWG 5108.01-2011****
>
> Table 77 MFD Common Operations and Antecedents****
>
> Table 78 Basic MFD Interface Requests and Responses****
>
> section 7.3.1.1 Add<service>HardcopyDocument****
>
> ** **
>
> ** **
>
> Peter Zehler
>
> *From:* Paul Tykodi [mailto:[email-masked]]
> *Sent:* Wednesday, August 07, 2013 11:29 AM
> *To:* 'Ira McDonald'
> *Cc:* [email-masked]; [email-masked]; 'Michael Sweet'; Zehler, Peter
> *Subject:* RE: [MFD] [IPP] Don't redefine Hardcopy Document****
>
> ** **
>
> Hi Ira,****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Ira McDonald
> Object - it muddies readability.****
>
>
> ****
>

---

From: Ira McDonald <[email-masked]>
Date: Wed, 7 Aug 2013 11:52:15 -0400

Hi Mike,

Or "Add<service>ScannedDocument"?  "Hardcopy" is causing some
confusion, it seems.

Cheers,
- Ira

On Wed, Aug 7, 2013 at 11:50 AM, Michael Sweet <[email-masked]> wrote:

> Ira,
>
> IIRC, all of the SM operations use <service> in their names, currently
> Add<service>HardcopyDocument, Send<service>Document, and Send<service>Uri.
>
> Using Add<service>ScanDocument might get confusing.
>  Add<service>DocumentFromScanner? Or Send<service>DocumentFromScanner to
> retain consistency with the other Send operations?
>
>

---

From: Michael Sweet <[email-masked]>
Date: Wed, 7 Aug 2013 11:54:42 -0400

That would be fine with me as well (Scan doesn't have the Add operation so we don't need to worry about AddScanScannedDocument :)

_____________
Michael Sweet