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: 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>>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>>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>>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-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-windows.msi>>>>>>>> Instructions for using the new "ippevesubmit" program can be found
>>>> here:
>>>>>>>>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>>> _______________________________________________
> 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/20200214/00629784/attachment.html>
