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.
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).
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 11:46 AM, Michael Sweet <msweet at apple.com> wrote:
> Smith,
>> The logical extension of the model in RFC 2911 would be this:
>>>>> The combination of IPP Server and Service is the IPP Printer (object),
> which is the instance you are addressing using the "printer-uri" attribute.
> We could generalize IPP Printer (object) by calling it an IPP Service
> (object), however since the target attribute is "printer-uri" and FaxOut is
> already using the IPP Printer terminology it may be simpler to document
> that an IPP Printer may perform functions other than printing. Whether a
> single IPP Server is used for all Services is an implementation detail we
> don't need to specify (I could add dotted lined to join each of the IPP
> Servers if that would be clearer?)
>> Also, in order to allow device access from multiple services, I opted to
> show the services interfacing (loosely) with devices through an arbitration
> layer - this should allow pretty much any implementation while showing that
> devices (and subunits) may be shared between services.
>> Thoughts?
>>> On Jan 10, 2014, at 3:37 PM, Kennedy, Smith (Wireless Architect) <
>smith.kennedy at hp.com> wrote:
>> So something more like this?
>> <PastedGraphic-4.png>
>>> The label “IPP Printer” was intended to convey that it was an IPP Printer
> Object.
>> Smith
>>>> On 2014-01-10, at 12:46 PM, Michael Sweet <msweet at apple.com> wrote:
>> Smith,
>> The IPP model defines a IPP Printer as the IPP Server + Service
> combination. So in your diagram having a shared IPP Server the interfaces
> with one or more services is a valid architecture, but the interior boxes
> should be the Print Service, Scan Service, FaxOut Service, etc. and not
> "IPP Printer" (which is the whole box).
>>> On Jan 10, 2014, at 12:20 PM, Kennedy, Smith (Wireless Architect) <
>smith.kennedy at hp.com> wrote:
>> Greetings,
>> For what it is worth, Pete’s description mirrors my own perception of the
> IPP object relationship. Graphically, this is how I understand the
> relationship between the “Printer objects” and the “server” to exist, at
> least in terms of IPP:
>> <PastedGraphic-2.png>
>> Pete, when you say “The Service URL identifies the service type”, do you
> mean that the resource path in a URL defines the service type? If so, I’m
> not sure that is guaranteed to be true. For instance “
>ipp://myhost.pwg.org/ipp/fax” could be “Fax” but could be anything. PWG
> 5100.15 says that an IPP FaxOut service MUST be at /ipp/fax but nothing
> prevents a single-function printer from having a conventional “Print”
> service at “/ipp/fax”. It seems that inspection of the
> “ipp-features-supported” is the way that one knows what service “type” is
> at a particular resource path.
>> Smith
>> /**
> Smith Kennedy
> ATB Wireless Architect - PPS
> Hewlett-Packard Co.
> */
>>>> On 2014-01-10, at 7:06 AM, Zehler, Peter <Peter.Zehler at xerox.com> wrote:
>> Bill,
>> I’m a little confused on what you have labeled as an IPP Server and IPP
> Printer. My view is that an IPP Server is what you have labeled as IPP
> Printer. It contains the required protocol stacks, resources and service
> instances. I have always understood an IPP Printer to be an instance of a
> Print Service. This would map to a Virtual Printer in ISO 10175 DPA.
>> I have assumed that there would be a single IPP stack implementation
> (i.e., IPP Server in your first diagram) that would front end the service
> instances. Each service instance would be referenced by its unique URL
> (e.g., same URI Scheme, hostname and port, different paths) Implementers
> are free to do things differently but I assume the intent of the IPP
> specification would be to multiplex all the IPP Services over a single port
> (i.e., 631)
>> I agree that we could have used generic verbs but once we finished print
> we were stuck with the names of the verb. Since IPP uses an enumeration we
> can reuse the enumeration across the services. In the semantic model the
> operation does not really identify the service type. The Service URL
> identifies the service type. The operation names are simply service
> specific aliases for a common semantic operation. We could have opted for
> a generic name but we went with a naming convention instead.
>> Pete
>> 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
>>> *From:* ipp-bounces at pwg.org [mailto:ipp-bounces at pwg.org<ipp-bounces at pwg.org>
> ] *On Behalf Of *William A Wagner
> *Sent:* Thursday, January 09, 2014 12:57 PM
> *To:* ipp at pwg.org; 'Semantic Model 3.0 Workgroup discussion list'
> *Subject:* [IPP] Models
>> I am unclear on a Semantic Model configuration issue, which also may
> relate to IPP multifunction. The Semantic Model assumes that communication
> is from client to service. But in our operations, we identify the Service
> (e.g., CancelFaxInJob), which should not be necessary if the operation is
> directed to the service. On the other hand, depending upon where you want
> to put the transport address boundary, it is reasonable to think of
> operations being directed to the MFD, which corresponds to the System, in
> which case the service should be identified. Of course, this is inadequate
> if there are multiple services of a given type in the same system. Bottom
> line, should operations identify the Service type?
>> With respect to IPP, should the multi service configuration look like A or
> B below? (or perhaps something else entirely?) Again, the modeling question
> is whether the service identification is included in the operation.
> <image001.jpg><image002.jpg>
> IPP Multifunction A
>> IPP Multifunction B
>> Thanks,
> Bill Wagner
>>> _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp>>> _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp>>> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>>>> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>>> _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp>>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140114/c3af0805/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-2.png
Type: image/png
Size: 60930 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140114/c3af0805/attachment.png>
