From: Ira McDonald (blueroofmusic@gmail.com)
Date: Thu Jan 29 2009 - 13:01:52 EST
Hi,
ALL - please don't send attachments to PWG reflectors - most are discarded
by the reflector - this one probably was deleted by many corporate email
gateways (typical policy of no attachments from mailing list servers).
I've posted Nancy's attachment to the PWG FTP server directory:
ftp://ftp.pwg.org/pub/pwg/mfd/white/
in the file:
nancy-Proposed-Resolution-for-Bill-W-comments-for-Resource-Service-20090127.pdf
I'll try to attend the MFD WG teleconference later today, to comment on
states/state transistions.
Briefly, IMHO there is NO such thing as a local Imaging Service (Job Service)
communicating with a local Resource Service EXCEPT as a regular client.
We shouldn't even imply that this could happen (because it breaks security
policy integrity).
Also, Jobs are ALWAYS actually created by receiving Services in all print
protocols. User clients ALWAYS simply REQUEST that a Job be created
with a given set of parameters. This is not a difference from other protocols.
The legacy informal phrase "submitting a Job" is indeed WRONG.
Lastly, the Resource Service does NOT simply exist to help processing of
Jobs by regular Imaging Services. It is a free-standing, useful "special" kind
of Service in its own right. We should NOT even mention Imaging Jobs
in the Resource Service spec (except perhaps in examples, but even there
I don't like it). If an Imaging Service wants to store and retrieve
Fonts, etc.,
in a local or remote Resource Service, that's fine, but it's an implementation
choice and should NOT be a requirement of the MFD Architecture Model.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music/High North Inc
email: blueroofmusic@gmail.com
winter:
579 Park Place Saline, MI 48176
734-944-0094
summer:
PO Box 221 Grand Marais, MI 49839
906-494-2434
On Wed, Jan 28, 2009 at 5:22 PM, <nchen@okidata.com> wrote:
>
> All,
>
> So far I have only received Bill Wagner's comments on the Resource Service
> Spec :ftp://ftp.pwg.org/pub/pwg/mfd/wd/wd-mfdresourcemodel10-20090115.pdf.
>
> Bill's comments are all very good. Here is my proposed resolutions to the
> comments:
>
>
> Please review and let's decide our consensus in tomorrow's teleconference.
> Some of the comments are about service states and state transitions. Ira is
> the expert in this area, hope he will attend tomorrow's teleconference and
> give us his expert recommendation.
>
> Thanks for your participation.
>
> -Nancy
>
>
>
> "William A Wagner" <wamwagner@comcast.net>
>
> 01/27/2009 03:42 PM
>
> To
> <nchen@okidata.com>, <mfd@pwg.org>, <owner-mfd@pwg.org>
> cc
> Subject
> RE: MFD> MFD Teleconference, Thursday 1/29 3:00 EDT
>
>
>
>
> All,
>
> Some comments and questions.
>
>
>
> 1. It is common usage that a Job is submitted to the Service. This is
> in Abstract to the Resource Service and at various places in the text. I
> have used the expression extensively in working on the General document. But
> in the model that is being defined, the user/client submits a CreateJob
> request, and perhaps he submits a document, but the Service creates the job.
> At least that is my understanding. Since this aspect of the model is
> different from common usage, I suggest we avoid the terminology of
> "submitting a job" in that it would reinforce a concept contrary to the
> Model.
>
> 2. I have trouble with saying that the Resource Service is accepting
> Jobs (para 6.5.10.2.1 et al). From my understanding of the overall model, it
> does not accept, create or deal with jobs. It accepts and provides
> information about accepted resources to a user/client. It provides resources
> to other Services. Should this be "is accepting and supplying resources"
>
> 3. If we agree in general that paths to and from Testing are
> implementation dependent, I suggest that the "test" operation be removed and
> perhaps that the Testing state be removed from 6.5.10.2.1 and 6.5.10.2.2
>
> 4. The sole purpose is to provide resources to other services. Yet
> are we considering the Resource Service to be completely independent and
> separate from the Job Processing services?
>
> a. Are the basic service operations described in Section 7.1 the
> inter-service operations as well setup and configuration operations with a
> Client/User?
>
> b. Is there but one access path, so that in the Idle State, it is
> handling neither client or Service requests? And in the Processing state, it
> is handling requests from a either client or another Service?
>
> c. When it is Down and offline with respect to clients, is it also
> offline with respect to responding to other services, perhaps in the same
> device?
>
> 5. SetResourceElements (7.1.11) and all of the Administrative
> Resource Service Operations (7.2) are not indicated as Required or
> Optional.
>
> 6. In the compliance section (8), requirements are placed on clients
> and Resource Service. If the operations listed also apply to the supported
> Services, are these Services also Resource Service clients? If so, I suggest
> that it is not reasonable to require them to support all of the "required"
> operations.
>
> Thanks,
>
>
>
> Bill Wagner
>
>
>
>
>
> From: owner-mfd@pwg.org [mailto:owner-mfd@pwg.org] On Behalf Of
> nchen@okidata.com
> Sent: Thursday, January 22, 2009 12:50 PM
> To: mfd@pwg.org; owner-mfd@pwg.org
> Subject: Re: MFD> MFD Teleconference, Thursday 1/29 3:00 EDT
>
>
>
>
> All,
>
> This is a reminder.
>
> As Pete announced, we will review the last updated Resource Service draft in
> the teleconference next Thursday to conclude our WG Last Call and move to
> PWG Last Call version after the update from the teleconference next
> Thursday.
>
> I urge you all review the draft at:
> <ftp://ftp.pwg.org/pub/pwg/mfd/wd/wd-mfdresourcemodel10-20090115.pdf
> and send your comments to mfd@pwg.org and cc me (nchen@okidata.com) or
> pete(Peter.Zehler@xerox.com).
>
> We will resolve all your comments in next Thursday's teleconference and
> prepare the Resouce Service spec for the PWG Last Call to start afterwards.
>
> Thanks for your participation.
>
> -Nancy
>
>
>
>
>
> "Zehler, Peter" <Peter.Zehler@xerox.com>
> Sent by: owner-mfd@pwg.org
>
> 01/22/2009 12:06 PM
>
>
> To
>
> <mfd@pwg.org>
>
>
> cc
>
>
>
> Subject
>
> MFD> MFD Teleconference, Thursday 1/29 3:00 EDT
>
>
>
>
>
>
>
>
> There will be an MFD conference call at 3:00 PM EDT (12:00 PM PDT) this
> Thursday. The meeting is held in accord with the PWG Intellectual
> Property Policy.
>
>
>
> Note the NEW Teleconference number and access code are now used.
>
> Please contact me if you do not have the new number and pass code.
>
>
>
> Agenda:
>
> 1. Identify Minute Taker
>
> 2. Approval of minutes from last teleconference
>
>
> <ftp://ftp.pwg.org/pub/pwg/mfd/minutes/pwg-mfd-minutes-20090115.pdf>
>
> 3. Agenda bashing
>
> 4. Discussion on Scan Service State and proposed change to section 10 of
> the specification
>
> a) Chose between the existing text, proposed text or arrive at
> some other consensus.
>
> Existing text is section 10
> <ftp://ftp.pwg.org/pub/pwg/mfd/wd/lcrc-mfdscanmodel10-20090122.pdf>
>
> Proposed change is available at
> <ftp://ftp.pwg.org/pub/pwg/mfd/white/ScanServiceTheoryOfOp.pdf>
>
> b) Discussion of Testing State, transition in and out, and method
> of transition
>
> 5. Discuss syntax of JobPhoneNumber on line 2182 of Scan specification
>
> 6. Discuss open ended REQUIREMENT governed by a third party (End User)
> policy on line 2788-2790 of Scan specification
>
> 7. Discuss any comments on the Resource Service interim draft.
> Objective is to move to the Last Call version for review at the Face to
> Face.
>
>
> <ftp://ftp.pwg.org/pub/pwg/mfd/wd/wd-mfdresourcemodel10-20090115.pdf>
>
> 8. Next steps
>
>
>
>
> Click Here to Join Live Meeting
> <https://www.livemeeting.com/cc/xerox/join?id=PWG_MFD&role=attend&pw=PQ%
> 25%3EFj5sN>
>
>
>
>
>
>
>
> Peter Zehler
>
> Xerox Research Center Webster
> Email: Peter.Zehler@Xerox.com
> Voice: (585) 265-8755
> FAX: (585) 265-7441
> US Mail: Peter Zehler
> Xerox Corp.
> 800 Phillips Rd.
> M/S 128-25E
> Webster NY, 14580-9701
>
>
>
>
>
>
>
>
>
>
This archive was generated by hypermail 2.1.4 : Thu Jan 29 2009 - 13:02:08 EST