[MFD] Dec. 8-9 Face-to-Face Meeting Minutes is now available

[MFD] Dec. 8-9 Face-to-Face Meeting Minutes is now available

[MFD] Dec. 8-9 Face-to-Face Meeting Minutes is now available

William Wagner wamwagner at comcast.net
Tue Dec 22 23:26:35 UTC 2009



Thanks for your response.


On Item 1, there are two levels of the question. One is specifically should
FaxOut and EmailOut show a digital output to a repository but not Print. I
believe that we can agree that FaxOut, EmailOut, and Print all behave the
same in this regard.

The second part of the question originally got phrased as a question of
"input" vs "output" storage. But I agree with Ira that this is not a
characteristic of the repository. Rather, I maintain that this is a function
of how the Print, etc. Service handles the storage. We have taken the
position  that, for modeling purposes, we are concerned only with elements
that are somehow accessible to a user. For example, although there
undoubtedly is a DigitalDocument somewhere in the inner workings of a
digital copier, we have maintained that the document is not accessible in
digital form and therefore, as far as the model is concerned, it does not
exist. Following this reasoning, if a Print, etc. Service stores a
DigitalDocument in such a way that only that service can re-access it (what
I was calling input storage), regardless of where that storage is
physically, it is an aspect of  implementation and it is not appropriate to
include it in the model. The question then is, do any of these Services have
the ability to store a digital document in a repository in such a way that
that DigitalDocument is accessible to the user? That would obviously include
returning to the user  information on where the document is stored. 


On the Set and Get operation questions, I understand that a request can
include one or more "top level" complex elements. Although I understand the
complexity problem with MediaCol, I remain disturbed about it being an


We will ask Pete to add the questions of  a conformance statement and
response semantic to the next conference call.


Thanks to all. Have a happy and healthy holiday.


Bill Wagner


From: Nancy.Chen at okidata.com [mailto:Nancy.Chen at okidata.com] 
Sent: Tuesday, December 22, 2009 12:54 PM
To: William Wagner
Cc: mfd at pwg.org; mfd-bounces at pwg.org
Subject: RE: [MFD] Dec. 8-9 Face-to-Face Meeting Minutes is now available


Hi Bill, 

I finally got a chance to catch up with my MFD WG emails. Sorry for the
delay in responding to your questions. 

Please see my reply inline in your email below. 

Regards and Happy Holidays! 


"William Wagner" <wamwagner at comcast.net> 
Sent by: mfd-bounces at pwg.org 

12/18/2009 01:52 PM 


<mfd at pwg.org> 




RE: [MFD] Dec. 8-9 Face-to-Face Meeting Minutes is now available




Sorry about these questions so close to the holidays, but I would like to
solidify the meeting comments before they are lost to our celebrations.

1.     With respect to item 1 below, I suggest that a path from Print,
FaxOut, EmailOut to an external repository is valid only if it is a normal
part of the service that a client can extract the document  from that
repository. Using an external repository for JobSave, if that digital
document is not normally accessible to the outside world, is an internal
implementation aspect and should not be considered in the model any more
than a Copy Service Digital Document should be. That being agreed, my
question is then whether it is a customary or desired feature of any Print,
FaxOut, or EmailOut Service to allow alternate access to a Digital Document.

<Nancy> I think we need to clarify whether the repository in Figure 2 should
be an abstract repository for either internal or external repository for the
source or the destination of a digital document of a MFD service, or an
external repository. Since the new IPP Job and Printer Extensions Set2
defines any URI (external or internal to MFD) can be the location for a
document saved for reprint or resubmit operation, I think the repository
should be abstract, therefore can be used for reprint, re-email, re-fax,
..., etc. However, re-print is a new semantics added to IPP as an optional
feature for high-end printing. Is this a customary feature for printing,
email, or fax? Should these be included in "Primary Interfaces with
Services" as the Figure is intended originally I believe? I think we should
discuss with the broader group. 

2.     I am confused by several comments in the minutes relative to
operations, and admit that I was working with the document at the time they
were discussed so did not digest the discussion at the time. The comments
start on line 84 of the minutes and deal with Table 49 and the following

a.      Add "comma" between all parameters.

(no problem)

b.      Get<service>XXXElements: Pete proposed the semantics of these
operations to be taking the requested element name (the keyword of the
top-level elements) as input, and returns one selected top level element
group elements (e.g. capabilities, default ticket, . etc., of a service) .
One exception is that the MediaCol element is quite large and thus the
elements of this group are not returned for Capabilities group. A single
element can only be returned by adding an extension operation. Pete will
align the current Print Service with this semantics.

Does this mean:

.        The  parameters supplied with the Get<service>DocumentElements,
Get<service>JobElements and  Get<service>ServiceElements operations must
include "Top-Level" elements? 

<Nancy> The input parameter "RequestedElement" can contain any number of the
names of the top-level group elements of the service. 

