[IPP] RFC: printer-finisher attribute

[IPP] RFC: printer-finisher attribute

[IPP] RFC: printer-finisher attribute

Ira McDonald blueroofmusic at gmail.com
Fri Jun 20 19:16:24 UTC 2014

Hi Mike,

Right - it's reasonable to defer the finisher details for now.

As you say, if there's a significant finisher detail that doesn't show up
"finishings-col", we should add it during our IPP WG final review.

- 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
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 Fri, Jun 20, 2014 at 3:09 PM, Michael Sweet <msweet at apple.com> wrote:

> Ira,
> On Jun 20, 2014, at 2:59 PM, Ira McDonald <blueroofmusic at gmail.com> wrote:
> Hi Mike,
> I like this "printer-finisher" proposal for exposing the Finisher MIB info.
> A few comments:
> (1) TYPO - Section 6.15.3 in title and second example says
> "printer-input-tray"
> Oops, will fix that on the next pass... :/
> (2) TECHNICAL - Section 16.5 should also reference finDeviceAttributeTable
> and later sections should reference a (flattened) "finisher-detail" member
> that
> is a simple key/value mapping for all defined finisher-specific
> attributes, e.g.,
> - general: deviceModel, finReferenceEdge, numberOfPositions, etc.
> - subunit types: stitching (staple,stitch,saddle,dual), folding, binding,
> etc.
> - subunit details for stitching and punching
> I'd actually like to defer these - the finishing intent attributes
> (finishings-supported, finishings-col-database/ready, etc.) already expose
> most of this information in a way that can be used by the Client.  The only
> information we didn't have a way to get via IPP was the capacity of the
> finisher subunits - how many sheets can be stapled, etc.
> Longer term (probably in System Control) we can expose things like
> deviceModel for use by management applications.  But anything regarding
> capabilities should already be exposed by the new finishings-col stuff (and
> if not then we should add it there and not using the octetString key/value
> syntax).
>  _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140620/3c946bc0/attachment.html>

More information about the ipp mailing list