Hi Paul,
Guessing you meant does my account have the permissions to run it properly? If I "sudo" it the result is the same:
Serenity: Downloads [524]$ ippfind --literal-name "HP TANGO Ken Smith" _print._sub._ipp._tcp.local
ippfind: Unable to browse or resolve: Bad parameter.
Serenity: Downloads [525]$ ippfind --literal-name "HP TANGO Ken Smith" _ipp._tcp,_print.local
ipp://hp-tango-ken-smith.local:631/ipp/print
Serenity: Downloads [526]$ sudo !524
sudo ippfind --literal-name "HP TANGO Ken Smith" _print._sub._ipp._tcp.local
ippfind: Unable to browse or resolve: Bad parameter.
Serenity: Downloads [527]$
I'm pretty sure the problem is the parsing logic in "ippfind". And what I guess we are talking about is two different issues:
1) what syntax does "ippfind" accept as an option; and
2) how is that parsed and passed down to the system's DNS-SD implementation
Smith
/**
Smith Kennedy
HP Inc.
*/
> On Feb 14, 2020, at 1:43 PM, Paul Santangelo <paul.santangelo at kmbs.konicaminolta.us> wrote:
>> Rights issue?
>> Regards,
>>>> PAUL SANTANGELO, CCNA, CNE
> Escalation System Support (ESS) Integrator
> Konica Minolta Business Solutions U.S.A., Inc.
> 101 Williams Drive Ramsey, NJ 07446
> Office: <applewebdata://EE0DA800-39EB-4E6E-8802-1B2F46EDAE89> 800-825-5664 <tel:800-825-5664>
> Visit us: Count on Konica Minolta <http://www.countonkonicaminolta.com/>
> <http://www.facebook.com/konicaminoltaus> <http://www.twitter.com/konicaminoltaus> <https://plus.google.com/u/0/101069343240482341568/about> <http://www.linkedin.com/companies/4830> <http://www.youtube.com/user/konicaminoltaus> <http://www.pinterest.com/konicaminoltaus>
> Disclaimer <http://kmbs.konicaminolta.us/signature/KMBSUS-Disclaimer%20.png>
>>>> On 2/14/2020 3:42 PM, Kennedy, Smith (Wireless & IPP Standards) via ipp wrote:
>> Hi Chris,
>>>> I'm on Catalina and if I run "/usr/bin/ippfind --version" I get CUPS v2.3.0. Is that what you get? On mine it fails as well. But it shouldn't. And since it is our own tool, it is within our power to change it. The IPP Everywhere Self-Certification tools, though, it uses a local copy of ippfind (or should), and the parameters come from a script. So my point here is that I believe we ought to normalize the syntax that "ippfind" accepts, and IMHO we should normalize it on "_print._sub._ipp._tcp.local" instead of "_ipp._tcp,_print.local" because the former is what is on the wire, while the latter is just an oddity that came from a mistake made by those that both wrote the "dns-sd" tool and contributed to the RFCs.
>>>> Sanity check me here - am I off in the weeds?
>>>> Smith
>>>> /**
>> Smith Kennedy
>> HP Inc.
>> */
>>>>> On Feb 14, 2020, at 1:20 PM, Rizzo, Christopher <Christopher.Rizzo at xerox.com <mailto:Christopher.Rizzo at xerox.com>> wrote:
>>>>>>>>> Hmm... On the Mac (I'm currently at Mojave), the ippfind tool doesn't like _print._sub._ipp._tcp.local. There does not appear to be a problem with --literal-name parameter:
>>>>>>crizzo at ChrisMacBook15:~/OneDrive - Xerox/pwg/ipp-self-cert-v1.1-beta1[18] ./ippfind --literal-name "Xerox AltaLink C8035"
>>>ipp://XRX9C934E681461.local:631/ipp/print <ipp://XRX9C934E681461.local:631/ipp/print>
>>>crizzo at ChrisMacBook15:~/OneDrive - Xerox/pwg/ipp-self-cert-v1.1-beta1[19] ./ippfind --literal-name "Xerox AltaLink C8035" _ipp._tcp
>>>ipp://XRX9C934E681461.local:631/ipp/print <ipp://XRX9C934E681461.local:631/ipp/print>
>>>crizzo at ChrisMacBook15:~/OneDrive - Xerox/pwg/ipp-self-cert-v1.1-beta1[20] ./ippfind --literal-name "Xerox AltaLink C8035" _ipps._tcp
>>>ipps://XRX9C934E681461.local:443/ipp/print <ipps://XRX9C934E681461.local:443/ipp/print>
>>>crizzo at ChrisMacBook15:~/OneDrive - Xerox/pwg/ipp-self-cert-v1.1-beta1[21] ./ippfind --literal-name "Xerox AltaLink C8035" _print._sub._ipp._tcp
>>> ippfind: Unable to browse or resolve: Bad parameter.
>>>crizzo at ChrisMacBook15:~/OneDrive - Xerox/pwg/ipp-self-cert-v1.1-beta1[22] ./ippfind --literal-name "Xerox AltaLink C8035" _print._sub._ipp._tcp.local
>>> ippfind: Unable to browse or resolve: Bad parameter.
>>>crizzo at ChrisMacBook15:~/OneDrive - Xerox/pwg/ipp-self-cert-v1.1-beta1[23]
>>>crizzo at ChrisMacBook15:~/OneDrive - Xerox/pwg/ipp-self-cert-v1.1-beta1[23] ./ippfind --version
>>> IPPEVESELFCERT11 v20200211
>>>crizzo at ChrisMacBook15:~/OneDrive - Xerox/pwg/ipp-self-cert-v1.1-beta1[24]
>>>crizzo at ChrisMacBook15:~/OneDrive - Xerox/pwg/ipp-self-cert-v1.1-beta1[24] ippfind --literal-name "Xerox AltaLink C8035" _print._sub._ipp._tcp.local
>>> ippfind: Unable to browse or resolve: Bad parameter.
>>>crizzo at ChrisMacBook15:~/OneDrive - Xerox/pwg/ipp-self-cert-v1.1-beta1[25] ippfind --version
>>> CUPS v2.2.9
>>>crizzo at ChrisMacBook15:~/OneDrive - Xerox/pwg/ipp-self-cert-v1.1-beta1[26]
>>>>>> Chris
>>>>>> Christopher Rizzo
>>> Xerox Corporation
>>> GDG/Discovery/Advance Technology
>>> 26600 SW Parkway Ave.
>>> Wilsonville, OR 97070-9251
>>> Phone: (585) 314-6936
>>> Email: Christopher.Rizzo at xerox.com <mailto:Christopher.Rizzo at xerox.com>
>>>>>> "The realization came over me with full force that a good part of the remainder of my life was going to be spent in finding errors in my own programs."
>>> -Maurice Wilkes, Memoirs of a Computer Pioneer
>>>>>> From: ipp <ipp-bounces at pwg.org <mailto:ipp-bounces at pwg.org>> on behalf of PWG Workgroup <ipp at pwg.org <mailto:ipp at pwg.org>>
>>> Reply-To: "Kennedy, Smith (Wireless & IPP Standards)" <smith.kennedy at hp.com <mailto:smith.kennedy at hp.com>>
>>> Date: Friday, February 14, 2020 at 11:48 AM
>>> To: "Kennedy, Smith (Wireless & IPP Standards)" <smith.kennedy at hp.com <mailto:smith.kennedy at hp.com>>
>>> Cc: PWG Workgroup <ipp at pwg.org <mailto:ipp at pwg.org>>, PWG Self-Certification <ippeveselfcert at pwg.org <mailto:ippeveselfcert at pwg.org>>
>>> Subject: Re: [IPP] BETA: IPP Everywhere Printer Self-Certification Tools v1.0 Update 4
>>>>>> 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 <mailto: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>
>>>>>> _______________________________________________
>> 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/0bd58ad5/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/0bd58ad5/attachment.sig>
