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
*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 3:40 PM Kennedy, Smith (Wireless & IPP Standards) <
smith.kennedy at hp.com> 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
>>>> On Dec 1, 2020, at 12: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 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 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 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 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
>>>>>>>>>>>>>>>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20201201/1cde85b7/attachment.html>