From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Thu Aug 17 2006 - 12:48:25 EDT
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
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
> -----Original Message-----
> From: Paul Tykodi [mailto:ptykodi@tykodi.com]
> Sent: Wednesday, August 16, 2006 8:06 PM
> To: ipp@pwg.org
> 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: ptykodi@tykodi.com
> WWW: http://www.tykodi.com
>
> > -----Original Message-----
> > From: owner-ipp@pwg.org [mailto:owner-ipp@pwg.org] On
> Behalf Of McDonald,
> > Ira
> > Sent: Monday, August 14, 2006 10:59 PM
> > To: 'ipp@pwg.org'
> > 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: 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
> >
>
-- 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
This archive was generated by hypermail 2.1.4 : Thu Aug 17 2006 - 12:48:45 EDT