Subject: [IPP] Models

From: "William A Wagner" <[email-masked]>
Date: Thu, 9 Jan 2014 12:57:25 -0500

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.

IPP Printer A.jpgIPP Printer B.jpg

IPP Multifunction A
IPP Multifunction B

Thanks,

Bill Wagner

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: "Zehler, Peter" <[email-masked]>
Date: Fri, 10 Jan 2014 14:06:29 +0000

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: [email-masked]<mailto:[email-masked]>
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: [email-masked] [mailto:[email-masked]] On Behalf Of William A Wagner
Sent: Thursday, January 09, 2014 12:57 PM
To: [email-masked]; '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.
[IPP Printer A.jpg][IPP Printer B.jpg]
IPP Multifunction A                                                                                                                                                                                         IPP Multifunction B

Thanks,
Bill Wagner

---

From: "William A Wagner" <[email-masked]>
Date: Fri, 10 Jan 2014 12:02:00 -0500

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:[email-masked]] 
Sent: Friday, January 10, 2014 9:06 AM
To: William A Wagner; [email-masked]; '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: [email-masked]
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: [email-masked] [mailto:[email-masked]] On Behalf Of William
A Wagner
Sent: Thursday, January 09, 2014 12:57 PM
To: [email-masked]; 'Semantic Model 3.0 Workgroup discussion list'
Subject: [IPP] Models

IPP Multifunction A
IPP Multifunction B

Thanks,

Bill Wagner

---

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Fri, 10 Jan 2014 17:20:19 +0000

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 <[email-masked]> 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.
>

---

From: "Zehler, Peter" <[email-masked]>
Date: Fri, 10 Jan 2014 18:05:00 +0000

Bill,
I don't think I'd object to eliminating the <service> term in defining operations (e.g., Create<service>Job) , in the SM3 document.  Even if they are  service-type specific I'd still try to keep the service name out of the operation.
The caveat I have is that we introduced this naming convention in operations and in attributes to get around the use of "print" in the names when they turned out to be more general as we expanded the scope from Print to MFD.
Pete

Peter Zehler

From: William A Wagner [mailto:[email-masked]]
Sent: Friday, January 10, 2014 12:02 PM
To: Zehler, Peter; [email-masked]; 'Semantic Model 3.0 Workgroup discussion list'
Subject: RE: [IPP] Models

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:[email-masked]]
Sent: Friday, January 10, 2014 9:06 AM
To: William A Wagner; [email-masked]<mailto:[email-masked]>; 'Semantic Model 3.0 Workgroup discussion list'
Subject: RE: [IPP] Models

Bill,

Pete

Peter Zehler

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of William A Wagner
Sent: Thursday, January 09, 2014 12:57 PM
To: [email-masked]<mailto:[email-masked]>; 'Semantic Model 3.0 Workgroup discussion list'
Subject: [IPP] Models

Thanks,
Bill Wagner

---

From: "Zehler, Peter" <[email-masked]>
Date: Fri, 10 Jan 2014 18:18:30 +0000

Smith,

When I say "The Service URL identifies the service type" I mean that the URL is the transport endpoint for s service instance.  The path segment of the URL is not necessarily fixed for a service type.  A URL such as <ipp://somemfd.example.com//ipp/appletree>  could just as easily be an IPP Printer as it could be IPP Scan.  The discovery protocols or directory entries would map the service instance to the URL.  The most common deployment will probably be a single instance of a service for a server (e.g., an MFD offering a single print service, a single scan service and a single faxout service).  I see no problem with various environments (e.g., WiFi Alliance, Mopria) mandating a best practice that would fix the path segment for the URL.

I had never thought about it before but the IPP model does not really have an service status attribute that self describes its service type.  I would agree that it seems that inspection of the "ipp-features-supported" is the way that one knows what service "type" is at a particular resource path.  (I had always assumed the Client would already know what type of service they require and would discover only those endpoints of the appropriate service type.)

Pete

Peter Zehler

From: [email-masked] [mailto:[email-masked]] On Behalf Of Kennedy, Smith (Wireless Architect)
Sent: Friday, January 10, 2014 12:20 PM
To: Zehler, Peter; William A Wagner; <[email-masked]>; Semantic Model 3.0 Workgroup discussion list
Subject: Re: [IPP] Models

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

