Hi Bill,
Shutdown is a special and thorny case - the DPA System
Admin (ISO 10175-Part3) state table shows that Shutdown
transitions the printer to 'shutdown' state (a first class state,
NOT just a condition or state reason). And says in the
description of the Shutdown operation:
"This abstract operation allows an administrator to shutdown
a specified print server or physical printer.
The means for restarting a printer or server which has been
shutdown with this operation is provided by the Control
operation with the 'reset' attribute set to 'reset-power-cycle'.
<snip>
When a print server is shutdown, it is first disabled. This
shall prevent new jobs from being accepted. Currently
scheduled print jobs on a print server being shutdown
shall be saved; the print jobs shall be re-scheduled when
the print server is restarted.
The order in which jobs will be printed shall not be changed
by invocation of the Shutdown operation.
The ability to shutdown physical printers is an implementation
option."
So DPA says that print jobs MUST be saved on shutdown and
MUST be re-scheduled on restart. Notice that DPA Control
is legal (and MUST be accepted) in every DPA printer state.
On the other hand, IPP System Admin (RFC 3998) defines all
three ShutdownPrinter, StartupPrinter, and RestartPrinter.
And says in StartupPrinter (page 15):
"This OPTIONAL operation allows a client to start up an instance of a
Printer object, provided that there isn't one already initiated. The
purpose of Startup-Printer is to allow a hosted implementation of the
IPP Printer object (i.e., a Server that implements an IPP Printer on
behalf of a networked or local Output Device) to be started after the
host is available (by means outside this document). See section
3.5.1 for the way to initialize the software or reset the Output
Device(s) when the IPP Printer object has already been initiated.
The host MUST accept this operation only when the Printer object has
not been initiated. If the Printer object already exists, the host
must return the 'client-error-not-possible' status code."
Note that the "host" (and NOT the IPP Printer object) accepts the
StartupPrinter operation. IPP and DPA want you to RESTART an
existing printer. So separating Startup/Restart makes sense for
Scan and other services. An existing service can receive its own
Restart and Shutdown operations (both valid in any state, though
Shutdown when already Down is a no-op, but legal in DPA).
Thinking back, I believe Pete let Server be the abstract root
object for the SM schema files and imported my System from
WIMS as-is.
The intent in WIMS was that the System object controls and
summarizes the activities of Service and Device objects (and
enforces admin policies like loading and running firewall and
anti-virus software).
In Counter MIB, 'systemTotals' is a special ServiceType that
acts as a System object for summary counters.
So actually, I think we're mostly on the same page here (DPA,
IPP, Semantic Model, WIMS, Scan Service, etc.)
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
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, Feb 6, 2009 at 1:43 PM, William A Wagner <wamwagner at comcast.net> wrote:
> Ira,
>> Thanks for your response. I apparently misunderstand the meaning of
> "off-line".
>> I think one difficulty is that we each read this stuff in the context of
> what we recall of what came before, and that may be different. For example,
> I find no definition of a printer "down" state in IPP, although there is a
> "Shutdown" state/condition defined as a printer-state-reasons response.
> 'shutdown': Someone has removed a Printer object from service, and
> the device may be powered down or physically removed. In this
> state, a Printer object MUST NOT produce printed output, and
> unless the Printer object is realized by a print server that is
> still active, the Printer object MUST perform no other
> operations requested by a client, including returning this
> value.
> To me, that would suggest that an object that is "shutdown" (the same as
> down?) does not itself accept requests.
>> On the other hand, I can find no explicit definition in IPP of "off-line"
> (indeed, I recall intentional avoidance of "on-line" and "off-line" since
> they did mean different things to different people.) However, there is a
> Job-state-reasons response defined:
> 'service-off-line': The Printer is off-line and accepting no
> jobs. All 'pending' jobs are put into the 'pending-held'
> state. This situation could be true if the service's or
> document transform's input is impaired or broken.
>> That does not disagree with your contention that an off-line service could
> accept non-job requests. But does that mean the "down" state is not in the
> "Off-line" phase? Or am I taking the terms out of context?
>> But then, if a Service in Offline/Down can accept and process requests other
> than Job requests, how is this different from the Service being in any state
> with a "not accepting jobs" condition?
>> With respect to WIMS efforts, note that the Counter Spec Fig 2 specifically
> shows the MFD Services as being contained in a Server. On the other hand,
> the Schema includes a System.xsd, but no mention (that I can find) of a
> Server.
>> I guess there is no way to be consistent with a past that is itself
> inconsistent. The best we can do is to try to be internally consistent, but
> that may be difficult too.
>> Thanks,
>> Bill Wagner
>> -----Original Message-----
> From: Ira McDonald [mailto:blueroofmusic at gmail.com]
> Sent: Friday, February 06, 2009 12:40 PM
> To: William A Wagner; Ira McDonald
> Cc: mfd at pwg.org> Subject: Re: MFD> Scan Service Sectionr 10
>> Hi Bill,
>> This all sounds pretty good to me.
>> One point - in IPP, DPA, and SM/1.0, an Offline/Down
> Service *can* accept and process incoming Admin
> Requests (like Startup). But it cannot accept (and
> must reject) incoming Job Requests (like CreateScanJob).
>> This has been true in IPP Model from the beginning and is
> discussed in some detail in IPP System Admin (RFC 3998).
>> Ah - I see Pete has reverted to pure DPA terminology
> and represented Server object, rather than System object
> (WIMS and PSI terminology) - same meaning - I still think
> System is a clearer term, but oh well...
>> Cheers,
> - Ira
>> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> 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 Thu, Feb 5, 2009 at 10:24 PM, William A Wagner <wamwagner at comcast.net>
> wrote:
>> Ira, Pete and the MFD group,
>>>> I very much wanted to get out a first cut Overall MFD document prior to
> the
>> face-to-face. It has been a very useful exercise for me, and I think my
>> understanding of what was intended is improving, although there are still
>> some dark spots. Note that it was my intent to provide a general context
> for
>> the Service models and, in doing so, to clarify a few areas. It was not my
>> intent to modify or embellish the model as manifest by the Scan Spec and
> the
>> schema.
>>>> In continuing to work on the "overall" document (rigorous or not), and
>> assenting to Ira's idea of a MFD entity other than a service that starts a
>> service, is not this entity identified as the "Server", since the Scan
> Spec
>> says "the multifunction device is represented as the Server element in the
>> PWG Semantic Model Schema"?
>>>> Further, if I understand Ira's suggestion on the startup sequence, it
> goes:
>> a. A client sends a StartupService to a System (perhaps implicitly
>> by powering up the MFD)
>> b. The System internally creates a scan service in an offline
>> phase/unknown state
>> c. The Service, internally and on its own accord transitions to an
>> offline phase/down state (but is unable to respond to state requests since
>> it of off-line...Perhaps the System can respond to a state request? Does
> the
>> System respond to the StartupService now, perhaps saying that state is
>> down?)
>> c. The System internally sends a StartupScanService to the
> Service,
>> which causes the Service to move to Online/Idle) Is this the point that
> the
>> System responds to the StartupService request, or is it dependent on how
>> long it takes the service get to an on-line state?
>>>> I would be interested in the sense of the working group in what we are
>> attempting to show with the model. If my tendency to "black box"
>> characterization is correct, that is, we do not get into internal
>> implementation aspects beyond what is necessary to characterize behavior,
>> then the items of interest are just StartupService and the response to
>> StartupService. The rest is implementation dependent.
>>>> Regardless, it would seem that the StartupService [type=XService] is a
>> System (or Server) input request since the Service is non-existent at this
>> point. StartupXService would seem to be a System (or Server) output
> request
>> sent internally since the Service is in an off-line phase.
>>>> Clarification on what how the group would like to deal with these
> interfaces
>> would be helpful.
>>>> Thanks,
>>>> Bill Wagner
>>>>>>>> -----Original Message-----
>> From: Ira McDonald [mailto:blueroofmusic at gmail.com]
>> Sent: Tuesday, February 03, 2009 11:44 AM
>> To: William A Wagner; Ira McDonald
>> Cc: mfd at pwg.org>> Subject: Re: MFD> Scan Service Sectionr 10
>>>> Hi Bill,
>>>> There is a need for considerable rigor in some top MFD
>> Requirements/Model/Whatnot
>> document, because it needs to be able to be *normatively* referenced
>> for state diagrams,
>> basic state tables, operation lifecycle, etc. by future Fax Service,
>> Copy, Email, etc.
>>>> This Chapter 10 model stuff from Scan Service belongs in that document.
>>>> If what you wish to write is truly informal, then someone else needs
>> to write the above
>> PWG Best Practices document - or we keep repeating term definitions
> (awful)
>> and
>> the model in each service. There was a strong consensus against
>> repetition in the
>> December PWG meeting MFD sessions, I thought.
>>>> About Startup.
>>>> How about if we do briefly describe the System object in Scan Service
>> (as the top
>> management entity in an MFD). Then we say that a System object processes
> an
>> incoming StartupService (type=ScanService) request by creating and
> executing
>> an
>> instance of ScanService (in an implementation-dependent manner), which
>> begins
>> in Offline / Unknown and transitions to (during initialization) to
>> Offline / Down.
>>>> Then the System sends a StartupScanService operation to the ScanService to
>> actually self-test, advertise, and move to Online / Idle. The
>> StartupScanService
>> operation completes more or less immediately (within seconds) and
>> ScanService
>> completes testing and advertising subsequently. Otherwise,
>> StartupScanService
>> may be pending for minutes. Worse the original StartupService would be
>> pending
>> all that time. This is why IPP System Admin operations (and DPA) MUST
>> complete
>> after validating input parameters, local resources, and (possibly) a
>> few directory
>> lookups, and IPP printer-state-reasons record that the activity is
>> still in-progress.
>>>> Anyway, some more thoughts.
>>>> Cheers,
>> - Ira
>>>> Ira McDonald (Musician / Software Architect)
>> Chair - Linux Foundation Open Printing WG
>> 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 Mon, Feb 2, 2009 at 10:45 PM, William A Wagner <wamwagner at comcast.net>
>> wrote:
>>> Ira,
>>>>>> I am sorry, I am not following you at all.
>>>>>> I made no suggestion that the state tables be deleted. Indeed, insofar as
>>> the state of the Service affects the response to interfaces/operation
>>> requests, I agree that the states and the actions effecting transitions
> be
>>> clearly stated.
>>>>>> I made no objection to maintaining that StartupScanService goes to the
>>> System to initiate a Scan Service instantiation; I do maintain that, if
>> that
>>> is the path, it should be identified as such and System should be defined
>> in
>>> the document.
>>>>>> Since Down is in the Offline phase, I find it confusing that a Service
> in
>>> the Down state would accept SOAP requests.
>>>>>> There currently are no references to ISO 10175. To the extent that
>>> information in that document is applicable, I have no problem to
> referring
>>> to it. I do have a problem in assuming the reader has full familiarity
>> with
>>> contents of that document to the extent that terms do not need to be
>> defined
>>> in the Scan Service document, indeed not even by reference.
>>>>>> Including a DeleteService (directed to a system) is nice for a
>> symmetrical
>>> model, but it is not in the current ScanService document, nor would I
>> expect
>>> a DeleteService request to be an operation in a typical implementation.
> It
>>> is not clear that much would be gained by explicitly adding it to the
>>> ScanService document, although it might be useful for other services,
>>> particularly if you have a system where there may be multiple
>> instantiations
>>> of a given service. I would leave that for general discussion.
>>>>>> Finally, my comments on the Scan Service Theory of Operation were
> intended
>>> to address areas that I found confusing and areas that appeared
>> inconsistent
>>> with other parts of the document. I took such issues to be a result of
> not
>>> updating the chapter as the rest of the document matured. It was not my
>>> intent to change or embellish the model.
>>>>>> I see the "General MFD Service" document as a less rigorous overview,
>>> dealing with general concepts applicable to models of multiple Services
>> and
>>> with how the various Services fit within a Multifunction Device.
>> Certainly,
>>> some of these issues will come up when we discuss my first draft (which I
>>> had better get cracking on).
>>>>>> Thanks,
>>>>>> Bill Wagner
>>>>>>>>> -----Original Message-----
>>> From: Ira McDonald [mailto:blueroofmusic at gmail.com]
>>> Sent: Monday, February 02, 2009 5:32 PM
>>> To: William A Wagner; Ira McDonald
>>> Cc: mfd at pwg.org>>> Subject: Re: MFD> Scan Service Sectionr 10
>>>>>> Hi Bill,
>>>>>> I hope you're not suggesting we delete the state
>>> tables?
>>>>>> We could certainly *bend* the operations (e.g., to let
>>> StartupScanService be an operation received by a
>>> ScanService in Initial / Down state).
>>>>>> But in the real world of WSDL bindings, that won't work!
>>>>>> A service can only receive an incoming WSDL (SOAP)
>>> request when it's ALREADY instantiated, addressable,
>>> and at least Down.
>>>>>> I believe that our MFD Model should have a first-class
>>> System object that receives StartupService (with a param
>>> for what type of service) and DeleteService (to really
>>> remove a Down service instance).
>>>>>> I do NOT see the problem with references to ISO 10175
>>> Part 1 (Printing Ops) and Part 3 (Admin Ops). This is the
>>> underpinning of most all IPP attributes and operations and
>>> therefore of the PWG Semantic Model v1.0 itself.
>>>>>> Cheers,
>>> - Ira
>>>>>> Ira McDonald (Musician / Software Architect)
>>> Chair - Linux Foundation Open Printing WG
>>> 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 Mon, Feb 2, 2009 at 1:31 PM, William A Wagner <wamwagner at comcast.net>
>>> wrote:
>>>> Ira,
>>>>>>>> Sorry, I am not following you. What I was attempting, in what little way
>> I
>>>> can, is to have the Scan Service document at least consistent within
>>> itself.
>>>> If my attempt has been unsuccessful, I will most willingly drop the
>>>> suggested changes.
>>>>>>>> I agree that it is good to also have the document consistent with
> related
>>>> documents; but one cannot assume that readers are all familiar with the
>>>> various other documents that you reference, at least not to the extent
>>> that
>>>> terms and concepts in those documents are common knowledge and need not
>> be
>>>> defined (at least by reference.. but that can get cumbersome)
>>>>>>>> The term "System" as a formal object is not defined in the Scan Service
>>>> document. The word system is appears to be used in a general sense,
>>> although
>>>> perhaps this is just my interpretation. Indeed, I wonder if these uses
> of
>>>> the word, although they may be derived from other definitive
>>> specifications,
>>>> make sense.
>>>>>>>> 1831 Pending - the job has been accepted by the system and is
>>>> awaiting system resources before it can start processing
>>>>>>>> 2276 Aborted - The Document has been aborted by the system,
> ...
>>>>>>>> Neither does the Scan Service document use the term Startup Event
> (except
>>>> cryptically in the State table) although it does use Startup() in the
>>> State
>>>> Diagram and define StartupScanService as an (optional) operation. (How
> is
>>>> the service "created" if there is no Startup operation?)
>>>>>>>> I find your explanation that "Startup *event* (not operation) arrives at
>>> the
>>>> Service object in Initial phase / Unknown state..." confusing
> considering
>>>> your statement that it is the "StartupScanService operation... sent to a
>>>> System (NOT a ScanService) that creates a new instance of a ScanService
>> in
>>>> the Initial phase..." If StartupScanService creates a service, how can
>> the
>>>> Startup *event* arrive at the Service...unless of course the Startup
>> event
>>>> is a secondary result of the Startup operation, occurring after the
>>>> operation has already created the service. Or perhaps the Startup event
>> is
>>>> completely independent from the Startup operation?
>>>>>>>> But I really question whether all this is germane. I think it is
>> important
>>>> for the specification define the external interfaces and how the service
>>> (or
>>>> system) responds to them. I think it desirable that the specification
> not
>>> be
>>>> self inconsistent or unnecessarily confusing. I think that attempts to
>>>> define the internal implementation beyond what is necessary to
>>> characterize
>>>> black-box behaiour are unnecessary, will usually be ignored, and may
>> cause
>>>> the document to be ignored. This of course is just my opinion.
>>>>>>>> Thanks,
>>>>>>>> Bill Wagner
>>>>>>>>>>>>>>>> -----Original Message-----
>>>> From: Ira McDonald [mailto:blueroofmusic at gmail.com]
>>>> Sent: Monday, February 02, 2009 10:51 AM
>>>> To: William A Wagner; Ira McDonald
>>>> Cc: mfd at pwg.org>>>> Subject: Re: MFD> Scan Service Sectionr 10
>>>>>>>> Hi Bill,
>>>>>>>> The System object is defined in WIMS and also in SM/2.0 schema
>>>> and has been for years.
>>>>>>>> Miracle happens is bad design - so MFD services that are created
>>>> AFTER the device is installed MUST be based on operations that
>>>> are targeted to the System object (same semantics as a Server
>>>> object in ISO 10175-Part3).
>>>>>>>> My Note (1) says that Startup *event* (not operation) arrives at the
>>>> Service object in Initial phase / Unknown state, which exactly follows
>>>> the state transition tables and notes in ISO 10175-Part3.
>>>>>>>> The alternative is to break with DPA and show that a Service object
>>>> comes into existence in the Initial phase / Down state (and receives
>>>> the Startup event). But that transition from Unknown to Down is the
>>>> one (in DPA) that does the one-time initialization of data structures.
>>>>>>>> Cheers,
>>>> - Ira
>>>>>>>> Ira McDonald (Musician / Software Architect)
>>>> Chair - Linux Foundation Open Printing WG
>>>> 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 Mon, Feb 2, 2009 at 12:39 AM, William A Wagner
> <wamwagner at comcast.net>
>>>> wrote:
>>>>> Ira,
>>>>>>>>>> 1. Yes, you had made the point before that StartupScanService was sent
>> to
>>>> a
>>>>> (undefined?) system, not to the service that is being started. However,
>>>> the
>>>>> detailed state diagram (Fig 27) indicates that "Startup" takes the
>>> service
>>>>> from Down to Idle. There is no indication of what takes service from
>>>> Unknown
>>>>> to Down. From a practical state, I questioned the Unknown to Down state
>>>>> transition prior to going to Idle. To address StartupScanService,
>>> perhaps
>>>>> line 5 should read: "On creation by a StartupScanService request, the
>>> Scan
>>>>> Service enters its Initial phase..."? Would acceptable wording on Line
>> 7
>>>>> be: "After successful initialization, the Scan enters the Online
>>>> state..."
>>>>>>>>>> Pete's 22 Jan version includes RestartScanService so I expect that that
>>>>> should be mentioned.
>>>>>>>>>> 2. I understand your distinction, but the detailed state diagram shows
>>>> that
>>>>> pause() and C.Critial effect the transition to Stopped. How about if we
>>>> keep
>>>>> it simple here in the text and just say "...either a Critical event
>> is
>>>>> generated" and avoid getting into the specific notation of the detailed
>>>>> state discussion?
>>>>>>>>>> Thanks,
>>>>>>>>>> Bill Wagner
>>>>>>>>>> -----Original Message-----
>>>>> From: owner-mfd at pwg.org [mailto:owner-mfd at pwg.org] On Behalf Of Ira
>>>> McDonald
>>>>> Sent: Sunday, February 01, 2009 10:28 PM
>>>>> To: William A Wagner; Ira McDonald
>>>>> Cc: mfd at pwg.org>>>>> Subject: Re: MFD> Scan Service Sectionr 10
>>>>>>>>>> Hi Bill and Pete.
>>>>>>>>>> Bill - I like all of your new text.
>>>>>>>>>> However, there are two serious problems in existing text:
>>>>>>>>>> (1) Second paragraph at line line 5 of page 2 is just wrong
>>>>>>>>>> It is a StartupScanService operation (spelled that way) sent
>>>>> to a System (NOT a ScanService) that creates a new instance
>>>>> of a ScanService in the Initial phase, causes self-test, and finally
>>>>> transition to Online phase / Idle state. The ScanService itself
>>>>> does NOT perform a start-up operation (line 7). It is handling
>>>>> the single E.startup *event* sent to it by the System (while in
>>>>> in the Initial phase / Unknown state).
>>>>>>>>>> If we keep it, a RestartScanService operation could be sent
>>>>> to a ScanService (to recover from a Shutdown to Offline
>>>>> phase / Down state). See the notes on lines 1628 to 1639
>>>>> on pages 66 and 67 of lcrc-mfdscanmodel10-20090119.pdf
>>>>>>>>>>>>>>> (2) Recurring problem of reading the terms in state tables
>>>>>>>>>> The notation key in the Scan Service spec for the state table
>>>>> is at line 1618 page 66 in lcrc-mfdscanmodel10-20090119.pdf
>>>>>>>>>> For example at line 12 in page 2 of your draft, we see:
>>>>>>>>>> "...either a C.Critical event is generated"
>>>>>>>>>> The expression "C.Critical" means a *passive* Condition (C)
>>>>> (i.e., a ScanService.StateReasons value) is TRUE that a Critical
>>>>> alert is now pending. While, the expression "~C.Critical" means
>>>>> that any NOT (~) Critical Condition is now pending.
>>>>>>>>>> The expression "E.Critical" means that an *active* Event (E)
>>>>> that is Critical has just occurred. Conversely "~E.Critical" means
>>>>> that any non-Critical (i.e., warning) event has just occurred.
>>>>>>>>>> So "C.Critical event" is confused.
>>>>>>>>>> Cheers,
>>>>> - Ira
>>>>>>>>>> Ira McDonald (Musician / Software Architect)
>>>>> Chair - Linux Foundation Open Printing WG
>>>>> 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, Jan 30, 2009 at 4:26 PM, William A Wagner
>> <wamwagner at comcast.net>
>>>>> wrote:
>>>>>> Considering the decisions at yesterday's conference call with respect
>> to
>>>>>> "submitting a job", I modified the proposed rework of Section 10 of
> the
>>>>> Scan
>>>>>> Service document. This rework (only in markup) is posted as
>>>>>>ftp://ftp.pwg.org/pub/pwg/mfd/white/ScanServiceTheoryOfOp-revB.pdf.>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>> Bill Wagner
>>>>>>>>>>>>>>>>>>>>>>>> From: owner-mfd at pwg.org [mailto:owner-mfd at pwg.org] On Behalf Of
> Zehler,
>>>>>> Peter
>>>>>> Sent: Thursday, January 29, 2009 1:38 PM
>>>>>> To: mfd at pwg.org>>>>>> Subject: MFD> Update to Agenda for 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. Discuss syntax of JobPhoneNumber on line 2182 of Scan specification
>>>>>>>>>>>> 5. Discuss open ended REQUIREMENT governed by a third party (End User)
>>>>>> policy on line 2788-2790 of Scan specification
>>>>>>>>>>>> 6. Discuss Bill's comments on in Resource Service
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <ftp://ftp.pwg.org/pub/pwg/mfd/white/nancy-Proposed-Resolution-for-Bill-W-co>>>>> mments-for-Resource-Service-20090127.pdf>
>>>>>>>>>>>> b) Discussion of Testing State, transition in and out, and
> method
>>>> of
>>>>>> transition Part of both Resource and Scan Service discussion)
>>>>>>>>>>>> 7. 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>
>>>>>>>>>>>> 8. 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>
>>>>>>>>>>>> 9. Next steps
>>>>>>>>>>>>>>>>>>>>>>>> Click Here to Join Live Meeting
>>>>>>>>>>>>>>>>>>>>> <https://www.livemeeting.com/cc/xerox/join?id=PWG_MFD&role=attend&pw=PQ%25%3>>>>> EFj5sN>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Peter Zehler
>>>>>>>>>>>> Xerox Research Center Webster
>>>>>> Email: Peter.Zehler at 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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>