Subject: [IPP] RFC: Add "printer-serial-number (text(255))" to NODRIVER

From: Michael Sweet via ipp <[email-masked]>
Date: Tue, 1 Dec 2020 08:47:40 -0500

All,

I was looking for a place to report a printer's hardware serial number and noticed that we never defined one for an IPP Printer object, just the System object (where it is OPTIONAL).

I propose we add this to NODRIVER.  Based on the text in the IPP System Service specification this would look something like the following:

6.7.N printer-serial-number (text(255))

This RECOMMENDED attribute provides the serial number for the Printer and is semantically equivalent to the prtGeneralSerialNumber element defined in [RFC3805].

I'm proposing this as RECOMMENDED since a) why define it if we don't want it implemented, and b) because not every Printer is backed by a hardware output device and so won't necessarily have a serial number to report.

This sort of information is commonly available via printer drivers/utilities (for support purposes) and so it fits with the focus of NODRIVER.

Thoughts?

________________________
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: Tue, 1 Dec 2020 13:59:14 +0000

Hi Mike,

No objections to adding this but a few thoughts:

- PII concerns?
- Overlap with the key/value pairs provided by "printer-device-id" - the "SN" key isn't standardized but is out there...

Smith

/**
    Smith Kennedy
    HP Inc.
*/

> On Dec 1, 2020, at 6:47 AM, Michael Sweet via ipp <[email-masked]> wrote:
> 
> Signed PGP part
> All,
>

---

From: Ira McDonald via ipp <[email-masked]>
Date: Tue, 1 Dec 2020 09:01:23 -0500

Hi Mike,

+1

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 Tue, Dec 1, 2020 at 8:48 AM Michael Sweet via ipp <[email-masked]> wrote:

> All,
>
> I was looking for a place to report a printer's hardware serial number and
> noticed that we never defined one for an IPP Printer object, just the
> System object (where it is OPTIONAL).
>
> I propose we add this to NODRIVER.  Based on the text in the IPP System
> Service specification this would look something like the following:
>
> This RECOMMENDED attribute provides the serial number for the Printer and
> is semantically equivalent to the prtGeneralSerialNumber element defined
> in [RFC3805].
>
>
> I'm proposing this as RECOMMENDED since a) why define it if we don't want
> it implemented, and b) because not every Printer is backed by a hardware
> output device and so won't necessarily have a serial number to report.
>
> This sort of information is commonly available via printer
> drivers/utilities (for support purposes) and so it fits with the focus of
> NODRIVER.
>
> Thoughts?
>
> ________________________
> Michael Sweet
>
>
>

---

From: Michael Sweet via ipp <[email-masked]>
Date: Tue, 1 Dec 2020 10:30:06 -0500

Smith,

> On Dec 1, 2020, at 8:59 AM, Kennedy, Smith (Wireless & IPP Standards) <[email-masked]> wrote:
> 
> Hi Mike,
> 

Not directly - this identifies the printer, not an individual.  If the value was propagated outside of IPP with other personal information it might be used to identify someone ("Mike" printed to a printer with serial number 12345678, it must be Mike Sweet and not Mike Jones). But this is purely informational from the Printer to the Client, for maintenance/support purposes.

> - Overlap with the key/value pairs provided by "printer-device-id" - the "SN" key isn't standardized but is out there...

Last time I checked (but I no longer have a copy...) IEEE-1284 defines SERIALNUMBER (official abbreviation SN, also SER and SERN in the wild) to hold this.  But "printer-device-id" isn't something we want in the long term (only needed for drivers) and implementation of the serial number in the device ID is spotty at best...

________________________
Michael Sweet

---

From: Ira McDonald via ipp <[email-masked]>
Date: Tue, 1 Dec 2020 11:44:54 -0500

Hi,

Although IEEE 1284 Device ID does allow a keyword for a serial number,
the PWG 5107.2-2010 standard ABNF does NOT allow serial number in a
conformant Device ID string.

May be in the wild, but not something relevant for IPP interoperability.

Cheers,
- Ira

On Tue, Dec 1, 2020 at 10:30 AM Michael Sweet via ipp <[email-masked]> wrote:

> Not directly - this identifies the printer, not an individual.  If the
> value was propagated outside of IPP with other personal information it
> might be used to identify someone ("Mike" printed to a printer with serial
> number 12345678, it must be Mike Sweet and not Mike Jones). But this is
> purely informational from the Printer to the Client, for
> maintenance/support purposes.
>
> > - Overlap with the key/value pairs provided by "printer-device-id" - the
> "SN" key isn't standardized but is out there...
>
> Last time I checked (but I no longer have a copy...) IEEE-1284 defines
> SERIALNUMBER (official abbreviation SN, also SER and SERN in the wild) to
> hold this.  But "printer-device-id" isn't something we want in the long
> term (only needed for drivers) and implementation of the serial number in
> the device ID is spotty at best...
>
> ________________________
> Michael Sweet
>
>
>

---

From: Michael Sweet via ipp <[email-masked]>
Date: Tue, 1 Dec 2020 12:05:23 -0500

Ira,

I don't see any mention of SERIALNUMBER or SN in 5107.2 - I thought that just standardized the COMMAND SET or CMD values in the device ID?!?

> On Dec 1, 2020, at 11:44 AM, Ira McDonald <[email-masked]> wrote:
> 
> Hi,
> 
> 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 WG
> Secretary - IEEE-ISTO Printer Working Group
> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music / High North Inc
> http://sites.google.com/site/blueroofmusic
> http://sites.google.com/site/highnorthinc
> mailto: [email-masked]
> (permanent) PO Box 221  Grand Marais, MI 49839  906-494-2434
> 
> 

________________________
Michael Sweet

---

From: Ira McDonald via ipp <[email-masked]>
Date: Tue, 1 Dec 2020 12:13:06 -0500

Hi Mike,

Right.  5107.2, in order to preserve space for the important info
(interpreters
and MIME types), does NOT allow other keywords in a conformant string
(except for vendor proprietary ones on the right hand end of the string).

Of course, we're deprecating IEEE 1284 Device ID entirely in IPP, so this is
not the right place to hide serial number info.

Cheers,
- Ira

On Tue, Dec 1, 2020 at 12:05 PM Michael Sweet <[email-masked]> wrote:

> Ira,
>
> I don't see any mention of SERIALNUMBER or SN in 5107.2 - I thought that
> just standardized the COMMAND SET or CMD values in the device ID?!?
>
>
> > > - Overlap with the key/value pairs provided by "printer-device-id" -
> the "SN" key isn't standardized but is out there...
> >

---

From: "Kennedy, Smith \(Wireless & IPP Standards\) via ipp" <[email-masked]>
Date: Tue, 1 Dec 2020 19:06:24 +0000

Hi there,

Going to return to the "main thread" ("printer-serial-number") in a second reply. But on the subject of "printer-device-id"...

