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 at tykodi.com
WWW: http://www.tykodi.com
> -----Original Message-----
> From: owner-ipp at pwg.org [mailto:owner-ipp at pwg.org] On Behalf Of McDonald,
> Ira
> Sent: Monday, August 14, 2006 10:59 PM
> To: 'ipp at 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 at 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
>