attachment-0001
<br><font size=2 face="sans-serif">Hi Bill,</font>
<br>
<br><font size=2 face="sans-serif">I finally got a chance to catch up with
my MFD WG emails. Sorry for the delay in responding to your questions.</font>
<br>
<br><font size=2 face="sans-serif">Please see my reply inline in your email
below.</font>
<br>
<br><font size=2 face="sans-serif">Regards and Happy Holidays!</font>
<br>
<br><font size=2 face="sans-serif">-Nancy</font>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>"William Wagner"
<wamwagner@comcast.net></b> </font>
<br><font size=1 face="sans-serif">Sent by: mfd-bounces@pwg.org</font>
<p><font size=1 face="sans-serif">12/18/2009 01:52 PM</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif"><mfd@pwg.org></font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">RE: [MFD] Dec. 8-9 Face-to-Face Meeting
Minutes is now available</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2><tt>MFD WG,<br>
</tt></font>
<br>
<br>
<br><font size=2><tt>Sorry about these questions so close to the holidays,
but I would like to<br>
solidify the meeting comments before they are lost to our celebrations.<br>
</tt></font>
<br>
<br>
<br><font size=2><tt>1. With respect to item 1 below, I suggest
that a path from Print,<br>
FaxOut, EmailOut to an external repository is valid only if it is a normal<br>
part of the service that a client can extract the document from that<br>
repository. Using an external repository for JobSave, if that digital<br>
document is not normally accessible to the outside world, is an internal<br>
implementation aspect and should not be considered in the model any more<br>
than a Copy Service Digital Document should be. That being agreed, my<br>
question is then whether it is a customary or desired feature of any Print,<br>
FaxOut, or EmailOut Service to allow alternate access to a Digital Document.</tt></font>
<br><font size=2><tt><br>
<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. </tt></font>
<br><font size=2><tt><Nancy></tt></font>
<br>
<br><font size=2><tt>2. I am confused by several comments
in the minutes relative to<br>
operations, and admit that I was working with the document at the time
they<br>
were discussed so did not digest the discussion at the time. The comments<br>
start on line 84 of the minutes and deal with Table 49 and the following<br>
text.<br>
</tt></font>
<br><font size=2><tt>a. Add "comma" between
all parameters.<br>
</tt></font>
<br><font size=2><tt>(no problem)<br>
</tt></font>
<br><font size=2><tt>b. Get<service>XXXElements:
Pete proposed the semantics of these<br>
operations to be taking the requested element name (the keyword of the<br>
top-level elements) as input, and returns one selected top level element<br>
group elements (e.g. capabilities, default ticket, . etc., of a service)
.<br>
One exception is that the MediaCol element is quite large and thus the<br>
elements of this group are not returned for Capabilities group. A single<br>
element can only be returned by adding an extension operation. Pete will<br>
align the current Print Service with this semantics.<br>
</tt></font>
<br><font size=2><tt>Does this mean:<br>
</tt></font>
<br><font size=2><tt>. The parameters
supplied with the Get<service>DocumentElements,<br>
Get<service>JobElements and Get<service>ServiceElements
operations must<br>
include "Top-Level" elements?</tt></font>
<br>
<br><font size=2><tt><Nancy> The input parameter "RequestedElement"
can contain any number of the names of the top-level group elements of
the service.</tt></font>
<br><font size=2><tt><Nancy><br>
</tt></font>
<br><font size=2><tt>. What are the "Top-Level"
elements? The original writeup<br>
identified DocumentReceipt, DocumentStatus or, DocumentTicket; JobReceipt,<br>
JobStatus, or JobTicket; and ServiceCapabilities, ServiceConfiguration,<br>
ServiceDescription, ServiceStatus or DefaultJobTicket.</tt></font>
<br><font size=2><tt><Nancy> These are correct.<Nancy><br>
</tt></font>
<br><font size=2><tt>. Can only one "Top-Level"
element be included in one request? This<br>
is implied in the original writeup but not clearly stated.</tt></font>
<br>
<br><font size=2><tt><Nancy> You can request any number of the top-level
element groups.<Nancy><br>
</tt></font>
<br><font size=2><tt>. The "exception"
for MediaCol is disturbing. Are we to simply say<br>
that all complex elements and constituting elements except MediaCol and
its<br>
constituent elements are reported?</tt></font>
<br><font size=2><tt><br>
<Nancy> Yes. <Nancy></tt></font>
<br>
<br>
<br><font size=2><tt>i. All<br>
Services must align with this semantics. This is the same used in WS-Print.<br>
</tt></font>
<br><font size=2><tt>ii. Bill<br>
will add these statements in the Conformance section.<br>
</tt></font>
<br><font size=2><tt>. The paragraph defining
the operation will reflect the semantics,<br>
once we clarify what the semantics is. I do not understand "ii".
The<br>
Conformance section, as revised, requires that the Service Specifications<br>
use the definitions in the Overall document. The Overall document does
not<br>
specify the conformance requirements of any Service.</tt></font>
<br><font size=2><tt><br>
<Nancy> I was not sure this was the agreement at the meeting. We
can confirm this with the group in the next teleconference. <Nancy></tt></font>
<br>
<br><font size=2><tt>c. Set element - should be able
to set a specific element<br>
</tt></font>
<br><font size=2><tt>i. Set<br>
uses sparsely populated tree (only contains element values to be set).
IPP<br>
specifies that "this must be an atomic" operation.<br>
</tt></font>
<br><font size=2><tt>ii. Get<br>
element: The client can obtain a specific group of elements. (not IPP<br>
semantic, a WS-scan semantic).<br>
</tt></font>
<br><font size=2><tt>iii. Bill<br>
will resolve offline with Ira's comments.<br>
</tt></font>
<br><font size=2><tt>. It is unclear to me what
I need resolve with Ira's comments. </tt></font>
<br><font size=2><tt><Nancy> You asked to resolve the semantics of
Set operations for Services with Ira offline. <Nancy></tt></font>
<br>
<br><font size=2><tt>I am<br>
concerned however about the semantics of all of the operations ,<br>
particularly the response. I would assume that the response to a GetElements<br>
would include an identification of each simple element falling somewhere<br>
under the "Top Element" and its value. Would complex element
names be<br>
returned?</tt></font>
<br><font size=2><tt><br>
<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.</tt></font>
<br><font size=2><tt><Nancy></tt></font>
<br>
<br><font size=2><tt>Regards. Best Wishes for a Merry Christmas and Happy
New Year to you all!</tt></font>
<br><font size=2><tt>-Nancy</tt></font>
<br>
<br><font size=2><tt>Thanks!<br>
</tt></font>
<br>
<br>
<br><font size=2><tt>Happy Holidays!<br>
</tt></font>
<br>
<br>
<br><font size=2><tt>Bill Wagner<br>
</tt></font>
<br>
<br>
<br>
<br>
<br><font size=2><tt>From: William Wagner [mailto:wamwagner@comcast.net]<br>
Sent: Thursday, December 17, 2009 10:28 PM<br>
To: 'mfd@pwg.org'<br>
Subject: RE: [MFD] Dec. 8-9 Face-to-Face Meeting Minutes is now available<br>
</tt></font>
<br>
<br>
<br><font size=2><tt>Nancy and MFD WG,<br>
</tt></font>
<br>
<br>
<br><font size=2><tt>Many thanks for your extensive minutes. However, I
wonder about a few of<br>
the Items.<br>
</tt></font>
<br><font size=2><tt>1. With respect to the comment relative
to Figure 2 of the Overall MFD<br>
spec, line 47 in the minutes:<br>
</tt></font>
<br><font size=2><tt>o There should be no data flow arrow from print
to Repository - the second<br>
digital-doc is for job save operation.<br>
</tt></font>
<br><font size=2><tt>It was my understanding that that path was to be retained
and was indeed<br>
associated with job save.<br>
</tt></font>
<br><font size=2><tt>Of course, the diagram (perhaps more for clarity)
shows a two<br>
repositories: one that a client inputs to and that provides documents to<br>
Services; the other that Services input to and that make document accessible<br>
to clients. One could argue that Services (other than Transform) that<br>
receive digital documents and potentially store them for some later action,<br>
but not for local client re-access in a digital form should show the data<br>
flow arrow back to the "input" respository. In that case, I suggest
that<br>
Print, FaxOut and EmailOut should shown the document storage path back
to<br>
the "Input" repository. Also, although I am a bit shaky
on the EmailIn/Out<br>
Services, I suspect that EmailOut should, like Print and FaxOut, have a<br>
potential input from an input repository. Comments?<br>
</tt></font>
<br><font size=2><tt>2. Line 51 in the minutes: There is
no document ticket, only job ticket<br>
containing document processing instructions. I had noted not to indicate<br>
that a job may contain a one or more Document Tickets. But if a Job cannot<br>
contain any Document Tickets, I wonder where document tickets get associated<br>
with the documents in a job?<br>
</tt></font>
<br><font size=2><tt>3. The resolution of StorageMakeAndModel
reference is not noted. I<br>
recall a reference to the HR MIB and the Printer MIB, but I can find this<br>
object in neither.<br>
</tt></font>
<br><font size=2><tt>4. Also, as noted in the minutes, there
are items that Pete and Ira have<br>
yet to supply.<br>
</tt></font>
<br><font size=2><tt>Thanks,<br>
</tt></font>
<br><font size=2><tt>Bill Wagner<br>
</tt></font>
<br>
<br>
<br>
<br>
<br>
<br>
<br><font size=2><tt>From: mfd-bounces@pwg.org [mailto:mfd-bounces@pwg.org]
On Behalf Of<br>
Nancy.Chen@okidata.com<br>
Sent: Wednesday, December 16, 2009 10:30 AM<br>
To: mfd@pwg.org<br>
Subject: [MFD] Dec. 8-9 Face-to-Face Meeting Minutes is now available<br>
</tt></font>
<br>
<br>
<br>
<br><font size=2><tt>All,<br>
</tt></font>
<br><font size=2><tt>The minutes is now available at the following links:<br>
</tt></font>
<br><font size=2><tt>ftp://ftp.pwg.org/pub/pwg/mfd/minutes/pwg-ftf-mfd-minutes-20091208-09.pdf<br>
and<br>
ftp://ftp.pwg.org/pub/pwg/mfd/minutes/pwg-ftf-mfd-minutes-20091208-09.doc<br>
</tt></font>
<br><font size=2><tt>Thanks for all the participants!<br>
</tt></font>
<br><font size=2><tt>-Nancy<br>
</tt></font>
<br><font size=2><tt>----------------------------------------------------------------------------<br>
----<br>
Nancy Chen<br>
Principal Engineer<br>
Solutions and Technology<br>
Oki Data<br>
2000 Bishops Gate Blvd.<br>
Mt. Laurel, NJ 08054<br>
Phone: (856)222-7006<br>
Email: Nancy.Chen@okidata.com<br>
--<br>
This message has been scanned for viruses and<br>
dangerous content by <http://www.mailscanner.info/> MailScanner,
and is<br>
believed to be clean.<br>
</tt></font>
<br>
<br><font size=2><tt>--<br>
This message has been scanned for viruses and<br>
dangerous content by MailScanner, and is<br>
believed to be clean.<br>
</tt></font>
<br>
<br>
<br><font size=2><tt>_______________________________________________<br>
mfd mailing list<br>
mfd@pwg.org<br>
https://www.pwg.org/mailman/listinfo/mfd</tt></font>
<br>
<br><br />--
<br />This message has been scanned for viruses and
<br />dangerous content by
<a href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is
<br />believed to be clean.