Hi Mike,
Thanks.
So we wouldn't want to revise Port Monitor MIB to add a MUST NOT anyway.
Good.
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 Tue, Dec 1, 2020 at 6:32 PM Michael Sweet <msweet at msweet.org> 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).
>>> > On Dec 1, 2020, at 2:44 PM, Ira McDonald <blueroofmusic at gmail.com>
> wrote:
> >
> > 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
> >
> > 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: blueroofmusic at gmail.com> > (permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434
> >
> >
> > On Tue, Dec 1, 2020 at 2:06 PM Kennedy, Smith (Wireless & IPP Standards)
> <smith.kennedy at hp.com> 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"...
> >
> >> On Dec 1, 2020, at 10:13 AM, Ira McDonald <blueroofmusic at gmail.com>
> wrote:
> >>
> >> 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).
> >
> > 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?
> >
> >>
> >> Of course, we're deprecating IEEE 1284 Device ID entirely in IPP, so
> this is
> >> 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".
> >
> >>
> >> 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 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: blueroofmusic at gmail.com> >> (permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434
> >>
> >>
> >> On Tue, Dec 1, 2020 at 12:05 PM Michael Sweet <msweet at msweet.org>
> 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?!?
> >>
> >>
> >> > On Dec 1, 2020, at 11:44 AM, Ira McDonald <blueroofmusic at gmail.com>
> wrote:
> >> >
> >> > 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
> >> >
> >> > 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: blueroofmusic at gmail.com> >> > (permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434
> >> >
> >> >
> >> > On Tue, Dec 1, 2020 at 10:30 AM Michael Sweet via ipp <ipp at pwg.org>
> wrote:
> >> > Smith,
> >> >
> >> > > On Dec 1, 2020, at 8:59 AM, Kennedy, Smith (Wireless & IPP
> Standards) <smith.kennedy at hp.com> wrote:
> >> > >
> >> > > Hi Mike,
> >> > >
> >> > > No objections to adding this but a few thoughts:
> >> > >
> >> > > - PII concerns?
> >> >
> >> > 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
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > ipp mailing list
> >> > ipp at pwg.org> >> > https://www.pwg.org/mailman/listinfo/ipp> >>
> >> ________________________
> >> Michael Sweet
> >>
> >>
> >>
> >
>> ________________________
> Michael Sweet
>>>>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20201201/0ecba7e3/attachment.html>