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 <blueroofmusic at gmail.com> wrote:
>> 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: 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 Wed, May 25, 2016 at 7:34 AM, Zehler, Peter <Peter.Zehler at xerox.com> 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 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
> Email: Peter.Zehler at Xerox.com> Office: +1 (585) 265-8755
> Fax: +1 (585) 422-0238
> Mobile: +1 (585) 329-9508
>>> -----Original Message-----
> From: Kennedy, Smith (Wireless Architect) [mailto:smith.kennedy at hp.com]
> Sent: Tuesday, May 24, 2016 2:52 PM
> To: Zehler, Peter <Peter.Zehler at xerox.com>
> Cc: ipp at pwg.org> Subject: Re: [IPP] Slides to discuss Orientation and feed direction in Finishings 2.x posted
>> Hi Pete,
>> To your first point:
>> > 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
>>>> > On 2016-05-24, at 6:22 AM, Zehler, Peter <Peter.Zehler at xerox.com> wrote:
> >
> > 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: Peter.Zehler at Xerox.com> > Office: +1 (585) 265-8755
> > Fax: +1 (585) 422-0238
> > Mobile: +1 (585) 329-9508
> >
> > -----Original Message-----
> > From: ipp [mailto:ipp-bounces at pwg.org] On Behalf Of Kennedy, Smith (Wireless Architect)
> > Sent: Monday, May 23, 2016 3:14 PM
> > To: ipp at pwg.org> > Subject: Re: [IPP] Slides to discuss Orientation and feed direction in Finishings 2.x posted
> >
> > 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) <smith.kennedy at hp.com> wrote:
> >>
> >> 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) <smith.kennedy at hp.com> 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
> >>>
> >>
> >> <Finishings-2.1-Orientation-and-Feed-Orientation-Extensions-2016-05-17.pdf>_______________________________________________
> >> 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>> _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp
_________________________________________________________
Michael Sweet, Senior Printing System Engineer