Regarding truncation our requirement is that the device Id has to have
MANUFACTURER (or MFG) and MODEL (or MDL) fields in order to be able to
calculate PnPId.
I'm fine with Ira's suggestion about having a plain OCTET STRING with
constrains we define.
Thanks,
Ivan
-----Original Message-----
From: pmp-owner@pwg.org [mailto:pmp-owner@pwg.org] On Behalf Of
McDonald, Ira
Sent: Tuesday, June 28, 2005 9:26 AM
To: 'thrasher@lexmark.com'; pmp@pwg.org
Subject: RE: PMP> PortMon Mib question
Hi Jerry,
I think we should change to 1023 octets for 'ppmPortIEEEDeviceID'
with normative 'intelligent truncation' rules (strip whole key/value
pairs) stated in the object and its OBJECT clause back in the
MODULE-COMPLIANCE macro.
Justification appears in the following note from the latest IETF
"Guidelines for Authors and Reviewers of MIB Documents", page 34:
"Note 2. DisplayString does not support internationalized text.
It MUST NOT be used for objects that are required to
hold internationalized text (which is always the case
if the object is intended for use by humans [RFC2277]).
Designers SHOULD consider using SnmpAdminString,
Utf8String, or LongUtf8String for such objects."
SnmpAdminString (which we have been using per Bert Wijnen) is defined
in the SNMP Framework MIB (RFC 3411), but is _limited_ to 255 octets.
LongUtf8String is defined in the System Application MIB (RFC2287)
and is limited to 1024 octets (but IPP/1.1 limits strings to 1023,
so for PWG Semantic Model coherence we should use 1023).
I don't like importing from RFC 2287. I suggest make this one object
plain ASN.1 'OCTET STRING' and constrain it in the DESCRIPTION clause
to UTF-8 (with max length 1023 octets and an OBJECT clause allowing
support for only 255 octets).
Comments?
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com
-----Original Message-----
From: pmp-owner@pwg.org [mailto:pmp-owner@pwg.org]On Behalf Of
thrasher@lexmark.com
Sent: Tuesday, June 28, 2005 11:33 AM
To: pmp@pwg.org
Subject: RE: PMP> PortMon Mib question
Ira,
A 1284 ID length of 1023 octets would probably encompass the vast
majority
of strings in use today, and
we(Lexmark) probably could live with 255 if that's what is decided,
however
we (PWG) would still need to explain the
truncation rules regardless of the length we decide (simple truncation
at
the final byte, or truncation at the last full key/value
pair before reaching the limit etc....).
JT
"McDonald, Ira" <imcdonald@sharplabs.com>
Sent by: pmp-owner@pwg.org
06/27/2005 11:23 PM
To: "'thrasher@lexmark.com'" <thrasher@lexmark.com>,
pmp@pwg.org
cc:
Subject: RE: PMP> PortMon Mib question
Hi Jerry,
The IETF SMIv2 and the IETF's best practices recommend that MIB string
objects longer
than 255 octets be avoided for interoperability reasons. There are some
instances in
some modern IETF MIBs of strings with max lengths of 1023 octets (and
conformance
statements allowing a short length such as 255 octets).
We could certainly make the IEEE Device ID string longer. Should we do
so?
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com
-----Original Message-----
From: pmp-owner@pwg.org [mailto:pmp-owner@pwg.org]On Behalf Of
thrasher@lexmark.com
Sent: Monday, June 27, 2005 9:05 PM
To: pmp@pwg.org
Subject: PMP> PortMon Mib question
Question/Issue from one of our dev's
For the variable ppmPortIEEE1284DeviceID, the MIB states:
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.
The definitition indicates that the size is 0-255. However, the actual
1284
device ID can be much longer.
I think the length field of the 1284 string is two bytes (and the length
includes the two bytes of length field).???
Jerry Thrasher
This archive was generated by hypermail 2b29 : Tue Jun 28 2005 - 14:34:58 EDT