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