From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Mon Aug 14 2006 - 22:59:22 EDT
Hi folks, Monday (14 August 2006)
Per my action item from the last IPP WG telecon, below is a revised
problem statement for IPP Printer State Reasons (PSX) project and a
short summary of our design alternatives.
Action - All - Please forward this note to your company's BMLinkS
representative for their feedback. The IPP PSX project developed from
a need first identified by the BMLinkS standards project in Japan.
Cheers,
- Ira (co-editor of IPP PSX spec)
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
------------------------------------------------------------------------
REQUEST FOR COMMENTS
The IEEE-ISTO PWG requests comments from BMLinkS consortium members on
the design alternatives summarized below. The PWG IPP Working Group is
at an effective standstill on the IPP Printer State Reasons Extensions
project until a concensus on the design alternatives is reached.
------------------------------------------------------------------------
PROBLEM STATEMENT
When deploying printers in enterprise networks, customers often disable
SNMPv1 (RFC 1157), based on local security policy - and secure SNMPv3
(RFC 3414) is not widely supported by current printers. Therefore,
alternative support for secure queries for printer device alerts is
required to manage, provision, and service these non-SNMP network
printers. IPP/1.1 (RFC 2911) can be securely deployed in enterprise
networks, using TLS/1.0 (RFC 2246) and HTTP/1.1 Upgrade (RFC 2817), so
an IPP solution to this requirement is attractive.
The IPP "printer-state-reasons" attribute was defined in IPP/1.1 (RFC
2911), but the mapping of printer device alerts from the 'prtAlertCode'
object defined in Printer MIB v1/v2 (RFC 1759/3805) was very sparse.
------------------------------------------------------------------------
DESIGN BACKGROUND
The draft IPP PSX spec overloaded the "printer-state-message (text)"
attribute for Printer MIB alert encoding. But Michael Sweet (CUPS) has
objected that storing non-localized data in "printer-state-message" is
non-conformant and Ted Tronson (Novell) has concurred, so the IPP PSX
spec _must_ define one or more _new_ IPP Printer attributes.
------------------------------------------------------------------------
DESIGN ALTERNATIVES
All missing values from the 'PrtAlertCodeTC' enumeration will be added
to IPP "printer-state-reasons" attribute - there is IPP WG unanimous
concensus on this decision.
But the Printer MIB v2 "generic alerts" (e.g., 'subunitAlmostEmpty') are
meaningless without more information from 'prtAlertTable' for context.
The design alternatives of a new IPP 'collection' attribute or a new
first-class IPP 'object' have already been rejected by the IPP WG.
Note: The IPP WG strongly prefers hybrid choice (3) described below.
(1) Structured string encoding in one new IPP attribute
Syntax:
"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
Pros:
P1a Avoids cross-registration between IANA Printer MIB enumerations
and IANA IPP Registry.
P1b Allows safe vendor extensions (with different keywords).
P1c Easy to specify in rigorous ABNF.
Cons:
C1a Cannot support encoding of 'prtAlertDescription' (localized
string, not keywords).
(2) IPP-centric encoding in a complete set of new IPP atributes
Syntax:
"printer-alert-code (1setOf keyword)"
"printer-alert-index (1setOf integer)"
"printer-alert-severity (1setOf keyword)"
"printer-alert-training (1setOf keyword)"
"printer-alert-group (1setOf keyword)"
"printer-alert-group-index (1setOf integer)"
"printer-alert-location (1setOf integer)"
"printer-alert-time (1setOf integer)"
"printer-alert-description (1setOf text(MAX))"
Example:
printer-alert-code[1] = jam
printer-alert-index[1] = 22
printer-alert-severity[1] = critical
printer-alert-group[1] = media-path -- keyword transformed
printer-alert-group-index[1] = 4
printer-alert-location[1] = 6
printer-alert-description[1] = Jam in duplex printing media path
Pros:
P2a Supports encoding of 'prtAlertDescription' (localized string,
not keywords).
Cons:
C2a Forces cross-registration between IANA Printer MIB enumerations
and IANA IPP Registry.
C2b Forces non-identity transforms of IANA Printer MIB enumerations
into IANA IPP Registry keywords (due to limited keyword syntax).
C2c Large set of parallel ordered attributes is fragile for generic
IPP parsers.
------------------------------------------------------------------------
(3) Hybrid - Structured encoding plus a parallel description attribute
Syntax:
"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-description[1] = Jam in duplex printing media path
Pros:
P3a See P1a, P1b, and P1c above.
P3b See P2a above.
P3c Avoids large set of parallel ordered attributes that would be
fragile for generic IPP parsers.
Cons:
None identified to date.
------------------------------------------------------------------------
-- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.10.10/418 - Release Date: 8/14/2006
This archive was generated by hypermail 2.1.4 : Mon Aug 14 2006 - 22:59:38 EDT