Subject: Re: [IPP] Slides to discuss Orientation and feed direction in Finishings 2.x posted

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Tue, 17 May 2016 12:16:09 +0000

Greetings,

Attached is an updated slide set as per the last IPP WG meeting.  Please review before next meeting and reply with feedback via email if possible if there are any glaring issues with the way that I've encoded things.  This is a complex problem, which would benefit from broad review.

Cheers,

Smith

> On 2016-04-28, at 10:24 AM, Kennedy, Smith (Wireless Architect) <[email-masked]> wrote:
> 
> Greetings,
> 
> I have posted a brief slide set that I will use later today to try to illustrate issue I think needs to be addressed in Finishings 2.1, that concerns managing finishings options based on job orientation and/or feed orientation.  It is here:
> 
> http://ftp.pwg.org/pub/pwg/ipp/slides/Finishings-2.1-Orientation-and-Feed-Orientation-Extensions.pdf
> 
> I've also updated the meeting page to list this slide deck.
> 
> Cheers,
> 
> Smith
> 

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

---

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Mon, 23 May 2016 19:13:55 +0000

Greetings,

This revision of the slide set is now on the FTP site here:

http://ftp.pwg.org/pub/pwg/ipp/slides/Finishings-2.1-Orientation-and-Feed-Orientation-Extensions-2016-05-17.pdf

Smith

/**
    Smith Kennedy
    Wireless Architect - Client Software - IPG-PPS
    Standards - IEEE ISTO PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum / USB IF
    PWG Chair
    HP Inc.
*/

> On 2016-05-17, at 6:16 AM, Kennedy, Smith (Wireless Architect) <[email-masked]> wrote:
> 
> Greetings,
> 
> <Finishings-2.1-Orientation-and-Feed-Orientation-Extensions-2016-05-17.pdf>_______________________________________________
> ipp mailing list
> [email-masked]

---

From: "Zehler, Peter" <[email-masked]>
Date: Tue, 24 May 2016 12:22:57 +0000

All,

I don't understand why the long established method of specifying finishing by intent is being modified to a process based model.  RFC2911 stated "specified with respect to the document as if the document were a portrait document.  If the document is actually a landscape or a reverse-landscape document, the client supplies the appropriate transformed value.".  PWG5100.1 clarified that "The approach for the coordinate system of being relative to the media feed direction is too dependent on the way the device is configured, i.e., pulling short edge first vs. long edge first, and can vary between different output bins in the same device.".  I'd also note that the semantics adopted by the PWG provide consistence not only between RFC2911 and PWG5100.1 but with the finisher MIB RFC3806 which states "All Finishing Processes are defined relative to a portrait orientation of the medium, regardless of the orientation of the printed image or the direction of feed.".

I would prefer to keep device specific processing out of the protocol whenever possible.  IPP printers support fan out.  There is a "walk and request" (aka Follow Me Print) mode of printing system in which a user can walk to any printer in the network pool and request that his or her job be released and printed at that particular printer.  Fan out also applies to printer clustering to increase resource utilization.  I do not want to see these intermediate printers have to transform a print ticket based on which device produces the output.  There are printers that support feeding the same media both long edge and short edge depending upon the tray from which the media is pulled.  These printers already must handle the transformation of the print job intent to the process necessary to produce the appropriate output.  This applies not only to job ticket elements but to job content as well.

In the definition of IPP we discussed at length whether or not an IPP Printer is a physical or logical/virtual device.  We purposely abstracted out as much of the physical device as possible.  I would hate to start modeling an IPP Printer as a physical device.  Introducing the complexities and variations of physical device implementations will reduce the interoperability of IPP Clients and IPP Printers.  It will make the specification of the user's intent more complex.  Looking at the Finishings-2.1-Orientation-and-Feed-Orientation-Extensions document, I see nothing that would require a deviation from the current semantics to accomplish the desired output.  

Peter Zehler
Xerox Corp.
Global Development Group
800 Phillips Rd, 111-04A
Webster NY, 14580-9701
Email: [email-masked]
Office: +1 (585) 265-8755
Fax: +1 (585) 422-0238
Mobile: +1 (585) 329-9508

-----Original Message-----
From: ipp [mailto:[email-masked]] On Behalf Of Kennedy, Smith (Wireless Architect)
Sent: Monday, May 23, 2016 3:14 PM
To: [email-masked]
Subject: Re: [IPP] Slides to discuss Orientation and feed direction in Finishings 2.x posted

Greetings,

Smith

