attachment
<html><body 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 class=""><br class=""></div><div class="">I have to assume this circumstance, where one attribute lists the range of values that could be enabled by the admin for use by end users, vs. the range of values that are available to end users, will come up in other cases? If so, should we rather define what that new suffix is and align to that? What does the SM or System Control Service have to say about this, if anything?</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><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 class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><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 class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Smith<br class=""><br class="">/**<br class=""> Smith Kennedy<br class=""> Wireless Architect - Client Software - IPG-PPS<br class=""> Standards - PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum<br class=""> HP Inc.<br class="">*/<br class=""><br class=""><br class=""></div><br class=""><blockquote type="cite" class="">On 2015-09-21, at 2:59 PM, Michael Sweet <<a href="mailto:msweet@apple.com" class="">msweet@apple.com</a>> wrote:<br class=""><br class="">All,<br class=""><br class="">I have posted the minutes from today's IPP WG meeting to:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><a href="http://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-concall-minutes-20150921.pdf" class="">http://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-concall-minutes-20150921.pdf</a><br class=""><br class="">Our next conference call will be on October 5, 2015 at 3pm ET.<br class=""><br class="">_________________________________________________________<br class="">Michael Sweet, Senior Printing System Engineer, PWG Chair<br class=""><br class="">_______________________________________________<br class="">ipp mailing list<br class="">ipp@pwg.org<br class="">https://www.pwg.org/mailman/listinfo/ipp<br class=""></blockquote><br class=""></div></body></html>