.        What are the  "Top-Level"  elements? The original writeup
identified DocumentReceipt, DocumentStatus or, DocumentTicket; JobReceipt,
JobStatus, or JobTicket;  and ServiceCapabilities, ServiceConfiguration,
ServiceDescription, ServiceStatus or DefaultJobTicket. 
<Nancy> These are correct.<Nancy>

.        Can only one "Top-Level"  element be included in one request? This
is implied in the original writeup but not clearly stated. 

<Nancy> You can request any number of the top-level element groups.<Nancy>

.        The "exception" for MediaCol is disturbing. Are we to simply say
that all complex elements and constituting elements except MediaCol and its
constituent elements are reported? 

<Nancy> Yes. <Nancy> 

i.      All
Services must align with this semantics. This is the same used in WS-Print.

ii.      Bill
will add these statements in the Conformance section.

.        The paragraph defining the operation will reflect  the semantics,
once we clarify what the semantics is. I do not understand "ii". The
Conformance section, as revised,  requires that the Service Specifications
use the definitions in the Overall document. The Overall document does not
specify the conformance requirements of any Service. 

<Nancy> I was not sure this was the agreement at the meeting. We can confirm
this with the group in the next teleconference. <Nancy> 

c.       Set element - should be able to set a specific element

i.      Set
uses sparsely populated tree (only contains element values to be set). IPP
specifies that "this must be an atomic" operation.

ii.      Get
element: The client can obtain a specific group of elements. (not IPP
semantic, a WS-scan semantic).

iii.      Bill
will resolve offline with Ira's comments.

.        It is unclear to me what I need resolve with Ira's comments. 
<Nancy> You asked to resolve the semantics of Set operations for Services
with Ira offline. <Nancy> 

I am
concerned however about the semantics of all of the operations ,
particularly the response. I would assume that the response to a GetElements
would include an identification of each simple element falling somewhere
under the "Top Element"  and its value. Would complex element names be

<Nancy> Yes, the response returns each entire group of elements requested
including simple elements at the leaf of the group structure. MediaCol is an
exception. The name of each MediaCol instances will be returned, but not the
simple elements. In order to ask for the simple elements, you need to write
an extension operation to retrieve each of them. 

Regards. Best Wishes for a Merry Christmas and Happy New Year to you all! 


Happy Holidays!

Bill Wagner

From: William Wagner [mailto:wamwagner at comcast.net]
Sent: Thursday, December 17, 2009 10:28 PM
To: 'mfd at pwg.org'
Subject: RE: [MFD] Dec. 8-9 Face-to-Face Meeting Minutes is now available

Nancy and MFD WG,

Many thanks for your extensive minutes. However, I wonder about a few  of
the Items.

1.     With respect to the comment relative to Figure 2 of the Overall MFD
spec, line 47 in the minutes:

o   There should be no data flow arrow from print to Repository - the second
digital-doc is for job save operation.

It was my understanding that that path was to be retained and was indeed
associated with job save.

Of course, the diagram (perhaps more for clarity)  shows  a two
repositories: one that a client inputs to and that provides documents to
Services; the other that Services input to and that make document accessible
to clients. One could argue that Services (other than Transform) that
receive digital documents and potentially store them for some later action,
but not for local client re-access in a digital form should show the data
flow arrow back to the "input" respository. In that case, I suggest that
Print, FaxOut and EmailOut should shown the document storage path back to
the "Input" repository.  Also, although I am a bit shaky on the EmailIn/Out
Services, I suspect that EmailOut should, like Print and FaxOut, have a
potential input from an input repository. Comments?

2.     Line 51 in the minutes: There is no document ticket, only job ticket
containing document processing instructions. I had noted not to indicate
that a job may contain a one or more Document Tickets. But if a Job cannot
contain any Document Tickets, I wonder where document tickets get associated
with the documents in a job?

3.     The resolution of StorageMakeAndModel reference is not noted. I
recall a reference to the HR MIB and the Printer MIB, but I can find this
object in neither.

4.     Also, as noted in the minutes, there are items that Pete and Ira have
yet to supply.


Bill Wagner

From: mfd-bounces at pwg.org [mailto:mfd-bounces at pwg.org] On Behalf Of
Nancy.Chen at okidata.com
Sent: Wednesday, December 16, 2009 10:30 AM
To: mfd at pwg.org
Subject: [MFD] Dec. 8-9 Face-to-Face Meeting Minutes is now available


The minutes is now available at the following links:


Thanks for all the participants!


Nancy Chen
Principal Engineer
Solutions and Technology
Oki Data
2000 Bishops Gate Blvd.
Mt. Laurel, NJ 08054
Phone: (856)222-7006
Email: Nancy.Chen at okidata.com
This message has been scanned for viruses and
dangerous content by  <http://www.mailscanner.info/> MailScanner, and is
believed to be clean.

This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

mfd mailing list
mfd at pwg.org

This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/mfd/attachments/20091222/a6926db6/attachment-0001.html>

More information about the mfd mailing list