/**
    Smith Kennedy

---

From: Michael Sweet <[email-masked]>
Date: Tue, 24 May 2016 11:41:45 -0400

Pete,

> On May 24, 2016, at 8:22 AM, Zehler, Peter <[email-masked]> wrote:
> 
> All,
> 

The issue is not one of specifying the processing details in the Job Ticket, but communicating the device constraints in finishings-col-database/ready (along with details that allow the Client to preview the results of finishing processes/intent).

> I would prefer to keep device specific processing out of the protocol whenever possible.

That is definitely the sticking point in this discussion - I completely agree that we want to avoid exposing low-level device processing details, but at the same time we want to provide enough information to the Client to know about hardware limitations/constraints.

> IPP printers support fan out.  There is a "walk and request" (aka Follow Me Print) mode of printing system in which a user can walk to any printer in the network pool and request that his or her job be released and printed at that particular printer.  Fan out also applies to printer clustering to increase resource utilization.

"Follow me" or "release" printing generally has a lower expectation of fidelity, and often the printing system will only expose a common subset of printer features and capabilities as configured by the administrator, e.g., all printers are configured with duplex, letter/a4, tabloid/a3, and a stapler.  In this case the printing system would not provide device-specific constraints but simply represent the generic finishing capabilities.

Printer clusters often involve multiple identical printers and/or fan-out jobs to printers that support the requested Job Ticket intent, e.g., Tabloid booklet fold jobs get routed to a printer that supports that media size, booklet fold, and saddle stitch.

> I do not want to see these intermediate printers have to transform a print ticket based on which device produces the output.

I think we are in agreement for this - to reiterate my original point, the member attributes under discussion provide descriptive values for finishings-col-database/ready Printer Status attributes and cannot be supplied in the finishings-col Job Template attribute.

> There are printers that support feeding the same media both long edge and short edge depending upon the tray from which the media is pulled.  These printers already must handle the transformation of the print job intent to the process necessary to produce the appropriate output.  This applies not only to job ticket elements but to job content as well.

The kicker is that a Client can specify the desired input tray via the "media-source" member attribute in the "media-col" Job Template attribute.  Including some constraint information in "finishings-col-database/ready" allows the Client to present a choice to the user (or limit the choices available to the user) depending on the selected media and finishings values.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer

---

From: Michael Sweet <[email-masked]>
Date: Tue, 24 May 2016 12:00:39 -0400

Smith,

Would using "job-constraints-supported" to list the exceptions to "finishings-col-database/ready" be a better match than specifying the feed orientation?  That way we are still tying the constraint to the media size/source without exposing the lower-level processing details, and the "job-resolvers-supported" attribute can provide a recommended change, e.g., use tray 2 instead of tray 3.

> On May 23, 2016, at 3:13 PM, Kennedy, Smith (Wireless Architect) <[email-masked]> wrote:
> 
> Greetings,
>

---

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Tue, 24 May 2016 18:51:44 +0000

Hi Mike,

Yesterday in the IPP WG meeting I agreed to work up sequence diagrams that will hopefully paint the picture more clearly than my slide set.  I'll model the "job-constraints-supported" approach as well as the approach we have considered thus far that uses additions to finishings-col and/or media-col.  I'm not married to any particular solution, just to finding an appropriate way to support these limitations.

Smith

> On 2016-05-24, at 10:00 AM, Michael Sweet <[email-masked]> wrote:
> 
> Smith,
>

---

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Tue, 24 May 2016 18:51:51 +0000

Hi Pete,

> I don't understand why the long established method of specifying finishing by intent is being modified to a process based model.  RFC2911 stated "specified with respect to the document as if the do…

If there were or are places where I didn't express the finishings in terms of portrait orientation, my apologies - it is likely due to mistakes or typos on my part (e.g. mistakenly using "staple-top-left" where I should have used "staple-bottom-left" or "staple-top-right".  I will try to make sure the sequence diagrams I'm working on will accurately specify these values to avoid further misunderstanding.

Mike's responses earlier accurately expressed what we are trying to do here.  I am not trying to add support for device specific processing, but rather trying allow the Printer to express limitations to finishings to the Client to give it the ability to present only those facilities that the device supports so that the User's intent can match the capabilities of the Printer, to try to avoid User disappointment.

Smith

> On 2016-05-24, at 6:22 AM, Zehler, Peter <[email-masked]> wrote:
> 
> All,
>

---

From: "Zehler, Peter" <[email-masked]>
Date: Wed, 25 May 2016 11:34:16 +0000

Smith,
I would prefer to have the limitations of finishings for an IPP Printer expressed using the "job-constraints-supported" approach.  I believe that tying finishings limitations to physical attributes of the media path is the wrong approach.  We have achieved a great deal of flexibility in implementation choices and improved interoperability as a result of treating the IPP Printer as  virtual device.  There are times when the physical configuration/status of a printer is important.  I don't believe that the construction of a print job ticket should be one of those times.  Expressing the finishings limitation in terms of the available media is preferable.  That way the physical aspects of the printer are factored out.  I know we have the tray selections defined for media but that was originally put in for backward compatibility and for very low end devices that have no concept of media.  I don't believe any printer supporting IPP does not comprehend media.  One of the remaining use cases
  I see now for specifying media with a tray name is for custom media via the bypass tray.  
Pete

Peter Zehler
Xerox Corp.
Global Development Group
800 Phillips Rd, 111-04A
Webster NY, 14580-9701

-----Original Message-----
From: Kennedy, Smith (Wireless Architect) [mailto:[email-masked]] 
Sent: Tuesday, May 24, 2016 2:52 PM
To: Zehler, Peter <[email-masked]>
Cc: [email-masked]
Subject: Re: [IPP] Slides to discuss Orientation and feed direction in Finishings 2.x posted

Hi Pete,

Smith

---

From: Ira McDonald <[email-masked]>
Date: Wed, 25 May 2016 09:22:11 -0400

Hi,

Like Pete, I endorse Mike's suggestion of considering using Job Constraints,
rather than muddying media-col-database or finishings-col-database/ready.

Directly accessible Printers (USB or local network domain) can provide more
info to IPP Clients about physical characteristics, but in the context of
Job
forwarding, Cloud/SDN print, etc. it's preferable to stick firmly to
intent-based
printing, IMO.

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 Wed, May 25, 2016 at 7:34 AM, Zehler, Peter <[email-masked]>
wrote:

> Smith,
> I would prefer to have the limitations of finishings for an IPP Printer
> expressed using the "job-constraints-supported" approach.  I believe that
> tying finishings limitations to physical attributes of the media path is
> the wrong approach.  We have achieved a great deal of flexibility in
> implementation choices and improved interoperability as a result of
> treating the IPP Printer as  virtual device.  There are times when the
> physical configuration/status of a printer is important.  I don't believe
> that the construction of a print job ticket should be one of those times.
> Expressing the finishings limitation in terms of the available media is
> preferable.  That way the physical aspects of the printer are factored
> out.  I know we have the tray selections defined for media but that was
> originally put in for backward compatibility and for very low end devices
> that have no concept of media.  I don't believe any printer supporting IPP
> does not comprehend media.  One of the remaining use cases
> > I don't understand why the long established method of specifying
> finishing by intent is being modified to a process based model.  RFC2911
> stated "specified with respect to the document as if the document were a
> portrait document.  If the document is actually a landscape or a
> reverse-landscape document, the client supplies the appropriate transformed
> value.".  PWG5100.1 clarified that "The approach for the coordinate system
> of being relative to the media feed direction is too dependent on the way
> the device is configured, i.e., pulling short edge first vs. long edge
> first, and can vary between different output bins in the same device.".
> I'd also note that the semantics adopted by the PWG provide consistence not
> only between RFC2911 and PWG5100.1 but with the finisher MIB RFC3806 which
> states "All Finishing Processes are defined relative to a portrait
> orientation of the medium, regardless of the orientation of the printed
> image or the direction of feed.".
>
> If there were or are places where I didn't express the finishings in terms
> of portrait orientation, my apologies - it is likely due to mistakes or
> typos on my part (e.g. mistakenly using "staple-top-left" where I should
> have used "staple-bottom-left" or "staple-top-right".  I will try to make
> sure the sequence diagrams I'm working on will accurately specify these
> values to avoid further misunderstanding.
>
> Mike's responses earlier accurately expressed what we are trying to do
> here.  I am not trying to add support for device specific processing, but
> rather trying allow the Printer to express limitations to finishings to the
> Client to give it the ability to present only those facilities that the
> device supports so that the User's intent can match the capabilities of the
> Printer, to try to avoid User disappointment.
>
> Smith
>
>
>
> > I don't understand why the long established method of specifying
> finishing by intent is being modified to a process based model.  RFC2911
> stated "specified with respect to the document as if the document were a
> portrait document.  If the document is actually a landscape or a
> reverse-landscape document, the client supplies the appropriate transformed
> value.".  PWG5100.1 clarified that "The approach for the coordinate system
> of being relative to the media feed direction is too dependent on the way
> the device is configured, i.e., pulling short edge first vs. long edge
> first, and can vary between different output bins in the same device.".
> I'd also note that the semantics adopted by the PWG provide consistence not
> only between RFC2911 and PWG5100.1 but with the finisher MIB RFC3806 which
> states "All Finishing Processes are defined relative to a portrait
> orientation of the medium, regardless of the orientation of the printed
> image or the direction of feed.".
> >
> > I would prefer to keep device specific processing out of the protocol
> whenever possible.  IPP printers support fan out.  There is a "walk and
> request" (aka Follow Me Print) mode of printing system in which a user can
> walk to any printer in the network pool and request that his or her job be
> released and printed at that particular printer.  Fan out also applies to
> printer clustering to increase resource utilization.  I do not want to see
> these intermediate printers have to transform a print ticket based on which
> device produces the output.  There are printers that support feeding the
> same media both long edge and short edge depending upon the tray from which
> the media is pulled.  These printers already must handle the transformation
> of the print job intent to the process necessary to produce the appropriate
> output.  This applies not only to job ticket elements but to job content as
> well.
> >
> > In the definition of IPP we discussed at length whether or not an IPP
> Printer is a physical or logical/virtual device.  We purposely abstracted
> out as much of the physical device as possible.  I would hate to start
> modeling an IPP Printer as a physical device.  Introducing the complexities
> and variations of physical device implementations will reduce the
> interoperability of IPP Clients and IPP Printers.  It will make the
> specification of the user's intent more complex.  Looking at the
> Finishings-2.1-Orientation-and-Feed-Orientation-Extensions document, I see
> nothing that would require a deviation from the current semantics to
> accomplish the desired output.
> >
> > Peter Zehler
> > Xerox Corp.
> > Global Development Group
> > 800 Phillips Rd, 111-04A
> > Webster NY, 14580-9701
> >> Attached is an updated slide set as per the last IPP WG meeting.
> Please review before next meeting and reply with feedback via email if
> possible if there are any glaring issues with the way that I've encoded
> things.  This is a complex problem, which would benefit from broad review.
> >>
> >> Cheers,
> >>
> >> Smith
> >>
> >>
> >>
> >>> I have posted a brief slide set that I will use later today to try to
> illustrate issue I think needs to be addressed in Finishings 2.1, that
> concerns managing finishings options based on job orientation and/or feed
> orientation.  It is here:
> >>>
> >>>

---

From: Michael Sweet <[email-masked]>
Date: Wed, 25 May 2016 10:11:24 -0400

All,

Let's give Smith some time to update the slides with examples using job-constraints-supported - that's a necessary first step to determine the feasibility of using constraints in this manner, given the potentially long list of constraints.

There is a long history of constraints being misused in PPDs to provide "absolute" guarantees of fidelity, leading to hundreds of thousands of constraints (!) needing to be processed by a Client for each user selection.  Naturally that poses a number of implementation challenges (something I've had to deal with over the years in CUPS, and I'll refrain from shaming any one vendor) that I'd rather we avoid.

So right now I'd like us to look at the problem from a "what is the best way to do this" perspective rather than a "how can we shoe-horn it into this arbitrary box we've created" perspective.  We have concerns about exposing the media path and physical processing aspects of IPP Printers, and we'd like to re-use our existing constraints mechanism if possible.  But we also have attribute filtering - the "printer-get-attributes-supported" Printer Description attribute lists which attributes influence the values returned by Get-Printer-Attributes and there are implementations that support "sides" for this already.  And we also have an existing, widely-implemented data model for printers and finishers (RFC 3805 and 3806) that could provide the information a Client needs but isn't all exposed via IPP yet.

The use case we want to support is a Client/User selecting a supported finishing process to be applied to the output from a Job.  This requires that the Printer be able to provide a list of supported finishing processes to the Client for the media used for the Job and/or a list of exceptions for specific combinations.

IMHO, the best solution to this problem will be one that does not unduly burden the Printer or Client while sticking to the spirit of the IPP intent-based model.  But this is one of those cases where I think we'll need to walk a fine line between the abstract/intent view and the physical/process view since hardware limitations are involved.  *And* I think we'll end up with a lot of implementation guidance in the specification WRT attribute fidelity/priority ("what is best effort for finishing processes?") and follow-me/release printing solutions.

> On May 25, 2016, at 9:22 AM, Ira McDonald <[email-masked]> wrote:
> 
> Hi,
> 
> info to IPP Clients about physical characteristics, but in the context of Job
> forwarding, Cloud/SDN print, etc. it's preferable to stick firmly to intent-based
> printing, IMO.
> 
> Cheers,
> - Ira
> 
> 
> On Wed, May 25, 2016 at 7:34 AM, Zehler, Peter <[email-masked]> wrote:
> Smith,

---

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Wed, 25 May 2016 19:52:47 +0000

Thanks to all of you for your input and guidance!  I will work on modeling the system using "job-constraints-supported" as well as with "finishings-col" additions in "finishings-col-ready" and "finishings-col-database", and we can walk through and compare them through the lens of preserving the integrity of the IPP "imaging model" as well as considering practical concerns for clients and printers.

More soon,
Smith

/**
    Smith Kennedy

> On 2016-05-25, at 8:11 AM, Michael Sweet <[email-masked]> wrote:
> 
> All,
>