> On Dec 1, 2020, at 10:13 AM, Ira McDonald <[email-masked]> wrote:
> 
> Hi Mike,
> 
> Right.  5107.2, in order to preserve space for the important info (interpreters

We all seem to agree that the scope of 5107.2 is limited to the values specified for the "COMMAND SET" or "CMD" Device ID capability key, It makes no assertions about any of the other capability keys, whether standard ("MFG" / "MANUFACTURER", "MDL" / "MODEL") or otherwise.

The "SN" is a separate capability key e.g. "MFG:PWG;MDL:Fake Printer;CMD:image/pwg-raster;SN:12345678;"

I think the PWG's perspective ought to be that vendors SHOULD NOT put PII in this or any IPP attributes that don't require authentication. Our "IPP Privacy Attributes v1.0 (PRIVACY)" doesn't seem to look at PII in the Printer itself, more of a focus on Job and Document PII?

> not the right place to hide serial number info.

The IANA IPP Registry doesn't show it to be deprecated currently. I don't have any objections to deprecating it, but I am aware of some driver systems that are using IPP as a replacement for SNMP, but they still depend on 1284 Device ID for driver matching, and taking this away from them would cause them to look elsewhere. Then again, we are deprecating, not obsoleting, so it is still "around".

> http://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] <mailto:[email-masked]>
> On Tue, Dec 1, 2020 at 12:05 PM Michael Sweet <[email-masked] <mailto:[email-masked]>> wrote:
> Ira,
> 
> > On Dec 1, 2020, at 11:44 AM, Ira McDonald <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > Hi,
> >
> > http://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] <mailto:[email-masked]>
> > On Tue, Dec 1, 2020 at 10:30 AM Michael Sweet via ipp <[email-masked] <mailto:[email-masked]>> wrote:
> > Smith,
> >
> > > On Dec 1, 2020, at 8:59 AM, Kennedy, Smith (Wireless & IPP Standards) <[email-masked] <mailto:[email-masked]>> wrote:
> > >
> > > Hi Mike,
> > >
> > [email-masked] <mailto:[email-masked]>
> > https://www.pwg.org/mailman/listinfo/ipp <https://www.pwg.org/mailman/listinfo/ipp>
> 
> ________________________
> Michael Sweet
> 
> 
>

---

From: Ira McDonald via ipp <[email-masked]>
Date: Tue, 1 Dec 2020 14:44:48 -0500

Hi Smith,

The PWG Port Monitor MIB (PWG 5701.1-2004), co-written by Mike Fenelon
(Microsoft)
and developed at the the request of Microsoft, defines:

ppmPrinterIEEE1284DeviceId OBJECT-TYPE
    SYNTAX      OCTET STRING (SIZE (0..1023))
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "The IEEE 1284 device ID for this printer, a set of capabilities
        (keys and values) specified in the US-ASCII charset and the
        format 'key1: value {, value }; ... keyN: value {,value };',
        as follows:

        (a) SPACE (0x20), TAB (0x09), VTAB (0x0B), CR (0x0D), NL (0x0A),
            and FF (0x0C) are allowed, but are ignored when parsing
        (b) other control characters (less than 0x20) MUST NOT be used
        (c) COLON (0x3A), COMMA (0x2C), and SEMICOLON (0x3B) are used as
            delimiters and MUST NOT be included in any key or value
        (d) each key MUST be separated from value(s) using COLON (0x3A)
        (e) multiple values MUST BE separated using COMMA (0x2C)
        (f) each capability MUST BE terminated using SEMICOLON (0x3B)
        (g) all printers MUST include the following capabilities
            - MANUFACTURER (or abbreviation MFG)
            - MODEL (or abbreviation MDL)
        (h) all printers MAY include the following capabilities
            - COMMAND SET (or abbreviation CMD)
            - COMMENT
            - ACTIVE COMMAND SET

        For example (actually all on one line of text):

            MANUFACTURER:ACME Manufacturing;
            COMMAND SET:PCL,PJL,PS,XHTML-Print+xml;
            MODEL:LaserBeam 9;
            COMMENT:Anything you like;
            ACTIVE COMMAND SET:PCL;

        The value of this object MUST exactly match the IEEE 1284-2000
        Device ID string, except that the length field MUST NOT be
        specified.  The value MUST be assigned by the Printer vendor
        and MUST NOT be localized by the Print Service.

        Compatibility Note:  At the time of publication of this MIB,
        IEEE device IDs are restricted to US-ASCII.  In order to support
        possible future evolution of IEEE device IDs (in a successor to
        IEEE 1284-2000) to allow non-ASCII characters, this object has
        been defined with a syntax of OCTET STRING to support the future
        use of UTF-8 (RFC 3629).

        If this object is empty, then the value of 'ppmPortProtocolType'
        for the selected port SHOULD be used to load a generic driver."
    REFERENCE
        "Section 7.6 of IEEE 1284-2000.
        printer-make-and-model in IPP/1.1 (RFC 2911)."
    DEFVAL      { ''H }                 -- no IEEE 1284 device ID
    ::= { ppmPrinterEntry 3 }

Note the required keywords and allowed keywords.  Serial number was
intentionally not
included.

Cheers,
- Ira

On Tue, Dec 1, 2020 at 2:06 PM Kennedy, Smith (Wireless & IPP Standards) <
[email-masked]> wrote:

> Hi there,
>
> Going to return to the "main thread" ("printer-serial-number") in a second
> reply. But on the subject of "printer-device-id"...
>
> We all seem to agree that the scope of 5107.2 is limited to the values
> specified for the "COMMAND SET" or "CMD" Device ID capability key, It makes
> no assertions about any of the other capability keys, whether standard
> ("MFG" / "MANUFACTURER", "MDL" / "MODEL") or otherwise.
>
> The "SN" is a separate capability key e.g. "MFG:PWG;MDL:Fake
> Printer;CMD:image/pwg-raster;SN:12345678;"
>
> I think the PWG's perspective ought to be that vendors SHOULD NOT put PII
> in this or any IPP attributes that don't require authentication. Our "IPP
> Privacy Attributes v1.0 (PRIVACY)" doesn't seem to look at PII in the
> Printer itself, more of a focus on Job and Document PII?
>
>
> The IANA IPP Registry doesn't show it to be deprecated currently. I don't
> have any objections to deprecating it, but I am aware of some driver
> systems that are using IPP as a replacement for SNMP, but they still depend
> on 1284 Device ID for driver matching, and taking this away from them would
> cause them to look elsewhere. Then again, we are deprecating, not
> obsoleting, so it is still "around".
>
>
> Cheers,
> - Ira

---

From: "Kennedy, Smith \(Wireless & IPP Standards\) via ipp" <[email-masked]>
Date: Tue, 1 Dec 2020 20:40:01 +0000

Hi Ira,

My reading of that OID definition is that including other capability keys is in a gray area - they are not explicitly disallowed but they are not explicitly allowed either. It would need to have a new clause that says something like "(i) all Printers MUST NOT include capabilities other than those listed in (g) and (h)".

Smith

> On Dec 1, 2020, at 12:44 PM, Ira McDonald <[email-masked]> wrote:
> 
> Hi Smith,
> 
> The PWG Port Monitor MIB (PWG 5701.1-2004), co-written by Mike Fenelon (Microsoft)
> Note the required keywords and allowed keywords.  Serial number was intentionally not
> included.
> 
> Cheers,
> - Ira
> 
> On Tue, Dec 1, 2020 at 2:06 PM Kennedy, Smith (Wireless & IPP Standards) <[email-masked] <mailto:[email-masked]>> wrote:
> Hi there,
> 
>> On Dec 1, 2020, at 10:13 AM, Ira McDonald <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Mike,
>>

---

From: "Kennedy, Smith \(Wireless & IPP Standards\) via ipp" <[email-masked]>
Date: Tue, 1 Dec 2020 21:59:23 +0000

Hi Mike,

Bringing this back to your proposal...

> On Dec 1, 2020, at 8:30 AM, Michael Sweet <[email-masked]> wrote:
> 
> Smith,
> 

Our concern is that the serial number could be used to identify the owner via a warranty call etc.

The IPP Privacy Attributes v1.0 doesn't define a "printer-privacy-attributes (1setOf type2 keyword)" or "printer-privacy-scope (type2 keyword)" so we don't have a way to indicate to a Client that "printer-serial-number" might not be available other than via an authenticated Get-Printer-Attributes etc.

Considering this, I almost wonder if we need to talk again about why an unauthenticated Get-Printer-Attributes is required to expose all Printer Description attributes. I remember us discussing the justification was to preserve backward compatibility. But surely some Printer management attributes should only be visible to the "Owner" or "Operator", and that identity should be authenticated?

Sorry, not trying to open up too many cans of worms here...we can discuss in person on Thursday?

---

From: Michael Sweet via ipp <[email-masked]>
Date: Tue, 1 Dec 2020 18:17:47 -0500

Smith,

> On Dec 1, 2020, at 2:06 PM, Kennedy, Smith (Wireless & IPP Standards) <[email-masked]> wrote:
> ...

The focus of IPP Privacy Attributes v1.0 is definitely on Job and Document attributes since those are supplied by the Client on behalf of the End User, and are processed by the Printer. From a protocol and processing standpoint, Printer data isn't considered PII because the service is configured to be available on the network, and things like Get-Printer-Attributes are available to anyone that can reach the Printer.

From a Client print spooler perspective, however, Printer information can be PII and in my former life as an Apple engineer I did a lot to limit the amount of information that got logged or stored by default by both cupsd on macOS and printd on iOS.

Saying anything about Client "processing" of Printer data would certainly be new ground for IPP...

> The IANA IPP Registry doesn't show it to be deprecated currently. I don't have any objections to deprecating it, but I am aware of some driver systems that are using IPP as a replacement for SNMP,…

We dropped printer-device-id from IPP Everywhere.  Whether we deprecate the attribute is something we can talk about, but as you say there *is* a purpose for legacy printers/printer drivers.

________________________
Michael Sweet

---

From: Michael Sweet via ipp <[email-masked]>
Date: Tue, 1 Dec 2020 18:32:16 -0500

Ira,

The wording below does not exclude all other keys - (g) is MUST include, (h) is MAY include, but there is no (i) MUST NOT include.  My experience is that printers report the same device ID over USB, IPP, SNMP, etc. and that often includes the serial number along with a lot of other stuff not mentioned in (g) or (h).

> On Dec 1, 2020, at 2:44 PM, Ira McDonald <[email-masked]> wrote:
> 
> Hi Smith,
> 
> On Tue, Dec 1, 2020 at 2:06 PM Kennedy, Smith (Wireless & IPP Standards) <[email-masked]> wrote:
> Hi there,
> 

________________________
Michael Sweet

---

From: Ira McDonald via ipp <[email-masked]>
Date: Tue, 1 Dec 2020 22:21:43 -0500

Hi Smith,

I agree that it could have been explicit about the MUST NOT.

But revising the Port Monitor MIB is way low on my priorities list.

Cheers,
- Ira

On Tue, Dec 1, 2020 at 3:40 PM Kennedy, Smith (Wireless & IPP Standards) <
[email-masked]> wrote:

> Hi Ira,
>
> My reading of that OID definition is that including other capability keys
> is in a gray area - they are not explicitly disallowed but they are not
> explicitly allowed either. It would need to have a new clause that says
> something like "(i) all Printers MUST NOT include capabilities other than
> those listed in (g) and (h)".
>
> Smith
>
>
>
>> Going to return to the "main thread" ("printer-serial-number") in a
>> second reply. But on the subject of "printer-device-id"...
>>

---

From: Ira McDonald via ipp <[email-masked]>
Date: Tue, 1 Dec 2020 22:24:32 -0500

Hi Mike,

Thanks.

So we wouldn't want to revise Port Monitor MIB to add a MUST NOT anyway.
Good.

Cheers,
- Ira

On Tue, Dec 1, 2020 at 6:32 PM Michael Sweet <[email-masked]> wrote:

> Ira,
>
> The wording below does not exclude all other keys - (g) is MUST include,
> (h) is MAY include, but there is no (i) MUST NOT include.  My experience is
> that printers report the same device ID over USB, IPP, SNMP, etc. and that
> often includes the serial number along with a lot of other stuff not
> mentioned in (g) or (h).
>
>
> > I think the PWG's perspective ought to be that vendors SHOULD NOT put
> PII in this or any IPP attributes that don't require authentication. Our
> "IPP Privacy Attributes v1.0 (PRIVACY)" doesn't seem to look at PII in the
> > The IANA IPP Registry doesn't show it to be deprecated currently. I
> don't have any objections to deprecating it, but I am aware of some driver
> >> I don't see any mention of SERIALNUMBER or SN in 5107.2 - I thought
> that just standardized the COMMAND SET or CMD values in the device ID?!?
> >>
> >>
> >> > Not directly - this identifies the printer, not an individual.  If
> the value was propagated outside of IPP with other personal information it
> >> > > - Overlap with the key/value pairs provided by "printer-device-id"
> - the "SN" key isn't standardized but is out there...
> >> >
> >> > Last time I checked (but I no longer have a copy...) IEEE-1284
> defines SERIALNUMBER (official abbreviation SN, also SER and SERN in the
> wild) to hold this.  But "printer-device-id" isn't something we want in the
> long term (only needed for drivers) and implementation of the serial number
> in the device ID is spotty at best...
> >> >
> >> > ________________________
> >> > Michael Sweet
> >> >
> >> >
> >> >

---

From: Michael Sweet via ipp <[email-masked]>
Date: Tue, 1 Dec 2020 23:19:58 -0500

Smith,

> On Dec 1, 2020, at 4:59 PM, Kennedy, Smith (Wireless & IPP Standards) <[email-masked]> wrote:
> ...

So, that *is* one of the use cases for having this information - the serial number is usually associated with a warranty registration of a product.  And per the definition of prtGeneralSerialNumber, it might also be reset to another site-specific identifier, e.g., enterprise property barcodes, etc.  (Note: the system-serial-number is read-only but the MIB element is read-write, so I think both system-serial-number and printer-serial-number should be potentially read-write...)

Anyways, a printer has a serial number (like all technology products) whether we report it in an attribute or not.  If (and this is a big if) we want to put conformance requirements on Clients, we can require (or recommend) that Clients only display these values for the user but not transmit the values to third parties, noting the opportunities for abuse.

That said, we already have a far more potent identification attribute - printer-uuid - which is widely implemented (close to 100% of all network printers), unique across vendors and product lines (where serial number might not be), and unchangeable.  But I've not heard of any abuse of this information...  Also, printer-uuid is exposed in the DNS-SD TXT record and is used for some basic man-in-the-middle protection (along with X.509 cert validation).

I will also note the default hostname of a printer typically is a vendor prefix followed by the last 3 bytes of the (unique) MAC address - also very useful as a unique identifier!  And then there are those pesky printer URIs we use...

> The IPP Privacy Attributes v1.0 doesn't define a "printer-privacy-attributes (1setOf type2 keyword)" or "printer-privacy-scope (type2 keyword)" so we don't have a way to indicate to a Client that "…

There is no such thing as an authenticated Get-Printer-Attributes request, and as we've discussed previously we can't retroactively change that without breaking billions of IPP Clients and all printing in the process.

We have Get-User-Printer-Attributes for the authenticated query operation, but the purpose there is for policy support and not privacy, and I honestly don't think it would be a good fit for querying private/sensitive attributes.

I'm not sure whether we need printer-privacy-xxx attributes - most of the printer description attributes can be used to uniquely identify a printer (that's the whole purpose, after all :) so I think the focus needs to be on best privacy practices for Clients and what Clients do with the information.

