[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

Ira McDonald blueroofmusic at gmail.com
Wed Dec 23 02:07:26 UTC 2009


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.




More information about the mfd mailing list