Hi Ira,
Thanks for your clarifications. However, for item 1 you did not address the
basic question about the elimination of the Print Service to Repository
path. Note also my later message where I suggest that DigitalDocument paths
to a repository when there is no intended client access to that
DigitalDocument are features of an implementation and not a Service, as with
the Copy Service.
At any rate, have a good holiday.
Thanks,
Bill Wagner
-----Original Message-----
From: Ira McDonald [mailto:blueroofmusic at gmail.com]
Sent: Friday, December 18, 2009 1:11 PM
To: William Wagner; Ira McDonald
Cc: mfd at pwg.org
Subject: Re: [MFD] Dec. 8-9 Face-to-Face Meeting Minutes is now available
Hi Bill,
Comments inline below.
Cheers,
- Ira
On Thu, Dec 17, 2009 at 10:27 PM, William Wagner <wamwagner at comcast.net>
wrote:
> 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?
>
<ira>
My two cents - a Repository is generic and only because of the diagram
is "input" or "output" - there is no abstract difference.
</ira>
> 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?
>
<ira>
A Job can contain ONLY JobTicket and Document objects.
A Document can contain an OPTIONAL DocumentTicket (to override
the JobTicket).
A Job object does NOT *directly* contain a DocumentTicket object.
</ira>
> 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.
<ira>
In the IETF HR MIB, manufacturer and model are ONLY formally specified
using the ProductID datatype (i.e., hrDeviceID for the storage element).
They can be *informally* specified in hrDeviceDescr and hrStorageDescr,
but those are not machine-readable (i.e., cannot be parsed).
</ira>
>> 4. Also, as noted in the minutes, there are items that Pete and Ira
have
> yet to supply.
<ira>
Nancy and I are now packing furiously for our move to Ann Arbor
early next week. Nancy's brother and family will arrive in A2 late
next week for a week's visit. I will have *very* limited time for
Power Model/MIB or MFD/SM stuff for the rest of December.
</ira>
>> Thanks,
>> 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
>>>> All,
>> The minutes is now available at the following links:
>>ftp://ftp.pwg.org/pub/pwg/mfd/minutes/pwg-ftf-mfd-minutes-20091208-09.pdf> and
>ftp://ftp.pwg.org/pub/pwg/mfd/minutes/pwg-ftf-mfd-minutes-20091208-09.doc>> Thanks for all the participants!
>> -Nancy
>>----------------------------------------------------------------------------
----
> 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 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>https://www.pwg.org/mailman/listinfo/mfd>>
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.