> Considering this, I almost wonder if we need to talk again about why an unauthenticated Get-Printer-Attributes is required to expose all Printer Description attributes.

*Because that is the definition in STD 92*.  IPP was never designed as a minimum exposure protocol.  We expose attributes and values that are necessary to use, monitor, and support a network printer, and we expect that the local site will, if necessary, configure the printer to limit access to specific clients or users, change values that are reported, etc. as appropriate.

> I remember us discussing the justification was to preserve backward compatibility. But surely some Printer management attributes should only be visible to the "Owner" or "Operator", and that identity should be authenticated?

What, if any, existing management attributes are you thinking of?  Don't forget that everything in IPP is also typically exposed via SNMP with no password, "public" community name, etc., including my proposed printer-serial-number attribute.

> Sorry, not trying to open up too many cans of worms here...we can discuss in person on Thursday?

Yes, of course.

________________________
Michael Sweet

---

From: Michael Sweet via ipp <[email-masked]>
Date: Thu, 3 Dec 2020 16:32:00 -0500

All,

So after discussion during today's IPP workgroup conference call, we decided to:

- Add "printer-serial-number (text(255))" as a Printer Status (read-only) attribute.
- Add a separate "printer-asset-tag (octetString(MAX) | no-value)" Printer Description (read-write) attribute to hold any site-specific asset tag/identifier.

We will have a separate discussion about the privacy implications of this and other Printer attributes that could be used as PII.

> On Dec 1, 2020, at 8:47 AM, Michael Sweet via ipp <[email-masked]> wrote:
> 
> Signed PGP part
> All,
> 

________________________
Michael Sweet