On 2014-01-10, at 7:06 AM, Zehler, Peter <[email-masked]<mailto:[email-masked]>> wrote:

Bill,

Pete

Peter Zehler

Thanks,
Bill Wagner

_______________________________________________
ipp mailing list
[email-masked]<mailto:[email-masked]>
https://www.pwg.org/mailman/listinfo/ipp

---

From: Michael Sweet <[email-masked]>
Date: Fri, 10 Jan 2014 14:26:05 -0500

Pete,

I think one of the attributes we'll be adding as we tackle multifunction will be a printer-service-type (or something like that) attribute that identifies the service type.  I don't think ipp-features-supported is necessarily a good fit (I see great chances of confusion there...)

On Jan 10, 2014, at 1:18 PM, Zehler, Peter <[email-masked]> wrote:

> Smith,
>  
> When I say “The Service URL identifies the service type” I mean that the URL is the transport endpoint for s service instance.  The path segment of the URL is not necessarily fixed for a service type.  A URL such as <ipp://somemfd.example.com//ipp/appletree>  could just as easily be an IPP Printer as it could be IPP Scan.  The discovery protocols or directory entries would map the service instance to the URL.  The most common deployment will probably be a single instance of a service for a server (e.g., an MFD offering a single print service, a single scan service and a single faxout service).  I see no problem with various environments (e.g., WiFi Alliance, Mopria) mandating a best practice that would fix the path segment  for the URL.
>  
> I had never thought about it before but the IPP model does not really have an service status attribute that self describes its service type.  I would agree that it seems that inspection of the “ipp-features-supported” is the way that one knows what service “type” is at a particular resource path.  (I had always assumed the Client would already know what type of service they require and would discover only those endpoints of the appropriate service type.)
>  
> Pete
>  
> Peter Zehler
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Michael Sweet <[email-masked]>
Date: Fri, 10 Jan 2014 14:44:13 -0500

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 <[email-masked]> 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.
>  
> To: William A Wagner; [email-masked]; 'Semantic Model 3.0 Workgroup discussion list'

---

From: Michael Sweet <[email-masked]>
Date: Fri, 10 Jan 2014 14:46:46 -0500

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).

---

From: Michael Sweet <[email-masked]>
Date: Fri, 10 Jan 2014 14:58:21 -0500

Pete,

> 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, r…

RFC 2911 says an IPP Printer is the combination of IPP Server and Print Service.

> 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 b…

Well, IPP is layered over HTTP, so technically an IPP Server could/would multiplex based on the URI, and in fact can have multiple URIs (and port numbers, schemes, hostnames/addresses, etc.) for the same service.

Whether the same IPP Server is used for all the services is an implementation choice, and in fact there are many Apache httpd-based IPP solutions out there where httpd handles the incoming requests but separate service handlers do the IPP layer.

---

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Fri, 10 Jan 2014 20:37:00 +0000

So something more like this?  

The label “IPP Printer” was intended to convey that it was an IPP Printer Object.

Smith

---

From: "William A Wagner" <[email-masked]>
Date: Fri, 10 Jan 2014 16:20:00 -0500

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:[email-masked]] 
Sent: Friday, January 10, 2014 2:44 PM
To: William A Wagner
Cc: Peter Zehler; <[email-masked]>; 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 <[email-masked]>
wrote:

Pete,

Thanks,

Bill Wagner

Bill,

Pete

Peter Zehler

 

IPP Multifunction A
IPP Multifunction B

Thanks,

Bill Wagner

---

From: Michael Sweet <[email-masked]>
Date: Tue, 14 Jan 2014 11:46:55 -0500

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?

---

From: Ira McDonald <[email-masked]>
Date: Tue, 14 Jan 2014 12:30:19 -0500

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: [email-masked]
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 <[email-masked]> wrote:

