attachment

<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class="">
<div><br class=""><blockquote type="cite" class=""><div class="">On May 18, 2020, at 9:10 AM, Kennedy, Smith (Wireless & IPP Standards) via ipp <<a href="mailto:ipp@pwg.org" class="">ipp@pwg.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="protected-part"><div class="protected-content"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="">On May 18, 2020, at 7:04 AM, Michael Sweet <<a href="mailto:msweet@msweet.org" class="">msweet@msweet.org</a>> wrote:</div><div class=""><div class=""><br class=""></div></div></blockquote></div><div class=""><blockquote type="cite" class=""><div class=""><div class="">
> 3. The current I-10.5 and I-10.6 are failing on my IPP Everywhere 1.0 certified printer. I'm wondering whether these tests ought to be enabled only if some DEFINE is defined ("PEDANTIC" / "WARNINGS" etc.). I know they should pass, but if that hasn't been exercised previously, that can cause some additional thrash. I don't want to lower the bar and remove those tests, but if there was some grace period, that might help teams who are trying to certify in the near term. I'm not sure what others think. Asking my firmware teams whether fixing that in pending devices' certifications will cause thrash.<br class="">
<br class="">
These tests (for requested-attributes='printer-description' and ='job-template') were added because the non-conformance to STD92 was causing problems with getting full IPP Everywhere support working in CUPS.<br class="">
<br class="">
I'd like to know what the failures were - too many attributes returned, too few?  Too many isn't a serious interoperability issue - might lead to some laziness on the Client side but testing will catch that - but too few prevents Clients from working which *is* a serious interoperability issue...<br class=""></div></div></blockquote><div class=""><br class=""></div></div>I'll look into this - more soon.</div></div></div></div></blockquote><br class=""></div><div>OK, so the "job-template" returns basically nothing other than "attributes-charset" and "attributes-natural-language", which seems too few. ðŸ˜ž It seems the firmware is equating 'job-template' with 'none' and 'printer-description' with 'all'.</div></body></html>