attachment
<div dir="ltr"><div><div><div><div><div><div><div>Hi Mike,<br><br></div>Thanks - I figured out your rationale after I sent that reply.<br><br></div>FYI - when I looked in my local copy of most recent IANA IPP Registry<br></div>updates today, *all* of the existing "xxx-attributes-supported" had an<br></div>infix of "type 2", so we need to globally check for and fix in the next<br></div>IANA update.<br><br></div>Cheers,<br></div>- Ira<br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">Ira McDonald (Musician / Software Architect)<br>Co-Chair - TCG Trusted Mobility Solutions WG<br>Chair - Linux Foundation Open Printing WG<br>Secretary - IEEE-ISTO Printer Working Group<br>Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG<br>IETF Designated Expert - IPP & Printer MIB<br>Blue Roof Music / High North Inc<br><a style="color:rgb(51,51,255)" href="http://sites.google.com/site/blueroofmusic" target="_blank">http://sites.google.com/site/blueroofmusic</a><br><a style="color:rgb(102,0,204)" href="http://sites.google.com/site/highnorthinc" target="_blank">http://sites.google.com/site/highnorthinc</a><br>mailto: <a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>Jan-April: 579 Park Place Saline, MI 48176 734-944-0094<br>May-Dec: PO Box 221 Grand Marais, MI 49839 906-494-2434<br><br><div style="display:inline"></div><div style="display:inline"></div><div style="display:inline"></div><div></div><div></div><div></div><div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Fri, Jun 16, 2017 at 4:10 PM, Michael Sweet <span dir="ltr"><<a href="mailto:msweet@apple.com" target="_blank">msweet@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ira,<br>
<br>
> On Jun 16, 2017, at 2:23 PM, Ira McDonald <<a href="mailto:blueroofmusic@gmail.com">blueroofmusic@gmail.com</a>> wrote:<br>
> ...<br>
<span class="">> - "printer-creation-attributes-<wbr>supported", "resource-settable-attributes-<wbr>supported", "system-mandatory-attributes-<wbr>supported", and "system-settable-attributes-<wbr>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).<br>
><br>
> ira - don't understand what you mean by "(no type2)" - do you mean the actual<br>
> type should be "1setOf type1 keyword" or that even type3 (deprecated) were<br>
> legal - in the IANA Registry, job-creation-attributes-<wbr>supported is has actual type<br>
> "1setOf type2 keyword" (i.e., an explicit type2) - is that one wrong?<br>
<br>
</span>No, just:<br>
<br>
printer-creation-attributes-<wbr>supported (1setOf keyword)<br>
resource-settable-attributes-<wbr>supported (1setOf keyword)<br>
etc.<br>
<br>
And yes the registry is wrong (I've actually fixed a few of them before, looks like I missed that one).<br>
<br>
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:<br>
<br>
job-foo-supported (1setOf type2 keyword)<br>
< any Job Template attribute ><br>
<br>
some have listed the names explicitly, and some list *both* - we haven't been consistent.<br>
<br>
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...<br>
<br>
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.<br>
<br>
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.<br>
<div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>___________________________<br>
Michael Sweet, Senior Printing System Engineer<br>
<br>
</div></div></blockquote></div><br></div>