> 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?
>
>
> 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).
>
>
> 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
> I’m a little confused on what you have labeled as an IPP Server and IPP
> 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
> 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
> 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
>
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>
> ] *On Behalf Of *William A Wagner
> *Sent:* Thursday, January 09, 2014 12:57 PM
> *To:* [email-masked]; '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.
> IPP Multifunction A
>
> IPP Multifunction B
>
> Thanks,
> Bill Wagner
>
>

---

From: Michael Sweet <[email-masked]>
Date: Tue, 14 Jan 2014 13:03:53 -0500

Ira,

On Jan 14, 2014, at 12:30 PM, Ira McDonald <[email-masked]> wrote:

> 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 

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.

---

From: Ira McDonald <[email-masked]>
Date: Tue, 14 Jan 2014 15:03:14 -0500

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

On Tue, Jan 14, 2014 at 1:03 PM, Michael Sweet <[email-masked]> wrote:

> 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:
>
> 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:
>
> 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.
>

---

From: Michael Sweet <[email-masked]>
Date: Tue, 14 Jan 2014 15:13:25 -0500

Ira,

On Jan 14, 2014, at 3:03 PM, Ira McDonald <[email-masked]> wrote:
> ...So, a question.  Can an implementation of SCS (at some "ipp/ipps"

Conceptually yes, although we would need to very carefully define this since ordinary users normally do not have access to the System Control Service, and you would need to define (or be able to define) the subordinate service that would receive the print jobs - this is especially important for systems with multiple marking engines (generally anything like CUPS).

---

From: Ira McDonald <[email-masked]>
Date: Tue, 14 Jan 2014 15:17:42 -0500

Hi Mike,

Although I agree that the answer is conceptually yes, it's yucky from the
point of view of attributes like "operations-supported".

Which is why I suggest we rule it out and say that an SCS has an endpoint
in an IPP System new first-class object (available ONLY to an Operator or
Administrator and never to an End User).  That actually matches the SM
definition of SCS much more faithfully and simplifies counter and diagnostic
attributes.

Cheers,
- Ira

On Tue, Jan 14, 2014 at 3:13 PM, Michael Sweet <[email-masked]> wrote:

> ...
> Conceptually yes, although we would need to very carefully define this
> since ordinary users normally do not have access to the System Control
> Service, and you would need to define (or be able to define) the
> subordinate service that would receive the print jobs - this is especially
> important for systems with multiple marking engines (generally anything
> like CUPS).
>

---

From: "William A Wagner" <[email-masked]>
Date: Tue, 14 Jan 2014 16:38:58 -0500

Sorry to continue on this point, but by the SM2 definitions, a Device is "An
abstract object representing a hardware component that implements one or
more Imaging Services." And an Imaging Device is "A hardware entity that
supports one or more Imaging Services, including the System." The Semantic
Model does not include "devices" (except for "output device", which is a
very low level element). Subunits are part of the System Configuration (and
also Service(s) configuration). Considering that the Device corresponds to
the System and the Services are components of the System, don't understand
the comment "Devices are directly addressable in IPP (and the Semantic
Model)" which seems to suggest that devices are components of System
(assuming that there is some correlation between an IPP Printer and a
Semantic Model System.)

With respect to the question of can a System Control Service accept Print
commands, I understand that we are saying that all IPP commands are Print
commands. On the other hand, the Semantic Model is clear in that the SM SCS
"is not job oriented there are no Jobs coming in or output produced and
therefore no subordinate DefaultJobTicket or Capabilities." I suggest that,
from the SM viewpoint, the System Control Service provides access to System
elements, including control of System Services, but would not understand any
imaging command.

That is not to say that IPP cannot deviate from the Semantic Model, but
hopefully not without good reason. 

Thanks,
Bill Wagner

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ira
McDonald
Sent: Tuesday, January 14, 2014 3:03 PM
To: Michael Sweet
Cc: Kennedy, Smith (Wireless Architect); <[email-masked]>; Semantic Model 3.0
Workgroup discussion list
Subject: Re: [SM3] [IPP] Models

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.

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: [email-masked]
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 <[email-masked]> wrote:

> 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.
>
>
> 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 -- -- -- -- -- -- -- -- -- 
> --
> -- -- -- --
>
> 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).
>
>
> 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.
>
> 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.
>
_______________________________________________
sm3 mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/sm3