Subject: [IPP] BETA: IPP Everywhere Printer Self-Certification Tools v1.0 Update 4

From: Michael Sweet via ipp <[email-masked]>
Date: Tue, 4 Feb 2020 19:05:23 -0500

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
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: "Kennedy, Smith \(Wireless & IPP Standards\) via ipp" <[email-masked]>
Date: Fri, 14 Feb 2020 19:32:49 +0000

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 <[email-masked]> wrote:
> 
> All,
> 
> 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>
> 
> https://istopwg.github.io/ippeveselfcert <https://istopwg.github.io/ippeveselfcert>
> 
> https://www.pwg.org/mailman/listinfo/ipp <https://www.pwg.org/mailman/listinfo/ipp>

---

From: "Kennedy, Smith \(Wireless & IPP Standards\) via ipp" <[email-masked]>
Date: Fri, 14 Feb 2020 19:46:32 +0000

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 <[email-masked]> wrote:
> 
> Signed PGP part
> Hi Mike,
> 
>> On Feb 4, 2020, at 5:05 PM, Michael Sweet via ipp <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> All,
>> 
>> [email-masked] <mailto:[email-masked]>

---

From: "Rizzo, Christopher via ipp" <[email-masked]>
Date: Fri, 14 Feb 2020 20:20:24 +0000

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@ChrisMacBook15:~/OneDrive - Xerox/pwg/ipp-self-cert-v1.1-beta1[18] ./ippfind --literal-name "Xerox AltaLink C8035"

ipp://XRX9C934E681461.local:631/ipp/print

crizzo@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@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@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@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@ChrisMacBook15:~/OneDrive - Xerox/pwg/ipp-self-cert-v1.1-beta1[23]

crizzo@ChrisMacBook15:~/OneDrive - Xerox/pwg/ipp-self-cert-v1.1-beta1[23] ./ippfind --version

IPPEVESELFCERT11 v20200211

crizzo@ChrisMacBook15:~/OneDrive - Xerox/pwg/ipp-self-cert-v1.1-beta1[24]

crizzo@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@ChrisMacBook15:~/OneDrive - Xerox/pwg/ipp-self-cert-v1.1-beta1[25] ippfind --version

CUPS v2.2.9

crizzo@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: [email-masked]

"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 <[email-masked]> on behalf of PWG Workgroup <[email-masked]>
Reply-To: "Kennedy, Smith (Wireless & IPP Standards)" <[email-masked]>
Date: Friday, February 14, 2020 at 11:48 AM
To: "Kennedy, Smith (Wireless & IPP Standards)" <[email-masked]>
Cc: PWG Workgroup <[email-masked]>, PWG Self-Certification <[email-masked]>
Subject: Re: [IPP] BETA: IPP Everywhere Printer Self-Certification Tools v1.0 Update 4

This doesn't work:

On Feb 14, 2020, at 12:32 PM, Kennedy, Smith (Wireless & IPP Standards) via ipp <[email-masked]<mailto:[email-masked]>> wrote:

Signed PGP part
Hi Mike,

but this fails:

Still testing...

Smith

/**
    Smith Kennedy
    HP Inc.
*/

On Feb 4, 2020, at 5:05 PM, Michael Sweet via ipp <[email-masked]<mailto:[email-masked]>> wrote:

All,

Changes include:

________________________
Michael Sweet

_______________________________________________
ipp mailing list
[email-masked]<mailto:[email-masked]>
https://www.pwg.org/mailman/listinfo/ipp

---

From: "Kennedy, Smith \(Wireless & IPP Standards\) via ipp" <[email-masked]>
Date: Fri, 14 Feb 2020 20:42:14 +0000

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 <[email-masked]> wrote:
> 
> 
> ipp://XRX9C934E681461.local:631/ipp/print <ipp://XRX9C934E681461.local:631/ipp/print>
> ipp://XRX9C934E681461.local:631/ipp/print <ipp://XRX9C934E681461.local:631/ipp/print>
> ipps://XRX9C934E681461.local:443/ipp/print <ipps://XRX9C934E681461.local:443/ipp/print>
> Email: [email-masked] <mailto:[email-masked]>
> 
>> On Feb 14, 2020, at 12:32 PM, Kennedy, Smith (Wireless & IPP Standards) via ipp <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Signed PGP part
>> Hi Mike,
>>

---

