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
>>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140114/df9a11b6/attachment.html>