From: Ira McDonald (blueroofmusic@gmail.com)
Date: Wed Jan 21 2009 - 17:28:27 EST
Hi Bill,
OK - here's my two cents.
StartupService (an operation targeted to a System and NOT to a Service)
starts a new Service instance that transitions (per DPA) from "unknown"
(Initial phase) to "idle" (Online phase).
ShutdownService (an operation targeted to the Service) deactivates the
service (per IPP Admin Ops and DPA) and results in "down" state (Offline
phase).
RestartService (an operation targeted to the Service) is accepted in ANY
state (per IPP Admin Ops) and can restart a Service from "down" (Offline
phase) to "idle" (Online phase).
TestService is accepted in EITHER the Online or Offline phase and takes
the Service to "testing" (and runs the named test in an input parameter).
This could be especially useful to take a Service to Offline and have the
Service *test* each associated Subunit (if they all work, then the Service,
which is otherwise pure software, should operate normally). Another
TestService operation simply starts another test (without exiting "testing").
A subsequent RestartService would exit from "testing" (Offline) to "idle"
(Online). Or a subsequent ShutdownService would exit from "testing"
(Offline) to "down" (Offline).
Perhaps you believe that TestDevice (or Subunit) is a more interesting
operation and we should leave "testing" out as a valid state for a Service?
I don't like this, but could maybe be convinced.
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 21, 2009 at 3:46 PM, William A Wagner <wamwagner@comcast.net> wrote:
> Ira et al,
>
> You make the point well that there are various not necessarily consistent
> models in existence. It behooves the MFD group to decide what states should
> be in the MFD model and to ensure that these states and state transitions
> are well defined and consistent. Right now, I do not think that we have done
> that for Scan Service. And I am having trouble coming up with a overall MFD
> generalization based on the Scan Service Model.
>
> Thanks,
>
> Bill Wagner
>
>
>
> -----Original Message-----
> From: owner-mfd@pwg.org [mailto:owner-mfd@pwg.org] On Behalf Of Ira McDonald
> Sent: Wednesday, January 21, 2009 3:16 PM
> To: William A Wagner; Ira McDonald
> Cc: mfd@pwg.org
> Subject: Re: MFD> Comments and questions on 20090112 Scan Model Doc
>
> Hi Bill,
>
> IPP Admin Ops (RFC 3998) clearly defines the behavior of
> ShutdownPrinter and StartupPrinter on page 14:
>
> "3.5.2. Shutdown-Printer Operation
>
> This OPTIONAL operation allows a client to shutdown a Printer; i.e.,
> to stop processing jobs without losing any jobs and to make the
> Printer object unavailable for any operations using the IPP protocol.
> There is no way to bring the instance of the Printer object back to
> being used, except for the Startup-Printer (see section 3.5.3), which
> starts up a new instance of the Printer object for hosted
> implementations."
>
> DPA Admin Ops (ISO 10175-Part3) defines ShutdownPrinter to
> place the Printer object in the "shutdown" state (NOT "idle" or
> "stopped") but to NOT delete the Printer object. It also defines
> DeletePrinter for deleting the object and discusses but does
> NOT define RestartPrinter - Palladium did RestartPrinter as a
> DPA Control operation (the DPA wildcard admin op) I believe.
>
> If, like DPA, you postulate that operations like StartupPrinter
> (in RFC 3998) and CreatePrinter (in DPA) are actually targeted
> at a System (IPP, WIMS, SM/2.0) or Server (DPA) object, then
> it's perfectly reasonable to let RestartPrinter restart an inactive
> Printer from the "shutdown" state.
>
> Note that DPA does NOT define "printer-state-reasons".
> DPA defines ONLY "printer-state" with enumerated values:
>
> unknown, idle, printing, needs-attention, paused, shutdown,
> job-start-wait, job-end-wait, job-password-wait,
> needs-key-operator, connecting-to-printer, timed-out
>
> DPA "shutdown" looks like IETF Host MIB "down" to me.
>
> Note that the basic reasons for IPP "stopped" are first-class
> states in DPA. There's clearly more to services than the
> three IPP states.
>
> Comments?
>
> 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 Tue, Jan 20, 2009 at 2:54 PM, William A Wagner <wamwagner@comcast.net>
> wrote:
>> Ira,
>>
>> Thanks for your explanation.
>>
>> BTW I did not suggest that Down and Testing were reasonably substates of
>> IDLE, but that they could be considered substates of STOPPED or, from an
>> external viewpoint, equivalent to UNKNOWN if the state cannot be
>> communicated.
>>
>> Since, from my understanding, IPP is the model of the Print service of an
>> MFD, defining a different state set for other MFD Services makes it
>> difficult to have a consistent approach to modeling MFD services. However,
>> if, as you suggest, we are committed to consider TESTING and DOWN as
> primary
>> states of a Service, I think we need to better deal with how these states
>> are entered and exited.
>>
>> I do not see in the document the information that ShutdownService shuts
> down
>> but does NOT end that service instance (it may be inferred from Fig 26,
> but
>> it is counterintuitive). I see no mention of a DeleteService operation or
>> action (although I agree that if ShutdownService does not end that service
>> instance, something should.) As I have indicated, I can find no
>> identification of a RestartService operation, or other explanation how
> this
>> action is effected. I can find no explanation of how a Service is put into
> a
>> TESTING state nor (without Restart) how it transitions to anything except
>> DOWN.
>>
>> Models are approximations or idealized views, and I think that different
>> models may be equally valid. But model descriptions should attempt to be
>> consistent and complete within themselves. They should be well explained
> and
>> neither intuitive understanding nor inherent understanding of some
>> unidentified standard should be assumed.
>>
>> It may not be appropriate to attempt to do this with the Scan Service at
>> this time, but if we are to define models with consistent semantics, I
> think
>> we need to settle on and properly document the Service states and the
> state
>> transition actions. Para 7.1.5.10 of the Scan Service document does
> present
>> a transition model, but I suggest a better documentation of the transition
>> actions is necessary.
>>
>> As always, opinions from others would be appreciated.
>>
>> Thanks,
>>
>> Bill Wagner
>>
>> -----Original Message-----
>> From: owner-mfd@pwg.org [mailto:owner-mfd@pwg.org] On Behalf Of Ira
> McDonald
>> Sent: Tuesday, January 20, 2009 11:47 AM
>> To: William A Wagner; Ira McDonald
>> Cc: mfd@pwg.org
>> Subject: Re: MFD> Comments and questions on 20090112 Scan Model Doc
>>
>> Hi Bill,
>>
>> Thanks for all your good comments on Scan Service.
>>
>> Here are my thoughts about service state.
>>
>> It's IPP that is deficient in primary states.
>>
>> DOWN is NOT some state-reason of IDLE.
>> It is a primary state in CIM Services as well.
>>
>> By the same token, TESTING is a primary state.
>> A service (or device) in TESTING MUST NOT
>> execute any normal user jobs.
>>
>> The stupidly deficient IPP states are the wrong
>> model to follow here, because mapping to CIM
>> and other interfaces will become convoluted and
>> fragile (i.e., implementation mappings will vary)
>> - behavior of operations would depend on the
>> state-reasons and not the primary state.
>>
>> Lastly, the WIMS/1.0 Protocol and Schema set
>> (and more recent Semantic Model/2.0 schemas)
>> have had this set of service states and their state
>> transitions for five years - it's pretty late to change
>> them, IMHO.
>>
>> StartupService instantiates a NEW service instance.
>> ShutdownService shuts down but does NOT destroy
>> that service instance. RestartService is necessary
>> to restart the previous service instance.
>>
>> These three admin operations are needed for every
>> Imaging System service. These operations are taken
>> from ISO 10175-Part3 (DPA Admin), as are equivalent
>> IPP operations in RFC 3998.
>>
>> DeleteService is probably also necessary (after a
>> ShutdownService) to actually delete the inactive
>> service object It's specified in ISO 10175-Part 3, but
>> was not included in RFC 3998 or WIMS/SM schema.
>>
>> BTW, while not exhaustive, the state transition tables
>> at the end of ISO 10175-Part3 are informative here.
>>
>> 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 Mon, Jan 19, 2009 at 11:05 PM, William A Wagner
>> <wamwagner@comcast.net> wrote:
>>> The following questions/comments are a result of my effort to generalize
>> the
>>> information for the overall MFD document. I acknowledge that the
> questions
>>> may be a result of my misunderstanding rather than an error or
>> inconsistency
>>> in the document. But that may suggest that some clarification may be
>> useful.
>>>
>>>
>>>
>>> Thanks.
>>>
>>>
>>>
>>> Bill Wagner
>>>
>>>
>>>
>>>
>>>
>>> 1. Line 2172 refers to an administrative RestartJob operation as
>> does
>>> Fig 33 and Fig 41. . No such operation is included under interfaces. As
>>> described, it is unclear that a RestartScanJob has the same sense as the
>> IPP
>>> Restart-Job (restart a job that is retained in the queue after
> processing
>>> has completed); indeed, it is unclear how RestartScanJob could have the
>>> same sense. Is there such an operation ?
>>>
>>>
>>>
>>> 2. Line 1393 refers to Restart in the same context as Startup and
>>> table 1403 refers to a RestartScanService operation. . Line 2166 refers
> to
>> a
>>> generic Restart. Fig 26, Fig 33 refer to a restart(), presumably
>>> RestartScanService. No such operation is included under Interfaces.
>>> Actually, I find the sentence starting "Otherwise, if the Scan Service
>>> needs a ShutdownScanService() operation…" on line 2165, confusing.
>>>
>>>
>>>
>>> 3. One of the service states is TESTING. Fig 26 indicates that only
>>> way into testing is via a testing() request. No such request is
>> identified.
>>> Should we indicate that testing() represents one of possibly several
>>> implementation dependent functions?
>>>
>>>
>>>
>>> 4. In Fig 26, the only ways out of TESTING are shutdown() to DOWN
>> and
>>> restart(), presumably RestartService, to IDLE. Again, is there a
>>> RestartService operation? Also, this diagram does not show the transition
>>> from UNKNOWN (initialization phase) that is identified in Fig 25 to be
> to
>>> DOWN; indeed, there is no entry to Fig 26. The Scan Service Theory of
>>> operation suggests that testing may take place in (or from) the
>>> Initialization phase (which right now only includes the UNKNOWN state.)
>> The
>>> reference is the HR MIB statuses; but the draft does not cover the other
>> HR
>>> defined statuses of RUNNING and WARNING. Does it make sense to mix IPP
>>> states with HR Device statuses? Do we really want to try to standardize
>>> Service startup and testing? I realize that this is a bit late in the
>> game
>>> to bring up, but in considering the MFD overall case, adapting the IPP
>>> approach of just three Service states: Idle, Processing, and Stopped
>> (along
>>> with an inherent Unknown) would seem adequate. If the Service is
>> reporting
>>> states, "Down" and "Testing" are variations of the Stopped state covered
>> by
>>> state-reasons; if the Service is not reporting state (i.e., is
> effectively
>>> "Unknown" as far as the rest of the world) then the transitions and
>>> intermediate states can be considered implementation dependent. I
>> recognize
>>> that this would affect 7.1.5.10. ( It would also address most of the
>> issues
>>> above.)
>>>
>>>
>>>
>>> 5. Line 1077 and subsequent. I do not understand the reference to
>> §6.
>>> (Console is discussed in para 2.2.12 of RFC3805)
>>>
>>>
>>>
>>> 6. Line 1084 . Cover is not defined in RFC3805 except as part of
>>> General Printer. I suggest the reference be dropped.
>>>
>>>
>>>
>>> 7. Line 1122; OutputChannelDefaultJobControlLanguage has a type
>>> interpreter?
>>>
>>>
>>>
>>> 8. Line 1127; OutputChannelInterface has a type interface
>>>
>>>
>>>
>>> 9. Line 1107; Interpreter is listed as not applicable to Scan
>> Service.
>>> What subunit does formatting of the digital document?
>>>
>>>
>>>
>>>
>>
>>
>
>
>
This archive was generated by hypermail 2.1.4 : Wed Jan 21 2009 - 17:28:35 EST