From: Paul Santangelo via ipp <[email-masked]>
Date: Fri, 14 Feb 2020 15:43:49 -0500

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.
>
>> On Feb 14, 2020, at 1:20 PM, Rizzo, Christopher 
>> <[email-masked] <mailto:[email-masked]>> 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@ChrisMacBook15:~/OneDrive - 
>> Xerox/pwg/ipp-self-cert-v1.1-beta1[18] ./ippfind --literal-name 
>> "Xerox AltaLink C8035"
>> crizzo@ChrisMacBook15:~/OneDrive - 
>> Xerox/pwg/ipp-self-cert-v1.1-beta1[19] ./ippfind --literal-name 
>> "Xerox AltaLink C8035" _ipp._tcp
>> crizzo@ChrisMacBook15:~/OneDrive - 
>> Xerox/pwg/ipp-self-cert-v1.1-beta1[20] ./ippfind --literal-name 
>> "Xerox AltaLink C8035" _ipps._tcp
>> crizzo@ChrisMacBook15:~/OneDrive - 
>> Xerox/pwg/ipp-self-cert-v1.1-beta1[21] ./ippfind --literal-name 
>> "Xerox AltaLink C8035" _print._sub._ipp._tcp
>> crizzo@ChrisMacBook15:~/OneDrive - 
>> Xerox/pwg/ipp-self-cert-v1.1-beta1[22] ./ippfind --literal-name 
>> "Xerox AltaLink C8035" _print._sub._ipp._tcp.local
>> crizzo@ChrisMacBook15:~/OneDrive - 
>> Xerox/pwg/ipp-self-cert-v1.1-beta1[23] ./ippfind --version
>> crizzo@ChrisMacBook15:~/OneDrive - 
>> Xerox/pwg/ipp-self-cert-v1.1-beta1[24] ippfind --literal-name "Xerox 
>> AltaLink C8035" _print._sub._ipp._tcp.local
>> crizzo@ChrisMacBook15:~/OneDrive - 
>> Xerox/pwg/ipp-self-cert-v1.1-beta1[25] ippfind --version
>> CUPS v2.2.9
>> Email:[email-masked] <mailto:[email-masked]>
>> "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 <[email-masked] <mailto:[email-masked]>> on 
>> behalf of PWG Workgroup <[email-masked] <mailto:[email-masked]>>
>> *Reply-To:*"Kennedy, Smith (Wireless & IPP Standards)" 
>> <[email-masked] <mailto:[email-masked]>>
>> *Date:*Friday, February 14, 2020 at 11:48 AM
>> *To:*"Kennedy, Smith (Wireless & IPP Standards)" 
>> <[email-masked] <mailto:[email-masked]>>
>> *Cc:*PWG Workgroup <[email-masked] <mailto:[email-masked]>>, PWG 
>> Self-Certification <[email-masked] 
>> <mailto:[email-masked]>>
>> *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:
>>> On Feb 14, 2020, at 12:32 PM, Kennedy, Smith (Wireless & IPP 
>>> Standards) via ipp <[email-masked] <mailto:[email-masked]>> wrote:
>>> Signed PGP part
>>> Hi Mike,
>>> 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.
>>> 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):
>>> 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.
>>> */
>>>
>>>
>>>> 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
>>>>
>>>>
>>>>

---

From: "Kennedy, Smith \(Wireless & IPP Standards\) via ipp" <[email-masked]>
Date: Fri, 14 Feb 2020 20:54:10 +0000

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 <[email-masked]> wrote:
> 
> Rights issue?
> 
> Regards,
> 
> 
> 
> PAUL SANTANGELO, CCNA, CNE
> Office: <applewebdata://EE0DA800-39EB-4E6E-8802-1B2F46EDAE89> 800-825-5664 <tel:800-825-5664>
>   <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,
>> 
>>> On Feb 14, 2020, at 1:20 PM, Rizzo, Christopher <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> 
>>> From: ipp <[email-masked] <mailto:[email-masked]>> on behalf of PWG Workgroup <[email-masked] <mailto:[email-masked]>>
>>> Reply-To: "Kennedy, Smith (Wireless & IPP Standards)" <[email-masked] <mailto:[email-masked]>>
>>> To: "Kennedy, Smith (Wireless & IPP Standards)" <[email-masked] <mailto:[email-masked]>>
>>> Cc: PWG Workgroup <[email-masked] <mailto:[email-masked]>>, PWG Self-Certification <[email-masked] <mailto:[email-masked]>>

