I should say further that even though Apple's own "dns-sd" tool uses the "_TYPE._TRANSPORT,_SUBTYPE" notation (which derives from the notation used in the RFC), the "dig" tool only accepts the "_SUBTYPE._sub._TYPE._TRANSPORT" syntax, which matches what is sent over the wire. This works:
$ dig @224.0.0.251 -p 5353 _print._sub._ipp._tcp.local. PTR IN
This doesn't work:
$ dig @224.0.0.251 -p 5353 _ipp._tcp,_print.local. PTR IN
And the bottom line is that the B-1 and B-5.2 tests will fail on Ubuntu when they shouldn't.
> On Feb 14, 2020, at 12:32 PM, Kennedy, Smith (Wireless & IPP Standards) via ipp <ipp at pwg.org> wrote:
>> Signed PGP part
> Hi Mike,
>> I can file defects for this, but one quick bit of feedback with tests B-1 and B-5.2 (the browse tests)
>> These tests are failing for me on Linux, and the cause seems to be at least partly due to a syntax problem with how subtypes can be specified to the "ippfind" tool. The "ippfind" tool used to accept a DNS-SD subtype using the "_SUBTYPE._sub._TYPE._TRANSPORT" syntax instead of the "_TYPE._TRANSPORT,_SUBTYPE" notation that was used in the RFC but isn't used on the wire.
>> The "bonjour-tests.sh" test does B-1 like so:
>> > ${IPPFIND} --literal-name "${TARGET}" "_ipp._tcp,_print.local --quiet
>> which fails on Ubuntu Linux but works on macOS. IMHO this line should be phrased like so:
>> > ${IPPFIND} --literal-name "${TARGET}" "_print._sub._ipp._tcp.local --quiet
>> and our code should be updated to work using that syntax on all platforms. I am observing that this successfully finds my target HP TANGO (Ubuntu 18.04.4):
>> $ avahi-browse _print._sub._ipp._tcp
>> but this fails:
>> $ avahi-browse _ipp._tcp,_print
>> If I use the system provided /usr/bin/ippfind (which "ippfind --version" reports "CUPS v2.2.7") it works the way I expect it to work as described above but doesn't support "--literal-name".
>> Still testing...
>> Smith
>> /**
> Smith Kennedy
> HP Inc.
> */
>>> On Feb 4, 2020, at 5:05 PM, Michael Sweet via ipp <ipp at pwg.org <mailto:ipp at pwg.org>> wrote:
>>>> All,
>>>> I have posted a proposed update to the IPP Everywhere v1.0 Printer Self-Certification Tools to:
>>>>https://ftp.pwg.org/pub/pwg/ipp/wd/sw-ippeveselfcert10-20200204-macos.zip <https://ftp.pwg.org/pub/pwg/ipp/wd/sw-ippeveselfcert10-20200204-macos.zip>
>>https://ftp.pwg.org/pub/pwg/ipp/wd/sw-ippeveselfcert10-20200204-rhel.tar.gz <https://ftp.pwg.org/pub/pwg/ipp/wd/sw-ippeveselfcert10-20200204-rhel.tar.gz>
>>https://ftp.pwg.org/pub/pwg/ipp/wd/sw-ippeveselfcert10-20200204-ubuntu.tar.gz <https://ftp.pwg.org/pub/pwg/ipp/wd/sw-ippeveselfcert10-20200204-ubuntu.tar.gz>
>>https://ftp.pwg.org/pub/pwg/ipp/wd/sw-ippeveselfcert10-20200204-windows.msi <https://ftp.pwg.org/pub/pwg/ipp/wd/sw-ippeveselfcert10-20200204-windows.msi>
>>>> Instructions for using the new "ippevesubmit" program can be found here:
>>>>https://istopwg.github.io/ippeveselfcert <https://istopwg.github.io/ippeveselfcert>
>>>> These will be moved over to the main PWG web site when the update goes live.
>>>> Changes include:
>>>> - Issue #41: Windows IPP Everywhere Self Cert 1.0 Update 3: ipptool fails to
>> run - missing regex.dll
>> - Updated the Windows test scripts to look for PWG Raster files on the Desktop,
>> and to write the test results to the Desktop since the installation
>> directory is now write-protected on current versions of Windows.
>> - Updated libcups and the IPP tools to CUPS v2.2.13.
>>>> Note: All binaries are for 64-bit systems only.
>>>> Please provide feedback before February 27, 2020. I would like to post update 4 after the IPP workgroup conference call on that day.
>>>> ________________________
>> Michael Sweet
>>>>>>>> _______________________________________________
>> ipp mailing list
>>ipp at pwg.org <mailto:ipp at pwg.org>
>>https://www.pwg.org/mailman/listinfo/ipp <https://www.pwg.org/mailman/listinfo/ipp>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20200214/a2c10e2f/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/20200214/a2c10e2f/attachment.sig>