Hi Ira,
Yes, access to the DigitalDocument would be the criterion. But as you
suggested, the repository does not have an Imaging Service in or out sense
to it: I need to figure out how to show that in the diagram.
Is there an analogous case for FaxOut and EmailOut?
Have a good holiday.
Bill Wagner
-----Original Message-----
From: Ira McDonald [mailto:blueroofmusic at gmail.com]
Sent: Tuesday, December 22, 2009 9:07 PM
To: William Wagner
Cc: mfd at pwg.org
Subject: Re: [MFD] Dec. 8-9 Face-to-Face Meeting Minutes is now available
Hi Bill,
[Just got out of our cars in Ann Arbor for the winter]
When doing job save (but not for proof print), the actual
Digital Document *path* in the Repository is exposed
(that's the difference between the two features).
A saved job can be queried for the path to the DD
in the Repository.
So Print Service SHOULD have an arrow to the
Repository (input and output).
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
email: blueroofmusic at gmail.com
winter:
579 Park Place Saline, MI 48176
734-944-0094
summer:
PO Box 221 Grand Marais, MI 49839
906-494-2434
On Fri, Dec 18, 2009 at 2:02 PM, William Wagner <wamwagner at comcast.net>
wrote:
> 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.