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

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

Kennedy, Smith (Wireless & IPP Standards) smith.kennedy at hp.com
Wed Nov 11 13:44:21 UTC 2020


Hi Mike,

> On Nov 9, 2020, at 8:28 AM, Michael Sweet <msweet at msweet.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).

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

> 
>> 			• "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
> 
> 
> 

-------------- 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/20201111/da19cb89/attachment.sig>


More information about the ipp mailing list