Re: MFD> Comments and questions on 20090112 Scan Model Doc

From: Ira McDonald (blueroofmusic@gmail.com)
Date: Tue Jan 20 2009 - 11:47:21 EST

  • Next message: William A Wagner: "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 : Tue Jan 20 2009 - 11:47:37 EST