Hi Smith,
Bit or arcana,
In Printer MIB and many other IETF MIBs, enum '1' is 'other' and '2' is
'unknown',
so we avoid them for compatibility in IPP as a rule.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Co-Chair - TCG Metadata Access Protocol SG
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/blueroofmusichttp://sites.google.com/site/highnorthinc
mailto: blueroofmusic at gmail.com
PO Box 221 Grand Marais, MI 49839 906-494-2434
On Wed, Apr 17, 2019 at 9:41 PM Kennedy, Smith (Wireless & Standards
Architect) via ipp <ipp at pwg.org> wrote:
>>> On Apr 17, 2019, at 5:40 PM, Michael Sweet <msweet at msweet.org> wrote:
>> Some quick comments:
>> 1. The tooltip stuff in strings files should be a separate Best Practice.
> Yes it will be mostly boilerplate... :(
>>> OK. Can reference that from this doc.
>>> 2. print-color-mode-default: Drop
>>> I'm interpreting this to mean to remove it from this document, since it is
> already defined in 5100.13?
>>> 3. print-color-mode-supported: Should be print-color-mode
>>> I'm interpreting this to mean just relabel the sub-section to be
> "print-color-mode"?
>> FWIW, I've been struggling with a related stylistic concern. If one is
> defining an attribute, say that specifies a keyword type syntax, and there
> are standard keywords defined as well, should those standard keyword
> definitions be made in the "xxx-supported" or "xxx" subsection?
>>> 4. print-quality enum extensions: enums are not supposed to use values 1
> and 2... :(
>>> Hum - I always puzzled over that. Why is that? Whatever the reason, we
> need to capture the reason for that in our as-yet-to-be-started IPP Design
> Patterns document...
>> Maybe we could look at a "print-quality-col (collection)" attribute with
> more details? Or define a separate range (10-19?) representing 10
> different vendor-specific qualities?
>>> I'd probably tend toward the latter since that attribute is already widely
> supported, and I don't know what other fields a "print-quality-col" might
> provide. Let's see if others have thoughts on that.
>>>>> On Apr 17, 2019, at 2:10 PM, Kennedy, Smith (Wireless & Standards
> Architect) via ipp <ipp at pwg.org> wrote:
>> Greetings,
>> I just posted a first draft of a "IPP Custom Print Quality and Intent
> Extensions
> (CUSTOMPQI)" white paper that proposes some additions to IPP that relate
> to supporting print quality hint and settings additions.
>>>https://ftp.pwg.org/pub/pwg/ipp/whitepaper/white-hp-ipp-custompqi-20190412.pdf> <https://protect-us.mimecast.com/s/W969CG6xjxhMD2MKTK84n2?domain=ftp.pwg.org>
>>>https://ftp.pwg.org/pub/pwg/ipp/whitepaper/white-hp-ipp-custompqi-20190412.docx> <https://protect-us.mimecast.com/s/iQcRCJ6AmAhY6gY3hGy9KW?domain=ftp.pwg.org>
>>> We won't likely have time to review it at our April 2019 F2F in a session,
> but I encourage those at the F2F to take a look at it so we can discuss
> after hours, etc. if you have an interest in what it proposes.
>> Cheers,
> Smith
>> /**
> Smith Kennedy
> HP Inc.
> */
>> _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp> <https://protect-us.mimecast.com/s/CCdKCKrBnBFnXZnzc3PXr6?domain=pwg.org>
>>> _____________
> Michael Sweet
>>> _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20190418/f4fe2622/attachment.html>