attachment
<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Smith,<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 6, 2015, at 5:16 PM, Kennedy, Smith (Wireless Architect) <<a href="mailto:smith.kennedy@hp.com" class="">smith.kennedy@hp.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi there,<div class=""><br class=""></div><div class="">A couple of questions about the changes we agreed that I should make to the "job-password-repertoire" whitepaper:</div><div class=""><br class=""></div><div class="">1. There was this discussion of what to do about managing the set of possible values the device supports, vs. what the printer is configured to use:</div><div class=""><br class=""></div><div class=""><div class=""><ul class="MailOutline"><li class="">Q: Do we need multiple values?</li><ul class=""><li class="">Original purpose was to tell client the 1 password format that is acceptable for job-password values</li><li class="">Important to convey capabilities (only have a numeric keypad)</li><li class="">Impossible to validate values when job-password is encrypted</li><li class="">A: Want a separate job-password-repertoire-configured Printer attribute that specifies the repertoire to use at the client end, job-password-repertoire-supported Printer attributes lists all of the (currently) available repertoire (for use by admin to configure the -configured value)</li></ul></ul><div class=""><br class=""></div></div><div class="">My worry about this is that this seems to break the "xxx" / "xxx-default" / "xxx-supported" design pattern that has been used thus far, because with this what would have been "xxx-supported" is now called "xxx-configured", and then the "xxx-supported" becomes an attribute that is considered by a tool engaging with the Printer via, for instance, a System Control Service.</div></div></div></div></blockquote><div><br class=""></div>Not exactly. The consensus from the concall was to define two attributes:</div><div><br class=""></div><div> job-password-repertoire-configured (type2 keyword | name(MAX))</div><div><br class=""></div><div> The configured password repertoire that a client uses to limit and validate</div><div> the values entered into the print UI.</div><div><br class=""></div><div> job-password-repertoire-supported (1setOf (type2 keyword | name(MAX)))</div><div><br class=""></div><div> The list of printer-supported repertoire that can be configured by the</div><div> administrator in the job-password-repertoire-configured attribute.</div><div><br class=""></div><div>This is consistent with how we handle printer settings for other things like natural language support - see the generated-natural-language-supported and natural-language-configured attributes from RFC 2911.</div><div><br class=""></div><div>For printer/service settings (that are not part of the job ticket), the xxx-supported attribute lists the supported values while the xxx-configured attribute specifies the configured value.</div><div><br class=""></div><div>For job tickets/settings we use xxx-default attributes to fill in values for missing Job Template xxx attributes.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">2. The Section 5.1 recommendation that we use the IANA registry for "Hash Function Textual Names" seems woefully out-of-date (last updated in August of 2006!):</div><div class=""><br class=""></div><div class=""><a href="https://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xml" class="">https://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xml</a></div><div class=""><br class=""></div><div class="">I think it is pretty clear how the new values will be encoded, but wanted to point this out and see if there were any follow-up recommendations. There seem to be a bunch of RFCs that didn't register new strings with IANA...</div></div></div></div></blockquote><div><br class=""></div>I don't think a SHA-3 RFC has come through yet, and sometimes registrations do get missed during document review. Anyways, I'll be posting the registration template for the SHA-3 hashes to the IPP list today, which will take care of our needs...</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">3. Referencing NIST specs for deprecation recommendations - if someone can provide me with links to NIST deprecation recommendations, and to the SHA-2 specifications, I would appreciate it. I seem to be having issues finding anything but the SHA-3 specs (already referenced).</div></div></div></div></blockquote><div><br class=""></div>Ira?</div><div><br class=""></div><div class="">
<div class=""><span style="font-family: 'Andale Mono'; orphans: 2; widows: 2;" class="">_________________________________________________________</span><br class="" style="font-family: 'Andale Mono'; orphans: 2; widows: 2;"><span style="font-family: 'Andale Mono'; orphans: 2; widows: 2;" class="">Michael Sweet, Senior Printing System Engineer, PWG Chair</span></div>
</div>
<br class=""></div></body></html>