Subject: RE: IPP> Revised PSX Problem Statement and Design Alternatives

From: "Whittle, Craig" <[email-masked]>
Date: Tue, 15 Aug 2006 14:24:01 -0700

All:

Please recall from our last teleconference call that PWG members with
interest in BMLinkS would "e-mail to their respective company
representatives in the BMLinkS community for feedback" on the approaches Ira
has listed below.

I am on vacation later this week and all of next week.  Our next
teleconference is tentatively scheduled for 8/31--please try and get
feedback before then.

Best regards,

**CW
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of McDonald,
Ira
Sent: Monday, August 14, 2006 7:59 PM
To: [email-masked]'
Subject: IPP> Revised PSX Problem Statement and Design Alternatives

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: [email-masked]

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

                            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

---

From: "McDonald, Ira" <[email-masked]>
Date: Thu, 17 Aug 2006 09:48:25 -0700

Hi Paul,

Yes.

MS Active Directory, Novell directory, BMLinkS Job and Device
Control, and a whole lot of other products will get the _only_
viable solution from the IPP PSX project.

More and more enterprise networks are disabling SNMP entirely,
for perfectly sound security reasons.

Meanwhile, the web services interfaces in network printers are
_all_ proprietary.

Cheers,
- Ira

> From: Paul Tykodi [mailto:[email-masked]]
> Sent: Wednesday, August 16, 2006 8:06 PM
> To: [email-masked]
> Cc: McDonald, Ira
> Subject: RE: IPP> Revised PSX Problem Statement and Design 
> Alternatives
> 
> 
> Dear Ira and IPP List,
> 
> Microsoft Active Directory has the capability to publish 
> certain information
> about printer capabilities. According to the following URL, 
> it seems that
> under certain conditions SNMP is utilized to extract some of 
> the information
> that will be stored in an Active Directory entry regarding a printer.
> 
> http://support.microsoft.com/kb/235925/en-us
> 
> Question: Do people believe that Ira's idea could be of 
> potential benefit to
> Microsoft's Active Directory support for printers when SNMP 
> is unavailable?
> 
> Thanks.
> 
> Best Regards,
> 
> /Paul
> --
> Paul Tykodi
> Principal Consultant
> TCS - Tykodi Consulting Services LLC
> 
> Tel/Fax: 603-343-1820
> Mobile:  603-866-0712
> E-mail:  [email-masked]
> WWW:     http://www.tykodi.com
> 
> > Sent: Monday, August 14, 2006 10:59 PM
> > To: [email-masked]'

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.11.1/421 - Release Date: 8/16/2006