Sorry to continue on this point, but by the SM2 definitions, a Device is "An
abstract object representing a hardware component that implements one or
more Imaging Services." And an Imaging Device is "A hardware entity that
supports one or more Imaging Services, including the System." The Semantic
Model does not include "devices" (except for "output device", which is a
very low level element). Subunits are part of the System Configuration (and
also Service(s) configuration). Considering that the Device corresponds to
the System and the Services are components of the System, don't understand
the comment "Devices are directly addressable in IPP (and the Semantic
Model)" which seems to suggest that devices are components of System
(assuming that there is some correlation between an IPP Printer and a
Semantic Model System.)
With respect to the question of can a System Control Service accept Print
commands, I understand that we are saying that all IPP commands are Print
commands. On the other hand, the Semantic Model is clear in that the SM SCS
"is not job oriented there are no Jobs coming in or output produced and
therefore no subordinate DefaultJobTicket or Capabilities." I suggest that,
from the SM viewpoint, the System Control Service provides access to System
elements, including control of System Services, but would not understand any
imaging command.
That is not to say that IPP cannot deviate from the Semantic Model, but
hopefully not without good reason.
Thanks,
Bill Wagner
-----Original Message-----
From: sm3-bounces at pwg.org [mailto:sm3-bounces at pwg.org] On Behalf Of Ira
McDonald
Sent: Tuesday, January 14, 2014 3:03 PM
To: Michael Sweet
Cc: Kennedy, Smith (Wireless Architect); <ipp at pwg.org>; Semantic Model 3.0
Workgroup discussion list
Subject: Re: [SM3] [IPP] Models
Hi Mike,
I agree with everything you said, including your diagram clarification for
Devices and Subunits. In SM, Services do expose their associated Subunits
(we only partially do this in IPP Logical Printer at present), but SCS
actually controls the Subunits and their contained in the System object.
Although I see the point of keeping "printer-uri" as the service endpoint,
I'm still sort of in favor of a new first-class IPP System object that is
the endpoint for System Control Service (using "printer-uri" and
"printer-xxx"
attributes as appropriate). This seems a bit more intuitive, because SCS is
*not* just another Job service, but is strictly a Management service.
My point with the ISO DPA and WIMS history was just to clarify the where the
terminology intersects.
So, a question. Can an implementation of SCS (at some "ipp/ipps"
URI endpoint) also accept Print commands at the same endpoint?
I suggest yes, but could be argued out of this. It partly has to do with
finding roll-up usage counters for all service instances from the SCS
somewhere on an IPP system.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility
Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO
Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusichttp://sites.google.com/site/highnorthinc
mailto: 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 Tue, Jan 14, 2014 at 1:03 PM, Michael Sweet <msweet at apple.com> wrote:
> Ira,
>> On Jan 14, 2014, at 12:30 PM, Ira McDonald <blueroofmusic at gmail.com>
> wrote:
>> Hi Mike,
>> I like your drawing and explanations.
>> But conflating Input/Output Devices with Subunits (non-free-standing
> components of a Printer, Scanner, Copier, etc.) bothers me. It
> doesn't cohere w/ the IETF Host Resources and Printer MIBs or the ISO
> 10175 DPA model (where subunits are all first-class objects).
>> I suggest changing the common bottom solid line below Print Service to
> SCS to a shorter height block (than the service blocks) labelled
> "Shared Subunits (input tray, marker, etc.)" to clarify this
> distinction.
>>> Devices are directly addressable in IPP (and the Semantic Model) to
> support fan-out, while subunits are not (subunits get used/addressed
> as a side effect of intent), so it is important to show devices in the
diagram.
> How about:
>> -- -- Arbitrated Device/Subunit Access -- -- -- -- -- -- -- -- --
> --
> -- -- -- --
>> +- Device -+ +- Device -+ +- Device -+
> | Subunits | | Subunits | ... | Subunits |
> +----------+ +----------+ +----------+
>> We can reference RFC 3805 for the definition of the different
> subunits, and we have already exposed some of them in the various IPP
> extensions (printer-supply, printer-input-tray, printer-output-tray,
> etc.)
>>> Historical Note:
>> In the ISO 10175 DPA model, there is actually a top object of Server.
> For consistency w/ IETF Host Resources and Printer MIBs, Pete and I
> renamed it from Server to System when I wrote the WIMS multifunction
> schema that Pete mostly adopted into the Semantic Model 2.0 schema.
>> The ISO DPA Control operation (all admin ops rolled into one command)
> has a target of Server (and can startup or shutdown an instance of a
> Logical Printer).
>>> For Semantic Model the Object and Service are defined as separate
> entities, e.g., System Object and System Control Service. But IPP
> defines the combination of the IPP Server and Service as a combined
> IPP object, e.g. IPP Printer object is the IPP Server and Print
> Service, IPP System object would be the IPP Server and System Control
> Service, etc. I don't think there is a fundamental difference in the
> models that needs to be reconciled, just some words to document the
> difference in terminology and diagrams.
>> If we choose to make a distinction, the rightmost IPP Printer in my
> diagram could just be changed to IPP System. But I think we should
> still use a "printer-uri" attribute to target the System Control
> Service, reusing as much as possible from RFC 2911.
>> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>>_______________________________________________
sm3 mailing list
sm3 at pwg.orghttps://www.pwg.org/mailman/listinfo/sm3