---

From: "Rizzo, Christopher via ipp" <[email-masked]>
Date: Fri, 14 Feb 2020 21:01:13 +0000

Hi Smith,

Yes, the tests (dnssd-tests.sh in my case) use the local ./ippfind (they come with the IPP cert download).  Anyway, hopefully here is the info you are requesting

crizzo@ChrisMacBook15:~/OneDrive - Xerox/pwg/ipp-self-cert-v1.1-beta1[30] which ippfind

/usr/bin/ippfind

crizzo@ChrisMacBook15:~/OneDrive - Xerox/pwg/ipp-self-cert-v1.1-beta1[31] which ./ippfind

./ippfind

crizzo@ChrisMacBook15:~/OneDrive - Xerox/pwg/ipp-self-cert-v1.1-beta1[32] /usr/bin/ippfind --version

CUPS v2.2.9

crizzo@ChrisMacBook15:~/OneDrive - Xerox/pwg/ipp-self-cert-v1.1-beta1[33] ./ippfind --version

My system is running MacOS Mojave version 10.14.6.

I'm not a full on expert with DNSSD, so not sure that the device I'm testing will support _print._sub._ipp._tcp.local and if we should we're missing a requirement or aren't working correctly.  For example, this device is not discovered with the following and I'm am unsure as the the purpose of the ",_print.local" portion.  Guess I have some reading up to do:

crizzo@ChrisMacBook15:~/OneDrive - Xerox/pwg/ipp-self-cert-v1.1-beta1[39] ./ippfind --literal-name "Xerox AltaLink C8035" _ipp._tcp,_print.local

crizzo@ChrisMacBook15:~/OneDrive - Xerox/pwg/ipp-self-cert-v1.1-beta1[40]

It just doesn't apparently like _print.local

Also ./ippfind hangs with the following (after the 1st discovered entry):

crizzo@ChrisMacBook15:~/OneDrive - Xerox/pwg/ipp-self-cert-v1.1-beta1[38] ./ippfind "Xerox AltaLink C8035" _sub._ipp._tcp

And ./ippfind doesn't like this:

crizzo@ChrisMacBook15:~/OneDrive - Xerox/pwg/ipp-self-cert-v1.1-beta1[40] ./ippfind --literal-name "Xerox AltaLink C8035" _print._sub._ipp._tcp.local

crizzo@ChrisMacBook15:~/OneDrive - Xerox/pwg/ipp-self-cert-v1.1-beta1[41]

Chris

Christopher Rizzo
Xerox Corporation

From: "Kennedy, Smith (Wireless & IPP Standards)" <[email-masked]>
Date: Friday, February 14, 2020 at 12:42 PM
To: Christopher Rizzo <[email-masked]>
Cc: PWG Workgroup <[email-masked]>, PWG Self-Certification <[email-masked]>
Subject: Re: [IPP] BETA: IPP Everywhere Printer Self-Certification Tools v1.0 Update 4

Hi Chris,

Smith

/**
    Smith Kennedy
    HP Inc.
*/

On Feb 14, 2020, at 1:20 PM, Rizzo, Christopher <[email-masked]<mailto:[email-masked]>> wrote:

Chris

Christopher Rizzo
Xerox Corporation
GDG/Discovery/Advance Technology
26600 SW Parkway Ave.
Wilsonville, OR 97070-9251
Phone: (585) 314-6936
Email: [email-masked]<mailto:[email-masked]>

From: ipp <[email-masked]<mailto:[email-masked]>> on behalf of PWG Workgroup <[email-masked]<mailto:[email-masked]>>
Reply-To: "Kennedy, Smith (Wireless & IPP Standards)" <[email-masked]<mailto:[email-masked]>>
Date: Friday, February 14, 2020 at 11:48 AM
To: "Kennedy, Smith (Wireless & IPP Standards)" <[email-masked]<mailto:[email-masked]>>
Cc: PWG Workgroup <[email-masked]<mailto:[email-masked]>>, PWG Self-Certification <[email-masked]<mailto:[email-masked]>>
Subject: Re: [IPP] BETA: IPP Everywhere Printer Self-Certification Tools v1.0 Update 4

This doesn't work:

Signed PGP part
Hi Mike,

but this fails:

Still testing...

Smith

/**
    Smith Kennedy
    HP Inc.
*/

All,

Changes include:

________________________
Michael Sweet