Thanks - I figured out your rationale after I sent that reply.
FYI - when I looked in my local copy of most recent IANA IPP Registry
updates today, *all* of the existing "xxx-attributes-supported" had an
infix of "type 2", so we need to globally check for and fix in the next
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
Jan-April: 579 Park Place Saline, MI 48176 734-944-0094
May-Dec: PO Box 221 Grand Marais, MI 49839 906-494-2434
On Fri, Jun 16, 2017 at 4:10 PM, Michael Sweet <msweet at apple.com> wrote:
>> > On Jun 16, 2017, at 2:23 PM, Ira McDonald <blueroofmusic at gmail.com>
> > ...
> > - "printer-creation-attributes-supported",
> "resource-settable-attributes-supported", "system-mandatory-attributes-supported",
> and "system-settable-attributes-supported" should all be "1setOf keyword"
> (no type2) since we don't register values for these kinds of keyword
> attributes (which refer to registered or vendor-extension attribute names).
> > ira - don't understand what you mean by "(no type2)" - do you mean the
> > type should be "1setOf type1 keyword" or that even type3 (deprecated)
> > legal - in the IANA Registry, job-creation-attributes-supported is has
> actual type
> > "1setOf type2 keyword" (i.e., an explicit type2) - is that one wrong?
>> No, just:
>> printer-creation-attributes-supported (1setOf keyword)
> resource-settable-attributes-supported (1setOf keyword)
>> And yes the registry is wrong (I've actually fixed a few of them before,
> looks like I missed that one).
>> The issue is that by marking it as "type1" or "type2" then we are signing
> up for maintaining a registry of values; in the past some have just used:
>> job-foo-supported (1setOf type2 keyword)
> < any Job Template attribute >
>> some have listed the names explicitly, and some list *both* - we haven't
> been consistent.
>> Because attribute and member names use the keyword syntax, and since these
> attributes list attribute or member names, they don't need explicit
> registration unless we want to include the attribute semantics ("list of
> Object Name attributes") in the registry...
>> My preference is to simplify the registry where possible, and in doing so
> I get to remove special-casing from the IPP-to-SM generator... :) Another
> bonus is that software the might validate the values of those attributes
> against the registry will continue to work in the presence of unregistered
> vendor values.
>> Alternately I'd like to normalize all of these attributes and their
> registrations so that a) we are consistent and b) the IPP-to-SM generator
> can generate something more useful.
> Michael Sweet, Senior Printing System Engineer
>>-------------- next part --------------
An HTML attachment was scrubbed...