[IPP] Models

[IPP] Models

[IPP] Models

Kennedy, Smith (Wireless Architect) smith.kennedy at hp.com
Fri Jan 10 17:20:19 UTC 2014


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:



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] 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140110/2123167c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-2.png
Type: image/png
Size: 16979 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140110/2123167c/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3319 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140110/2123167c/attachment.p7s>


More information about the ipp mailing list