IPP Mail Archive: IPP> Details on methods for IPP encoding of alerts

IPP> Details on methods for IPP encoding of alerts

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Sat Jul 29 2006 - 19:56:19 EDT

  • Next message: McDonald, Ira: "IPP> PSX> Reminder Thu 3 Aug 11am EDT - Next IPP WG teleconference"

    Hi folks, Saturday (29 July 2006)

    At our last IPP WG teleconference, we tentatively converged on methods
    (1) and (2) from my previous note (sent Wednesday 19 July) as the best
    candidates for encoding 'prtAlertTable' objects from the Printer MIB
    into IPP Printer attributes.

    As background for our next IPP WG teleconference (Thursday 3 August),
    below are more detailed examples and discussions of methods (1) and (2).

    Michael Sweet (CUPS) has argued convincingly that putting non-localized
    data into "printer-state-message (text(MAX))" is non-conformant and Ted
    Tronson (Novell) has concurred, so the IPP PSX spec must define one or
    more new IPP Printer attributes (otherwise generic subunit alerts would
    be meaningless).

    Note: A hybrid method (1+) below defines two new IPP attributes:

      "printer-alert (1setOf octetString(MAX))"
      "printer-alert-description (1setOf text(MAX))"

    The problem of IPP Printer and Printer MIB instances in different
    locales is still be present, but vendors who already place message key
    prefixes in 'prtAlertDescription' (for use by client software) can
    preserve that functionality.

    Cheers,
    - Ira (co-editor of PWG IPP Printer State Reasons Extensions)

    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

    ------------------------------------------------------------------------

    Method 1: Structured encoding in one attribute

    Compare:
      IPP Printer Installation Extension
        (ftp://ftp.pwg.org/pub/pwg/ipp/new_DRV/
          draft-ietf-ipp-install-04.txt)
      "client-print-support-files-supported (1setOf
        octetString(MAX))"

    IPP PSX Encoding:
      "printer-alert (1setOf octetString(MAX))"

    Example:
      printer-alert[1] =
        alert-code=jam;alert-index=22;alert-severity=critical
        ;alert-group=mediaPath;alert-group-index=4;alert-location=6
      printer-alert[2] =
        alert-code=coverOpen;alert-index=23;alert-severity=critical
        ;alert-group=cover;alert-group-index=6;alert-location=2

    Remarks:
      (1) Because the IPP datatype '1setOf' does NOT allow an empty array,
      an empty 'prtAlertTable' MUST be represented by a _missing_ IPP
      attribute "printer-alert" - an empty attribute would be illegal.

      (2) Because IPP Printer object and Printer MIB instances MAY be set to
      different current locales and 'prtAlertDescription' values MUST be
      server localized (i.e., are NOT machine-readable by client software),
      localized alert descriptions CANNOT be interoperably supported
      - but this is currently out-of-scope for the IPP PSX spec.

    ------------------------------------------------------------------------

    Method 1+: Structured encoding plus a paralllel description attribute

    Compare:
      See method (1) above and method (2) below

    IPP PSX Encoding:
      "printer-alert (1setOf octetString(MAX))"
      "printer-alert-description (1setOf text(MAX))"

    Example:
      printer-alert[1] =
        alert-code=jam;alert-index=22;alert-severity=critical
        ;alert-group=mediaPath;alert-group-index=4;alert-location=6
      printer-alert[2] =
        alert-code=coverOpen;alert-index=23;alert-severity=critical
        ;alert-group=cover;alert-group-index=6;alert-location=2
      printer-alert-description[1] =
        XL1400.MP0036 Critical alert - jam in duplex printing media path
      printer-alert-description[2] =
        XL1400.CV0042 Critical alert - top right front cover is open

    Remarks:
      (1) Because the IPP datatype '1setOf' does NOT allow an empty array,
      an empty 'prtAlertTable' MUST be represented by a _missing_ IPP
      attribute "printer-alert" - an empty attribute would be illegal.

      (2) The common practice of overloading 'prtAlertLocation' to contain a
      message key forces vendors to coordinate message catalogs across all
      models of network printers - not practical. The use of imbedded
      message keys in 'prtAlertDescription', on the other hand, allows
      vendors to decentralize message catalogs to product families or
      individual models - matching current product localization practice.

      (3) Because IPP Printer object and Printer MIB instances MAY be set to
      different current locales and 'prtAlertDescription' values MUST be
      server localized (i.e., are NOT machine-readable by client software),
      an implementation mechanism like imbedded message keys is still needed
      for an IPP Printer to convert the locale of alert descriptions without
      brute force message catalog searches.

    ------------------------------------------------------------------------

    Method 2: Parallel ordered multi-valued attributes

    Compare:
      From IPP/1.1 Model and Semantics
        (ftp://ftp.isi.edu/in-notes/
          rfc2911.txt)
      "printer-uri-supported (1setOf uri)"
      "uri-authentication-supported (1setOf type2 keyword)"
      "uri-security-supported (1setOf type2 keyword)

    IPP PSX Encoding:
      "printer-alert-code (1setOf keyword)" <or>
        "printer-alert-code (1setOf integer)" -- not human-readable

      "printer-alert-index (1setOf integer)" <or>
        "printer-alert-index (1setOf octetString(MAX))" -- not useful

      "printer-alert-severity (1setOf keyword)" <or>
        "printer-alert-severity (1setOf integer)" -- not human-readable

      "printer-alert-training (1setOf keyword)" <or>
        "printer-alert-training (1setOf integer)" -- not human-readable

      "printer-alert-group (1setOf keyword)" <or>
        "printer-alert-group (1setOf integer)" -- not human-readable

      "printer-alert-group-index (1setOf integer)" <or>
        "printer-alert-group-index (1setOf octetString(MAX))" -- not useful

      "printer-alert-location (1setOf integer)" <or>
        "printer-alert-location (1setOf octetString(MAX))" -- not useful

      "printer-alert-time (1setOf integer)" <or>
        "printer-alert-time (1setOf octetString(MAX))" -- not useful

    Example (using preferred encodings above):
      printer-alert-code[1] = jam
      printer-alert-code[2] = cover-open -- keyword transformed
      printer-alert-index[1] = 22
      printer-alert-index[2] = 23
      printer-alert-severity[1] = critical
      printer-alert-severity[2] = critical
      printer-alert-group[1] = media-path -- keyword transformed
      printer-alert-group[2] = cover
      printer-alert-group-index[1] = 4
      printer-alert-group-index[2] = 6
      printer-alert-location[1] = 6
      printer-alert-location[2] = 2

    Remarks:
      (1) Because the IPP datatype '1setOf' does NOT allow an empty array,
      an empty 'prtAlertTable' MUST be represented by _missing_ IPP
      attributes "printer-alert[...]" - empty attributes would be illegal.

      (2) Parallel '1setOf X' attributes (section 4.1.16 of RFC2911) are
      fragile for interoperability, because IPP/1.1 (page 90) states:

        "Sets are normally unordered. However each attribute
        description of this type may specify that the values
        MUST be in a certain order for that attribute."

      In practice, this means that a generic IPP parser MUST NOT
      be order-preserving, thus the inherent fragility.

      (3) The best (and human-readable) encoding of Printer MIB enumerations
      in method (2) as IPP datatype 'keyword' has two problems:
        (a) Forces cross-registration with IANA for the IPP and Printer MIB
            enumerations;
        (b) Forces keyword changes (insertion of hyphens and lowercase only)
            due to IPP datatype 'keyword' restrictions.

      (4) Using the IPP 'enum' datatype (section 4.1.4 of RFC 2911) is worse
      than using 'keyword', because the over-the-wire encoding is integer
      (and thus not human-readable) and the enumeration tags STILL must
      be transformed to fit the 'keyword' datatype restrictions - see (3).

      (5) Using the IPP datatype 'integer' for Printer MIB enumerations
      would avoid IANA cross-registration, but is NOT human-readable.

      (6) Using the IPP datatype 'octetString' for Printer MIB enumerations
      would avoid IANA cross-registration, but argues for method (1/1+).

    ------------------------------------------------------------------------

    -- 
    No virus found in this outgoing message.
    Checked by AVG Free Edition.
    Version: 7.1.394 / Virus Database: 268.10.5/403 - Release Date: 7/28/2006
     
    


    This archive was generated by hypermail 2.1.4 : Sat Jul 29 2006 - 19:56:47 EDT