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 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:
>> 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
>>> 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
> 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,
> - 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
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>>-------------- next part --------------
An HTML attachment was scrubbed...