PMP Mail Archive: RE: PMP> PortMon Mib question

PMP Mail Archive: RE: PMP> PortMon Mib question

RE: PMP> PortMon Mib question

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Tue Jun 28 2005 - 14:41:14 EDT

  • Next message: CommsAccounts: "Your Revenue Statement"

    Hi Ivan,

    Yes - I just realized that we need to say that every implementation
    of the MIB MUST include both MANUFACTURER (or MFG) and MODEL (or MDL)
    fields within the first 255 octets (the minimum legal string size
    for conformance in our new OBJECT clause in MODULE-COMPLIANCE macro),
    so that any intermediate gateway can't accidentally truncate these
    principal fields.

    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: Ivan Pavicevic [mailto:ivanp@windows.microsoft.com]
    > Sent: Tuesday, June 28, 2005 2:35 PM
    > To: McDonald, Ira; thrasher@lexmark.com; pmp@pwg.org
    > Subject: RE: PMP> PortMon Mib question
    >
    >
    > 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:41:13 EDT