Subject: [IPP] Moving "client-info-col" forward

From: "Kennedy, Smith \(Wireless & IPP Standards\) via ipp" <[email-masked]>
Date: Mon, 9 Nov 2020 14:08:32 +0000

Hi there,

I wanted to continue the discussion offline about the proposed "client-info-col" (currently named "client-info" in the 2020-10-29 draft of IPP Driverless Printing Extensions v2.0 (NODRIVER)) to see if we can evolve it more quickly to something stable.

Proposals (changes in red):
2020-10-29 IPP Driverless Printing Extensions v2.0 (NODRIVER)
"client-info" (1setOf collection)
"client-key" (type2 keyword) - REQUIRED
"client-name" (name(MAX)) - REQUIRED
"client-patches" (text(MAX) | 'no-value') - REQUIRED
"client-string-version" (text(MAX)) - REQUIRED
"client-version" (octetString(64) | 'no-value) - REQUIRED
2020-11-05 November 2020 F2F IPP WG Session
"client-info-col"
"client-key" (type2 keyword) - REQUIRED
"client-name" (name(MAX)) - RECOMMENDED
"client-patches" (text(MAX) | 'no-value') - RECOMMENDED
"client-string-version" (text(MAX)) - RECOMMENDED
"client-version" (octetString(64) | 'no-value) - REQUIRED
"client-coswid" (octetString(MAX)) - RECOMMENDED

What does the next evolution of this look like? Any recommendations? Thanks for any input!

Smith

/**
    Smith Kennedy
    HP Inc.
*/

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

---

From: Michael Sweet via ipp <[email-masked]>
Date: Mon, 9 Nov 2020 10:28:43 -0500

Smith,

I'm generally +1 on this.  Obviously we need to have a discussion of the privacy implications in the Security Considerations section.  And I'd like to make this RECOMMENDED or CONDITIONALLY REQUIRED to support (not the current REQUIRED) with an explicit mention that Clients MUST obtain explicit consent to send the information.  In short, it needs to be aligned with the work we've done in Job Accounting and Job Extensions 2.0.

A quick note below...

On Nov 9, 2020, at 9:08 AM, Kennedy, Smith (Wireless & IPP Standards) via ipp <[email-masked]> wrote:
> Signed PGP part
> 	• 2020-10-29 IPP Driverless Printing Extensions v2.0 (NODRIVER)
> 		• "client-info" (1setOf collection)
> 			• "client-key" (type2 keyword) - REQUIRED

> 			• "client-name" (name(MAX)) - REQUIRED
> 			• "client-patches" (text(MAX) | 'no-value') - REQUIRED
> 			• "client-string-version" (text(MAX)) - REQUIRED
> 			• "client-version" (octetString(64) | 'no-value) - REQUIRED
> 	• 2020-11-05 November 2020 F2F IPP WG Session
> 		• "client-info-col"
> 			• "client-key" (type2 keyword) - REQUIRED

I think we also need to explicitly allow non-registered reverse-DNS identifiers since that is what macOS/iOS bundle identifiers and Java class naming uses, with a note about that.  The goal should be to have a stable identifier that you don't have to do fuzzy matching on (like happens with User-Agent in the HTTP world).

> 			• "client-name" (name(MAX)) - RECOMMENDED
> 			• "client-patches" (text(MAX) | 'no-value') - RECOMMENDED
> 			• "client-string-version" (text(MAX)) - RECOMMENDED
> 			• "client-version" (octetString(64) | 'no-value) - REQUIRED
> 			• "client-coswid" (octetString(MAX)) - RECOMMENDED
> 

________________________
Michael Sweet

---

From: Ira McDonald via ipp <[email-masked]>
Date: Mon, 9 Nov 2020 10:57:40 -0500

Hi,

+1 to Smith's proposal w/ Mike's updates.  We need to carefully highlight
the privacy
considerations.

Cheers,
- Ira

*Ira McDonald (Musician / Software Architect)*

*Chair - SAE Trust Anchors and Authentication TF*
*Co-Chair - TCG Trusted Mobility Solutions WG*

*Co-Chair - TCG Metadata Access Protocol SG*

*Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer
Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF
Designated Expert - IPP & Printer MIBBlue Roof Music / High North
Inchttp://sites.google.com/site/blueroofmusic
<http://sites.google.com/site/blueroofmusic>http://sites.google.com/site/highnorthinc
<http://sites.google.com/site/highnorthinc>mailto: [email-masked]
<[email-masked]>(permanent) PO Box 221  Grand Marais, MI 49839
906-494-2434*

On Mon, Nov 9, 2020 at 10:28 AM Michael Sweet via ipp <[email-masked]> wrote:

> Smith,
>
> I'm generally +1 on this.  Obviously we need to have a discussion of the
> privacy implications in the Security Considerations section.  And I'd like
> to make this RECOMMENDED or CONDITIONALLY REQUIRED to support (not the
> current REQUIRED) with an explicit mention that Clients MUST obtain
> explicit consent to send the information.  In short, it needs to be aligned
> with the work we've done in Job Accounting and Job Extensions 2.0.
>
> A quick note below...
>
>
> > I wanted to continue the discussion offline about the proposed
> "client-info-col" (currently named "client-info" in the 2020-10-29 draft of
> IPP Driverless Printing Extensions v2.0 (NODRIVER)) to see if we can evolve
> it more quickly to something stable.
> >
> I think we also need to explicitly allow non-registered reverse-DNS
> identifiers since that is what macOS/iOS bundle identifiers and Java class
> naming uses, with a note about that.  The goal should be to have a stable
> identifier that you don't have to do fuzzy matching on (like happens with
> User-Agent in the HTTP world).
>

---

From: "Kennedy, Smith \(Wireless & IPP Standards\) via ipp" <[email-masked]>
Date: Wed, 11 Nov 2020 13:44:21 +0000

Hi Mike,

> On Nov 9, 2020, at 8:28 AM, Michael Sweet <[email-masked]> wrote:
> 
> Smith,
> 

No objections, but if so would that require a shift in the syntax definition to be (type2 keyword | name(MAX))?

---

From: Michael Sweet via ipp <[email-masked]>
Date: Wed, 11 Nov 2020 09:46:10 -0500

Smith,

> On Nov 11, 2020, at 8:44 AM, Kennedy, Smith (Wireless & IPP Standards) <[email-masked]> wrote:
>>> ...

No, it can stay as a type2 keyword.  Much like we do for the media keywords, this client-key member attribute can have registered values and (registered or unregistered) vendor values that follow a defined syntax.

The goal here is to have unique identifiers for different software components on the Clients.  On macOS and iOS those identifiers are reverse-DNS things like "com.apple.pages" and "org.mozilla.firefox".  Java has a similar convention, while Windows seems to use a keyword-friendly format of the form "[Vendor or Application].[Component].[Version]":

    https://docs.microsoft.com/en-us/windows/win32/shell/fa-progids

I really don't think we can expect Clients to do any useful mapping of application IDs, nor can we expect application developers to register their software with the PWG.  Rather, I think having an up-to-date registry for operating system names (and maybe major IPP clients like CUPS) along with a liberal syntax for (unregistered) application identifiers ("local_foo.bar.bla" with no version information) will be about the best we can expect Clients to support.

________________________
Michael Sweet