IPP> Details on methods for IPP encoding of alerts

IPP> Details on methods for IPP encoding of alerts

IPP> Details on methods for IPP encoding of alerts

McDonald, Ira imcdonald at sharplabs.com
Sat Jul 29 19:56:19 EDT 2006


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 at 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
 



More information about the Ipp mailing list