[IPP] Models

[IPP] Models

[IPP] Models

Ira McDonald blueroofmusic at gmail.com
Tue Jan 14 17:30:19 UTC 2014


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/blueroofmusic
http://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>


More information about the ipp mailing list