[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

Nancy.Chen at okidata.com Nancy.Chen at okidata.com
Tue Dec 22 17:53:55 UTC 2009

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 
FaxOut, or EmailOut Service to allow alternate access to a Digital 

<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 
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? 
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 
constituent elements are reported?

<Nancy> Yes. <Nancy>

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

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 
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 
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 
to clients. One could argue that Services (other than Transform) that
receive digital documents and potentially store them for some later 
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 
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 
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 
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 
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/b204929e/attachment-0001.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/mfd/attachments/20091222/b204929e/attachment.htm>

More information about the mfd mailing list