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

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

Ira McDonald blueroofmusic at gmail.com
Mon Nov 9 15:57:40 UTC 2020


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: blueroofmusic at gmail.com
<blueroofmusic at gmail.com>(permanent) PO Box 221  Grand Marais, MI 49839
906-494-2434*


On Mon, Nov 9, 2020 at 10:28 AM Michael Sweet via ipp <ipp at pwg.org> 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...
>
>
> On Nov 9, 2020, at 9:08 AM, Kennedy, Smith (Wireless & IPP Standards) via
> ipp <ipp at pwg.org> wrote:
> >
> > Signed PGP part
> > 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
>
> 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
> >
> > What does the next evolution of this look like? Any recommendations?
> Thanks for any input!
> >
> >
> > Smith
> >
> > /**
> >     Smith Kennedy
> >     HP Inc.
> > */
> >
> >
> >
>
> ________________________
> Michael Sweet
>
>
>
> _______________________________________________
> 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/20201109/66ecd779/attachment.html>


More information about the ipp mailing list