Michael,
Yes, I don't think that differs much from what I suggested; regardless of
the physical configuration, the diagram indicates that the IPP Server, the
Print Services and the output device are conceptually separate entities and
the IPP Server and the Print Service comprise the IPP Printer. I think
perhaps that point is that there is an IPP Server and there are various
imaging services. A single IPP Service should be able to (but may not
necessarily) support interfaces to different types of imaging services. One
might suggest that referring to an IPP FaxOut Service is inappropriate.
Rather, it is a IPP Server that handles IPP FaxOut communications (and
perhaps other IPP Imaging communications) and interfaces with a FaxOut
Service.
The combination of an IPP Server with a Print Service is an IPP Printer. Is
the combination of an IPP Server and a Scan Service an IPP Printer or an IPP
Scanner? Is the combination of an IPP Server with multiple imaging services
an IPP Printer or an IPP Multifunction?
Thanks,
Bill Wagner
From: Michael Sweet [mailto:msweet at apple.com]
Sent: Friday, January 10, 2014 2:44 PM
To: William A Wagner
Cc: Peter Zehler; <ipp at pwg.org>; Semantic Model 3.0 Workgroup discussion
list
Subject: Re: [IPP] Models
Bill,
The device isn't part of (as in embedded in) the Print Service in IPP, but
there is an association between them.
A single IPP Server *might* be a front-end for multiple services or it might
only handle a single server - that's an implementation choice. The point in
the IPP model is that the IPP Server is the protocol interface to the
underlying service and device(s).
On Jan 10, 2014, at 12:02 PM, William A Wagner <wamwagner at comcast.net>
wrote:
Pete,
The configuration of an " IPP Printer" being composed of an IPP Server and a
Print Service follows the diagram in IPP SIX and, indeed, goes back to RFC
2911. Furthermore, the "output device" was not considered part of the IPP
Printer. We did not necessarily adhere to this configuration in the MFD
model where we defined the Device as representing the hardware implementing
the Service, prompting two distinct uses of the word "device". I think the
point of separating the IPP Server and the Print Service was that IPP just
defines the IPP interface to the IPP Printer but does not define the form or
specifics of the Print Service (one could argue that the Semantic Model
does). But the separation is convenient in considering IPP multifunction so
that, as you suggest, there is a common IPP front end to potentially
multiple imaging services.
I am inclined, in the SM3 document, to eliminate the <service> term in
defining operations (e.g., Create<service>Job), unless they are
service-type specific. The understanding would be that the specific service
is in the address. What is your opinion in this?
Thanks,
Bill Wagner
From: Zehler, Peter [mailto:Peter.Zehler at xerox.com]
Sent: Friday, January 10, 2014 9:06 AM
To: William A Wagner; ipp at pwg.org; 'Semantic Model 3.0 Workgroup discussion
list'
Subject: RE: [IPP] Models
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] 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.orghttps://www.pwg.org/mailman/listinfo/ipp
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair