Hi there,
A couple of questions about the changes we agreed that I should make to the "job-password-repertoire" whitepaper:
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:
Q: Do we need multiple values?
Original purpose was to tell client the 1 password format that is acceptable for job-password values
Important to convey capabilities (only have a numeric keypad)
Impossible to validate values when job-password is encrypted
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)
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.
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?
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!):
https://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xml
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...
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).
Smith
/**
Smith Kennedy
Wireless Architect - Client Software - IPG-PPS
Standards - PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum
HP Inc.
*/
> On 2015-09-21, at 2:59 PM, Michael Sweet <msweet at apple.com> wrote:
>> All,
>> I have posted the minutes from today's IPP WG meeting to:
>>http://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-concall-minutes-20150921.pdf>> Our next conference call will be on October 5, 2015 at 3pm ET.
>> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>> _______________________________________________
> 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/20151006/7c70a0cb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4956 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20151006/7c70a0cb/attachment.p7s>