> On May 18, 2020, at 9:10 AM, Kennedy, Smith (Wireless & IPP Standards) via ipp <ipp at pwg.org> wrote:
>>> On May 18, 2020, at 7:04 AM, Michael Sweet <msweet at msweet.org <mailto:msweet at msweet.org>> wrote:
>>>>> > 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.
>>>> 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.
>>>> 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...
>> I'll look into this - more soon.
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'.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20200521/fcac49e4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://www.pwg.org/pipermail/ipp/attachments/20200521/fcac49e4/attachment.sig>